Incidentes e Vulnerabilidades
Vazamento da Equifax (2017) — como uma falha não corrigida no Apache Struts expôs 147M de pessoas
Em 2017, dados de cerca de 147M de pessoas vazaram da Equifax. A causa: uma falha já corrigida do Apache Struts (CVE-2017-5638 / CVSS 10.0) deixada sem aplicar. Defesas: inventário de ativos, SLA de patch e monitoramento por máquina.
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, declarações oficiais, a Apache Software Foundation, reportagens), citados ao final.
- Alvo
- Equifax (grande bureau de crédito dos EUA)
- Divulgado
- 7 de set. de 2017 (intrusão mai–jul / detectado em 29/jul)
- Classe
- Intrusão via um CVE conhecido sem aplicar (RCE do Apache Struts) + exfiltração
- Escala
- cerca de 147M de pessoas nos EUA (nomes, SSNs, datas de nascimento, endereços; alguns números de cartão)
- Causa raiz
- CVE conhecido negligenciado + ausência de inventário de ativos + uma lacuna de detecção (certificado expirado)
- Correção real
- SLA de patch, inventário de ativos, monitoramento por máquina, detecção saudável
O que aconteceu (em termos simples)
A Equifax operava um portal online onde consumidores contestam suas informações de crédito. O componente Apache Struts por baixo dele tinha uma falha grave que permitia execução de código arbitrário a partir de fora (CVE-2017-5638).
A correção foi lançada no mesmo dia em que a falha foi publicada (7 de março de 2017). Mas o sistema em questão foi deixado sem patch. Dois meses depois, o invasor explorou o buraco conhecido, moveu-se lateralmente pela rede e exfiltrou dados pessoais em larga escala.
Pior, o dispositivo que monitorava o tráfego estava fora do ar por um longo tempo por causa de um certificado expirado, então a exfiltração anômala passou despercebida por 76 dias. No momento em que o certificado foi renovado, em 29 de julho, o tráfego suspeito apareceu — o mecanismo para perceber tinha sido desligado.
Não foi um 'ataque difícil' — foi um 'não aplicaram'
O buraco usado aqui era público no mundo todo e já corrigido. Não foi a sofisticação do ataque, mas a falta de uma operação para fechar riscos conhecidos dentro de um prazo que causou o dano. Isso acontece da mesma forma para desenvolvedores solo e organizações.
A cadeia também é um mapa de defesa
O que importa é que esta foi uma cadeia de cinco saltos, e cada salto tinha um ponto para interrompê-la. Leia isto como "onde ela poderia ter sido cortada", não como uma receita de ataque.
① Um CVE conhecido é publicado (correção lançada no mesmo dia)
⊘ pare: detecte por máquina os CVEs que combinam com você
② Um sistema público é deixado sem patch
Sem visão de onde o Struts rodava, escapou da rede.
⊘ pare: inventário de ativos + SLA de patch (prazo)
③ Intrusão via RCE
Execução de código arbitrário através do buraco sem aplicar.
⊘ pare: menor privilégio; um WAF apenas como reserva
④ Movimento lateral por uma rede plana, exfiltração em massa
Segmentação fraca permitiu que um vazamento alcançasse dados amplos.
⊘ pare: segmentação de rede reduz o raio de explosão
⑤ Sem detecção por 76 dias (certificado de monitoramento expirado)
O dispositivo para perceber estava desligado.
⊘ pare: verificações rotineiras de saúde do certificado/monitoramento
Linha do tempo divulgada
2017-03-07
O CVE-2017-5638 é publicado; uma correção é lançada no mesmo dia.2017-03–
Um aviso interno é emitido, mas o sistema em questão fica sem patch.2017-05–07
O invasor explora o buraco sem aplicar e exfiltra dados.2017-07-29
Logo após o certificado de monitoramento ser renovado, tráfego suspeito é detectado.2017-09-07
Divulgação pública; cerca de 147M de pessoas afetadas.2019-07
Acordo de até cerca de US$700M com a FTC, a CFPB e os estados (o maior de seu tipo).
A causa raiz não é um único "não aplicaram"
Encerre em "esqueceram o patch" e se repetirá. Na verdade, várias camadas falharam em sequência.
Como estava (na época)
- Negligenciaram um CVE conhecido (a correção existia, não aplicada a um sistema público)
- Sem inventário de ativos (não sabiam onde o componente rodava)
- Uma rede plana (permitiu movimento lateral e dispersão de dados)
- Uma lacuna de detecção (monitoramento fora do ar por certificado expirado)
Como deveria ser (prevenção)
- SLA de patch: um prazo da publicação até a aplicação, priorizando KEV / CVSS alto
- Inventário de ativos: rastreie por máquina as dependências e onde elas rodam
- Segmentação de rede: reduza o raio de explosão de um vazamento
- Detecção saudável: verifique rotineiramente se os certificados e o monitoramento estão vivos
'Corrigir' é uma operação, não algo pontual
A chave não é "corrigir algum dia", mas ter um prazo (SLA): aplicar dentro de N horas/dias da publicação. E para não perder alvos, uma máquina precisa saber o que roda onde. Confie na memória e, como a Equifax, "só uma máquina" fica para trás.
Prevenindo isso no seu ambiente
Correções priorizadas que funcionam em qualquer escala, ancoradas em uma coisa: não negligencie um CVE publicado.
Mantenha um inventário de ativos (o que roda onde)
Liste suas bibliotecas de dependência e quais serviços/contêineres as executam. O maior tropeço da Equifax foi não saber de um alvo. Julgue pela versão que efetivamente roda.
Defina um SLA de patch (prazo da publicação até a aplicação)
Decida de antemão "aplicar CVEs críticos dentro de N dias da publicação". Priorize KEV (sendo explorado) e CVSS alto. Um prazo torna a "negligência" visível.
Deixe máquinas monitorarem (não cace à mão)
Caçar CVEs manualmente é impossível. Verifique lockfiles com o Dependabot (GitHub) ou o osv-scanner, e notifique automaticamente apenas os CVEs que combinam com você. Veja como montar o monitoramento de dependências.
Tenha isolamento e detecção (seguro após uma queda)
Segmente redes para limitar o movimento lateral e detecte exfiltração anômala em massa. Inclua 'o monitoramento e o certificado estão vivos' nas operações — um alarme desligado não é alarme.
Este site faz isso ele próprio
Este site mantém suas próprias dependências sob monitoramento de CVE, exatamente como descrito aqui. A lição da Equifax — fechar buracos conhecidos com um processo que as pessoas não possam esquecer — é a convicção do produto. Substitua "corrigir algum dia" por "corrigir dentro de um prazo, com ajuda de máquina".
Fontes (registros públicos)
Os fatos aqui são baseados nas seguintes informações públicas, focadas em lições defensivas — não em passos de reprodução ou payloads.
- Apache Software Foundation, "Media Alert: Equifax Data Breach Due to Failure to Install Patches" (2017) — news.apache.org
- Equifax, "Releases Details on Cybersecurity Incident" (2017) — investor.equifax.com
- Anúncio do acordo da CFPB/FTC/estados (2019) — consumerfinance.gov
- CSO Online, "Equifax data breach FAQ" — csoonline.com
Leia em seguida
- Glossário: O que é um CVE · O que é CVSS · O que é RCE
- Defesa: Monitore dependências por máquina (operações de patch)
- Incidente: Capital One — SSRF expôs mais de 100M
FAQ
QQual foi a causa raiz do vazamento da Equifax?
Não foi um ataque inédito e sofisticado, mas uma 'vulnerabilidade conhecida e já corrigida (Apache Struts CVE-2017-5638 / CVSS 10.0) deixada sem aplicar em um sistema público'. Eles também não sabiam onde o componente rodava, e um dispositivo de monitoramento estava fora do ar por causa de um certificado expirado, então a exfiltração passou despercebida por 76 dias.
QO patch existia — por que não foi aplicado?
Segundo os registros públicos, a correção foi lançada no mesmo dia em que a falha foi publicada (7 de março de 2017). Um aviso interno foi emitido, mas o patch não foi aplicado ao sistema de contestação online em questão. Inventário de ativos inadequado — 'onde esse componente roda' — fez com que escapasse.
QHá uma lição para projetos pequenos?
Sim. Independentemente da escala, valem os mesmos três pontos: não negligencie CVEs conhecidos, saiba se esse componente está nas suas dependências e deixe que máquinas monitorem para que nada passe. Caçar CVEs à mão é impossível — deixe o Dependabot ou o osv-scanner vigiarem.