Criminosos roubaram credenciais da AWS

Criminosos roubaram credenciais da AWS de sites mal configurados e as mantiveram em um bucket aberto do S3.

Acredita-se que o assalto ligado ao ShinyHunters esteja em andamento desde março

Um grande assalto online direcionado a clientes da AWS, durante o qual criminosos digitais abusaram de configurações incorretas em sites públicos e roubaram código-fonte, milhares de credenciais e outros segredos, permanece “em andamento até hoje”, de acordo com pesquisadores de segurança.

Os caçadores de violações Noam Rotem e Ran Locar identificaram e relataram nomes e informações de contato de alguns dos meliantes envolvidos tanto para a Diretoria Cibernética de Israel quanto para a Equipe de Fraude da AWS, de acordo com Rotem, que falou exclusivamente com o The Register sobre sua investigação.

Além de roubar chaves e segredos de clientes da AWS, Rotem e Locar dizem que os saqueadores digitais estavam procurando descobrir credenciais de banco de dados, credenciais Git e código-fonte, informações SMTP para envio de e-mails, chaves Twilio para SMS, CPanel e credenciais SSH, chaves Cryptopay e CoinPayment, credenciais de e-mail Sendgrid, além de segredos de conta do Google, Facebook e Binance.

Eles acreditam que os ladrões de dados estão conectados às gangues de crimes cibernéticos Nemesis e ShinyHunters com base em algumas das ferramentas de hacking usadas durante a operação.

ShinyHunters, como os leitores devem se lembrar, é a equipe que supostamente violou a AT&T Wireless, a Microsoft e a Ticketmaster. Os pesquisadores nos dizem que as ferramentas usadas foram assinadas por “Sezyo Kaizen”, um pseudônimo vinculado ao desenvolvedor do site de phishing da ShinyHunters, Sebastien Raoult, que em janeiro se declarou culpado de conspiração para cometer fraude eletrônica e roubo de identidade agravado.

Durante a investigação, a dupla também viu uma assinatura usada pelo operador de um mercado darknet chamado Nemesis Blackmarket.

Eles suspeitam que a operação começou já em março, “e monitorando o canal ‘Nemesis’, vemos que ainda está em andamento até hoje”, disse Rotem ao The Register.

E os bandidos teriam escapado impunes, se não fosse por uma reviravolta irônica. Os criminosos armazenaram os dados das vítimas, mais de 2 TB no total, em um bucket S3 aberto configurado incorretamente por seu proprietário.

Crims deixou dados roubados em bucket S3 aberto

“Encontramos o balde aberto durante nossas próprias varreduras para ambientes de nuvem mal configurados”, disse Rotem. “Nosso objetivo era fechá-lo para que os dados do cliente permanecessem seguros; os perpetradores de Nemesis fizeram o mesmo por intenções diferentes.”

Além de levar os pesquisadores de ameaças à infraestrutura digital dos criminosos, o bucket de armazenamento mal configurado também indica que as pessoas – incluindo criminosos – ainda têm dificuldade em entender o modelo de responsabilidade compartilhada entre provedores de nuvem e seus clientes.

Como Rotem e Locar observaram em um relatório publicado na segunda-feira e compartilhado antecipadamente com o The Register, as configurações incorretas que permitiram que os invasores roubassem pelo menos 1.526 credenciais de clientes da AWS somente em agosto “estão do lado do cliente do modelo de responsabilidade compartilhada”. Sim, eles afetaram os clientes da AWS. Mas eles “podem ocorrer em qualquer provedor de serviços em nuvem”.

Esses erros incluíam “deixar as chaves em arquivos disponíveis publicamente, deixar repositórios de código aberto, deixar bancos de dados desprotegidos, etc”, disse Rotem. “Essas coisas estão nas mãos dos clientes da AWS e a AWS não tem controle sobre elas.”

A AWS, por sua vez, disse ao El Reg que todos os seus serviços “estão operando conforme o esperado” e que a campanha de roubo de credenciais e dados não apresenta uma falha de segurança que a gigante da nuvem precise preencher.

Havia também arquivos listando dezenas de milhares de alvos vulneráveis em todo o mundo, bem como todas as informações necessárias para acessar seus dados ou usar seus recursos para outros fins

