Darkweb

Introducción

Este documento presenta la resolución completa de la máquina Darkweb, desarrollada por d1se0 para la plataforma DockerLabs, clasificada con una dificultad Media.

El laboratorio expone servicios SMB accesibles sin autenticación, desde donde se extrae un archivo con texto cifrado mediante César. Tras descifrarlo, se obtiene un enlace .onion que conduce a un sitio oculto en la red Tor, donde se descubren un usuario y una lista de contraseñas ocultos en el código fuente de las páginas.

Con esta información, se realiza un ataque de fuerza bruta contra el servicio SSH, obteniendo acceso como el usuario dark.

Tras el acceso inicial, se identifica que el usuario puede ejecutar un script Python (hidden.py) como root mediante sudo. Este script llama a su vez a un archivo Bash (Update.sh) en un directorio donde el usuario tiene permisos de escritura, permitiendo modificar su contenido para otorgar privilegios SUID a /bin/bash y así escalar a superusuario.

Todo el proceso se llevó a cabo dentro de un entorno controlado con fines estrictamente educativos.

---

Información Técnica

Atributo	Valor
Nombre	Darkweb
Autor	d1se0
Dificultad	Medio
Fecha	17/12/2024
Plataforma	DockerLabs
IP Objetivo	172.17.0.2

---

Paso 0 — Despliegue y preparación

Se descomprime la máquina y se despliega utilizando el script proporcionado:

unzip Darkweb.zip
sudo bash auto_deploy.sh Darkweb.tar

Una vez iniciado el contenedor, se asigna la dirección IP correspondiente.

Se organiza el entorno de trabajo para mantener una estructura clara durante el análisis:

mkdir -p Darkweb/{content,exploits,nmap,scripts}
cd Darkweb

---

Paso 1 — Reconocimiento

1.1 Escaneo de puertos

Se realiza un escaneo completo de puertos TCP para identificar servicios expuestos:

nmap -p- --open -sS --min-rate 5000 -vvv -n 172.17.0.2 -oG allPorts
extractPorts allPorts

El resultado muestra los siguientes servicios accesibles externamente:

• 22/tcp — SSH
• 139/tcp — SMB
• 445/tcp — SMB

---

1.2 Enumeración de servicios

Dado que tenemos varios servicios abiertos, realizamos un escaneo de posibles vulnerabilidades con nmap:

nmap -sCV -p22,139,445 172.17.0.2

Lo más resaltante es que el servicio SMB no requiere usuario ni contraseña para acceder:

---

1.3 Enumeración SMB

Realizamos un escaneo con enum4linux para descubrir los recursos compartidos (shares):

enum4linux -a 172.17.0.2

Encontramos lo siguiente:

---

Paso 2 — Explotación (acceso inicial)

Lo primero que hacemos es conectarnos por SMB al recurso compartido para detectar archivos interesantes:

smbclient \\\\172.17.0.2\\darkshare

Aquí observamos varios archivos:

Todos ellos los descargamos para su análisis. Al abrirlos, el único que contenía algo interesante fue el archivo ilegal.txt, con el siguiente contenido:

Parece ser una frase en cifrado César, por lo que la analizamos en una página especializada, obteniendo el siguiente resultado:

El texto descifrado contiene un enlace .onion. Lo abrimos en el navegador Tor, y nos dirige al índice:

Esta página contiene varios enlaces, pero hay un endpoint /darkweb.html que visitamos. También contiene múltiples enlaces. Revisando el código fuente de cada enlace, notamos algunas cosas interesantes:

• marketplace.html: aquí nos da una función que contiene un archivo de contraseñas que guardaremos por su utilidad:

• redroom.html: también hay código JavaScript que simula un “hackeo”. Dentro del mismo hay un usuario:

Debido a que tenemos una lista de contraseñas y un posible usuario (dark), realizamos un ataque de fuerza bruta con Hydra:

hydra -l dark -P passwordList ssh://172.17.0.2 -I

Esto nos da un resultado rápidamente:

Con esto ya podemos acceder por SSH mediante ssh dark@172.17.0.2:

Obtenemos acceso a la máquina víctima.

---

Paso 3 — Escalada de privilegios

3.1 De dark → root

Lo primero que hacemos es listar los permisos con sudo -l:

Esto nos indica que podemos ejecutar el script hidden.py como el usuario root. Además, dicho script es propiedad de root. Revisamos su código:

/home/dark/hidden.py

#!/bin/python3

import subprocess

# Ruta al archivo Update.sh
script_path = '/usr/local/bin/Update.sh'

# Ejecutar el script de Bash
try:
    subprocess.run(['bash', script_path], check=True)
    print("Script ejecutado con éxito.")
except subprocess.CalledProcessError as e:
    print(f"Hubo un error al ejecutar el script: {e}")

Este script llama al archivo /usr/local/bin/Update.sh, que no podemos modificar directamente, pero el directorio padre /usr/local/bin sí es modificable por nuestro usuario. Por lo tanto, eliminamos el archivo original y creamos uno nuevo con el siguiente contenido:

/usr/local/bin/Update.sh

#!/bin/bash
chmod u+s /bin/bash

Después de esto, ejecutamos cómodamente el script Python con sudo:

sudo ./hidden.py

Y listo, tenemos permisos de administrador:

---

Análisis de Vulnerabilidades

Fallos de Seguridad Identificados

Vulnerabilidad	Severidad	Impacto
SMB accesible sin autenticación	Alta	Exposición de archivos sensibles del sistema
Almacenamiento de texto cifrado (César) en archivo accesible	Media	Ofuscación trivial que no impide la lectura
Exposición de credenciales y contraseñas en código fuente JavaScript	Alta	Permite obtener usuario y lista de contraseñas desde el cliente
Servicio SSH accesible con contraseña débil	Alta	Ataque de fuerza bruta exitoso
Permiso sudo para script Python (hidden.py) sin restricciones	Crítica	Permite ejecutar código como root indirectamente
Escritura en directorio /usr/local/bin por usuario no privilegiado	Crítica	Permite reemplazar Update.sh con código malicioso
El script hidden.py llama a un script Bash sin validar su integridad	Alta	Facilita la sustitución del archivo invocado

---

Recomendaciones de Mitigación

• Proteger el servicio SMB con autenticación adecuada y nunca exponer recursos compartidos sin credenciales en entornos de producción.
• No almacenar archivos con información sensible (incluso si están cifrados de forma trivial) en recursos accesibles públicamente.
• Evitar incluir credenciales o listas de contraseñas en el código fuente del lado del cliente (HTML/JS). Cualquier lógica sensible debe manejarse en el servidor.
• Implementar políticas de contraseñas seguras y sistemas de bloqueo por intentos fallidos (fail2ban, rate limiting) para servicios como SSH.
• Revisar y endurecer las configuraciones de sudo: restringir qué scripts pueden ejecutarse y asegurarse de que no llamen a otros archivos modificables por el usuario.
• Aplicar el principio de mínimo privilegio: los usuarios no deberían tener permisos de escritura en directorios del sistema como /usr/local/bin.
• Validar la integridad de los scripts invocados (por ejemplo, mediante sumas de verificación) antes de ejecutarlos con privilegios elevados.