Como o Equifax ignorou um patch e expôs 147 milhões de pessoas

Em 29 de julho de 2017, um analista de segurança do Equifax notou tráfego suspeito saindo da rede. O que a investigação revelou nas horas seguintes foi alarmante: hackers estavam dentro dos sistemas da empresa há 76 dias, varrendo silenciosamente bancos de dados com informações pessoais de metade da população adulta dos Estados Unidos. A porta de entrada? Um patch disponível havia meses que simplesmente não foi aplicado.

Uma vulnerabilidade conhecida, ignorada por meses

Em 7 de março de 2017, a Apache Software Foundation divulgou publicamente o CVE-2017-5638, uma falha crítica no framework Apache Struts que permite execução remota de código sem autenticação. O patch foi lançado no mesmo dia. Dois dias depois, em 9 de março, a equipe de segurança do Equifax enviou um comunicado interno orientando a aplicação urgente da correção.

O comunicado foi ignorado. O sistema ACIS — a aplicação web que o Equifax usava para que consumidores pudessem contestar informações em seus relatórios de crédito — continuou rodando a versão vulnerável do Apache Struts por mais dois meses.

Em 13 de maio de 2017, os atacantes entraram.

Como os invasores operaram por 76 dias sem serem detectados

Uma vez dentro do sistema ACIS, os atacantes encontraram algo que facilitou muito o trabalho deles: credenciais de administrador armazenadas em texto puro em um arquivo acessível na rede. Com essas credenciais, eles se moveram lateralmente para outros sistemas que o Equifax não havia segmentado adequadamente.

O Equifax também não tinha monitoramento robusto de tráfego nos bancos de dados legados. Para piorar, o certificado SSL usado para inspecionar tráfego interno estava expirado há 19 meses — o que significava que o tráfego criptografado dos atacantes passava sem inspeção.

Os invasores realizaram mais de 9.000 consultas a 51 tabelas de banco de dados distintas durante os 76 dias de acesso, exfiltrando dados em pequenos lotes para não levantar alertas. Quando a equipe de segurança finalmente detectou o tráfego anômalo em 29 de julho, os atacantes já haviam saído há um dia.

O que exatamente ficou exposto no breach do Equifax?

147 milhões de registros foram comprometidos, incluindo: nomes completos, números de Seguro Social (equivalente ao CPF americano), datas de nascimento, endereços e, em muitos casos, números de carteira de motorista. Cerca de 209 mil números de cartões de crédito também foram roubados, além de documentos de disputas de crédito de aproximadamente 182 mil pessoas.

Além dos americanos, consumidores do Reino Unido e do Canadá também foram afetados — 15 milhões e 19 mil registros, respectivamente. O Equifax só divulgou o incidente publicamente em 7 de setembro de 2017, mais de cinco semanas após a descoberta.

A cadeia de falhas que o Senado americano documentou

O relatório do Senado dos EUA, publicado em 2019, catalogou as falhas em camadas. Não foi uma única negligência — foi um sistema de descuidos que se reforçavam:

• Processo de patch quebrado: o comunicado de março foi enviado, mas não havia verificação de cumprimento. Ninguém confirmou que o patch havia sido aplicado.
• Sem segmentação de rede: o comprometimento inicial de um sistema deu acesso a dezenas de outros, porque as redes não estavam isoladas.
• Monitoramento inexistente em sistemas legados: o ACIS era um sistema antigo com logging inadequado.
• Credenciais em texto puro: senhas de administrador acessíveis sem criptografia dentro da rede interna.
• Certificado TLS expirado há 19 meses: impossibilitava a inspeção de tráfego criptografado interno.

Isoladamente, cada uma dessas falhas seria séria. Combinadas, tornaram a detecção quase impossível por mais de dois meses.

O acordo de US$ 700 milhões e o que mudou

Em julho de 2019, o Equifax fechou acordo com a FTC, o CFPB e os procuradores-gerais de todos os 50 estados americanos. O valor total chegou a US$ 700 milhões — até então, um dos maiores acordos por violação de dados da história. Desse montante, US$ 425 milhões foram destinados a um fundo de compensação para consumidores afetados, US$ 175 milhões foram aos estados e US$ 100 milhões de multa ao CFPB.

O CEO Richard Smith renunciou dias após a divulgação pública do breach. O CIO e o CSO também saíram. O Equifax foi obrigado a implementar um programa abrangente de segurança da informação e a passar por auditorias de terceiros por anos.

Na prática, o impacto para consumidores individuais foi limitado: a maioria recebeu alguns anos de monitoramento de crédito gratuito. Os dados roubados — números de Seguro Social, datas de nascimento, endereços — são permanentes e imutáveis. Não há como "trocar" o número do seu Seguro Social depois que ele foi exposto.

A lição que o Equifax deixou para o setor

O CVE-2017-5638 não era uma vulnerabilidade zero-day desconhecida. Era uma falha pública, com patch disponível, que havia sido amplamente noticiada por Bleeping Computer, The Register e outros veículos especializados. A exploração que derrubou o Equifax usava exatamente o exploit de prova de conceito publicado pela própria comunidade de segurança para demonstrar a gravidade da falha.

Isso torna o caso do Equifax diferente de incidentes como o WannaCry, que usou um exploit da NSA vazado pelo Shadow Brokers, ou o NotPetya, que foi um ataque de Estado disfarçado de ransomware. No Equifax, não havia sofisticação excepcional do adversário — havia uma falha básica de processo.

A pergunta que o caso levanta para qualquer organização é direta: se amanhã um patch crítico for divulgado, você tem como verificar, em 48 horas, que todos os sistemas afetados foram corrigidos? O Equifax não tinha. E 147 milhões de pessoas pagaram por isso.

O mesmo tipo de falha — código de terceiros desatualizado em produção — estava no centro do Heartbleed em 2014, quando a vulnerabilidade no OpenSSL ficou dois anos no código antes de ser descoberta. Bibliotecas e frameworks de terceiros criam superfícies de ataque invisíveis que só aparecem quando alguém verifica.

Se você cuida de infraestrutura ou desenvolvimento, vale revisar agora: quais frameworks e dependências estão rodando em produção na sua organização, e qual é o processo real para garantir que patches críticos sejam aplicados — não apenas comunicados?