Vulnerabilidades críticas da AWS permitem bonança de ataques S3

BLACK HAT USA – Las Vegas – Quinta-feira, 8 de agosto – Seis vulnerabilidades críticas no Amazon Web Services (AWS) podem ter permitido que agentes de ameaças atacassem organizações com execução remota de código (RCE), exfiltração, ataques de negação de serviço ou até mesmo invasões de contas.

“A maioria das vulnerabilidades foi considerada crítica porque dava acesso a outras contas com esforço mínimo da perspectiva do invasor”, disse o pesquisador-chefe de segurança da Aqua, Yakir Kadkoda, ao Dark Reading.

Durante um briefing na quarta-feira na Black Hat USA em Las Vegas, pesquisadores da Aqua Security revelaram que descobriram novos vetores de ataque usando os bugs “Bucket Monopoly” e “Shadow Resources”. Os serviços da AWS impactados incluem Cloud Formation, CodeStar, EMR, Glue, SageMaker e Service Catalog.

Ao descobrir as vulnerabilidades em fevereiro, os pesquisadores da Aqua as relataram à AWS, que confirmou os problemas e implementou mitigações para os respectivos serviços aos poucos entre março e junho. No entanto, iterações de código aberto ainda podem ser vulneráveis.

‘Bucket Monopoly’: Atacando IDs de contas públicas da AWS

Os pesquisadores descobriram primeiro o Bucket Monopoly, um método de ataque que pode aumentar significativamente a taxa de sucesso de ataques que exploram os buckets do AWS S3 — ou seja, contêineres de armazenamento online para gerenciar objetos, como arquivos ou imagens, e recursos necessários para armazenar dados operacionais.

O problema é que os buckets de armazenamento S3 foram projetados para usar IDs de conta da AWS previsíveis e fáceis de adivinhar, em vez de um identificador exclusivo para cada nome de bucket usando um hash ou qualificador.

“Às vezes, a única coisa que um invasor precisa saber sobre uma organização é sua ID de conta pública na AWS, que não é considerada um dado sensível no momento, mas recomendamos que seja algo que uma organização mantenha em segredo”, diz Kadkoda.

Para atenuar o problema, a AWS alterou as configurações padrão.

“Todos os serviços foram corrigidos pela AWS, pois eles não criam mais o nome do bucket automaticamente”, ele explica. “A AWS agora adiciona um identificador aleatório ou número de sequência se o nome do bucket desejado já existir.”

Pesquisadores de segurança e clientes da AWS há muito debatem se os IDs de conta da AWS devem ser públicos ou privados. A AWS alerta os clientes contra o compartilhamento de credenciais e os aconselha a usar e compartilhar IDs de conta com cuidado. No entanto, de acordo com a documentação da AWS sobre identidades de conta, os IDs de conta “não são considerados informações secretas, sensíveis ou confidenciais”.

Os pesquisadores da Aqua discordam.

“Com base em nossa pesquisa, acreditamos fortemente que IDs de conta devem ser considerados segredos, pois pode haver outros tipos de explorações semelhantes que podem ser realizadas com base no conhecimento de uma ID de conta”, observa Kadkoda em um relatório técnico detalhado sobre as vulnerabilidades a ser publicado na sexta-feira. “Embora a suposição comum seja que saber apenas uma ID de conta não seja suficiente para hackear uma conta, os invasores ainda podem usá-la para coletar informações sobre sua conta AWS e muito mais.”

Um porta-voz da AWS se recusou a comentar sobre isso especificamente, mas disse que a AWS estava ciente dessa pesquisa.

“Podemos confirmar que corrigimos esse problema, todos os serviços estão operando conforme o esperado e nenhuma ação do cliente é necessária”, diz o porta-voz.

Recursos ocultos: ativos ocultos oferecem cobertura para invasores

Kadkoda diz que sua equipe também descobriu o vetor de ataque Shadow Resources, que pode criar componentes de serviço AWS S3 desconhecidos do proprietário da conta.

Os pesquisadores descobriram inicialmente o problema no serviço AWS CloudFormation, onde um invasor poderia se envolver em agachamento de recursos criando contas em regiões geográficas não utilizadas da AWS com o mesmo nome de pilhas legítimas existentes. Uma vez que a vítima armazenasse suas cargas de trabalho em uma nova região, ela poderia se conectar a ela e, então, sem saber, usar buckets S3 controlados pelo invasor.

Isso ocorre porque, ao usar o serviço com o AWS Management Console para criar uma nova pilha, a AWS cria automaticamente um bucket S3 para armazenar modelos do CloudFormation. O nome do bucket S3 é o mesmo em todas as regiões da AWS, que é como um invasor pode adivinhar o nome da conta e obter acesso a ela.

“Eu posso assumir seu bucket S3 e simplesmente envenenar a configuração e substituí-la”, diz o pesquisador de segurança da Aqua, Assaf Morag. “É algo enorme porque, entre as linhas, com uma execução remota de código, você pode pegar as contas de qualquer empresa no mundo.”

Todos os serviços exigem arquivos de configuração, e a AWS usa buckets S3 como seu sistema de arquivos para armazenar configurações.

“Na maioria dos casos, essas configurações são realmente significativas porque são as instruções para os serviços”, diz Morag. “Pode ser um arquivo YAML ou outras coisas que o serviço precisa usar nos bastidores.”

Dado que os clientes podem ter centenas ou milhares de contas distintas da AWS espalhadas por regiões do mundo todo, explorações de serviços sombra podem ter sido significativas, enfatiza Morag. Não se sabe onde houve vítimas da vulnerabilidade.

“O potencial de ser atacado ou de ser vítima poderia ser enorme”, diz ele.

Projetos de código aberto em buckets S3 ainda podem ser vulneráveis

Embora a AWS tenha mitigado as vulnerabilidades que impactam seus serviços, Kadkoda alerta que os vetores de ataque ainda podem impactar projetos de código aberto implantados em seus ambientes AWS. Muitos projetos de código aberto criam automaticamente buckets S3 ou direcionam os usuários para implantá-los, ele observa.

“Descobrimos muitos projetos de código aberto vulneráveis ​​a esse vetor porque eles os usam nos bastidores com nomes de bucket previsíveis”, diz Kadkoda.

Os usuários devem verificar se o nome de cada bucket existente foi reivindicado em outro lugar e, se for o caso, devem renomeá-lo.

Em todos os casos, Kadkoda e Morag dizem que os usuários devem evitar criar buckets S3 com identificadores previsíveis ou estáticos em primeiro lugar. Em vez disso, eles devem criar um nome de bucket S3 com um hash exclusivo ou um identificador aleatório para cada região e conta para evitar que invasores os reivindiquem primeiro.