Em 19 de julho de 2019, o Capital One Bank recebeu uma mensagem de que toda empresa moderna tem medo - ocorreu um vazamento de dados. Afetou mais de 106 milhões de pessoas. 140.000 números de seguridade social dos EUA, um milhão de números de seguridade social do Canadá. 80.000 contas bancárias. Desagradável, concorda?
Infelizmente, o hacking não aconteceu em 19 de julho. Paige Thompson, também conhecido como
Erratic , apresentou-o entre 22 e 23 de março de 2019. Isso é
quase quatro meses atrás . De fato, somente com a ajuda de consultores externos a Capital One sabia que algo havia acontecido.
Ex-funcionária da Amazon presa, ela enfrenta uma multa de US $ 250 mil e cinco anos de prisão ... mas há muita negatividade. Porque Porque muitas empresas que foram invadidas por hackers estão tentando deixar de lado a responsabilidade de fortalecer sua infraestrutura e aplicativos em meio ao crescente cibercrime.
De qualquer forma, você pode facilmente pesquisar no Google esta história. Não vamos entrar em drama, mas falar sobre o lado
técnico das coisas.
Primeiro o que aconteceu?
Na Capital One, havia cerca de 700 baldes S3 que Paige Thompson copiou e esvaziou.
Em segundo lugar, esse é outro caso de uma política de bucket S3 configurada incorretamente?
Não, desta vez não. Aqui, ela obteve acesso a um servidor com um firewall configurado incorretamente e, a partir daí, conduziu toda a operação.
Espere, como isso é possível?
Bem, vamos começar fazendo login no servidor, embora tenhamos poucos detalhes. Só nos disseram que isso aconteceu através de um "firewall configurado incorretamente". Portanto, algo tão simples quanto as configurações erradas do grupo de segurança ou a configuração do firewall do aplicativo da web (Imperva) ou do firewall da rede (iptables, ufw, shorewall etc.). A Capital One apenas se declarou culpada e disse que fechou o buraco.
Stone disse que o Capital One não notou inicialmente a vulnerabilidade do firewall, mas respondeu rapidamente assim que descobriu. Obviamente, isso foi ajudado pelo fato de o hacker ter deixado a chave de identificação das informações disponíveis ao público, disse Stone.
Se você está interessado em saber por que não estamos nos aprofundando nesta parte, entenda que, devido a informações limitadas, podemos apenas especular. Isso não faz sentido, uma vez que o hack dependia da lacuna deixada pela Capital One. E se eles não nos disserem mais, apenas listaremos todas as maneiras possíveis que a Capital One deixou seu servidor aberto em combinação com todas as maneiras possíveis pelas quais alguém poderia usar uma dessas várias opções. Essas lacunas e métodos podem variar de descuidos estúpidos a padrões incrivelmente complexos. Dada a gama de possibilidades, isso se transformará em uma longa saga sem uma conclusão real. Portanto, focaremos na análise da parte em que temos os fatos.Portanto, a primeira conclusão: saiba o que seus firewalls permitem
Estabeleça uma política ou processo para garantir que APENAS o que está aberto esteja aberto. Se você usa recursos da AWS, como grupos de segurança ou ACLs de rede, obviamente a lista de verificação para verificação pode ser longa ... mas, como muitos recursos são criados automaticamente (ou seja, CloudFormation), você também pode automatizar a auditoria deles. Seja um script improvisado que procure por novos objetos em busca de falhas ou algo como uma auditoria de segurança em um processo de CI / CD ... existem muitas opções fáceis para evitar isso.
A parte "divertida" da história é que, se a Capital One tivesse fechado o buraco desde o início ... nada teria acontecido. E, portanto, francamente, é sempre chocante ver como algo realmente
simples se torna a única razão para uma empresa de hackers. Especialmente do tamanho da Capital One.
Então, o hacker lá dentro - o que aconteceu depois?
Bem, depois de invadir a instância do EC2 ... muita coisa pode dar errado. Você caminha quase ao longo da ponta de uma faca se permitir que alguém vá tão longe. Mas como ela entrou no balde S3? Para entender isso, vamos discutir os papéis do IAM (Funções do IAM).
Portanto, uma maneira de acessar os serviços da AWS é ser um usuário. Ok, isso é bastante óbvio. Mas e se você quiser conceder a outros serviços da AWS, por exemplo, seus servidores de aplicativos, acesso aos seus buckets S3? Para isso, existem funções do IAM. Eles consistem em dois componentes:
- Política de Confiança - quais serviços ou quais pessoas podem usar essa função?
- Política de permissões - o que essa função permite?
Por exemplo, você deseja criar uma função do IAM que permita que instâncias do EC2 acessem o bucket S3: em primeiro lugar, ele define uma Política de Confiança para a função, para que o EC2 (todo o serviço) ou instâncias específicas possam assumir a função. Assumir uma função significa que eles podem usar suas permissões 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 algo no S3, seja acesso a um intervalo específico ... ou a mais de 700, como no caso do Capital One.
Quando você estiver em uma instância do EC2 com a função IAM, poderá obter credenciais de várias maneiras:
- Você pode solicitar os metadados da instância em
http://169.254.169.254/latest/meta-data
Entre outras coisas, neste endereço, você pode encontrar a função do IAM com qualquer uma das chaves de acesso. Obviamente, apenas se você estiver em uma instância.
- Use o AWS CLI ...
Se a interface da linha de comando da AWS estiver instalada, ela será carregada com as credenciais das funções do IAM, se houver. Resta apenas trabalhar com a instância. Obviamente, se sua Política de Confiança estivesse aberta, Page poderia fazê-lo diretamente.
Portanto, a essência das funções do IAM é que elas permitem que um recurso atue DE SEU NOME em OUTROS RECURSOS.
Agora que você entende os papéis do IAM, podemos falar sobre o que Page Thompson fez:
- Ela ganhou acesso ao servidor (instância EC2) através de um buraco no firewall
Sejam grupos de segurança / ACLs ou firewalls de aplicativos da Web, o buraco foi provavelmente muito fácil de fechar, conforme declarado nos registros oficiais.
- Uma vez no servidor, ela foi capaz de agir "como se" fosse o servidor
- Como a função de servidor IAM permitiu o acesso do S3 a esses mais de 700 baldes, ela pôde acessá-los
A partir de agora, ela só poderia executar o comando
List Buckets e o comando
Sync na CLI da AWS ...
O Capital One Bank estima danos de hackers no valor de 100 a 150 milhões de dólares . Prevenir esse dano é o motivo pelo qual as empresas investem tanto na proteção da infraestrutura de nuvem, DevOps e especialistas em segurança. E quão valiosa e econômica é a transição para a nuvem? Tanto que, mesmo diante de mais e mais problemas de segurança cibernética, o
mercado geral de nuvens públicas cresceu 42% no primeiro trimestre de 2019 !
A moral desta história: verifique sua segurança; realizar auditorias regulares; respeitar o princípio do menor privilégio para as políticas de segurança.
(Você pode ver o relatório jurídico completo aqui).