Em 19 de julho de 2019, a Capital One recebeu a mensagem que toda empresa moderna teme: ocorreu uma violação de dados. Afetou mais de 106 milhões de pessoas. 140 números de segurança social dos EUA, um milhão de números de segurança social canadenses. 000 contas bancárias. Desagradável, você não concorda?
Infelizmente, o hack não ocorreu em 19 de julho. Acontece que Paige Thompson, também conhecida como Errático, cometeu entre 22 e 23 de março de 2019. Aquilo é há quase quatro meses. Na verdade, foi apenas com a ajuda de consultores externos que a Capital One conseguiu descobrir que algo tinha acontecido.
Um ex-funcionário da Amazon foi preso e enfrenta uma multa de US$ 250 mil e cinco anos de prisão... mas ainda resta muita negatividade. Por que? Porque muitas empresas que sofreram ataques de hackers estão tentando se livrar da responsabilidade de fortalecer suas infraestruturas e aplicações em meio ao aumento do crime cibernético.
De qualquer forma, você pode facilmente pesquisar essa história no Google. Não entraremos em drama, mas falaremos sobre técnico lado da questão.
Em primeiro lugar, o que aconteceu?
A Capital One tinha cerca de 700 baldes S3 em execução, que Paige Thompson copiou e desviou.
Além disso, este é outro caso de política de bucket S3 mal configurada?
Não, não desta vez. Aqui ela obteve acesso a um servidor com firewall configurado incorretamente e realizou toda a operação a partir daí.
Espere, como isso é possível?
Bem, vamos começar fazendo login no servidor, embora não tenhamos muitos detalhes. Fomos informados apenas de que isso aconteceu por meio de um “firewall mal configurado”. Portanto, algo tão simples como configurações incorretas do grupo de segurança ou configuração do firewall do aplicativo da web (Imperva) ou firewall de rede (iptables, ufw, shorewall, etc.). A Capital One apenas admitiu a sua culpa e disse que tinha fechado o buraco.
Stone disse que a Capital One inicialmente não percebeu a vulnerabilidade do firewall, mas agiu rapidamente assim que tomou conhecimento dela. Isso certamente foi ajudado pelo fato de que o hacker supostamente deixou informações importantes de identificação disponíveis publicamente, disse Stone.
Se você está se perguntando por que não estamos nos aprofundando nesta parte, entenda que, devido às informações limitadas, só podemos especular. Isso não faz sentido, visto que o hack dependeu de um buraco deixado pela Capital One. E, a menos que eles nos contem mais, listaremos todas as maneiras possíveis pelas quais o Capital One deixou seu servidor aberto em combinação com todas as maneiras possíveis de alguém usar uma dessas diferentes opções. Essas falhas e técnicas podem variar de descuidos extremamente estúpidos a padrões incrivelmente complexos. Dada a gama de possibilidades, esta se tornará uma longa saga sem conclusão real. Portanto, vamos nos concentrar em analisar a parte onde temos os fatos.
Portanto, a primeira lição é: saiba o que seus firewalls permitem.
Estabeleça uma política ou processo adequado para garantir que SOMENTE o que precisa ser aberto seja aberto. Se você estiver usando recursos da AWS, como grupos de segurança ou Network ACLs, obviamente a lista de verificação para auditoria pode ser longa... mas assim como muitos recursos são criados automaticamente (ou seja, CloudFormation), também é possível automatizar sua auditoria. Seja um script caseiro que verifica falhas em novos objetos ou algo como uma auditoria de segurança em um processo de CI/CD... há muitas opções fáceis para evitar isso.
A parte “engraçada” da história é que se a Capital One tivesse tapado o buraco em primeiro lugar... nada teria acontecido. E então, francamente, é sempre chocante ver como algo realmente bem simples torna-se a única razão para uma empresa ser hackeada. Especialmente um tão grande como o Capital One.
Então, hacker lá dentro – o que aconteceu a seguir?
Bem, depois de invadir uma instância do EC2... muita coisa pode dar errado. Você está praticamente andando no fio da navalha se deixar alguém ir tão longe. Mas como isso entrou nos buckets S3? Para entender isso, vamos discutir as funções do IAM.
Portanto, uma forma de acessar os serviços AWS é ser um usuário. Ok, este é bastante óbvio. Mas e se você quiser fornecer a outros serviços da AWS, como servidores de aplicativos, acesso aos seus buckets S3? É para isso que servem as funções do IAM. Eles consistem em dois componentes:
- Política de Confiança – quais serviços ou pessoas podem usar esta função?
- Política de permissões – o que esta função permite?
Por exemplo, você deseja criar uma função IAM que permitirá que instâncias EC2 acessem um bucket S3: Primeiro, a função é definida para ter uma política de confiança para que o EC2 (todo o serviço) ou instâncias específicas possam “assumir” a função. Aceitar uma função significa que eles podem usar as permissões da função para executar ações. Em segundo lugar, a Política de Permissões permite que o serviço/pessoa/recurso que “assumiu a função” faça qualquer coisa no S3, seja acessando um bucket específico... ou mais de 700, como no caso do Capital One.
Quando estiver em uma instância do EC2 com a função IAM, você poderá obter credenciais de diversas maneiras:
- Você pode solicitar metadados de instância em
http://169.254.169.254/latest/meta-dataEntre outras coisas, você pode encontrar a função IAM com qualquer uma das chaves de acesso neste endereço. Claro, apenas se você estiver em uma instância.
- Usar AWS CLI...
Se a AWS CLI estiver instalada, ela será carregada com credenciais das funções do IAM, se presentes. Resta apenas trabalhar ATRAVÉS da instância. É claro que, se a sua Política de Confiança fosse aberta, Paige poderia fazer tudo diretamente.
Portanto, a essência das funções do IAM é que elas permitem que alguns recursos atuem EM SEU NOME em OUTROS RECURSOS.
Agora que você entende as funções do IAM, podemos falar sobre o que Paige Thompson fez:
- Ela obteve acesso ao servidor (instância EC2) através de uma falha no firewall
Quer se trate de grupos de segurança/ACLs ou de seus próprios firewalls de aplicativos da web, a falha provavelmente foi muito fácil de tapar, conforme declarado nos registros oficiais.
- Uma vez no servidor, ela foi capaz de agir “como se” ela mesma fosse o servidor
- Como a função de servidor IAM permitiu acesso do S3 a esses mais de 700 buckets, ele foi capaz de acessá-los
Daquele momento em diante, tudo o que ela precisava fazer era executar o comando List Bucketse então o comando Sync da AWS CLI...
. A prevenção de tais danos é a razão pela qual as empresas investem tanto em proteção de infraestrutura em nuvem, DevOps e especialistas em segurança. E quão valiosa e econômica é a migração para a nuvem? Tanto é verdade que mesmo diante de cada vez mais desafios de segurança cibernética !
Moral da história: verifique sua segurança; Realizar auditorias regulares; Respeite o princípio do menor privilégio para políticas de segurança.
( Você pode ver o relatório jurídico completo).
Fonte: habr.com