Vulnerabilidade na AWS: usuários correm risco de sofrer ataques de apropriação de conta

De acordo com relatórios recentes, pesquisadores de segurança cibernética descobriram recentemente uma vulnerabilidade na AWS no Cloud Development Kit (CDK). Se explorada, essa vulnerabilidade poderia resultar em ataques de apropriação de conta em determinados cenários. Neste artigo, vamos nos aprofundar nos detalhes de uma possível exploração, na descoberta inicial e muito mais. Vamos começar! 

Vulnerabilidade na AWS: Descoberta inicial e detalhes

O CDK da Amazon Web Services (AWS) é uma estrutura de desenvolvimento de software de código aberto utilizada para definir recursos de aplicativos por meio de linguagens de programação, utilizando o CloudFormation. As linguagens de programação utilizadas incluem:  

• Python.
• TypeScript.
• JavaScript. 

Antes de entrarmos em mais detalhes, vale ressaltar que o problema foi identificado pela Aqua, uma empresa de segurança em nuvem, com base em suas descobertas anteriores. Essas descobertas detalhavam a existência de recursos ocultos na AWS. Além disso, elas também revelaram como as convenções de nomenclatura predefinidas para buckets do AWS Simple Storage Service (S3) podem ser exploradas para fins maliciosos. 

A ocorrência desse cenário permitiria que agentes mal-intencionados orquestrassem ataques do tipo “Bucket Monopoly” e, caso fossem bem-sucedidos, tais ataques ajudariam a obter acesso a informações confidenciais. No que diz respeito à vulnerabilidade da AWS no CDK, é importante saber que tais ambientes podem ser criados por meio do bootstrapping.

Durante o processo de inicialização, vários recursos da AWS são provisionados no ambiente. Esses recursos incluem:  

• Um bucket do AWS S3.
• Repositório do Amazon Elastic Container Registry (Amazon ECR).
• Funções do AWS Identity and Access Management (IAM).

Risco de segurança relacionado à nomenclatura de buckets do S3 

Para compreender plenamente a vulnerabilidade da AWS, é preciso saber que algumas das funções do IAM criadas como parte do processo de inicialização concedem diferentes tipos de permissão. Essas permissões incluem o upload e a exclusão de ativos associados aos buckets do S3.

Assim como as equipes precisam ficar atentasàs vulnerabilidades do Kubernetes emseus clusters, você também precisa se proteger contra nomes previsíveis de buckets do S3. Além disso, isso também pode incluir a implantação de uma pilha de permissões com acesso administrativo. 

Especialistas em segurança cibernética afirmaram que o padrão de nomenclatura das funções de IAM criadas pelo AWS CDK segue a mesma estrutura:

“cdk-{Qualificador}-{Descrição}-{ID da conta}-{Região}”

Os detalhes de cada campo dessa estrutura são apresentados a seguir:  

Além disso, o bucket do S3 criado durante o processo de inicialização segue o padrão de nomenclatura:

“cdk-{Qualificador}-assets-{ID da conta}-{Região}.”

Apresentando mais informações sobre essa vulnerabilidade da AWS, a Aqua afirmou que:  

“Como muitos usuários executam o comando `cdk bootstrap` sem personalizar o qualificador, o padrão de nomenclatura do bucket S3 de teste torna-se previsível. Isso ocorre porque o valor padrão para o qualificador do nome do bucket é definido como ‘hnb659fds’, o que facilita a previsão do nome do bucket.”

Como demonstraram as vulnerabilidades da NVIDIA em drivers populares de GPU, os invasores exploram qualquer padrão previsível; assim, também neste caso, os agentes mal-intencionados podem automatizar o “bucket-sniping” em grande escala.

Vale ressaltar que várias instâncias descobertas no GitHub estavam usando o qualificador padrão. Para os agentes mal-intencionados, isso significa que adivinhar o nome de um bucket é tão simples quanto determinar o ID da conta da AWS e a região na qual o CDK está implantado. 

Esta vulnerabilidade da AWS permite que agentes mal-intencionados realizem a apropriação indevida de nomes de buckets do S3. Essa técnica, também conhecida como “bucket sniping”, garante que os hackers consigam explorar com sucesso a vulnerabilidade da AWS , já que lhes permite se apropriar do bucket CDK de outro usuário.

Consequências da vulnerabilidade da AWS exploração

No que diz respeito às consequências de uma possível exploração, essa vulnerabilidade da AWS abre caminho para uma ataque de negação de serviço (DoS). Isso ocorre quando um usuário tenta inicializar o CDK com o mesmo ID de conta e a mesma região. 

A gravidade das consequências da vulnerabilidade da AWS aumenta quando o CDK comprometido tem permissão para ler e gravar dados no bucket do S3 controlado pelo invasor.

