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.
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.
- Nota oficial da Capital One (também tem um FAQ)
- Former Seattle Tech Worker Indicted on Federal Charges for Wire Fraud and Computer Data Theft (U.S. Department of Justice)
- Blog da CloudSploit: "A Technical Analysis of the Capital One Hack"
- Artigo do Brian Krebs: "What We Can Learn from the Capital One Hack"
- Preventing The Capital One Breach
- Capital One Data Breach: What Went Wrong for the Financial Giant
- Capital One Breach: What we know and what you can do
- A Look at the Capital One Data Breach Through the Lens of MITRE ATT&CK
- Analysis of the Capital One Breach
- What the Capital One Hack Means for Boards of Directors
- Artigo da The Hack com a história do ataque e julgamento (27/06/2022)
- Notícia oficial do Julgamento (portal Justice.gov): Former Seattle tech worker convicted of wire fraud and computer intrusions
- Notícia da The Hack: "Vazamento de dados do Capital One, banco dos EUA, afeta 106 milhões"
PS: Post atualizado em 05 e 06/10/2022.
Nenhum comentário:
Postar um comentário