Português - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - Basic Information

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

Hierarquia da Organização

Contas

Na AWS, há uma conta raiz, que é o contêiner pai para todas as contas da sua organização. No entanto, você não precisa usar essa conta para implantar recursos, você pode criar outras contas para separar diferentes infraestruturas AWS entre elas.

Isso é muito interessante do ponto de vista da segurança, pois uma conta não poderá acessar recursos de outra conta (exceto se pontes forem criadas especificamente), dessa forma 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 de membro.

  • A conta de gerenciamento (a conta raiz) é a conta que você usa para criar a organização. A partir da conta de gerenciamento da organização, você pode fazer o seguinte:

  • Criar contas na organização

  • Convidar outras contas existentes para a organização

  • Remover contas da organização

  • Gerenciar convites

  • Aplicar políticas a entidades (raízes, OUs ou contas) dentro da organização

  • Habilitar a integração com serviços AWS suportados para fornecer funcionalidade de serviço em todas as contas da organização.

  • É possível fazer login como usuário raiz usando o e-mail e a senha usados para criar esta conta raiz/organização.

A conta de gerenciamento tem as responsabilidades de uma conta pagadora e é responsável por pagar todas as cobranças acumuladas pelas contas de membro. Você não pode alterar a conta de gerenciamento de uma organização.

  • As contas de membro 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 de membro 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 ela).

aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

Unidades de Organização

As 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.

# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

Política de Controle de Serviço (SCP)

Uma política de controle de serviço (SCP) é uma política que especifica os serviços e ações que os usuários e funções podem usar nas contas que o SCP afeta. SCPs são semelhantes às políticas de permissões IAM, exceto que não concedem permissões. Em vez disso, SCPs especificam as permissões máximas para uma organização, unidade organizacional (OU) ou conta. Quando você anexa um SCP à raiz da sua organização ou a uma OU, o SCP limita as permissões para entidades em contas membros.

Esta é a ÚNICA maneira de impedir até mesmo o usuário raiz de fazer algo. Por exemplo, poderia ser usado para impedir que os usuários desativem o CloudTrail ou excluam backups. A única maneira de contornar isso é comprometer também a conta mestra que configura os SCPs (a conta mestra não pode ser bloqueada).

Observe que SCPs apenas restringem os princípios na conta, então outras contas não são afetadas. Isso significa que ter um SCP negando s3:GetObject não impedirá as pessoas de acessar um bucket S3 público em sua conta.

Exemplos de SCP:

  • Negar completamente a conta raiz

  • Permitir apenas regiões específicas

  • Permitir apenas serviços em lista branca

  • Negar que GuardDuty, CloudTrail e Acesso Público ao Bloqueio do S3 sejam desativados

  • Negar que funções de segurança/resposta a incidentes sejam excluídas ou modificadas

  • Negar a exclusão de backups

  • Negar a criação de usuários IAM e chaves de acesso

Encontre exemplos em JSON em https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html

ARN

Amazon Resource Name é o nome único que cada recurso dentro da AWS possui, é composto assim:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

Observe que existem 4 partições na AWS, mas apenas 3 maneiras de chamá-las:

  • AWS Padrão: aws

  • AWS China: aws-cn

  • AWS US Internet Público (GovCloud): aws-us-gov

  • AWS Secret (Classificado dos EUA): aws

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.

  • Autenticação - Processo de definir uma identidade e a verificação dessa identidade. Esse processo pode ser subdividido em: Identificação e verificação.

  • Autorização - Determina o que uma identidade pode acessar dentro de um sistema uma vez que foi autenticada nele.

  • Controle de Acesso - O método e processo de como o acesso é concedido a um recurso seguro.

IAM pode ser definido por sua capacidade de gerenciar, controlar e governar mecanismos de autenticação, autorização e controle de acesso de identidades aos seus recursos dentro da sua conta AWS.

Usuário raiz da conta AWS

Quando você cria uma conta Amazon Web Services (AWS), 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 raiz da conta AWS e é acessado fazendo login com o endereço de e-mail e senha que você usou para criar a conta.

Observe que um novo usuário administrador terá menos permissões que o usuário raiz.

Do ponto de vista da segurança, é recomendado criar outros usuários e evitar usar este.

Usuários IAM

Um usuário IAM é uma entidade que você cria na AWS para representar a pessoa ou aplicativo que o utiliza para interagir com a AWS. Um usuário na AWS consiste em um nome e credenciais (senha e até duas chaves de acesso).

Ao criar um usuário IAM, você concede a ele permissões tornando-o um membro de um grupo de usuários que possui políticas de permissão apropriadas anexadas (recomendado), ou anexando políticas diretamente ao usuário.

Os usuários podem ter MFA ativado para fazer login através do console. Tokens de API de usuários com MFA ativado não são protegidos por MFA. Se você deseja restringir o acesso das chaves de API de um usuário usando MFA, você precisa indicar na política que para realizar certas ações o MFA precisa estar presente (exemplo aqui).

