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
- Medidas principales
- 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.
Con un SSRF, un endpoint «solo accesible desde dentro» puede alcanzarse desde fuera
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» deja de ser cierto en cuanto existe un solo fallo SSRF.
Cada fase del ataque y cómo detenerla
Lo que importa es que esto fue una cadena de cuatro pasos, y que cada paso tenía un punto donde detenerlo. Léela no como una receta de ataque, sino como «dónde se pudo haber detenido».
① Punto de partida: 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.
Causa raíz: faltaban varias defensas a la vez
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
Responsabilidad compartida: lo que debe proteger el cliente de la nube
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». Usar la nube no es el problema; lo que importa es si has diseñado por completo la parte que te corresponde.
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 el primer paso)
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 (limita el daño)
Para que unas claves filtradas causen un daño limitado, 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 el primer paso 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 muestra con claridad por qué son necesarios los principios sobre los que construimos: validar las entradas, usar el mínimo privilegio y no dar por hecho que «interno» significa seguro. Incluso en una plataforma en la nube cómoda, la parte que te corresponde la tienes que diseñar tú.
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 partida de esta filtración, 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