Pesquisadores de segurança cibernética divulgaram uma falha de segurança que afeta o Cloud Growth Package (CDK) da Amazon Net Providers (AWS) que poderia ter resultado no controle de uma conta em circunstâncias específicas.
“O impacto deste problema pode, em certos cenários, permitir que um invasor obtenha acesso administrativo a uma conta alvo da AWS, resultando no controle complete da conta”, disse Aqua em um relatório compartilhado com The Hacker Information.
Após a divulgação responsável em 27 de junho de 2024, o problema foi resolvido pelos mantenedores do projeto na versão 2.149.0 do CDK lançada em julho.
AWS CDK é uma estrutura de desenvolvimento de software program de código aberto para definir recursos de aplicativos em nuvem usando Python, TypeScript ou JavaScript e provisioná-los por meio do CloudFormation.
O problema identificado pela Aqua baseia-se em descobertas anteriores da empresa de segurança em nuvem sobre recursos ocultos na AWS e como as convenções de nomenclatura predefinidas para buckets do AWS Easy Storage Service (S3) poderiam ser transformadas em armas para orquestrar ataques de monopólio de bucket e obter acesso a dados confidenciais.
A preparação de um ambiente AWS para uso com o AWS Cloud Growth Package (AWS CDK) é realizada por um processo chamado bootstrapping, em que determinados recursos da AWS são provisionados para o ambiente. Isso inclui um bucket AWS S3, um repositório Amazon Elastic Container Registry (Amazon ECR) e funções AWS Identification and Entry Administration (IAM).
“Os recursos e suas configurações usados pelo CDK são definidos em um modelo AWS CloudFormation”, de acordo com a documentação da AWS.
“Para inicializar um ambiente, você usa o comando cdk bootstrap da AWS CDK Command Line Interface (AWS CDK CLI). A CLI do CDK recupera o modelo e o implanta no AWS CloudFormation como uma pilha, conhecida como pilha de inicialização. Por padrão, a pilha nome é CDKToolkit.”
Algumas das funções do IAM criadas como parte do processo de inicialização concedem permissão para fazer add e excluir ativos do bucket S3 associado, bem como realizar implantações de pilha com acesso de administrador.
Aqua disse que o padrão de nomenclatura das funções IAM criadas pelo AWS CDK segue a estrutura “cdk-{Qualifier}-{Description}-{Account-ID}-{Area}”, onde cada um dos campos é explicado abaixo –
- Qualificador, um valor de string exclusivo de nove caracteres cujo padrão é “hnb659fds”, embora possa ser personalizado durante a fase de inicialização
- Descrição, descrição do recurso (por exemplo, cfn-exec-role)
- ID da conta, ID da conta AWS do ambiente
- Região, região AWS do ambiente
Na mesma linha, o bucket S3 criado durante a inicialização segue o padrão de nomenclatura “cdk-{Qualifier}-assets-{Account-ID}-{Area}”.
“Como muitos usuários executam o comando cdk bootstrap sem personalizar o qualificador, o padrão de nomenclatura do bucket S3 do bucket de teste torna-se previsível”, disse Aqua. “Isso ocorre porque o valor padrão para o qualificador de nome do bucket é definido como 'hnb659fds', facilitando a antecipação do nome do bucket.”
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 da AWS e a região na qual o CDK está implantado.
Combinando esse aspecto com o fato de que os nomes dos buckets S3 são globalmente exclusivos em todas as contas da AWS, a brecha abre a porta para o que é chamado de S3 Bucket Namesquatting (ou Bucket Sniping), permitindo que um invasor reivindique o bucket CDK de outro usuário se ele não existir. já.
Isso poderia então abrir caminho para uma negação de serviço (DoS) parcial quando um usuário tenta inicializar o CDK com o mesmo ID de conta e região, um cenário que poderia ser resolvido especificando um qualificador personalizado durante a inicialização.
Uma consequência mais séria poderia ocorrer se o CDK da vítima tivesse permissão para ler e gravar dados de e para o bucket S3 controlado pelo invasor, possibilitando assim a adulteração de modelos do CloudFormation e a execução de ações maliciosas na conta AWS da vítima.
“A função de implantação do serviço CloudFormation, que é a função CloudFormationExecutionRole no CDK, tem privilégios administrativos na conta por padrão”, destacou Aqua.
“Isso significa que qualquer modelo 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 privilegiados.”
Em um ataque hipotético, caso um usuário tenha iniciado o processo de inicialização do CDK no passado e posteriormente excluído o bucket S3 devido aos limites de cota, um adversário poderia aproveitar a situação para criar um bucket com o mesmo nome.
Isso poderia fazer com que o CDK confiasse implicitamente no bucket não autorizado e lesse/gravasse modelos do CloudFormation nele, tornando-os suscetíveis à exploração. No entanto, para que isso seja bem-sucedido, espera-se que o invasor cumpra os pré-requisitos abaixo:
Reivindique o bucket com o nome previsível e permita acesso público
Crie uma função Lambda que injetará uma função de administrador mal-intencionada ou backdoor em um determinado arquivo de modelo do CloudFormation sempre que ele for carregado no bucket
No estágio ultimate, quando o usuário implanta o CDK usando “cdk deploy”, o processo não apenas envia o modelo para o bucket de réplica, mas também injeta uma função de administrador que o invasor pode assumir para obter o controle da conta da vítima.
Em outras palavras, a cadeia de ataque facilita a criação de uma função administrativa em uma conta AWS de destino quando um bucket CDK S3 configurado durante o processo de inicialização é excluído e o CDK é usado novamente. Desde então, a AWS confirmou que aproximadamente 1% dos usuários do CDK eram vulneráveis ao vetor de ataque.
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 que não pertencem à conta que iniciou a inicialização. Ela também pediu aos clientes que usassem um qualificador personalizado em vez do padrão “hnb659fds”.
Dito isso, a ação do usuário será necessária se a inicialização tiver sido realizada usando o CDK versão v2.148.1 ou anterior, sendo necessário atualizar o CDK para a versão mais recente e executar novamente o comando de inicialização. Como alternativa, os usuários têm a opção de aplicar uma condição de política do IAM à função FilePublishingRole CDK.
As descobertas mais uma vez exigem manter os IDs das contas da AWS em segredo, definir uma política IAM com escopo definido e evitar fornecer nomes previsíveis aos buckets S3.
“Em vez disso, gere hashes exclusivos ou identificadores aleatórios por região e conta e incorpore-os aos nomes dos seus buckets S3”, concluiu Aqua. “Essa estratégia ajuda a proteger contra invasores que reivindicam preventivamente seu bucket.”
A divulgação ocorre no momento em que a Symantec, de propriedade da Broadcom, encontrou vários aplicativos Android e iOS que codificavam e não criptografavam credenciais de serviço em nuvem para AWS e Microsoft Azure Blob Storage, colocando os dados do usuário em risco.
Alguns dos aplicativos ofensivos incluem Pic Sew: Collage Maker, Crumbl, Eureka: Ganhe dinheiro com pesquisas, Videoshop – Editor de vídeo, Meru Cabs, Sulekha Enterprise e ReSound Tinnitus Aid.
“Essa prática perigosa significa que qualquer pessoa com acesso ao código binário ou fonte do aplicativo pode extrair essas credenciais e usá-las indevidamente para manipular ou exfiltrar dados, levando a graves violações de segurança”, disseram os pesquisadores de segurança Yuanjing Guo e Tommy Dong.