Incidentes y vulnerabilidades
Filtración de Capital One (2019) — cómo un SSRF expuso más de 100M de registros, y cómo defenderse
En 2019 se filtraron ~106M de registros de Capital One. Un solo SSRF alcanzó el endpoint de metadatos de la nube, robó credenciales IAM con privilegios excesivos y copió S3. La cadena de ataque como mapa de defensa, más las soluciones.
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, prensa, análisis académico, declaraciones oficiales), citados al final.
- Objetivo
- Capital One (gran banco estadounidense)
- Divulgado
- 29 de julio de 2019 (detectado el 19 de julio / intrusión en marzo)
- Clase
- Robo de credenciales de la nube iniciado por SSRF y exfiltración
- Escala
- ~106M de personas en EE. UU./CA (incl. ~140k SSN, ~80k números de cuenta bancaria vinculados)
- Causa raíz
- Fallo SSRF + un endpoint de metadatos desprotegido + un rol IAM con privilegios excesivos
- Solución real
- defensa en profundidad: lista de destinos permitidos, IMDSv2, IAM de mínimo privilegio
Qué ocurrió (en lenguaje llano)
Capital One ejecutaba parte de su procesamiento de solicitudes en la nube. Un componente situado delante (funcionando como proxy inverso / WAF) tenía un fallo SSRF: se le podía obligar a enviar una petición, en nombre del servidor, hacia un destino elegido desde fuera.
Las VM de la nube tienen un endpoint de metadatos especial al que se accede solo desde dentro, que devuelve las credenciales temporales asignadas a esa máquina. Mediante el SSRF, el atacante alcanzó ese endpoint interno y obtuvo las claves. El rol IAM detrás de ellas (registrado en los registros públicos como ISRM-WAF-Role) tenía permiso amplio para leer el almacenamiento, así que el contenido de unos 700 buckets de almacenamiento (S3) fue copiado tal cual hacia fuera.
«Solo accesible desde dentro» se convierte en «dentro» cuando existe un SSRF
El endpoint de metadatos estaba protegido por la suposición de «inalcanzable desde fuera». Pero el SSRF hace que el propio servidor actúe de proxy del acceso, rompiendo esa suposición. «Solo interno, por tanto seguro» se derrumba con un único SSRF en la entrada.
La cadena de ataque también es un mapa de defensa
Lo que importa es que esto fue una cadena de cuatro saltos, y que cada salto tenía un punto donde detenerlo. Léela no como una receta de ataque, sino como «dónde se pudo haber cortado».
① Entrada: SSRF
Un fallo deja que el servidor actúe de proxy de una petición hacia cualquier destino.
⊘ parada: lista de destinos permitidos
② Alcanzar el endpoint de metadatos interno
Un endpoint «solo interno» se vuelve alcanzable vía SSRF.
⊘ parada: IMDSv2 (token obligatorio + límite de saltos)
③ Obtener las credenciales temporales de IAM
El rol de la máquina devuelve claves temporales.
⊘ parada: rol de mínimo privilegio (sin lectura total del almacenamiento)
④ Copia masiva del almacenamiento (S3)
~700 buckets copiados directamente hacia fuera.
⊘ parada: controles de salida + detección de lecturas anómalas
Cronología divulgada
2019-03
Acceso no autorizado al entorno de la nube (determinado después).2019-07-17
Un aviso externo (una publicación en GitHub) señala la anomalía.2019-07-19
Capital One confirma la filtración en su investigación interna.2019-07-29
Divulgación pública; el FBI arresta a una exingeniera de AWS.2019-11
AWS anuncia IMDSv2 como defensa en profundidad frente al SSRF.2020-08
La OCC impone una sanción de ~$80M, alegando una evaluación de riesgos inadecuada antes de la migración a la nube.
La causa raíz no es un solo error, sino capas cediendo
Atribúyelo solo al «SSRF» y se repetirá. En realidad fallaron tres capas en secuencia.
Como estaba (en su momento)
- Sin validación de destino en la entrada (cualquier petición proxificada era posible)
- El endpoint de metadatos devolvía claves sin token (modo heredado)
- El rol IAM de la máquina podía leer el almacenamiento ampliamente (privilegios excesivos)
Como debería ser (prevención)
- Lista de permitidos para los destinos y denegar el acceso proxificado a direcciones internas
- Metadatos vía IMDSv2: token de sesión obligatorio + límite de saltos que bloquea el alcance proxificado
- Rol IAM de mínimo privilegio: solo los buckets y acciones realmente necesarios
Dónde cae la línea de la «responsabilidad compartida»
El proveedor de la nube asegura los cimientos, pero corregir el SSRF, diseñar los permisos de IAM y proteger los metadatos son responsabilidad del cliente. La propia sanción citó una «evaluación de riesgos inadecuada antes de la migración a la nube». Subirse a una plataforma cómoda no es el problema: el problema es si has diseñado por completo tu lado de la línea.
Cómo prevenirlo en tu entorno
Soluciones ordenadas por prioridad que funcionan a cualquier escala. Si tienes aunque sea una función que «toma una URL y la descarga» o que «entrega un webhook/imagen», esto va contigo.
Lista de permitidos para los destinos salientes (detén el SSRF en la puerta)
Donde un servidor proxifica el acceso a una URL suministrada por el usuario, restríngelo a solo destinos permitidos. Deniega por defecto el alcance a direcciones internas (el endpoint de metadatos, redes privadas). La entrada sobre SSRF cubre las trampas de validación que la gente pasa por alto (seguimiento de redirecciones, DNS rebinding).
Impón IMDSv2 para los metadatos
Restringe el endpoint de metadatos de la nube al modo con token obligatorio y límite de saltos (IMDSv2 en AWS). Esto por sí solo dificulta enormemente el robo de credenciales vía SSRF. La clave es desactivar el modo heredado.
IAM de mínimo privilegio (reduce el radio de impacto)
Para que unas claves filtradas contengan el daño, limita los permisos de una máquina/servicio a solo los objetivos y acciones necesarios. «Permitir todo el almacenamiento sin más» convierte una sola brecha en una exfiltración total.
Control de salida y detección de anomalías
Restringe el tráfico saliente a los destinos necesarios y detecta anomalías como una ráfaga de lecturas grandes. Aunque la entrada no se detenga, mantén una capa que advierta la exfiltración.
Dónde coincide esto con el diseño de este sitio
Este sitio diseña las funciones que manejan URLs en torno a solo dominios verificados (a salvo de SSRF por diseño). Esta filtración es el caso más elocuente de por qué los principios sobre los que construimos —validar la entrada, mínimo privilegio, no fiarse de suposiciones de «interno»— son necesarios. Detrás de la comodidad, tú diseñas tu propio lado de la línea.
Fuentes (registros públicos)
Los hechos aquí se basan en la siguiente información pública. No cubrimos pasos de reproducción ni payloads, solo las lecciones 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
Lee a continuación
- Glosario: Qué es el SSRF (el punto de entrada, con sus trampas de validación)
- Incidente: Golpeado por un CVSS 10.0 descuidado
- Defensa: Integra el mínimo privilegio y la monitorización automática en la operación
FAQ
Q¿Cuál fue la causa raíz de la filtración de Capital One?
No una única causa, sino varias capas de defensa fallando en secuencia. La entrada fue un fallo SSRF (se podía obligar a un servidor a hacer de proxy de una petición hacia cualquier destino). Desde ahí se alcanzaba el endpoint de metadatos de la nube, y el rol IAM detrás de él tenía permisos amplios, así que unas credenciales temporales permitieron al atacante leer todo el almacenamiento.
Q¿Esto importa para mi pequeño servicio?
Sí. El SSRF surge de funciones corrientes que «toman una URL y la descargan» (previsualizaciones, webhooks). En la nube, el robo de credenciales desde el endpoint de metadatos ocurre sin importar la escala. Las tres soluciones de aquí (IMDSv2, IAM de mínimo privilegio, lista de destinos permitidos) también sirven para proyectos indie.
Q¿Lo habría evitado un WAF?
No. En esta filtración, el componente que actuaba como WAF se convirtió en el propio trampolín del SSRF. Un WAF bloquea algunos ataques, pero mal configurado se vuelve un agujero. «Tenemos un WAF, así que estamos a salvo» es un error de concepto: la validación de entradas, el mínimo privilegio y la protección de los metadatos son las defensas reales.