Um dos vazamentos de dados mais comentados neste ano aconteceu com o banco americano Capital One, anunciado publicamente em julho deste ano. Através de um ataque realizado por uma pessoa com conhecimento de sua infra-estrutura, a empresa sofreu um roubo de informações que afetou 106 milhões de clientes (100 milhões dos EUA e 6 milhões do Canadá).
Esse caso é bem interessante pois há várias informações sobre o caso, uma vez que a investigação do FBI e seu relatório de acusação
está disponível online. Junte a isso um
post no blog da empresa ClousSploit e um
artigo do Brian Krebs, e conseguimos identificar vários detalhes de como ocorreu o ataque.
O incidente, fruto de uma invasão criminosa, ocorreu nos dias 22 e 23 de março; porém, a instituição só percebeu o ataque no dia 19 de julho. O comprometimento dos dados só foi descoberto porque um pesquisador de segurança identificou a informação vazada e notificou a Capital One, via e-mail, através de seu programa de Vulnerability Disclosure.
Assim, a empresa identificou que seus dados e o script utilizado estavam disponíveis online em uma conta no GitHub. Pior ainda: o FBI identificou a suspeita da invasão pois ela publicou tudo em sua própria conta do serviço GitHub. E, ainda mais, conseguiu validar a identidade da pessoa cruzando seus perfis e comentários sobre o incidente em redes sociais. De nada adiantou usar VPN e TOR...
A acusada, chamada Paige Thompson, já trabalhou como engenheira de software para a Amazon Web Services (AWS) e prestou serviços para a Capital One entre 2015 e 2016.
Para acessar e roubar os dados, a atacante se aproveitou de uma falha de configuração no Web Application Firewall (WAF) ModSecurity utilizado pela CapitalOne para proteger o seu servidor hospedado na AWS, e realizou um ataque de
Server-Side Request Forgery (SSRF) para executar remotamente alguns comandos no servidor e, assim, acessar mais de 700 diretórios com dados de clientes.
Segundo a investigação do FBI, o script encontrado no GitHub possuía os comandos utilizados para obter o acesso ao ambiente da Capital One na AWS, listar seus repositórios de dados e copiar as informações.
Com base no material do FBI, no blog da CloudSploit e no artigo do Krebs, podemos reconstruir os principais passos realizados pelo atacante:
- O ataque SSRF permitiu enganar o servidor para executar comandos em nome de um usuário remoto, permitindo que o usuário obtenha acesso a serviços no ambiente privado, não públicos;
- A configuração incorreta do WAF permitiu ao invasor induzir o firewall a encaminhar os comandos para um recurso padrão no back-end na plataforma da AWS, conhecido como "serviço de metadados" (acessado através do endereço http://169.254.169.254);
- Combinando o ataque SSRF com o acesso ao serviço de metadados contendo credenciais temporárias do ambiente, a invasora conseguiu induzir o servidor a fazer uma solicitação para obter as credenciais de acesso. Ao usar a URL http://169.254.169.254/iam/security-credentials, a atacante teve como retorno informações de AccessKeyId e SecretAccessKey. Tais credenciais permitiram executar comandos no ambiente AWS via API, CLI ou algum SDK;
- Com essas credenciais, a invasora executou várias vezes o comando "ls" (para listar os Buckets da AWS S3), que retornou uma lista completa de todos os buckets do AWS S3 na conta comprometida da Capital One ("$ aws s3 ls");
- Ao final, a atacante utilizou o comando "sync" da AWS para copiar os dados desses buckets para sua máquina local da invasora ("$ aws s3 sync s3://bucketone ."). Esse comando permitiu ao atacante o acesso a mais de 700 buckets, de acordo com a acusação.
É interessante notar também que todos os acessos acima foram realizados através de TOR e VPN, para ocultar a origem do ataque.
Um exercício legal é mapear todos os passos do ataque de acordo com o
framework ATT&CK do MITRE, como na imagem abaixo, criada pela empresa
exabea:
A propósito, eu senti que no framework ATT&CK falta nomear uma técnica relacionada a exploração de falha de configuração em dispositivo de segurança existente (o WAF da Capital One, nesse caso), que na minha opinião poderia ser incluída na categoria de "Defense Evasion". Ao menos temos algo similar na lista de técnicas "PRE-ATT&CK", como
"Analyze architecture and configuration posture".
Como esse ataque poderia ter sido evitado? O próprio framework ATT&CK nos dá algumas dicas, pois ele também descreve, para cada técnica de ataque conhecida, as principais recomendações de mitigação e detecção que podem ser utilizadas, quando for aplicável. Alguns controles são relativamente óbvios na primeira leitura do caso, como por exemplo:
- Falha de controle de acesso, permitindo o acesso a infra-estrutura a partir de endereços IP da rede TOR e de serviços de VPN;
- Falha na gestão da solução WAF. Faltou também auditoria de configuração e auditoria de vulberabilidades que poderiam ter identificado essa falha;
- Monitoramento insuficiente do ambiente de Cloud Computing. O ambiente AWS possui o recurso CloudTrail, um serviço de auditoria que registra e monitora as ações executadas na infraestrutura, inclusive ações executadas via Console de Gerenciamento da AWS, dos SDKs e das ferramentas da linha de comando;
- Monitoramento insuficiente do tráfego de saída do ambiente na AWS, permitindo a exfiltração de grande volume de dados sensíveis.
Após
resultado do julgamento em junho de 2022, em setembro a
Paige Thompson recebeu sua sentença de prisão e cinco anos de liberdade condicional após sua condenação em junho nos tribunais federais dos EUA por cinco acusações de crimes e duas contravenções. Thompson deverá prestar 50 horas de serviço comunitário a cada ano durante o período de liberdade condicional, ficando sujeita a monitoramento por três anos restrita a ficar em sua casa, e seu uso de computadores e internet estará sujeito a monitoramento federal.
Para saber mais:
PS: Post atualizado em 05 e 06/10/2022.
