Post

BugBountyLabs - Principiante: [Redirection]

Posted Updated
Preview Image
By Oscar Sanchez 7 min read
📛 Nombre: Redirect📈 Dificultad: Principiante💻 SO: Docker👨‍💻 Creador: Curiosidades De Hackers & El Pingüino de Mario

🕵️ Resolución del Bug Bounty: Redirect

Redirect es un laboratorio principiante ofrecido por la plataforma BugBountyLabs. Este laboratorio permite comprender y explotar una vulnerabilidad clásica de redirección abierta, utilizada comúnmente en ataques de phishing. A través de este writeup, exploraremos los pasos para identificar, analizar y explotar la vulnerabilidad, además de reflexionar sobre las posibles medidas de mitigación.

🌐 Entorno Inicial

Para comenzar, descargamos y ejecutamos el laboratorio provisto en formato Docker. BugBountyLabs nos facilita un script en Python que automatiza la creación del entorno.

📥 Descarga y Ejecución del Laboratorio

  1. Listamos el contenido del directorio:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

└─$ ls
bugbountylabs_redirection.py
                                                                                                                                                                                                        
└─$ sudo python3 bugbountylabs_redirection.py
        
Fundadores
El Pingüino de Mario
Curiosidades De Hackers

Cofundadores
Zunderrub
CondorHacks

Descargando la máquina redirection, espere por favor...

