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 3ed5f0bc3..3faedb3f6 100644 --- a/src/pentesting-cloud/aws-security/aws-basic-information/README.md +++ b/src/pentesting-cloud/aws-security/aws-basic-information/README.md @@ -26,8 +26,8 @@ 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 **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). +- 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 não poderão gerenciar a cobrança (mas podem receber acesso a ela). ``` aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com ``` @@ -42,11 +42,11 @@ 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, poderia 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, pode 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 negando `s3:GetObject` não impedirá as pessoas de **acessar um bucket S3 público** em sua conta. Exemplos de SCP: @@ -92,7 +92,7 @@ Note que existem 4 partições na AWS, mas apenas 3 maneiras de chamá-las: - AWS US public Internet (GovCloud): `aws-us-gov` - AWS Secret (US Classified): `aws` -## IAM - Identity and Access Management +## IAM - Gerenciamento de Identidade e Acesso IAM é o serviço que permitirá que você gerencie **Autenticação**, **Autorização** e **Controle de Acesso** dentro da sua conta AWS. @@ -104,7 +104,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**. @@ -126,15 +126,15 @@ Os usuários podem ter **MFA habilitado para login** através do console. Tokens Sempre que você precisar **mudar a Chave de Acesso**, este é o processo que você deve seguir:\ _Criar uma nova chave de acesso -> Aplicar a nova chave ao sistema/aplicação -> marcar a original como inativa -> Testar e verificar se a nova chave de acesso está funcionando -> Deletar a chave de acesso antiga_ -### MFA - Multi Factor Authentication +### 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 authentication 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: - Um usuário ou grupo IAM -- Um recurso como um bucket Amazon S3, fila Amazon SQS ou tópico Amazon SNS +- Um recurso como um bucket do Amazon S3, fila do Amazon SQS ou tópico do Amazon SNS - A política de confiança de um papel IAM que pode ser assumido por um usuário Se você quiser **acessar via CLI** um recurso que **verifica o MFA**, você precisa chamar **`GetSessionToken`**. Isso lhe dará um token com informações sobre o MFA.\ @@ -152,7 +152,7 @@ Você pode anexar uma **política baseada em identidade a um grupo de usuários* 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). @@ -181,7 +181,7 @@ São usadas para atribuir permissões. Existem 2 tipos: - 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 **uma única "Negar" existir, ela 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 "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). ```javascript { "Version": "2012-10-17", //Version of the policy @@ -210,17 +210,17 @@ Os [campos específicos que podem ser usados para condições por serviço estã #### Políticas Inline Esse tipo de políticas são **atribuídas diretamente** a um usuário, grupo ou função. Assim, elas não aparecem na lista de Políticas, pois qualquer outra pode usá-las.\ -Políticas inline são úteis se você deseja **manter uma relação estrita um-para-um entre uma política e a identidade** à qual ela é aplicada. Por exemplo, você quer ter certeza de que as permissões em uma política não são atribuídas inadvertidamente a uma identidade diferente daquela para a qual foram destinadas. Quando você usa uma política inline, as permissões na política não podem ser anexadas inadvertidamente à identidade errada. Além disso, quando você usa o AWS Management Console para excluir essa identidade, as políticas incorporadas na identidade também são excluídas. Isso ocorre porque elas fazem parte da entidade principal. +Políticas inline são úteis se você deseja **manter uma relação estrita de um-para-um entre uma política e a identidade** à qual ela é aplicada. Por exemplo, você quer ter certeza de que as permissões em uma política não são inadvertidamente atribuídas a uma identidade diferente daquela para a qual foram destinadas. Quando você usa uma política inline, as permissões na política não podem ser inadvertidamente anexadas à identidade errada. Além disso, quando você usa o AWS Management Console para excluir essa identidade, as políticas incorporadas na identidade também são excluídas. Isso ocorre porque elas fazem parte da entidade principal. #### Políticas de Bucket de Recursos Essas são **políticas** que podem ser definidas em **recursos**. **Nem todos os recursos da AWS as suportam**. -Se um principal não tiver uma negação explícita sobre elas, e uma política de recurso conceder acesso, então ele está autorizado. +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 do IAM -Os 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. +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**. 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. @@ -245,7 +245,7 @@ Portanto, se em algum momento você enfrentar o erro "... porque nenhuma políti ### 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 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. @@ -275,7 +275,7 @@ 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 elas têm as mesmas permissões**. +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**. ### Confianças e Funções entre Contas @@ -301,7 +301,7 @@ O aplicativo usa o AssumeRoleWithWebIdentity para criar credenciais temporárias ### Outras opções IAM - Você pode **definir uma configuração de política de senha** com opções como comprimento mínimo e requisitos de senha. -- Você pode **baixar o "Relatório de Credenciais"** com informações sobre credenciais atuais (como tempo de criação do usuário, se a senha está habilitada...). Você pode gerar um relatório de credenciais com a frequência de uma vez a cada **quatro horas**. +- Você pode **baixar o "Relatório de Credenciais"** com informações sobre credenciais atuais (como tempo de criação do usuário, se a senha está habilitada...). Você pode gerar um relatório de credenciais com frequência de até uma vez a cada **quatro horas**. O AWS Identity and Access Management (IAM) fornece **controle de acesso granular** em toda a AWS. Com o IAM, você pode especificar **quem pode acessar quais serviços e recursos**, e sob quais condições. Com as políticas IAM, você gerencia permissões para sua força de trabalho e sistemas para **garantir permissões de menor privilégio**. @@ -343,7 +343,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 a **aws cli**, o chamado **`[default]`** nesse arquivo será usado.\ +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.\ Exemplo de arquivo de credenciais com mais de 1 perfil: ``` [default] diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md index e4aa6ee8e..fe6e79961 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md @@ -28,7 +28,7 @@ iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md ### `iam:PassRole`, (`cloudformation:UpdateStack` | `cloudformation:SetStackPolicy`) -Neste caso, você pode **abusar de uma pilha de cloudformation existente** para atualizá-la e escalar privilégios como no cenário anterior: +Neste caso, você pode **abusar de uma pilha de cloudformation existente** para atualizá-la e escalar privilégios, como no cenário anterior: ```bash aws cloudformation update-stack \ --stack-name privesc \ @@ -53,7 +53,7 @@ A permissão `cloudformation:SetStackPolicy` pode ser usada para **dar a si mesm Um atacante com permissões para **passar um papel e criar & executar um ChangeSet** pode **criar/atualizar uma nova pilha do cloudformation e abusar dos papéis de serviço do cloudformation** assim como com o CreateStack ou UpdateStack. -A seguinte exploração é uma **variação do**[ **CreateStack one**](#iam-passrole-cloudformation-createstack) usando as **permissões ChangeSet** para criar uma pilha. +A seguinte exploração é uma **variação da**[ **CreateStack one**](#iam-passrole-cloudformation-createstack) usando as **permissões ChangeSet** para criar uma pilha. ```bash aws cloudformation create-change-set \ --stack-name privesc \ @@ -128,7 +128,7 @@ cdk-hnb659fds-lookup-role-- ``` ### Adicionando código malicioso ao código-fonte do projeto -Se você pode escrever no código-fonte do projeto, mas não pode implantá-lo você mesmo (por exemplo, o desenvolvedor implanta o código via CI/CD, não a máquina local), você ainda pode comprometer o ambiente adicionando recursos maliciosos à pilha. O seguinte adiciona um papel IAM que pode ser assumido por uma conta de atacante a um projeto python CDK. +Se você pode escrever no código-fonte do projeto, mas não pode implantá-lo você mesmo (por exemplo, o desenvolvedor implanta o código via CI/CD, não a máquina local), você ainda pode comprometer o ambiente adicionando recursos maliciosos à pilha. O seguinte adiciona uma função IAM que pode ser assumida por uma conta de atacante a um projeto python CDK. ```python class CdkTestStack(Stack): def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None: