Pesquisadores em cibersegurança divulgaram uma falha de segurança que impacta o Kit de Desenvolvimento em Nuvem (CDK) da Amazon Web Services (AWS) que poderia resultar em uma tomada de conta sob circunstâncias específicas.

“O impacto deste problema poderia, em certos cenários, permitir que um invasor obtivesse acesso administrativo a uma conta AWS alvo, resultando em uma tomada de conta completa.”

Após a divulgação responsável em 27 de junho de 2024, o problema foi abordado pelos mantenedores do projeto na versão 2.149.0 do CDK lançada em julho.

O CDK da AWS é um framework de desenvolvimento de software de código aberto para definir recursos de aplicação em nuvem usando Python, TypeScript ou JavaScript e provisioná-los via CloudFormation.

O problema identificado se baseia em descobertas anteriores sobre recursos sombra na AWS, e como convenções de nomenclatura pré-definidas para buckets do AWS Simple Storage Service (S3) poderiam ser usadas para orquestrar ataques do tipo Bucket Monopoly e acessar dados sensíveis.

Preparar um ambiente AWS para uso com o Kit de Desenvolvimento em Nuvem da AWS (AWS CDK) é realizado por meio de um processo chamado bootstrapping, onde certos recursos AWS são provisionados para o ambiente. Isso inclui um bucket S3 da AWS, um repositório do Amazon Elastic Container Registry (Amazon ECR) e funções do AWS Identity and Access Management (IAM).

“Os recursos e suas configurações que são usados pelo CDK são definidos em um modelo do AWS CloudFormation”, de acordo com a documentação da AWS.

Algumas das funções IAM criadas como parte do processo de bootstrapping concedem permissão para enviar e excluir ativos do bucket S3 associado, bem como realizar implantações de pilhas com acesso administrativo.

A estrutura de nomenclatura das funções IAM criadas pelo AWS CDK segue a estrutura “cdk-{Qualifier}-{Description}-{Account-ID}-{Region},” onde cada um dos campos é explicado abaixo:

• Qualifier, um valor de string único de nove caracteres que por padrão é “hnb659fds”, embora possa ser personalizado durante a fase de bootstrapping
• Description, descrição do recurso (ex: cfn-exec-role)
• Account-ID, ID da conta AWS do ambiente
• Region, região AWS do ambiente

De maneira semelhante, o bucket S3 criado durante o bootstrapping segue o padrão de nomenclatura “cdk-{Qualifier}-assets-{Account-ID}-{Region}.”.

“Como muitos usuários executam o comando cdk bootstrap sem personalizar o qualificador, o padrão de nomenclatura do bucket de preparação torna-se previsível.”

Com milhares de instâncias descobertas no GitHub onde o qualificador padrão é usado, isso também significa que adivinhar o nome do bucket é tão simples quanto encontrar o ID da conta AWS e a região para a qual o CDK é implantado.

Combinando este aspecto com o fato de que os nomes dos buckets S3 são globalmente únicos em todas as contas AWS, a brecha abre a porta para o que é chamado de S3 Bucket Namesquatting, permitindo que um invasor reivindique o bucket CDK de outro usuário se ele ainda não existir.

Isso poderia então pavimentar o caminho para uma negação parcial de serviço (DoS) quando um usuário tenta inicializar o CDK com o mesmo ID da conta e região, um cenário que poderia ser resolvido especificando um qualificador personalizado durante o bootstrapping.

Uma consequência mais séria poderia ocorrer se o CDK da vítima tiver permissão para ler e gravar dados do e para o bucket S3 controlado pelo invasor, tornando possível interferir em modelos do CloudFormation e executar ações maliciosas dentro da conta AWS da vítima.

“O papel de implantação do serviço CloudFormation, que é o papel CloudFormationExecutionRole no CDK, possui privilégios administrativos dentro da conta por padrão.”

“Isso significa que qualquer modelo CloudFormation escrito no bucket S3 do invasor pelo CDK da vítima seria implantado posteriormente com privilégios administrativos na conta da vítima.”

Em um ataque hipotético, se um usuário tivesse iniciado o processo de bootstrapping do CDK no passado e posteriormente excluído o bucket S3 devido a limites de cota, um adversário poderia aproveitar a situação para criar um bucket com o mesmo nome.

Isso poderia então fazer com que o CDK confiasse implicitamente no bucket malicioso e lesse/gravasse modelos do CloudFormation nele, tornando-os suscetíveis à exploração. No entanto, para que isso tenha sucesso, espera-se que o invasor cumpra os seguintes pré-requisitos:

• Reivindicar o bucket com o nome previsível e permitir acesso público.
• Criar uma função Lambda que injetará um papel de administrador malicioso ou uma porta dos fundos em um dado arquivo de modelo do CloudFormation sempre que for enviado para o bucket.

Na etapa final, quando o usuário implantar o CDK usando “cdk deploy”, não apenas o processo envia o modelo para o bucket replicado, mas também injeta um papel de administrador que o invasor pode assumir para, em última análise, ganhar controle da conta da vítima.