[########################################] 100%
Descarga completa.
La IP de la máquina es -> 172.17.0.2

Presiona Ctrl+C para detener la máquina

🔍 Enumeración

🚪 Análisis Inicial

Una vez desplegado el laboratorio y obtenida la dirección IP (172.17.0.2), verificamos la conectividad con la máquina mediante un comando ping. Este paso asegura que el laboratorio está accesible desde nuestra máquina anfitriona.

📡 Comprobación de Conexión

Ejecutamos el siguiente comando:

1

ping -c3 172.17.0.2

Salida del comando:

1
2
3
4
5
6
7
8

PING 172.17.0.2 (172.17.0.2) 56(84) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.244 ms
64 bytes from 172.17.0.2: icmp_seq=2 ttl=64 time=0.050 ms
64 bytes from 172.17.0.2: icmp_seq=3 ttl=64 time=0.072 ms

--- 172.17.0.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2036ms
rtt min/avg/max/mdev = 0.050/0.122/0.244/0.086 ms

🛠️ Observaciones

  • Conexión exitosa: Los paquetes fueron transmitidos y recibidos correctamente, confirmando la conectividad.
  • Sistema operativo: El TTL (time to live) de los paquetes es 64, lo que sugiere que la máquina objetivo es Linux.

Conectividad establecida, procedemos al siguiente paso para explorar los servicios expuestos en la máquina.

🔍 Enumeración

🚪 Escaneo de Puertos

Con la conectividad confirmada, realizamos un escaneo completo de puertos en la máquina objetivo utilizando nmap. Esto nos permite identificar servicios activos y obtener información detallada sobre ellos.

Ejecutamos el siguiente comando:

1

sudo nmap -sSCV -p- -Pn -n --min-rate 5000 172.17.0.2

Salida del escaneo:

1
2
3
4
5
6
7
8
9

Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-01-07 10:10 CET
Nmap scan report for 172.17.0.2
80/tcp open  http    Apache httpd 2.4.62 ((Debian))
|_http-server-header: Apache/2.4.62 (Debian)
|_http-title: Laboratorio de Open Redirect
MAC Address: 02:42:AC:11:00:02 (Unknown)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.01 seconds

🛠️ Observaciones del Escaneo

  • Servicio activo: El puerto 80 está abierto y sirve contenido a través de un servidor web Apache 2.4.62 (Debian).
  • Título del sitio: “Laboratorio de Open Redirect”, lo que confirma que el objetivo está relacionado con el tema del laboratorio.

🌐 Análisis HTTP

Con el puerto 80 identificado como activo, inspeccionamos el servicio web utilizando WhatWeb para obtener más información sobre las tecnologías subyacentes.

Ejecutamos el siguiente comando:

1

whatweb http://172.17.0.2

Salida del comando:

1

http://172.17.0.2 [200 OK] Apache[2.4.62], Country[RESERVED][ZZ], HTML5, HTTPServer[Debian Linux][Apache/2.4.62 (Debian)], IP[172.17.0.2], Title[Laboratorio de Open Redirect]

🛠️ Observaciones del Análisis

  • Servidor web: Apache 2.4.62 en Debian Linux.
  • Tecnologías: HTML5.
  • Estado del servidor: Todo parece estar correctamente configurado, sin errores evidentes en los encabezados HTTP o el contenido inicial.

Con esta información, estamos listos para explorar más a fondo el sitio web y buscar parámetros o funcionalidades susceptibles a un Open Redirect.

Web

🧪 Laboratorio 1: Redirección Básica

Accedemos al Laboratorio 1, donde se nos presenta un botón con la funcionalidad de redirigirnos a otro sitio. Al hacer clic, somos redirigidos a http://google.com.

🚩 Observación

La URL del botón es la siguiente:

1

http://172.17.0.2/laboratorio1/redirect.php?url=http://google.com

🛠️ Explotación

Modificamos el parámetro url para redirigir a un sitio de nuestra elección. Cambiamos la URL del enlace a:

1

http://172.17.0.2/laboratorio1/redirect.php?url=https://thehackerslabs.com/

Web

Resultado:

  • La aplicación redirige correctamente a https://thehackerslabs.com/.

Web

✅ Conclusión

El laboratorio demuestra un Open Redirect básico, donde la validación del parámetro url no existe, permitiendo redirigir a cualquier sitio arbitrario. Este comportamiento puede ser explotado en ataques de phishing u otras técnicas maliciosas.

Laboratorio 1 completado con éxito.

🧪 Laboratorio 2: Redirección con Validación

Accedemos al Laboratorio 2, que presenta un botón similar al del Laboratorio 1. Al hacer clic, somos redirigidos a https://www.google.com.

🚩 Observación

La URL del botón es la siguiente:

1

http://172.17.0.2/laboratorio2/redirect.php?url=https://www.google.com

Intentamos modificar el parámetro url para redirigir a un sitio diferente:

1

http://172.17.0.2/laboratorio2/redirect.php?url=https://elrincondelhacker.es/

Resultado:

  • La aplicación detecta el cambio y muestra un mensaje de alerta:

    “Redirección no permitida. Solo puedes redirigirte a Google.”

🛠️ Explotación

Para evadir la validación, utilizamos un método conocido como redirección con autenticación embebida. Modificamos la URL para incluir el dominio permitido como parte del usuario en la autenticación HTTP básica:

1

http://172.17.0.2/laboratorio2/redirect.php?url=https://www.google.com@elrincondelhacker.es/

Resultado:

  • Al acceder, el navegador muestra un aviso:

    “You are about to log in to the site ‘elrincondelhacker.es’ with the username ‘www.google.com’, but the website does not require authentication. This may be an attempt to trick you. Is ‘elrincondelhacker.es’ the site you want to visit?”

  • Confirmamos con “Yes” y somos redirigidos correctamente a https://elrincondelhacker.es/.

Web Web

✅ Conclusión

La aplicación no valida correctamente la URL al interpretar https://www.google.com@elrincondelhacker.es/. Este método permite evadir restricciones al incluir el dominio permitido como un identificador de autenticación en la URL.

Laboratorio 2 completado con éxito.

🧪 Laboratorio 3: Redirección con Validación Estricta

El Laboratorio 3 tiene un diseño similar a los anteriores, con un botón que redirige a https://www.google.com. Sin embargo, la validación en este caso es más estricta, bloqueando los métodos utilizados en los laboratorios previos.

🚩 Observación

El enlace del botón es el siguiente:

1

http://172.17.0.2/laboratorio3/redirect.php?url=https://www.google.com

Intentamos modificar el parámetro url como en los laboratorios anteriores:

  1. Cambio directo de URL:
    1

    http://172.17.0.2/laboratorio3/redirect.php?url=https://bugbountylabs.com/

    Resultado:

    “Redirección no permitida. Solo puedes redirigirte a Google.”

  2. Uso del método de autenticación embebida:
    1

    http://172.17.0.2/laboratorio3/redirect.php?url=https://www.google.com@https://bugbountylabs.com/

    Resultado:

    “Redirección no permitida. Solo puedes redirigirte a Google.”

A pesar de los intentos, los métodos anteriores fallan debido a las validaciones adicionales implementadas en la aplicación. Sin embargo, al hacer clic en el botón, somos redirigidos correctamente a https://www.google.com.

🛠️ Explotación

Nos preguntamos: ¿Qué ocurre si usamos un enlace válido de Google pero que apunte a otra página o dominio?

Modificamos el parámetro url para apuntar a una búsqueda de Google, como la siguiente:

1

http://172.17.0.2/laboratorio3/redirect.php?url=https://www.google.com/search?q=bugbountylabs

Resultado:

  • La aplicación redirige correctamente al enlace de búsqueda de Google:

    https://www.google.com/search?q=bugbountylabs.

✅ Explicación del Método

La validación de la aplicación se limita a verificar si el dominio base contiene www.google.com, pero no inspecciona ni valida correctamente el resto del enlace. Esto permite aprovechar cualquier subdominio, ruta, o enlace que tenga www.google.com como parte del dominio, sin importar su autenticidad o contenido.

Por ejemplo, en este caso usamos un enlace dentro del dominio principal: 172.17.0.2/laboratorio3/redirect.php?url=https://www.google.com/search?q=bugbountylabs&sca_esv=7caec7b3ee93c0f3&source=hp&ei=JAF9Z9_cKbvj5NoPkObqmA8&iflsig=AL9hbdgAAAAAZ30PNPh_qj6ISjaNs5tFzfOEUQWE5nkJ&ved=0ahUKEwjf_sfVsuOKAxW7MVkFHRCzGvMQ4dUDCBA&uact=5&oq=bugbountylabs.

Este enlace redirige a una búsqueda de Google que muestra resultados para “bugbountylabs”. Sin embargo, también habría funcionado un subdominio como www.analisis.google.com, ya que la validación no distingue entre dominios legítimos y subdominios, lo que amplía las posibilidades de explotación. Esto puede ser aprovechado para confundir al usuario y redirigirlo a contenido malicioso o no deseado bajo la apariencia de un dominio confiable.

Web Web

🎉 Conclusión del Laboratorio 3

Este laboratorio demuestra cómo incluso con validaciones más estrictas, los Open Redirects pueden ser explotados utilizando enlaces válidos dentro de dominios permitidos. Este método es especialmente útil cuando la aplicación solo permite un conjunto restringido de dominios y valida únicamente el dominio base.

Laboratorio 3 completado con éxito.

🎉 Agradecimientos

Un agradecimiento especial a Curiosidades De Hackers y El Pingüino de Mario por diseñar este interesante reto en BugBountyLabs. La creatividad y atención al detalle en cada uno de los laboratorios son un excelente ejemplo de cómo aprender sobre vulnerabilidades en un entorno seguro y controlado.

🏁 Reflexión Final

Este conjunto de laboratorios nos permitió explorar diferentes enfoques para explotar vulnerabilidades de Open Redirect, desde redirecciones básicas hasta métodos más avanzados que implican evadir validaciones. Entre los aprendizajes clave están:

  1. Conocer las validaciones de la aplicación: Identificar cómo funcionan las restricciones y buscar formas de evadirlas.
  2. Aprovechar comportamientos permisivos: Como el uso de subdominios o enlaces válidos dentro de un dominio permitido.
  3. Pensar de forma creativa: Las vulnerabilidades no siempre son evidentes; a veces requieren explorar caminos indirectos para su explotación.

Espero que este writeup haya sido útil para comprender mejor las vulnerabilidades de Open Redirect y cómo abordarlas en un entorno de Bug Bounty. ¡Nos vemos en el próximo desafío! 🚀

Bug Bounty, Writeups
Bug Bounty Writeups BugBountyLabs Docker Principiante
This post is licensed under CC BY 4.0 by the author.