> 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/pinguinazo.md).
# Pinguinazo
## Información de la máquina
Pinguinazo es una máquina Linux catalogada con dificultad fácil que presenta una vulnerabilidad de Server-Side Template Injection (SSTI). A través de esta falla, lograremos obtener acceso inicial al sistema. Posteriormente, en la fase de escalada de privilegios, identificaremos permisos de ejecución con `sudo` sobre Java, lo que nos permitirá generar una reverse shell y obtener privilegios máximos en la máquina.
***
## 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.
Empezaremos haciendo un ping a la máquina víctima para ver si está encendida y ante que nos enfrentamos.
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).
**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 65,535 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).
* 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 que el puerto 5000 está abierto. Ahora realizamos un escaneo más detallado:
**1. `-p5000` → Escaneo de puertos específicos**
Con `-p5000`, le indicamos que **solo** escanee los puertos 5000 **(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**.
Al parecer tenemos una web por el puerto 5000, por lo que vamos a visitarla:
***
## Enumeración y búsqueda de vulnerabilidades
Completamos el formulario de la aplicación con un nombre y hacemos clic en el botón de envío. Observamos la respuesta que genera el sistema para analizar si hay algún comportamiento inesperado.
La aplicación nos devuelve un mensaje del tipo "Hello \". Esto indica que el valor ingresado se refleja en la página sin ser filtrado adecuadamente. Para comprobar si es vulnerable, intentaremos una inyección de código HTML (`HTML Injection`) o una inyección de plantilla del lado del servidor (`SSTI`).
***
## Explotación de las vulnerabilidades
Probamos a introducir código HTML en el campo del formulario, por ejemplo:
```html
test
```
Al enviarlo, vemos que la aplicación lo interpreta y lo renderiza como HTML en la página. Esto confirma que es vulnerable a `HTML Injection`. Ahora verificaremos si también es vulnerable a `SSTI`.
{% hint style="success" %}
Server-Side Template Injection (SSTI) ocurre cuando un atacante puede inyectar código dentro de una plantilla de renderizado del servidor. Si el servidor usa motores de plantillas como Jinja2 (Python), Twig (PHP) o Velocity (Java), podemos ejecutar código en el sistema.
{% endhint %}
Para comprobar si el sistema es vulnerable a SSTI, introducimos en el formulario:
```jinja
{{7*7}}
```
Si la respuesta muestra `49`, significa que el servidor está evaluando las expresiones dentro de la plantilla. Esto nos permite buscar exploits para ejecutar comandos en la máquina.
Investigamos exploits específicos para `Jinja2`, el motor de plantillas en Python. Encontramos un `oneliner` que nos permite ejecutar comandos del sistema. Probamos introduciendo un comando como `id` para ver si se ejecuta correctamente.
Si logramos ejecutar comandos, podemos aprovecharlo para obtener acceso remoto. En lugar de `id`, usamos un comando para establecer una `reverse shell`, conectando la máquina víctima con nuestra máquina atacante en el puerto `443`.
Para facilitar la explotación, creamos un script `.sh` que contendrá el código necesario para establecer la `reverse shell`.
Subimos el archivo `.sh` a nuestra máquina atacante y lo servimos a través de un servidor HTTP en el puerto `80`:
Desde la máquina víctima, descargamos el archivo `.sh` usando `curl`:
Si todo ha funcionado correctamente, nuestra máquina atacante recibirá la conexión de la víctima, obteniendo acceso remoto a través de `netcat`.
***
## Post Explotación y escalada de privilegios
Enumerando el sistema, vemos que podemos ejecutar `java` como `sudo` sin necesidad de contraseña. Esto nos da la oportunidad de escalar privilegios.
Aprovechamos la capacidad de ejecutar `java` con privilegios `sudo` para lanzar una shell con permisos de `root`.
Nos dirigimos al directorio `/tmp` y creamos un archivo `Exploit.java` con el siguiente código:
En nuestra máquina atacante, preparamos `netcat` para recibir la conexión en el puerto `1234`:
Si todo ha salido bien, nuestra sesión de `netcat` recibirá una conexión desde la máquina víctima con permisos de `root`, lo que nos da control total del sistema.
***
## Conclusión
La explotación de Pinguinazo nos ha permitido aplicar técnicas clave en auditorías de seguridad, desde la identificación y explotación de SSTI hasta la escalada de privilegios mediante el uso de `sudo` con Java. Este escenario refuerza la importancia de mitigar vulnerabilidades en aplicaciones web y restringir adecuadamente los permisos en entornos Linux para evitar accesos no autorizados.