Incidentes e Vulnerabilidades
Vazamento da Capital One (2019) — como um SSRF expôs mais de 100M de registros, e como se defender
Em 2019, cerca de 106M de registros vazaram da Capital One. Um único SSRF alcançou o endpoint de metadados da nuvem, roubou credenciais IAM com privilégios excessivos e copiou o S3. A cadeia de ataque como mapa de defesa, e as correções: allowlist de destinos, IMDSv2, IAM de menor privilégio.
Lemos incidentes públicos reais não como reprises de notícias, mas pela ótica de "como você se defenderia disso". Este artigo é baseado em registros públicos (reguladores, reportagens, análise acadêmica, declarações oficiais), citados ao final.
- Alvo
- Capital One (grande banco dos EUA)
- Divulgado
- 29 de julho de 2019 (detectado em 19/jul / intrusão em março)
- Classe
- Roubo de credenciais da nuvem iniciado por SSRF e exfiltração
- Escala
- cerca de 106M de pessoas nos EUA/CA (incl. ~140k SSNs, ~80k números de conta bancária vinculados)
- Causa raiz
- falha de SSRF + um endpoint de metadados desprotegido + um papel IAM com privilégios excessivos
- Correção real
- defesa em profundidade: allowlist de destinos, IMDSv2, IAM de menor privilégio
O que aconteceu (em termos simples)
A Capital One rodava parte do seu processamento de inscrições na nuvem. Um componente à frente dele (atuando como proxy reverso / WAF) tinha uma falha de SSRF: ele podia ser induzido a enviar uma requisição, em nome do servidor, para um destino escolhido de fora.
VMs na nuvem têm um endpoint de metadados especial, acessível apenas internamente, que retorna as credenciais temporárias atribuídas àquela máquina. Usando o SSRF, o invasor alcançou esse endpoint interno e obteve as chaves. O papel IAM por trás delas (registrado nos documentos públicos como ISRM-WAF-Role) tinha permissão ampla para ler armazenamento, então o conteúdo de cerca de 700 buckets de armazenamento (S3) foi copiado tal como estava.
'Só acessível internamente' vira 'interno' quando existe SSRF
O endpoint de metadados estava protegido pela suposição "inacessível de fora". Mas o SSRF faz o próprio servidor encaminhar o acesso, quebrando essa suposição. "Só interno, portanto seguro" desmorona com um único SSRF na entrada.
A cadeia de ataque também é um mapa de defesa
O que importa é que esta foi uma cadeia de quatro saltos, e cada salto tinha um ponto para interrompê-la. Leia isto não como uma receita de ataque, mas como "onde ela poderia ter sido cortada".
① Entrada: SSRF
Uma falha permite que o servidor encaminhe uma requisição para qualquer destino.
⊘ pare: allowlist de destinos
② Alcançar o endpoint interno de metadados
Um endpoint "só interno" torna-se acessível via SSRF.
⊘ pare: IMDSv2 (token exigido + limite de saltos)
③ Obter as credenciais IAM temporárias
O papel da máquina devolve chaves temporárias.
⊘ pare: papel de menor privilégio (sem leitura total do armazenamento)
④ Copiar o armazenamento em massa (S3)
cerca de 700 buckets copiados diretamente.
⊘ pare: controles de egress + detecção de leituras anômalas
Linha do tempo divulgada
2019-03
Acesso não autorizado ao ambiente de nuvem (determinado depois).2019-07-17
Uma denúncia externa (um post no GitHub) sinaliza a anomalia.2019-07-19
A Capital One confirma o vazamento em investigação interna.2019-07-29
Divulgação pública; uma ex-engenheira da AWS é presa pelo FBI.2019-11
A AWS anuncia o IMDSv2 como defesa em profundidade contra SSRF.2020-08
A OCC aplica uma multa de cerca de US$80M, citando avaliação de risco inadequada antes da migração para a nuvem.
A causa raiz não é um único erro — são camadas cedendo
Atribua isso só ao "SSRF" e se repetirá. Na verdade, três camadas falharam em sequência.
Como estava (na época)
- Sem validação de destino na entrada (qualquer requisição encaminhada era possível)
- O endpoint de metadados retornava chaves sem um token (modo legado)
- O papel IAM da máquina podia ler armazenamento amplamente (privilégios excessivos)
Como deveria ser (prevenção)
- Allowlist de destinos e negar acesso encaminhado a endereços internos
- Metadados via IMDSv2: token de sessão exigido + limite de saltos bloqueia o alcance encaminhado
- Papel IAM com menor privilégio: apenas os buckets e ações realmente necessários
Onde fica a linha da 'responsabilidade compartilhada'
O provedor de nuvem protege a base, mas corrigir o SSRF, projetar as permissões IAM e proteger os metadados são responsabilidade do cliente. A própria multa citou "avaliação de risco inadequada antes da migração para a nuvem". Usar uma plataforma conveniente não é o problema — o problema é se você projetou plenamente o seu lado da linha.
Prevenindo isso no seu ambiente
Correções priorizadas que funcionam em qualquer escala. Se você tem ao menos uma funcionalidade que "recebe uma URL e a busca" ou "entrega um webhook/imagem", isto é sobre você.
Allowlist de destinos de saída (interrompa o SSRF na porta)
Onde um servidor encaminha acesso a uma URL fornecida pelo usuário, restrinja a apenas destinos permitidos. Negue por padrão o alcance a endereços internos (o endpoint de metadados, redes privadas). A página sobre SSRF cobre as armadilhas de validação que as pessoas costumam ignorar (seguir redirecionamentos, DNS rebinding).
Imponha o IMDSv2 para metadados
Restrinja o endpoint de metadados da nuvem ao modo com token exigido e limite de saltos (IMDSv2 na AWS). Só isso já torna o roubo de credenciais via SSRF muito mais difícil. O ponto é desabilitar o modo legado.
IAM de menor privilégio (reduza o raio de explosão)
Para que chaves vazadas contenham o dano, restrinja as permissões de uma máquina/serviço a apenas os alvos e ações necessários. "Simplesmente permitir todo o armazenamento" transforma um vazamento em exfiltração total.
Egress e detecção de anomalias
Restrinja o tráfego de saída aos destinos necessários e detecte anomalias como uma rajada de leituras grandes. Mesmo que a entrada não seja interrompida, mantenha uma camada que perceba a exfiltração.
Onde isso se sobrepõe ao design deste site
Este site projeta funcionalidades que lidam com URLs em torno de apenas domínios verificados (seguro contra SSRF por design). Este vazamento é o caso mais eloquente de por que os princípios sobre os quais construímos — validar a entrada, menor privilégio, não depender de suposições de "interno" — são necessários. Por trás da conveniência, você projeta o seu lado da linha por conta própria.
Fontes (registros públicos)
Os fatos aqui são baseados nas seguintes informações públicas. Não cobrimos passos de reprodução nem payloads — apenas as lições defensivas.
- Krebs on Security, "What We Can Learn from the Capital One Hack" (2019) — krebsonsecurity.com
- ACM Transactions on Privacy and Security, "A Systematic Analysis of the Capital One Data Breach" — dl.acm.org
- CyberScoop, "US financial regulator fines Capital One $80 million over data breach" (2020) — cyberscoop.com
Leia em seguida
- Glossário: O que é SSRF (o ponto de entrada, com as armadilhas de validação)
- Incidente: Atingido por um CVSS 10.0 negligenciado
- Defesa: Incorpore menor privilégio e monitoramento por máquina às operações
FAQ
QQual foi a causa raiz do vazamento da Capital One?
Não foi uma única causa, mas várias camadas de defesa falhando em sequência. A entrada foi uma falha de SSRF (um servidor podia ser induzido a fazer uma requisição, em seu próprio nome, para qualquer destino). A partir daí, o endpoint de metadados da nuvem ficou acessível, e o papel IAM por trás dele tinha permissões amplas, então credenciais temporárias permitiram que o invasor lesse todo o armazenamento.
QIsso importa para o meu pequeno serviço?
Sim. O SSRF surge de funcionalidades comuns que 'recebem uma URL e a buscam' (prévias, webhooks). Na nuvem, o roubo de credenciais a partir do endpoint de metadados acontece independentemente da escala. As três correções aqui (IMDSv2, IAM de menor privilégio, allowlist de destinos) também funcionam para projetos indie.
QUm WAF teria evitado isso?
Não. Neste vazamento, o componente que atuava como WAF tornou-se ele próprio o trampolim do SSRF. Um WAF bloqueia alguns ataques, mas mal configurado vira um buraco. 'Temos um WAF, então estamos seguros' é um equívoco — validação de entrada, menor privilégio e proteção dos metadados são as defesas reais.