Metadatos en la nube: la superficie de ataque oculta

Todos los grandes proveedores de nube exponen un servicio de metadatos de instancia a las máquinas virtuales que se ejecutan en su plataforma, normalmente accesible en la dirección de enlace local 169.254.169.254. Desde dentro de la instancia, una simple solicitud HTTP a esa dirección puede devolver la configuración de la instancia, detalles de red y, en muchas configuraciones predeterminadas, credenciales de seguridad temporales del rol o la identidad que se haya asignado a la instancia.

Por qué es especialmente peligroso combinado con SSRF

Se supone que el endpoint de metadatos solo es accesible desde la propia instancia: no está expuesto a internet. Pero si se puede engañar a un proceso del lado del servidor para que haga una solicitud HTTP a una dirección elegida por el atacante (el SSRF clásico), y esa dirección resulta ser el endpoint de metadatos, el atacante consigue que el servidor obtenga sus propias credenciales de nube y las entregue en la respuesta. No hace falta acceso de red directo al endpoint de metadatos desde fuera: el servidor vulnerable hace la petición en nombre del atacante.

• 169.254.169.254 se encuentra dentro del rango de enlace local más amplio 169.254.0.0/16, que nunca debería tratarse como un destino legítimo de resolución DNS pública.
• Algunos proveedores han adoptado una versión del servicio de metadatos protegida por token precisamente para dificultar los SSRF más simples, pero bloquear la dirección por completo en la capa de aplicación sigue siendo la defensa más sólida.
• Por eso mismo las direcciones de enlace local deben figurar en la misma lista de bloqueo que los rangos privados y de bucle local en cualquier herramienta que resuelva dominios proporcionados por el usuario: no es una categoría de riesgo distinta ni menor.

La conclusión práctica

Cualquier sistema que resuelva y solicite una URL en nombre de un usuario debe tratar 169.254.169.254, y el rango de enlace local más amplio al que pertenece, como estrictamente prohibido. Esa comprobación debe hacerse en el momento de la solicitud real y siempre, sin importar cómo se haya llegado a la dirección (escrita directamente o alcanzada mediante un registro DNS que apunta a ella).

No es exclusivo de un solo proveedor de nube

169.254.169.254 es, en concreto, la convención de AWS, Google Cloud y Azure, pero el patrón de fondo (una dirección de enlace local que expone la identidad y las credenciales de la instancia solo a la propia instancia) aparece de alguna forma en prácticamente todas las grandes plataformas de nube y de contenedores, a veces en la misma dirección y otras en una específica del proveedor. Los clústeres de Kubernetes suelen tener sus propios endpoints internos afines a los de metadatos, accesibles desde dentro de un pod. Conviene memorizar la dirección concreta de los proveedores de nube más habituales, pero lo que realmente se generaliza es el principio: tratar cualquier endpoint de tipo metadatos como territorio prohibido para todo lo que resuelva y obtenga una URL proporcionada por el usuario, sea cual sea la plataforma en la que se ejecute.

IMDSv2: una mitigación real, no solo un filtro

La respuesta de AWS a años de explotación de este mismo patrón fue una segunda versión de su servicio de metadatos, IMDSv2, que exige un token de sesión obtenido mediante una solicitud PUT especial antes de poder leer cualquier metadato. Y, lo que es crucial, esa solicitud PUT no puede replicarse con la simple solicitud GET que provoca un SSRF, que es la que realizan en realidad la mayoría de las rutas de código vulnerables.

Es una mejora significativa, pero en muchas cuentas es opcional por compatibilidad con versiones anteriores y protege únicamente el endpoint de metadatos: no hace nada frente al resto de direcciones privadas e internas a las que un SSRF todavía podría llegar. El filtrado a nivel de aplicación de las direcciones resueltas sigue siendo necesario, sea cual sea la versión del servicio de metadatos en uso.