Tais privilégios permitiriam que um agente mal-intencionado adulterasse os modelos do CloudFormation. Isso significaria que hackers poderiam realizar ações maliciosas dentro da conta comprometida. Ao se referirem aos modelos do CloudFormation, os especialistas afirmaram que:  

“A função de implantação do serviço CloudFormation, que corresponde à função CloudFormationExecutionRole no CDK, possui privilégios administrativos na conta por padrão. Isso significa que qualquer modelo do CloudFormation gravado no bucket S3 do invasor pelo CDK da vítima seria implantado posteriormente com privilégios administrativos na conta da vítima. Isso permitiria ao invasor criar recursos com privilégios.”

Cadeia de ataques à vulnerabilidade de apropriação de conta na AWS 

No que diz respeito à cadeia de ataque para essa vulnerabilidade da AWS , o agente mal-intencionado precisaria criar um bucket com um nome que coincidisse com o de um já existente. Para isso, os usuários teriam que iniciar o processo de inicialização do CDK e, posteriormente, excluir o bucket do S3. Esse seria o recurso utilizado para iniciar a exploração da vulnerabilidade da AWS . 

A criação de um bucket duplicado faria com que o CDK o reconhecesse como legítimo, garantindo que agentes mal-intencionados pudessem ter modelos do CloudFormation gravados nele. No entanto, há certos pré-requisitos que um hacker precisa cumprir para que isso seja bem-sucedido. Entre eles estão:  

• • Reivindicar o bucket com o nome previsível e permitir o acesso público

• Criação de uma função Lambda para injetar uma função de administrador maliciosa ou um backdoor em um determinado arquivo de modelo do CloudFormation. 

Assim que todas essas condições forem atendidas, a vulnerabilidade da AWS pode assumir o controle total da conta visada. No entanto, para que isso aconteça, o usuário deve fazer a implantação do CDK usando “cdk deploy”. Isso enviaria o modelo para o bucket duplicado que foi criado pelo hacker durante a fase inicial do ataque. 

Além disso, também injetaria uma função de administrador usada para obter controle. Vale ressaltar que a função de administrador seria injetada por meio da função Lambda do invasor. Essa função criaria uma porta dos fundos no arquivo de modelo do CloudFormation, escrito pelo CKD da vítima, no bucket do S3 comprometido. 

Assim que essa sequência de eventos for concluída, a conta da vítima irá ler e implantar recursos do bucket do invasor, permitindo que o hacker crie uma nova função de administrador. Ao fornecerem informações sobre essa metodologia de ataque, especialistas em segurança cibernética afirmaram que: 

“Conseguimos criar uma função de administrador em uma conta de destino caso alguém exclua o bucket S3 de teste do CDK criado durante o processo de inicialização e, em seguida, tente usar o CDK novamente. No entanto, devemos levar em conta a possibilidade de alguém excluir o bucket S3 do CDK após a conclusão do processo de inicialização.”

Protocolos de segurança para mitigação de riscos 

Considerando as possíveis consequências dessa vulnerabilidade da AWS ser explorada, é importante conhecer medidas de segurança que podem ser adotadas para mitigar o risco é essencial. Esses protocolos de segurança incluem: 

• Atualização para a versão v2.149.0 do CDK, uma vez que ela inclui medidas de segurança aprimoradas que determinam que apenas os buckets do S3 dentro da conta do usuário sejam considerados confiáveis. Isso impede que o CDK envie dados para um bucket que não pertença à conta do usuário. 
• Usando um qualificador personalizado em vez do padrão “hnb659fds” ao personalizar os recursos de inicialização, conforme mencionado na documentação atualizada da AWS. 

Vale a pena mencionar que os usuários que iniciaram o sistema com uma versão mais antiga ainda podem correr o risco de serem vítimas da vulnerabilidade da AWS . Para mitigar o risco, esses usuários devem atualizar para a versão v2.149.0 ou posterior e executar novamente o comando “cdk bootstrap” . Como alternativa, esses usuários também podem aplicar uma política do IAM semelhante ao patch da AWS. 

Conclusão 

Esta vulnerabilidade da AWS destaca a importância de manter configurações seguras e versões de software atualizadas. Ao seguir os protocolos recomendados, como atualizar para a versão v2.149.0 do CDK e personalizar as configurações padrão, os usuários podem reduzir significativamente o risco de ataques de apropriação de conta e proteger recursos confidenciais da AWS. Essa vulnerabilidade e os possíveis cenários de ataque agora exigem o uso de medidas proativas de segurança cibernética que possam ajudar a mitigar riscos e melhorar a postura de segurança. 

As fontes utilizadas neste artigo incluem matérias publicadas no The Hacker News e Aqua.