WriteUp: Breakout | VulnHub

Fase 1: Reconocimiento y Enumeración de Servicios

Mi análisis comenzó con un escaneo exhaustivo de la red para identificar los servicios expuestos. Utilicé nmap con un escaneo rápido de todos los puertos TCP para obtener una visión inicial de la superficie de ataque.

nmap -n -Pn -sS -p- --min-rate 5000 192.168.56.33

PORT      STATE SERVICE
80/tcp    open  http
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
10000/tcp open  snet-sensor-mgmt
20000/tcp open  dnp

El escaneo inicial reveló cinco puertos abiertos. Para obtener información más detallada sobre los servicios y sus versiones, procedí con un segundo escaneo más profundo, enfocado en los puertos descubiertos.

nmap -sVC -p80,139,445,10000,20000 192.168.56.33

PORT      STATE SERVICE     VERSION
80/tcp    open  http        Apache httpd 2.4.51 ((Debian))
139/tcp   open  netbios-ssn Samba smbd 4
445/tcp   open  netbios-ssn Samba smbd 4
10000/tcp open  http        MiniServ 1.981 (Webmin httpd)
20000/tcp open  http        MiniServ 1.830 (Webmin httpd)

Los resultados de este segundo escaneo fueron mucho más reveladores:

  • Puerto 80: Un servidor web Apache estándar.

  • Puertos 139/445: Servicios Samba, lo que indica una posible compartición de archivos o integración con entornos Windows.

  • Puertos 10000 y 20000: Dos instancias de Webmin, una interfaz de administración de sistemas basada en la web, cada una con una versión diferente del servidor MiniServ.

Fase 2: Análisis de Vectores y Acceso Inicial

2.1 Enumeración Web y Criptografía Esotérica

Al inspeccionar el servicio web en el puerto 80, me encontré con la página por defecto de Apache, la cual no ofrecía información útil a simple vista.

Sin embargo, una revisión del código fuente HTML reveló un comentario que contenía un mensaje y una cadena de caracteres crípticos.

Reconocí inmediatamente el formato como Brainfuck, un lenguaje de programación esotérico conocido por su minimalismo extremo. Utilicé un decodificador en línea (dcode.fr) para traducir el código, obteniendo la siguiente cadena de texto:

Esta cadena tenía todas las características de una contraseña compleja. La guardé para su uso posterior.

2.2 Enumeración de Samba

La presencia de los puertos 139 y 445 (Samba) me llevó a utilizar enum4linux, una herramienta diseñada para extraer información de estos servicios, como listas de usuarios, recursos compartidos y políticas de sistema.

La herramienta tuvo éxito y, entre la información recopilada, encontró un nombre de usuario válido en el sistema:

Ahora poseía dos piezas clave de información: un nombre de usuario (cyber) y una contraseña (.2uqPEfj3D<P'a-3).

2.3 Explotación de Webmin

Con las credenciales en mi poder, mi siguiente objetivo fueron las dos interfaces de Webmin en los puertos 10000 y 20000.

Intenté iniciar sesión en ambas interfaces. El intento en el puerto 10000 falló, pero las credenciales fueron aceptadas en la instancia del puerto 20000.

La razón más probable de este comportamiento es la configuración de autenticación. La instancia de Webmin en el puerto 20000 seguramente estaba configurada para autenticar a los usuarios contra el sistema local a través de PAM (Pluggable Authentication Modules). Como cyber era un usuario válido del sistema Linux subyacente, Webmin validó las credenciales y me concedió el acceso.

Una vez dentro del panel de administración, mi objetivo era encontrar una forma de ejecutar comandos en el sistema. Webmin es una herramienta de administración muy potente, por lo que a menudo incluye terminales web o módulos de ejecución de comandos.

Esta interfaz me proporcionó un vector directo para la ejecución remota de comandos.

Fase 3: Obtención de Shell y Estabilización

Para obtener una shell interactiva, utilicé la interfaz de comandos de Webmin para ejecutar un payload de reverse shell. Generé el payload utilizando la herramienta en línea revshells.com.

Primero, puse un listener de netcat en mi máquina atacante para recibir la conexión entrante.

Luego, ejecuté el siguiente comando en la consola de Webmin:

La conexión se estableció de inmediato, proporcionándome una shell en la máquina víctima como el usuario cyber.

La shell obtenida era no interactiva y muy limitada. Para poder trabajar de manera eficiente, la actualicé a una TTY completamente funcional.

Tras este proceso, obtuve una shell bash estable e interactiva.

Fase 4: Escalada de Privilegios

4.1 Enumeración Local y Análisis del Binario tar

Una vez con una shell estable, comencé la fase de enumeración local para encontrar un vector de escalada de privilegios.

No arrojaron resultados favorables.

Sin embargo, al listar el contenido del directorio personal del usuario cyber, encontré un archivo inusual.

El archivo tar era un ejecutable propiedad del usuario root, sobre el cual yo tenía permisos de ejecución. Mi primera hipótesis fue que podría ser un binario personalizado. Para verificarlo, realicé una comprobación forense comparando su hash sha256 con el del binario del sistema /bin/tar.

Los hashes eran idénticos. Esto confirmaba que era una copia del comando tar del sistema, pero con una diferencia crucial: al ser propiedad de root, los procesos que ejecutara podrían heredar ciertos privilegios de acceso a archivos.

4.2 Explotación de tar para Lectura de Archivos

Continuando con mi enumeración, descubrí un archivo sospechoso en /var/backups/.

El archivo .old_pass.bak pertenecía a root y no tenía permisos de lectura para mi usuario. Aquí es donde el binario tar local se convirtió en la clave.

Entendí que el comando tar, al ejecutarse, accede a los archivos con los privilegios del propietario del binario (en este caso, root). Por lo tanto, el proceso de compresión podría leer el archivo protegido. Luego, al descomprimir el archivo resultante, el nuevo archivo sería creado con los permisos del usuario que ejecuta el comando (en este caso, cyber), dándome acceso de lectura.

Ejecuté el siguiente procedimiento:

El plan funcionó a la perfección y obtuve una nueva contraseña.

4.3 Acceso como Superusuario

Con una nueva contraseña en mi poder y ya siendo el usuario cyber, la única posibilidad restante era que esta contraseña perteneciera al usuario root. Intenté cambiar de usuario con el comando su.

El inicio de sesión fue exitoso. Había escalado privilegios y obtenido control total del sistema.

Y con esto, la máquina fue completada.

Última actualización