“As credenciais da AWS incluem segredos que devem ser tratados com segurança. A AWS fornece recursos que eliminam a necessidade de armazenar essas credenciais no código-fonte”, disse um porta-voz, apontando o AWS Secrets Manager como uma dessas ferramentas que a gigante da nuvem fornece para ajudar os clientes a gerenciar e alternar credenciais de banco de dados, chaves de API e outros segredos.

“Às vezes, os clientes ainda expõem inadvertidamente credenciais em repositórios de código público”, acrescentou o porta-voz.

“Quando a AWS detecta essa exposição, aplicamos automaticamente uma política para colocar em quarentena o usuário do IAM com as credenciais comprometidas para limitar drasticamente as ações disponíveis para esse usuário e notificamos o cliente”, continuou ele. “Se as credenciais de um cliente forem comprometidas, recomendamos que ele revogue as credenciais, verifique os logs do AWS CloudTrail em busca de atividades indesejadas e revise sua conta da AWS em busca de uso indesejado.”

A dupla descobriu a operação de roubo de dados em agosto, depois de encontrarem o balde S3 aberto dos bandidos que estava sendo usado como uma “unidade compartilhada” entre membros de gangues.

“Durante nossa investigação, encontramos não apenas o código e as ferramentas de software usadas para executar a operação, mas também alguns dos próprios dados roubados, incluindo milhares de chaves e segredos”, escreveram os pesquisadores. “Havia também arquivos listando dezenas de milhares de alvos vulneráveis em todo o mundo, bem como todas as informações necessárias para acessar seus dados ou usar seus recursos para outros fins.”

Operação de varredura massiva

Veja como o ataque aconteceu. Envolveu uma série de atividades de pré-varredura para identificar alvos antes que os criminosos procurassem segredos e outras informações confidenciais para roubar.

Primeiro, os invasores usaram uma série de scripts e ferramentas de código aberto, incluindo o software de equipe vermelha do Project Discovery, para verificar 26,8 milhões de endereços IP pertencentes à AWS. Em seguida, eles usaram o Shodan disponível publicamente para realizar pesquisas reversas nos endereços IP e obter os nomes de domínio associados a cada um.

Os criminosos também analisaram os certificados SSL servidos por cada IP para estender ainda mais sua lista de domínios.

Depois de determinar seus alvos, os criminosos iniciaram o processo de verificação real procurando endpoints genéricos expostos, como arquivos de ambiente (.env), arquivos de configuração e repositórios git expostos e, em seguida, categorizando por sistema ou estrutura, como Laravel, WordPress, YII, etc.

“Uma vez que um sistema foi categorizado, um conjunto especial de testes foi realizado nele, tentando extrair informações de acesso ao banco de dados, chaves, senhas e muito mais de endpoints específicos do produto”, de acordo com os pesquisadores.

Nos casos em que queriam mais do que apenas as informações expostas, os criminosos usavam exploits conhecidos para instalar shells remotos e, assim, cavar mais fundo em busca de informações confidenciais.

Depois de verificar as credenciais expostas do cliente da AWS, os criminosos procuraram privilégios nos principais serviços da AWS, incluindo o IAM, o que é um jackpot para os criminosos porque as chaves com privilégios do IAM podem ser exploradas para criar usuários administradores adicionais.

Eles também verificaram privilégios nos serviços de e-mail e notificação SNS SES da Amazon que podem ser abusados para enviar mensagens fraudulentas e de phishing, bem como buckets S3, que permitem que criminosos roubem dados confidenciais pertencentes a organizações e seus clientes.

Depois de relatar o crime à Diretoria Cibernética de Israel no início de setembro, os pesquisadores notificaram a segurança da AWS em 26 de setembro. A gigante da nuvem concluiu sua investigação no mês passado.

O relatório de Rotem e Locar inclui uma seção inteira sobre como as organizações podem se proteger de ataques semelhantes, e é altamente recomendável lê-lo na íntegra. Mas um ponto-chave que queremos destacar, como a dupla observa em negrito: “A primeira coisa que qualquer operador de sistema deve fazer é garantir que NUNCA tenha credenciais codificadas em seu código ou mesmo em seu sistema de arquivos”