> For the complete documentation index, see [llms.txt](https://4lec4st.gitbook.io/4lec4st/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://4lec4st.gitbook.io/4lec4st/writes-ups/dockerlabs/easy/reflection.md).

# Reflection

## Información de la máquina

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

**Reflection** es una máquina de nivel fácil en plataformas como Hack The Box, diseñada para enseñar y practicar técnicas relacionadas con **Cross-Site Scripting** (XSS), un tipo de vulnerabilidad en aplicaciones web.

A través de esta máquina, aprenderemos a identificar y explotar diferentes tipos de XSS, como:

1. **XSS Reflejado (Reflected XSS)**: Este tipo de XSS ocurre cuando los datos proporcionados por el usuario en la URL o en una solicitud HTTP son reflejados directamente en la respuesta sin ser filtrados ni validados. Esto puede permitir que un atacante ejecute código JavaScript malicioso en el navegador de la víctima, comprometiendo así su seguridad.
2. **XSS Almacenado (Stored XSS)**: En este caso, el código malicioso enviado por el atacante es almacenado de forma persistente en el servidor y luego se refleja cada vez que otros usuarios visitan una página vulnerable. A diferencia del XSS reflejado, este tipo de vulnerabilidad es más grave porque el código malicioso persiste en el servidor.

En cuanto a la **escalada de privilegios**, la máquina nos enseña cómo explotar una vulnerabilidad en un binario que tiene permisos de **sudo mal implementados**. Esto significa que un binario en el sistema ha sido configurado de manera incorrecta, permitiendo que un usuario con pocos privilegios (por ejemplo, un usuario normal) ejecute ese binario como **root** (superusuario) sin tener los permisos necesarios. Esta es una técnica común para escalar privilegios en sistemas comprometidos.

***

## Reconocimiento

La fase de **reconocimiento** es el primer paso a la hora de resolver una máquina. Su objetivo es recopilar la mayor cantidad de información posible sobre el sistema objetivo, permitiendo entender su estructura, tecnología y posibles vectores de ataque.&#x20;

Empezaremos haciendo un ping a la máquina víctima para ver si está encendida y ante que nos enfrentamos.

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

Si recibimos respuesta, significa que la máquina está en línea. Además, observamos que el **TTL** (Time To Live) es **64**, lo que indica que es un sistema **Linux** (normalmente, los sistemas Windows tienen un TTL de 128).&#x20;

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

**1. `-p-` → Escaneo de todos los puertos (1-65535)**

Por defecto, `nmap` solo escanea los **1000 puertos más comunes**.\
Con `-p-`, forzamos a que escanee **los 65535 puertos** de la máquina objetivo, lo que puede ser útil para encontrar servicios que corren en puertos poco convencionales.

**2. `--open` → Filtrar solo los puertos abiertos**

Cuando escaneamos un sistema, muchos puertos pueden estar cerrados o filtrados por un firewall.\
Este parámetro hace que `nmap` **solo muestre los puertos abiertos**, reduciendo el ruido y facilitando el análisis.

**3. `-sS` → Stealth Scan (Escaneo Sigiloso con SYN)**

Es conocido como **"TCP SYN Scan"**, y funciona de la siguiente manera:

* `nmap` envía un paquete **SYN** (solicitud de conexión).
* &#x20;Si el puerto está abierto, el servidor responde con **SYN-ACK**.
* En lugar de completar la conexión con un **ACK**, `nmap` responde con un **RST (Reset)**, interrumpiendo la comunicación.

**4. `--min-rate 5000` → Velocidad mínima de paquetes (5000 por segundo)**

Por defecto, `nmap` ajusta dinámicamente la velocidad de los paquetes según la respuesta de la red.\
Con `--min-rate 5000`, obligamos a `nmap` a **no enviar menos de 5000 paquetes por segundo**, acelerando el escaneo.

**5. `-n` → Deshabilitar resolución DNS**

Normalmente, `nmap` intenta resolver el nombre de dominio de las IPs escaneadas (DNS lookup).\
Con `-n`, evitamos esta resolución de nombres, lo que **acelera el escaneo** y evita que los servidores DNS registren nuestra actividad.

**6. `-Pn` → Omitir detección de host (Host Discovery Off)**

Por defecto, `nmap` envía paquetes ICMP (ping) para ver si un host está activo antes de escanearlo.\
Si un firewall bloquea los pings, `nmap` puede marcarlo como "host down" y no escanearlo.

**7. `-oG`** **→ Exportar el contenido en formato grepeable**

Todo el resultado del escaneo lo exportaremos en un archivo llamado **`puertos` .**

El escaneo revela 2 puertos abiertos, puerto 22(SSH) y puerto 80(HTTP). Ahora realizamos un escaneo más avanzado sobre estos 2 puertos

<figure><img src="/files/712N1QF1xHeeBS6ZeE3J" alt=""><figcaption></figcaption></figure>

**1. `-p22,80` → Escaneo de puertos específicos**

Con `-p22,80`, le indicamos que **solo** escanee los puertos **22 (SSH)** y **80 (HTTP)**

**2. `-sCV` → Escaneo de versiones y scripts básicos**

Este parámetro en realidad es **dos combinaciones en una**:

* **`-sC`** → Activa los **NSE scripts por defecto** en `nmap` (similar a usar `--script=default`).\
  Ejecuta scripts básicos para enumerar información del servicio detectado, como banners, versiones, etc.
* **`-sV`** → Realiza **fingerprinting de versiones**, intentando identificar la versión exacta del software en cada puerto abierto.

**3. `-oN` → Guardar el resultado en formato Normal**

Por defecto, `nmap` muestra los resultados en pantalla, pero con **`-oN targeted`**, guardamos el resultado en un archivo en **formato legible para humanos**.

Si visitamos la página web vemos la página por defecto de apache2

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

***

## Enumeración y búsqueda de vulnerabilidades

Enumeramos directorios, y archivo con GoBuster:

{% hint style="success" %}
**Gobuster** es una herramienta de software escrita en el lenguaje de programación **Go** que se utiliza para encontrar directorios y archivos ocultos en sitios web mediante ataques de fuerza bruta.
{% endhint %}

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

Descubrimos un archivo llamado `index.html`. Al abrirlo, observamos que contiene lo siguiente:

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

***

## Explotación de las vulnerabilidades

### Laboratorio 1

Si introducimos código HTML como, por ejemplo:

```html
h<h1>Pwned</h1>
```

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

Observamos que el contenido se renderiza directamente en la página. Esto indica que existe una vulnerabilidad de tipo XSS Reflected, ya que el código HTML que insertamos es interpretado por el navegador. Por lo tanto, completamos el primer reto.

### Laboratorio 2

Insertamos nuevamente código HTML:

```html
<h1>Pwned</h1>
```

Y después añadimos otro fragmento:

```html
<h2>Hacked!</h2>
```

<figure><img src="/files/5j7iBgBDS5ZgxLhPoJ82" alt=""><figcaption></figcaption></figure>

Vemos que ambos fragmentos se muestran correctamente en la página y que el contenido permanece almacenado. Esto nos confirma que la aplicación guarda y muestra el contenido sin validarlo, lo cual puede escalar hacia una vulnerabilidad de tipo **Stored XSS (Cross-Site Scripting)**. Pasamos al siguiente reto.

### Laboratorio 3

En este laboratorio se nos permite seleccionar algunas opciones predeterminadas a través de la interfaz.

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

Posteriormente, si modificamos manualmente los parámetros en la URL, cambiando los valores por otros personalizados, vemos que el contenido mostrado en la página también cambia en función de lo que pasamos por la URL.

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

Esto indica que hay una vulnerabilidad basada en **reflejo de parámetros** (posible XSS reflejado) pero con dropdowns

### Laboratorio 4

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

Si probamos a insertar un payload como el siguiente directamente en la URL:

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

El navegador ejecuta el código y se muestra la alerta, lo cual confirma una **vulnerabilidad de XSS reflejado**. Con esto finalizamos los retos de los cuatro laboratorios.

***

## Post Explotación y escalada de privilegios

Una vez resueltos los cuatro laboratorios, se habilita un botón en la interfaz. Al pulsarlo, obtenemos credenciales del contenedor vulnerable y se nos ofrece conectarnos mediante SSH.

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

Accedemos al contenedor usando las credenciales proporcionadas. Una vez dentro, exploramos el sistema en busca de archivos sensibles.

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

Este archivo contiene credenciales del usuario `balulito`, lo cual nos permite acceder con su cuenta dentro del mismo contenedor.

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

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

**Si enumeramos el sistema, vemos que el usuario `balulito` tiene permisos `sudo` sobre el binario `cp`:**

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

**Creamos una copia modificada del archivo `/etc/passwd` en `/tmp`, eliminando la `x` del usuario root:**

```bash
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
```

**Sobrescribimos el archivo original usando el binario `cp` con privilegios sudo:**

```bash
sudo cp /tmp/pass /etc/passwd
```

Al hacer esto, reemplazamos el archivo `/etc/passwd` del sistema con nuestra versión modificada, eliminando la contraseña del usuario root.

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

Ahora podemos usar el comando `su root` sin necesidad de contraseña y obtener una shell con privilegios de superusuario.

***

## Conclusión

La máquina **Reflection** es una excelente introducción a la explotación de vulnerabilidades web, específicamente en lo que respecta a **Cross-Site Scripting (XSS)**. A través de la resolución de los distintos laboratorios, los usuarios pueden familiarizarse con los diferentes tipos de XSS, como el **reflejado** y el **almacenado**, aprendiendo cómo estos pueden ser explotados para comprometer la seguridad de una aplicación web.