Cómo Equifax ignoró un parche y expuso a 147 millones de personas

El 29 de julio de 2017, un analista de seguridad de Equifax notó tráfico sospechoso saliendo de la red. Lo que la investigación reveló en las horas siguientes fue alarmante: los hackers llevaban 76 días dentro de los sistemas de la empresa, escaneando silenciosamente bases de datos con información personal de la mitad de la población adulta de Estados Unidos. ¿La puerta de entrada? Un parche disponible desde hacía meses que simplemente no se aplicó.

Una vulnerabilidad conocida, ignorada durante meses

El 7 de marzo de 2017, la Apache Software Foundation divulgó públicamente el CVE-2017-5638, una falla crítica en el framework Apache Struts que permite ejecución remota de código sin autenticación. El parche se lanzó el mismo día. Dos días después, el 9 de marzo, el equipo de seguridad de Equifax envió un comunicado interno indicando la aplicación urgente de la corrección.

El comunicado fue ignorado. El sistema ACIS — la aplicación web que Equifax usaba para que los consumidores pudieran disputar información en sus reportes de crédito — siguió corriendo la versión vulnerable de Apache Struts por dos meses más.

El 13 de mayo de 2017, los atacantes entraron.

Cómo operaron los intrusos durante 76 días sin ser detectados

Una vez dentro del sistema ACIS, los atacantes encontraron algo que facilitó mucho su trabajo: credenciales de administrador almacenadas en texto plano en un archivo accesible en la red. Con esas credenciales, se movieron lateralmente hacia otros sistemas que Equifax no había segmentado adecuadamente.

Equifax tampoco tenía un monitoreo robusto de tráfico en las bases de datos heredadas. Para empeorar las cosas, el certificado SSL usado para inspeccionar el tráfico interno estaba vencido desde hacía 19 meses — lo que significaba que el tráfico cifrado de los atacantes pasaba sin inspección.

Los intrusos realizaron más de 9.000 consultas a 51 tablas de base de datos distintas durante los 76 días de acceso, exfiltrando datos en pequeños lotes para no levantar alertas. Cuando el equipo de seguridad finalmente detectó el tráfico anómalo el 29 de julio, los atacantes ya habían salido un día antes.

¿Qué quedó exactamente expuesto en la brecha de Equifax?

147 millones de registros fueron comprometidos, incluyendo: nombres completos, números de Seguro Social (equivalente al DNI/CPF), fechas de nacimiento, direcciones y, en muchos casos, números de licencia de conducir. Cerca de 209 mil números de tarjetas de crédito también fueron robados, además de documentos de disputas de crédito de aproximadamente 182 mil personas.

Además de los estadounidenses, también se vieron afectados consumidores del Reino Unido y Canadá — 15 millones y 19 mil registros, respectivamente. Equifax solo divulgó el incidente públicamente el 7 de septiembre de 2017, más de cinco semanas después del descubrimiento.

La cadena de fallas que documentó el Senado de EE. UU.

El informe del Senado de EE. UU., publicado en 2019, catalogó las fallas por capas. No fue una única negligencia — fue un sistema de descuidos que se reforzaban entre sí:

• Proceso de parcheo roto: el comunicado de marzo se envió, pero no había verificación de cumplimiento. Nadie confirmó que el parche hubiera sido aplicado.
• Sin segmentación de red: el compromiso inicial de un sistema dio acceso a decenas de otros, porque las redes no estaban aisladas.
• Monitoreo inexistente en sistemas heredados: el ACIS era un sistema antiguo con registro de eventos inadecuado.
• Credenciales en texto plano: contraseñas de administrador accesibles sin cifrado dentro de la red interna.
• Certificado TLS vencido desde hacía 19 meses: imposibilitaba la inspección del tráfico cifrado interno.

Aisladamente, cada una de estas fallas sería seria. Combinadas, hicieron la detección casi imposible durante más de dos meses.

El acuerdo de US$ 700 millones y lo que cambió

En julio de 2019, Equifax cerró un acuerdo con la FTC, el CFPB y los fiscales generales de los 50 estados de EE. UU. El valor total llegó a US$ 700 millones — hasta entonces, uno de los mayores acuerdos por violación de datos de la historia. De ese monto, US$ 425 millones se destinaron a un fondo de compensación para los consumidores afectados, US$ 175 millones fueron a los estados y US$ 100 millones como multa al CFPB.

El CEO Richard Smith renunció días después de la divulgación pública de la brecha. El CIO y el CSO también salieron. Equifax fue obligado a implementar un programa integral de seguridad de la información y a pasar por auditorías de terceros durante años.

En la práctica, el impacto para los consumidores individuales fue limitado: la mayoría recibió algunos años de monitoreo de crédito gratuito. Los datos robados — números de Seguro Social, fechas de nacimiento, direcciones — son permanentes e inmutables. No hay forma de "cambiar" tu número de Seguro Social después de que fue expuesto.

La lección que Equifax dejó para el sector

El CVE-2017-5638 no era una vulnerabilidad zero-day desconocida. Era una falla pública, con parche disponible, ampliamente cubierta por Bleeping Computer, The Register y otros medios especializados. El exploit que derribó a Equifax usaba exactamente la prueba de concepto publicada por la propia comunidad de seguridad para demostrar la gravedad de la falla.

Eso hace que el caso de Equifax sea diferente de incidentes como el WannaCry, que usó un exploit de la NSA filtrado por Shadow Brokers, o el NotPetya, que fue un ataque de Estado disfrazado de ransomware. En Equifax no hubo sofisticación excepcional del adversario — hubo una falla básica de proceso.

La pregunta que plantea el caso para cualquier organización es directa: si mañana se divulga un parche crítico, ¿tienes forma de verificar, en 48 horas, que todos los sistemas afectados fueron corregidos? Equifax no la tenía. Y 147 millones de personas pagaron por eso.

El mismo tipo de falla — código de terceros desactualizado en producción — estuvo en el centro del Heartbleed en 2014, cuando la vulnerabilidad en OpenSSL pasó dos años en el código antes de ser descubierta. Las bibliotecas y frameworks de terceros crean superficies de ataque invisibles que solo aparecen cuando alguien las verifica.

Si te encargas de infraestructura o desarrollo, vale la pena revisar ahora mismo: ¿qué frameworks y dependencias están corriendo en producción en tu organización, y cuál es el proceso real para garantizar que los parches críticos se apliquen — no solo se comuniquen?