Pesquisadores de cibersegurança descobriram múltiplas falhas críticas nas ofertas da Amazon Web Services (AWS) que, se exploradas com sucesso, poderiam resultar em sérias consequências.
"O impacto dessas vulnerabilidades varia entre execução remota de código (RCE), tomada de controle total do usuário do serviço (o que pode proporcionar acesso administrativo poderoso), manipulação de módulos de IA, exposição de dados sensíveis, exfiltração de dados e negação de serviço (DoS)," afirmou a empresa de segurança em nuvem Aqua em um relatório detalhado.
Após a divulgação responsável em fevereiro de 2024, a Amazon abordou as deficiências ao longo de vários meses, de março a junho.
Os achados foram apresentados no Black Hat USA 2024.
Central para a questão, batizada de Monopólio do Bucket, é um vetor de ataque referido como Recurso Oculto, que, neste caso, refere-se à criação automática de um bucket AWS S3 ao usar serviços como CloudFormation, Glue, EMR, SageMaker, ServiceCatalog e CodeStar.
O nome do bucket S3 criado desta maneira é único e segue uma convenção de nomeação predefinida (por exemplo, "cf-templates-{Hash}-{Região}").
Um atacante poderia tirar vantagem desse comportamento para configurar buckets em regiões AWS não utilizadas e esperar por um cliente AWS legítimo usar um dos serviços suscetíveis para ganhar acesso oculto ao conteúdo do bucket S3.
Com base nas permissões concedidas ao bucket S3 controlado pelo adversário, a abordagem poderia ser usada para escalar e desencadear uma condição de DoS, ou executar código, manipular ou roubar dados, e até mesmo obter controle total sobre a conta da vítima sem o conhecimento do usuário.
Para maximizar suas chances de sucesso, utilizando o Monopólio do Bucket, os atacantes podem criar buckets não reivindicados antecipadamente em todas as regiões disponíveis e armazenar código malicioso no bucket.
Quando a organização alvo ativa um dos serviços vulneráveis em uma nova região pela primeira vez, o código malicioso será executado sem o conhecimento, potencialmente resultando na criação de um usuário admin que pode conceder controle aos atacantes.
Visão geral da vulnerabilidade do CloudFormation No entanto, é importante considerar que o atacante terá que esperar pela vítima para implantar uma nova pilha CloudFormation em uma nova região pela primeira vez para lançar o ataque com sucesso.
Modificar o arquivo de template do CloudFormation no bucket S3 para criar um usuário admin malicioso também depende se a conta da vítima tem permissão para gerenciar papéis IAM.
Visão geral da vulnerabilidade no Glue Visão geral da vulnerabilidade no CodeStar A Aqua disse que encontrou outros cinco serviços AWS que dependem de uma metodologia de nomeação semelhante para os buckets S3 – {Prefixo do Serviço}-{ID da Conta AWS}-{Região} – expondo-os, assim, a ataques do Recurso Oculto e, finalmente, permitindo que um ator de ameaça escale privilégios e realize ações maliciosas, incluindo DoS, divulgação de informações, manipulação de dados e execução arbitrária de código -
AWS Glue: aws-glue-assets-{ID da Conta}-{Região}
AWS Elastic MapReduce (EMR): aws-emr-studio-{ID da Conta}-{Região}
AWS SageMaker: sagemaker-{Região}-{ID da Conta}
AWS CodeStar: aws-codestar-{Região}-{ID da Conta}
AWS Service Catalog: cf-templates-{Hash}-{Região}
A empresa também observou que os IDs das contas AWS deveriam ser considerados um segredo, ao contrário do que a Amazon afirma em sua documentação, pois poderiam ser usados para organizar ataques semelhantes.
O que é mais, hashes usados para contas AWS podem ser descobertos usando pesquisas de expressão regular no GitHub ou Sourcegraph, ou, alternativamente, raspando questões abertas, tornando possível montar o nome do bucket S3 mesmo na ausência de um meio de calcular o hash diretamente do ID da conta ou de qualquer outra metadado relacionado à conta.
"Esse vetor de ataque afeta não apenas os serviços AWS, mas também muitos projetos de código aberto usados por organizações para implantar recursos em seus ambientes AWS," disse a Aqua.
Muitos projetos de código aberto criam buckets S3 automaticamente como parte de sua funcionalidade ou instruem seus usuários a implantar buckets S3.
Em vez de usar identificadores previsíveis ou estáticos no nome do bucket, é aconselhável gerar um hash único ou um identificador aleatório para cada região e conta, incorporando esse valor no nome do bucket S3.
Essa abordagem ajuda a proteger contra atacantes reivindicando seu bucket prematuramente.
Publicidade
Em 14 de janeiro a Solyd irá revolucionar a forma como pentest e hacking deve ser ensinado. Se inscreva para ser o primeiro a saber das novidades. Saiba mais...