Incidentes y vulnerabilidades
Filtración de Equifax (2017) — cómo un fallo de Apache Struts sin parchear expuso a 147M de personas
En 2017 se filtraron los datos de ~147M de personas de Equifax. La causa: un fallo conocido y ya parcheado de Apache Struts (CVE-2017-5638 / CVSS 10.0) dejado sin aplicar en un sistema público, más un certificado de monitorización caducado que ocultó la exfiltración 76 días.
Leemos incidentes públicos reales no como repeticiones de noticias, sino a través de «cómo te defenderías de esto». Este artículo se basa en registros públicos (reguladores, declaraciones oficiales, la Apache Software Foundation, prensa), citados al final.
- Objetivo
- Equifax (gran agencia de crédito estadounidense)
- Divulgado
- 7 de septiembre de 2017 (intrusión de mayo a julio / detectado el 29 de julio)
- Clase
- Intrusión vía un CVE conocido sin aplicar (Apache Struts RCE) + exfiltración
- Escala
- ~147M de personas en EE. UU. (nombres, SSN, fechas de nacimiento, direcciones; algunos números de tarjeta)
- Causa raíz
- CVE conocido descuidado + falta de inventario de activos + un hueco de detección (certificado caducado)
- Solución real
- SLA de parcheo, inventario de activos, monitorización automática, detección saludable
Qué ocurrió (en lenguaje llano)
Equifax operaba un portal en línea donde los consumidores disputan su información crediticia. El componente Apache Struts que lo sustentaba tenía un fallo grave que permitía la ejecución de código arbitrario desde fuera (CVE-2017-5638).
La corrección salió el mismo día en que se publicó el fallo (7 de marzo de 2017). Pero el sistema objetivo quedó sin parchear. Dos meses después, el atacante explotó el agujero conocido, se movió lateralmente por la red y exfiltró datos personales a gran escala.
Peor aún, el dispositivo que monitorizaba el tráfico estaba caído durante mucho tiempo por un certificado caducado, así que la exfiltración anómala pasó sin detectarse durante 76 días. En el momento en que el certificado se renovó el 29 de julio, apareció el tráfico sospechoso: el mecanismo para advertirlo había estado apagado.
No fue un «ataque difícil», sino un «no se aplicó»
El agujero usado aquí era público en todo el mundo y ya estaba parcheado. No fue la sofisticación del ataque, sino la falta de una operación para cerrar riesgos conocidos dentro de un plazo, lo que causó el daño. Esto ocurre igual para desarrolladores en solitario y para organizaciones.
La cadena también es un mapa de defensa
Lo que importa es que esto fue una cadena de cinco saltos, y que cada salto tenía un punto donde detenerlo. Léela como «dónde se pudo haber cortado», no como una receta de ataque.
① Se publica un CVE conocido (corrección lanzada el mismo día)
⊘ parada: detección automática de los CVE que te afectan
② Un sistema público queda sin parchear
Sin visibilidad de dónde se ejecutaba Struts, se escapó de la red.
⊘ parada: inventario de activos + SLA de parcheo (plazo)
③ Intrusión vía RCE
Ejecución de código arbitrario a través del agujero sin aplicar.
⊘ parada: mínimo privilegio; un WAF solo como respaldo
④ Movimiento lateral por una red plana, exfiltración masiva
Una segmentación débil dejó que una brecha alcanzara amplios datos.
⊘ parada: la segmentación de red reduce el radio de impacto
⑤ Sin detectar durante 76 días (certificado de monitorización caducado)
El dispositivo para advertirlo estaba apagado.
⊘ parada: comprobaciones de salud rutinarias de certificados/monitorización
Cronología divulgada
2017-03-07
Se publica CVE-2017-5638; se lanza una corrección el mismo día.2017-03–
Se emite un aviso interno, pero el sistema objetivo sigue sin parchear.2017-05–07
El atacante explota el agujero sin aplicar y exfiltra datos.2017-07-29
Justo después de renovar el certificado de monitorización, se detecta tráfico sospechoso.2017-09-07
Divulgación pública; ~147M de personas afectadas.2019-07
Acuerdo de hasta ~$700M con la FTC, la CFPB y los estados (el mayor de su tipo).
La causa raíz no es un solo «no se aplicó»
Termínalo en «se les olvidó el parche» y se repetirá. En realidad fallaron varias capas en secuencia.
Como estaba (en su momento)
- Descuidaron un CVE conocido (la corrección existía, no se aplicó a un sistema público)
- Sin inventario de activos (no podían saber dónde se ejecutaba el componente)
- Una red plana (permitió el movimiento lateral y la difusión de datos)
- Un hueco de detección (monitorización caída por un certificado caducado)
Como debería ser (prevención)
- SLA de parcheo: un plazo desde la publicación hasta la aplicación, priorizando KEV / CVSS alto
- Inventario de activos: rastrear de forma automática las dependencias y dónde se ejecutan
- Segmentación de red: reducir el radio de impacto de una brecha
- Detección saludable: verificar de forma rutinaria que los certificados y la monitorización están vivos
«Parchear» es una operación, no un acto único
La clave no es «arreglarlo algún día», sino tener un plazo (SLA): aplicar dentro de N horas/días desde la publicación. Y para no pasar por alto objetivos, una máquina debe saber qué se ejecuta y dónde. Confía en la memoria y, como Equifax, «un solo equipo» se queda atrás.
Cómo prevenirlo en tu entorno
Soluciones ordenadas por prioridad que funcionan a cualquier escala, ancladas en una sola cosa: no descuidar un CVE publicado.
Mantén un inventario de activos (qué se ejecuta y dónde)
Lista tus librerías de dependencias y qué servicios/contenedores las ejecutan. El mayor tropiezo de Equifax fue pasar por alto un objetivo. Juzga por la versión que realmente se ejecuta.
Fija un SLA de parcheo (plazo desde la publicación hasta la aplicación)
Decide de antemano «aplicar los CVE críticos dentro de N días desde la publicación». Prioriza KEV (en explotación activa) y CVSS alto. Un plazo hace visible el «descuido».
Deja que las máquinas monitoricen (no persigas a mano)
Perseguir CVE manualmente es imposible. Comprueba los lockfiles con Dependabot (GitHub) u osv-scanner, y notifica automáticamente solo los CVE que te afectan. Consulta cómo construir la monitorización de dependencias.
Ten aislamiento y detección (el seguro tras un golpe)
Segmenta las redes para limitar el movimiento lateral y detecta la exfiltración masiva anómala. Incluye «¿están vivos la monitorización y el certificado?» en la operación: una alarma apagada no es ninguna alarma.
Este sitio lo hace consigo mismo
Este sitio mantiene sus propias dependencias bajo monitorización de CVE, exactamente como se escribe aquí. La lección de Equifax —cerrar agujeros conocidos con un proceso que la gente no pueda olvidar— es la convicción del producto. Sustituye «arreglarlo algún día» por «arreglarlo dentro de un plazo, con ayuda automática».
Fuentes (registros públicos)
Los hechos aquí se basan en la siguiente información pública, centrada en las lecciones defensivas, no en pasos de reproducción ni 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
- CFPB/FTC/states settlement announcement (2019) — consumerfinance.gov
- CSO Online, "Equifax data breach FAQ" — csoonline.com
Lee a continuación
- Glosario: Qué es un CVE · Qué es el CVSS · Qué es el RCE
- Defensa: Monitoriza las dependencias de forma automática (operación de parcheo)
- Incidente: Capital One — un SSRF expuso más de 100M
FAQ
Q¿Cuál fue la causa raíz de la filtración de Equifax?
No un ataque novedoso y sofisticado, sino una «vulnerabilidad conocida y ya parcheada (Apache Struts CVE-2017-5638 / CVSS 10.0) dejada sin aplicar en un sistema público». Además, no podían saber dónde se ejecutaba el componente, y un dispositivo de monitorización estaba caído por un certificado caducado, así que la exfiltración pasó inadvertida durante 76 días.
QEl parche existía, ¿por qué no se aplicó?
Según los registros públicos, la corrección salió el mismo día en que se publicó el fallo (7 de marzo de 2017). Se emitió un aviso interno, pero el parche no se aplicó al sistema objetivo de disputas en línea. Un inventario de activos inadecuado —«dónde se ejecuta este componente»— hizo que se colara.
Q¿Hay una lección para proyectos pequeños?
Sí. Sin importar la escala, valen los mismos tres puntos: no descuidar los CVE conocidos, saber si ese componente está entre tus dependencias, y dejar que las máquinas monitoricen para que no se escape nada. Perseguir CVE a mano es imposible: deja que Dependabot u osv-scanner vigilen.