CLI

  • ID da Chave de Acesso: 20 caracteres alfanuméricos maiúsculos aleatórios como AKHDNAPO86BSHKDIRYT

  • ID da Chave de Acesso Secreta: 40 caracteres aleatórios maiúsculos e minúsculos: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Não é possível recuperar IDs de chaves de acesso secretas perdidas).

Sempre que precisar alterar a Chave de Acesso, este é o processo que você deve seguir: Criar uma nova chave de acesso -> Aplicar a nova chave ao sistema/aplicativo -> marcar a original como inativa -> Testar e verificar se a nova chave de acesso está funcionando -> Excluir a chave antiga

MFA - Autenticação Multifator

É usado para criar um fator adicional para autenticação além dos seus métodos existentes, como senha, portanto, criando um nível de autenticação multifator. 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

  • A política de confiança de uma função IAM que pode ser assumida por um usuário

Se você deseja acessar via CLI um recurso que verifica o MFA, você precisa chamar GetSessionToken. Isso lhe dará um token com informações sobre o MFA. Observe que as credenciais de AssumeRole não contêm essa informação.

aws sts get-session-token --serial-number <arn_device> --token-code <code>

Conforme declarado aqui, existem muitos casos diferentes em que MFA não pode ser usado.

Grupos de usuários IAM

Um grupo de usuários 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 fazer 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 os grupos se relacionam com permissões, não autenticação, e os princípios são entidades IAM autenticadas.

Aqui estão algumas características importantes dos grupos de usuários:

  • Um grupo de usuários pode conter 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 da AWS. Se você deseja 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 da 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 do IAM e AWS STS.

Funções IAM

Uma função IAM é muito semelhante a um usuário, no sentido de que é uma identidade com políticas de permissão que determinam o que ela pode e não pode fazer na AWS. No entanto, uma função não possui credenciais (senha ou chaves de acesso) associadas a ela. Em vez de ser exclusivamente associada a uma pessoa, uma função destina-se a ser assumida por qualquer pessoa que precise dela (e tenha permissões suficientes). Um usuário IAM pode assumir uma função temporariamente para adquirir permissões diferentes para uma tarefa específica. Uma função pode ser atribuída a um usuário federado que faz login usando um provedor de identidade externo em vez do 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 ela pode acessar.

Serviço de Token de Segurança da AWS (STS)

O Serviço de Token de Segurança da AWS (STS) é um serviço da web que facilita a emissão de credenciais temporárias com privilégios limitados. É especificamente projetado para:

Credenciais temporárias no IAM

Credenciais temporárias são usadas principalmente com funções IAM, mas também têm outros usos. Você pode solicitar credenciais temporárias que tenham um conjunto de permissões mais restrito do que o seu usuário IAM padrão. Isso impede que você execute acidentalmente tarefas não permitidas pelas credenciais mais restritas. Uma vantagem das credenciais temporárias é que elas expiram automaticamente após um período de tempo determinado. Você tem controle sobre a duração em que as credenciais são válidas.

Políticas

Permissões de Política