Em outras palavras, a cadeia de ataque facilita a criação de um papel de administrador em uma conta AWS alvo quando um bucket S3 do CDK configurado durante o processo de bootstrapping é excluído e o CDK é usado novamente.

A correção implementada pela AWS garante que os ativos sejam carregados apenas em buckets dentro da conta do usuário para evitar que o CDK envie dados para buckets não pertencentes à conta que iniciou o bootstrapping. A empresa também instou os clientes a usar um qualificador personalizado em vez do padrão “hnb659fds.”

Dito isso, é necessária ação do usuário se o bootstrapping foi realizado usando a versão v2.148.1 do CDK ou anterior, o que exige que atualizem o CDK para a versão mais recente e reexecução do comando de bootstrapping.

As descobertas mais uma vez chamam a atenção para a importância de manter os IDs de conta AWS em segredo, definir uma política IAM restrita e evitar dar nomes previsíveis aos buckets S3.

“Em vez disso, gere hashes únicos ou identificadores aleatórios por região e conta, e os incorpore nos nomes dos seus buckets S3.”

Quais as etapas para realizar o bootstrapping seguro do AWS CDK?

Para realizar o bootstrapping seguro do AWS Cloud Development Kit (AWS CDK), são necessárias várias etapas e considerações de segurança. Neste artigo, abordaremos os principais passos e melhores práticas para garantir que sua implementação do CDK seja robusta e segura, minimizando o risco de vulnerabilidades.

1. Personalize o Qualificador do Bucket S3

Evite usar o qualificador padrão “hnb659fds” para o nome do bucket S3, pois isso torna o nome do bucket previsível e vulnerável a ataques de S3 Bucket Namesquatting. Use um qualificador personalizado para evitar essa vulnerabilidade.

2. Use Políticas de IAM Restritivas

As funções IAM criadas durante o bootstrapping, como a CloudFormationExecutionRole, possuem privilégios administrativos por padrão. Para seguir o princípio do menor privilégio, crie políticas de IAM personalizadas e atribua-as a essas funções. Isso ajudará a limitar as permissões concedidas durante as implantações.

3. Configure Chaves de Criptografia Personalizadas

Use chaves de criptografia gerenciadas pelo cliente (CMKs) para o bucket S3 em vez das chaves gerenciadas pela AWS. Isso pode ser feito usando a opção --bootstrap-bucket-encryption do comando cdk bootstrap.

4. Habilitar Proteção Contra Exclusão

Habilite a proteção contra exclusão para o stack de bootstrapping para evitar que os recursos provisionados sejam excluídos acidentalmente. Use a opção --termination-protection do comando cdk bootstrap.

5. Restringir Acessos

Restringir quem pode assumir as funções de implantação e lookup. Use a opção --trust e --trust-for-lookup para especificar as contas AWS que podem deployar ou buscar informações no ambiente bootstrapped.

6. Manter o CDK Atualizado

Certifique-se de que o AWS CDK esteja atualizado para a versão mais recente, especialmente se você estava usando a versão v2.148.1 ou anterior, que era vulnerável a um ataque específico. A atualização para a versão 2.149.0 ou posterior resolve essa vulnerabilidade.

7. Implementar Guardrails e Políticas de Segurança

Use serviços como AWS Control Tower, AWS Config, AWS CloudTrail, e AWS Security Hub para implementar guardrails, regras de conformidade, auditoria e monitoramento. Aplique políticas de IAM e limites de permissões para prevenir bypass de mecanismos de segurança existentes.

Exemplo de Comando de Bootstrapping Seguro

ACCOUNT_ID=$(aws sts get-caller-identity --query "Account" --output text)
cdk bootstrap aws://$ACCOUNT_ID/example-Region \
  --bootstrap-bucket-name my-custom-bucket-name \
  --cloudformation-execution-policies "arn:aws:iam::$ACCOUNT_ID:policy/my-custom-execution-policy" \
  --termination-protection

Este comando personaliza o nome do bucket, usa uma política de execução personalizada e habilita a proteção contra exclusão.

Fontes de Pesquisa

• AWS CDK Bootstrap Template for Custom Bootstrapping
• AWS Cloud Development Kit Vulnerability Exposes Users to Account Takeovers
• AWS CDK Bootstrapping
• AWS CDK Security Best Practices
• Customize AWS CDK Bootstrapping

Conclusão

Realizar o bootstrapping seguro do AWS CDK é fundamental para garantir a segurança de suas aplicações na nuvem. Seguindo as etapas descritas acima, você pode mitigar riscos de vulnerabilidades e garantir que o acesso aos recursos seja controlado de forma eficaz. A implementação de políticas restritivas, a personalização de recursos e a manutenção da atualização do CDK são práticas essenciais para um ambiente seguro e eficiente.
Fonte

#AWS, #CDK, #segurança, #vulnerabilidade, #S3, #acesso, #admin, #cryptoalch