Metadatos y SSRF

Toda VM en la nube puede consultar un endpoint interno especial para obtener información sobre sí misma: el Instance Metadata Service (IMDS). Y lo que es más importante, también puede proporcionar las credenciales temporales del rol asociado a la instancia.

• AWS / GCP / Azure exponen metadatos en 169.254.169.254
• Solo se puede acceder a él desde dentro de la instancia
• No requiere autenticación por parte de los procesos locales

Esta comodidad se convierte en un arma cuando se combina con SSRF.

En el IMDSv1 heredado, una única solicitud GET devuelve metadatos, incluidas las credenciales del rol. No se necesita ningún token.

Precisamente por eso IMDSv1 es peligroso cuando una aplicación presenta SSRF.

Server-Side Request Forgery (SSRF) es una vulnerabilidad en la que un atacante engaña a un servidor para que realice solicitudes HTTP en su nombre. El servidor se convierte en un proxy hacia lugares a los que el atacante no puede acceder directamente.

• Un parámetro de URL que el servidor obtiene
• Un webhook, un generador de PDF o una función para cambiar el tamaño de imágenes
• Cualquier elemento que acepte una URL proporcionada por el usuario

El objetivo clásico de SSRF en la nube es el endpoint de metadatos.

La combinación letal: una aplicación con SSRF permite al atacante dirigir el servidor a 169.254.169.254. El servidor obtiene las credenciales de IAM de la instancia y se las devuelve.

El atacante ya dispone de credenciales de la nube, lo que a menudo constituye el inicio de una toma de control completa de la cuenta.

La respuesta de metadatos contiene una clave de acceso, una clave secreta y un token de sesión. El atacante las exporta y actúa inmediatamente como el rol de la instancia.

A partir de aquí, enumera los permisos y busca vías de escalada.

AWS introdujo IMDSv2 para mitigar SSRF. Primero requiere un token de sesión obtenido mediante una solicitud HTTP PUT, algo que la mayoría de las primitivas SSRF no pueden realizar, ya que solo ejecutan solicitudes GET.

Aplicar IMDSv2 y establecer un límite de saltos bajo reduce drásticamente el robo de metadatos mediante SSRF.

Los demás proveedores también exponen metadatos, aunque con sus propias particularidades. Ambos requieren un encabezado especial, lo que constituye por sí mismo una pequeña mitigación contra SSRF.

• Azure requiere Metadata: true
• GCP requiere Metadata-Flavor: Google

A menudo, los defensores bloquean 169.254.169.254. Los atacantes eluden los filtros ingenuos mediante codificaciones IP alternativas y redirecciones.

• IP decimal: 2852039166
• Codificaciones octales o hexadecimales de la misma dirección
• DNS rebinding hacia un nombre que resuelve a la IP de metadatos
• Redirecciones abiertas que redirigen la solicitud a la URL de metadatos

Las defensas sólidas deben validar la IP resuelta, no la cadena sin procesar.

Los metadatos son el objetivo principal, pero SSRF también permite acceder a otros recursos internos:

• Paneles de administración y dashboards internos vinculados a localhost
• Bases de datos y cachés internos (Redis, Elasticsearch)
• Servidor de API de Kubernetes y endpoints de kubelet
• Otros microservicios que no están expuestos externamente

SSRF atraviesa eficazmente el perímetro de red desde un punto de vista de confianza.

Para romper la cadena de SSRF a metadatos se necesita una defensa por capas:

• Aplique IMDSv2 y establezca el límite de saltos de metadatos en 1
• Valide las URL salientes y use una lista de permitidas en las funciones de obtención
• Bloquee las solicitudes a rangos de IP locales al enlace y privados después de resolver el DNS
• Aplique el principio de mínimo privilegio a los roles de las instancias para limitar las credenciales robadas

Los roles con privilegios mínimos garantizan que incluso un robo exitoso tenga consecuencias limitadas.

Las pruebas de SSRF pueden alcanzar deliberadamente sistemas internos sensibles. Actúe con disciplina:

• Confirme que el host objetivo y la cuenta de la nube están dentro del alcance
• No se desplace hacia sistemas ajenos al encargo
• Deténgase e informe en cuanto haya demostrado el acceso a las credenciales

Acceder a los metadatos tiene un gran impacto: demuéstrelo con cuidado y no utilice sin control las claves robadas.

Ha aprendido la cadena de ataque específica de la nube con mayor impacto.

• El servicio de metadatos en 169.254.169.254 proporciona las credenciales del rol de la instancia
• SSRF permite que un atacante haga que el servidor consulte ese endpoint
• Las credenciales temporales robadas permiten tomar el control de la cuenta
• IMDSv2 bloquea la mayoría de los ataques SSRF al requerir un token basado en PUT
• Defiéndase mediante listas de permitidas para URL, validación de IP y roles con privilegios mínimos

Con esto termina Pentesting de la nube. Siguiente curso: Bug Bounty Hunting.