São usadas para atribuir permissões. Existem 2 tipos:

  • Políticas gerenciadas pela AWS (preconfiguradas 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..

Por padrão, o acesso é negado, o acesso será concedido se uma função explícita tiver sido especificada. Se existir um único "Negar", ele substituirá o "Permitir", exceto para solicitações que usam as credenciais de segurança raiz da conta da AWS (que são permitidas por padrão).

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

Os campos globais que podem ser usados para condições em qualquer serviço são documentados aqui. Os campos específicos que podem ser usados para condições por serviço são documentados aqui.

Políticas Inline

Este tipo de políticas são atribuídas diretamente a um usuário, grupo ou função. Então, elas não aparecem na lista de Políticas como qualquer outra que pode ser usada. As 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ê deseja garantir que as permissões em uma política não sejam 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 Console de Gerenciamento da AWS 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

Estas 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 eles e uma política de recurso conceder acesso a eles, então eles são permitidos.

Limites do IAM

Os limites do IAM podem ser usados para limitar as permissões a 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 só pode ler buckets S3, 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 para que os usuários não tenham mais permissões do que as necessárias.

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 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 as 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 no caso de a sessão ser comprometida.

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

Observe que por padrão a AWS pode adicionar políticas de sessão às sessões que serão geradas por terceiros. Por exemplo, em funções assumidas do Cognito não autenticadas por padrão (usando autenticação aprimorada), a AWS irá gerar credenciais de sessão com uma política de sessão que limita os serviços aos quais a sessão pode acessar para a seguinte lista.

Portanto, se em algum momento você se deparar com o erro "... porque nenhuma política de sessão permite o...", e a função tem acesso para realizar a ação, é porque existe 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 externos à AWS acessem recursos da AWS de forma segura sem precisar fornecer credenciais de usuário da AWS de uma conta de usuário IAM válida. Um exemplo de provedor de identidade pode ser seu próprio Active Directory da Microsoft (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 irá 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.

No entanto, geralmente você desejará atribuir uma função diferente dependendo do grupo do usuário na plataforma de terceiros. Em seguida, várias funções IAM podem confiar no Provedor de Identidade de terceiros e a plataforma de terceiros será a responsável por permitir que os usuários assumam uma função ou outra.

Centro de Identidade IAM

O Centro de Identidade IAM da AWS (sucessor do AWS Single Sign-On) expande as capacidades do AWS Identity and Access Management (IAM) para fornecer um local central que reúne a administração de usuários e seu acesso às contas da AWS e aplicativos em nuvem.

O domínio de login será algo como <user_input>.awsapps.com.

Para fazer login de usuários, existem 3 fontes de identidade que podem ser usadas:

  • Diretório do Centro de Identidade: Usuários regulares da AWS

  • Active Directory: Suporta diferentes conectores

  • Provedor de Identidade Externo: Todos os usuários e grupos vêm de um Provedor de Identidade externo (IdP)

No caso mais simples do diretório do Centro de Identidade, o Centro de Identidade terá uma lista de usuários e grupos e poderá atribuir políticas a eles para qualquer uma das contas da organização.

Para conceder acesso a um usuário/grupo do Centro de Identidade a uma conta, um Provedor de Identidade SAML confiando no Centro de Identidade será criado, e uma função confiando no Provedor de Identidade com as políticas indicadas será criada na conta de destino.

AwsSSOInlinePolicy

É possível dar permissões via políticas inline para funções criadas via Centro de Identidade IAM. As funções criadas nas contas que recebem políticas inline no Centro de Identidade IAM 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, não significa que elas tenham as mesmas permissões.

Confianças e Funções entre Contas

Um usuário (confiante) 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 acesso indicado nas políticas da nova função. Para criar isso, basta criar uma nova Função e selecionar Função entre Contas. As Funções para Acesso entre Contas oferecem duas opções. Fornecer acesso entre contas da AWS que você possui e fornecer acesso entre uma conta que você possui e uma conta da AWS de terceiros. É recomendável 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

Não suportado:

  • Relações de Confiança

  • Centro de Administração do AD

  • Suporte total à API do PS

  • Lixeira de Reciclagem do AD

  • Contas de Serviço Gerenciadas em Grupo

  • Extensões de Esquema

  • Sem acesso direto ao SO ou Instâncias

Federação Web ou Autenticação OpenID

O aplicativo usa o AssumeRoleWithWebIdentity para criar credenciais temporárias. No entanto, isso não concede acesso ao console da AWS, apenas acesso a recursos dentro da AWS.

Outras opções do IAM

  • Você pode definir uma 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 as credenciais atuais (como horário de criação do usuário, se a senha está habilitada...). Você pode gerar um relatório de credenciais com uma frequência de até uma vez a cada quatro horas.

O AWS Identity and Access Management (IAM) fornece controle de acesso refinado em toda a AWS. Com o IAM, você pode especificar quem pode acessar quais serviços e recursos, e em quais condições. Com políticas do IAM, você gerencia permissões para sua força de trabalho e sistemas para garantir permissões de privilégio mínimo.

Prefixos de ID do IAM

Na esta página você pode encontrar os prefixos de ID do IAM de chaves dependendo de sua natureza:

ABIA

Token de portador de serviço AWS STS

ACCA

Credencial específica do contexto

AGPA

Grupo de usuários

AIDA

Usuário IAM

AIPA

Perfil de instância Amazon EC2

AKIA

Chave de acesso

ANPA

Política gerenciada

ANVA

Versão em uma política gerenciada

APKA

Chave pública

AROA

Função

ASCA

Certificado

ASIA

IDs de chaves de acesso temporário (AWS STS) usam este prefixo, mas são únicos apenas em combinação com a chave de acesso secreta e o token de sessão.

Permissões recomendadas para auditar contas

Os seguintes privilégios concedem vários acessos de leitura de metadados:

  • arn:aws:iam::aws:policy/SecurityAudit

  • arn:aws:iam::aws:policy/job-function/ViewOnlyAccess

  • codebuild:ListProjects

  • config:Describe*

  • cloudformation:ListStacks

  • logs:DescribeMetricFilters

  • directconnect:DescribeConnections

  • dynamodb:ListTables

Diversos

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. Exemplo de arquivo de credenciais com mais de 1 perfil:

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2

Se precisar acessar diferentes contas da AWS e seu perfil tiver acesso para assumir uma função dentro dessas contas, não é necessário chamar manualmente o STS toda vez (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) e configurar as credenciais.

Você pode usar o arquivo ~/.aws/config para indicar quais funções assumir, e então usar o parâmetro --profile como de costume (a assume-role será realizada de forma transparente para o usuário). Um exemplo de arquivo de configuração:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

Com este arquivo de configuração, você pode então usar aws cli assim:

aws --profile acc2 ...

Se estiver procurando algo similar a isso, mas para o navegador, você pode verificar a extensão AWS Extend Switch Roles.

Referências

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

AnteriorAWS PentestingSiguienteAWS - Federation Abuse

Última actualización