Un filtro SSRF que bloquea 127.0.0.1 y los rangos privados es lo estándar. La mayoría de investigadores se topa con ese muro y pasa al siguiente endpoint. La forma de saltárselo no es un payload, es la brecha temporal entre cuando la aplicación valida la URL y cuando la pide de verdad.
La forma del ataque:
Envías una URL con un dominio que controlas. Digamos my-ssrf-test.com. El backend la valida resolviendo el dominio y comprobando la dirección IP. Tu registro DNS apunta a una IP pública en ese momento, así que la validación pasa. La URL se marca como segura y se almacena en el sistema.
;; Antes de enviar (pública, pasa la lista blanca)
my-ssrf-test.com. 5 IN A 203.0.113.42Ahora viene la parte interesante.
Después de que pase la validación, cambias el registro A de DNS de tu dominio. Lo apuntas a 127.0.0.1 o cualquier IP interna que quieras atacar. El dominio sigue siendo el mismo. La URL sigue siendo la misma. Pero hacia dónde resuelve ha cambiado.
;; Después de la validación (redirigido al interior del perímetro)
my-ssrf-test.com. 5 IN A 127.0.0.1Si la aplicación solo comprobó la IP durante la validación inicial pero resuelve el dominio de nuevo cada vez que hace una petición, tu URL previamente validada como "segura" ahora apunta a localhost o servicios internos.
El backend confía en el dominio porque pasó la validación. No vuelve a comprobar hacia dónde apunta realmente ese dominio antes de hacer peticiones posteriores. El filtro SSRF se evita a través del timing en lugar de la explotación.
Esto es una especie de race condition. Estás compitiendo para cambiar el registro DNS después de la validación pero antes de que se haga la petición real. En algunos casos, hay tiempo suficiente para hacer esto manualmente. En otros, necesitas automatizarlo o usar servicios DNS que soporten cambios rápidos de TTL.
¿Por qué funciona esto? Dos razones.
Primero, muchas aplicaciones separan la validación de la ejecución. Comprueban la IP cuando envías la URL, la almacenan como segura y luego confían en esa validación para peticiones futuras sin volver a comprobar. La suposición es que un dominio no cambiará hacia dónde apunta. Esa suposición es incorrecta.
Segundo, el comportamiento del caché DNS varía. Algunas aplicaciones cachean las búsquedas DNS agresivamente. Otras no cachean en absoluto y resuelven el dominio de nuevo cada vez. Buscas las últimas. Si la aplicación no cachea resultados DNS pero tampoco revalida IPs en cada petición, tienes una ventana.
El impacto depende de qué esté ejecutándose internamente. Servicios localhost. APIs internas. Endpoints de metadatos cloud. Cualquier cosa accesible desde la perspectiva del servidor se vuelve accesible para ti a través del SSRF.
He usado esta técnica para acceder a:
- Paneles de admin internos ejecutándose en localhost
- Servicios de metadatos cloud (169.254.169.254)
- Microservicios internos no expuestos a internet
- Interfaces de gestión de bases de datos
- Dashboards de monitorización internos
Cada vez, el SSRF inicial parecía bloqueado. Los filtros estándar pillaban intentos directos de llegar a localhost o IPs privadas. Pero el bypass de DNS rebinding funcionó porque la lógica de validación no tenía en cuenta que los registros DNS cambiaran después.
Este es un caso extremo. La mayoría de filtros SSRF o cachean las búsquedas DNS correctamente o revalidan en cada petición. Cuando encuentras una aplicación que no hace ninguna de las dos, la técnica convierte un SSRF bloqueado en un pivote hacia la red interna.
La solución es directa. Las aplicaciones deberían:
- Resolver y validar la IP en cada petición, no solo en la primera
- Cachear las búsquedas DNS y usar la IP cacheada para la petición real
- Implementar tanto la validación como la ejecución usando la misma IP resuelta
La mayoría no lo hacen. Validan una vez, confían en el dominio y lo resuelven de nuevo más tarde. Esa brecha es lo que hace que esto funcione.
Probar esto requiere algo de preparación. Necesitas un dominio que controles con la capacidad de cambiar registros DNS rápidamente. Algunos proveedores DNS soportan valores TTL muy bajos y propagación instantánea. Úsalos. Envía tu URL, espera la validación, cambia el DNS y luego dispara la petición que usa la URL almacenada.
El timing importa. Si la aplicación cachea DNS durante cualquier duración significativa, esto no funcionará. Si revalida IPs antes de cada petición, esto no funcionará. Buscas el caso específico donde la validación ocurre una vez pero la resolución DNS ocurre múltiples veces sin revalidación.
Cuando funciona, documéntalo con cuidado. Muestra la validación inicial con la IP pública. Muestra el cambio DNS. Muestra la petición posterior llegando al objetivo interno. Deja claro que la vulnerabilidad existe por la brecha entre validación y ejecución.
No funciona a menudo. Cuando funciona, el impacto es alcance total a la red interna desde un parámetro que parecía aislado. Tenla en el repertorio para hallazgos SSRF donde el filtro bloquea los intentos obvios contra localhost e IPs privadas.
