Resumen
Los mejores reportes de SSRF no se quedan en "mira, el servidor hace una petición por mí": demuestran hasta dónde se puede llegar tirando del hilo. Este es de esos. Empieza con algo tan inofensivo como crear una tienda en Shopify y termina con una shell de root dentro de la infraestructura. El eslabón clave es que el sistema que generaba las capturas de pantalla de las tiendas ejecutaba el contenido de la plantilla password.liquid, y eso permitía dirigir peticiones al servicio de metadatos de Google Cloud.
Los identificadores, certificados y claves reales del reporte original aparecen tachados; aquí se conservan como [REDACTADO].
Pasos de reproducción
1. Alcanzar los metadatos de Google Cloud. Se crea una tienda y se edita password.liquid para que el renderizador, al hacer la captura, navegue al endpoint de metadatos:
<script>
window.location="http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token";
</script>El detalle bonito: el endpoint /v1beta1 seguía activo y no exigía la cabecera Metadata-Flavor: Google que normalmente protege estas rutas, así que devolvía el token de la cuenta de servicio igualmente. Añadiendo ?alt=json se forzaban respuestas en JSON y se filtraban aún más cosas (claves SSH públicas con correos, nombre del proyecto, de la instancia…).
2. Volcar kube-env. La metadata concealment de GKE no estaba activada, de modo que el atributo kube-env era accesible, y ahí dentro venían nada menos que el certificado y la clave privada del Kubelet.
3. Convertir eso en ejecución de comandos. Con ese certificado ya se podía hablar con el clúster usando kubectl: listar pods, crearlos, y —describiendo pods para sacar nombres de *secrets*— hacerse con el token de una cuenta de servicio de Kubernetes. Con ese token, shell de root dentro de los contenedores:
id
uid=0(root) gid=0(root) groups=0(root)Impacto
Resumiendo el viaje: de "puedo crear una tienda y editar una plantilla" a "ejecuto comandos como root en la infraestructura". Ese es el impacto real, y explica por qué un SSRF que a primera vista parece "solo lectura" merece tratarse como crítico: lo que se lee son las credenciales de la orquestación, y con ellas se controla todo lo demás.
Remediación
Tres frentes, y los tres importan: activar la metadata concealment de GKE, bloquear el acceso al endpoint heredado v1beta1 del servicio de metadatos, y —el más importante— aislar de la red interna cualquier componente que renderice o capture contenido del usuario. Si un sistema "abre" lo que le da un tercero, hay que asumir que ese tercero lo va a apuntar contra tus servicios internos.