Compromiso de la máquina UltraTech

Información General

  • Nombre de la máquina: UltraTech

  • Dirección IP: 10.10.166.75

  • Sistema Operativo: Linux (Ubuntu, según versiones de software)

  • Objetivo: Obtener acceso como root y extraer flags o evidencias.


Parte 1: Reconocimiento

Teoría

El reconocimiento inicial es la fase crítica donde se identifican los activos y servicios expuestos del objetivo. Se utilizan escaneos de puertos para descubrir puertos abiertos y sus servicios asociados, incluyendo versiones y configuraciones, lo que ayuda a perfilar posibles vectores de ataque.

Herramientas y Comandos

Se utilizó nmap para el escaneo de puertos y detección de servicios.

┌──(kali㉿kali)-[~/ultratech]
└─$ nmap -p- -n -Pn -sS --min-rate 5000 10.10.166.75 -oG ports                                                                                 
Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-03 23:51 EDT
Nmap scan report for 10.10.166.75
Host is up (0.18s latency).
Not shown: 65531 closed tcp ports (reset)
PORT      STATE SERVICE
21/tcp    open  ftp
22/tcp    open  ssh
8081/tcp  open  blackice-icecap
31331/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 14.28 seconds

Una vez identificados los puertos abiertos, se realizó un escaneo más detallado para la detección de versiones y scripts de vulnerabilidad.

Resultados relevantes

Los puertos abiertos y servicios identificados son:

  • 21/tcp: ftp vsftpd 3.0.3

  • 22/tcp: ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3

  • 8081/tcp: http Node.js Express framework (Sin título, con CORS para HEAD, GET, POST, PUT, DELETE, PATCH)

  • 31331/tcp: http Apache httpd 2.4.29 (Ubuntu) (Título: "UltraTech - The best of technology (AI, FinTech, Big Data)")


Parte 2: Enumeración

Teoría

La enumeración se enfoca en profundizar en los servicios expuestos para descubrir información que pueda conducir a un vector de ataque. Para los servicios web (puertos 8081 y 31331), esto implica el descubrimiento de rutas y archivos ocultos, y la revisión del código accesible públicamente.

Herramientas y técnicas

Se utilizó gobuster para el descubrimiento de directorios en ambos servicios HTTP.

Enumeración en el puerto 8081 (Node.js Express):

Resultados

Al ingresar al sitio web en el puerto 8081, se encontró lo siguiente:

Se identificaron las rutas /auth y /ping.

  • Al acceder a /auth, se obtiene el mensaje "You must specify a login and a password", lo que sugiere un endpoint de autenticación.

  • Al acceder a /ping, se encontró la siguiente información de error: El error TypeError: Cannot read property 'replace' of undefined con un stack trace revela el archivo /home/www/api/index.js en la línea 45.

Enumeración en el puerto 31331 (Apache httpd):

Se identificó la ruta /partners.html y el directorio /js.

  • Al acceder a http://ultratech.thm:31331/partners.html, se encontró un formulario de autenticación.

  • El código fuente de /partners.html reveló que el formulario usaba method='GET' para enviar los parámetros login y password.

  • La inspección del archivo http://ultratech.thm:31331/js/api.js (enlazado desde partners.html y encontrado en la enumeración) fue crítica:

    Este script confirmó que el endpoint /ping en el puerto 8081 espera un parámetro llamado ip (/ping?ip=...), lo que explicaba el TypeError inicial. También confirmó que el formulario de autenticación en partners.html envía datos al endpoint /auth en el puerto 8081.


Parte 3: Explotación

Teoría

La identificación del endpoint /ping con el parámetro ip (/ping?ip=...) y la naturaleza de un servicio "ping" sugieren una alta probabilidad de Inyección de Comandos (Command Injection). Esto ocurre cuando una aplicación ejecuta un comando del sistema con la entrada del usuario sin una sanitización adecuada, permitiendo al atacante inyectar comandos adicionales.

Herramienta o script utilizado

Explotación manual utilizando curl.

Comando y resultado

  1. Validación de la inyección de comandos: Se probó la inyección de comandos con un comando de ping a la máquina atacante (Kali).

    Al enviar la solicitud HTTP:

    La respuesta web del servidor fue: Esto confirmó la ejecución del comando ping en el objetivo al observar los paquetes ICMP en tcpdump.

  2. Exfiltración de comandos con backticks para exfiltración: Se utilizó el operador backtick (`) para ejecutar comandos y redirigir su salida al comando ping, esperando que la salida se incluyera en la respuesta HTTP.

    Este error indica que el comando id se ejecutó, pero ping intentó interpretar su salida (groups=...) como un hostname. Esto confirma la inyección, pero el output no se muestra directamente en el cuerpo de la respuesta HTTP, solo el error.

    La respuesta web del servidor fue: Aquí, el comando ls se ejecutó y su salida (utech.db.sqlite) fue interpretada por ping como un hostname, pero el nombre del archivo se reveló en el mensaje de error.

  3. Exfiltración de credenciales de la base de datos utech.db.sqlite: Al confirmar que ls mostraba utech.db.sqlite y que la inyección funcionaba ciegamente, se intentó catear el contenido de este archivo.

    La respuesta web del servidor fue: La salida de cat incluyó la cadena f357a0c52799563c7c7b76c1e7543a32 mezclada con un mensaje de error.

  4. Descifrado de Hash y Acceso SSH: La cadena f357a0c52799563c7c7b76c1e7543a32 se identificó como un hash MD5. Al consultarlo en CrackStation.net, se obtuvo la credencial:f357a0c52799563c7c7b76c1e7543a32:n100906 Esto reveló el nombre de usuario n100906 y su contraseña n100906.

    Se procedió a iniciar sesión vía SSH con estas credenciales:

    Acceso obtenido como usuario n100906.


Parte 4: Escalada de Privilegios

Teoría

La escalada de privilegios es el proceso de obtener un mayor nivel de acceso en un sistema. En Linux, la pertenencia a ciertos grupos (docker, sudo) puede permitir a un usuario común ejecutar comandos con privilegios elevados.

Método aplicado

Enumeración de grupos del usuario para identificar posibles vectores de escalada, seguido del abuso de permisos de Docker.

Comando y resultado

Una vez dentro de la shell SSH como n100906, se verificaron los grupos a los que pertenecía el usuario:

La pertenencia al grupo docker es un vector de escalada de privilegios bien conocido, ya que permite a un usuario ejecutar comandos como root al interactuar con el daemon de Docker.

Se intentaron varios comandos docker run para escapar del contenedor y obtener una shell de root, aunque algunos intentos iniciales fallaron debido a imágenes no encontradas o errores de conexión. El intento de sudo docker run también falló, confirmando que n100906 no estaba en sudoers.

Finalmente, una variante exitosa de Docker escape para obtener una shell de root fue:

Este comando monta el sistema de archivos raíz del host (/) dentro del contenedor en /mnt, y luego ejecuta un chroot a /mnt para cambiar el directorio raíz a la del host, obteniendo así una shell de root.

Confirmación de privilegios:

Se obtuvo acceso como root (uid=0, gid=0).


Parte 5: Post-Explotación

Una vez como root, se exploró el sistema de archivos para encontrar información sensible y la clave privada SSH.

Se exploró el directorio .ssh de root para buscar claves SSH privadas que pudieran usarse para acceso persistente o lateral.

Se encontró y extrajo la clave privada id_rsa del usuario root, que permite acceso directo por SSH como root.


Parte 6: Flags o evidencias obtenidas

  • Hash de contraseña extraído y descifrado (Flag):

    • Hash: f357a0c52799563c7c7b76c1e7543a32

    • Descifrado: La clave de la flag obtenida al descifrar el hash fue n100906.

  • Clave Privada SSH de root:

    (El contenido completo de la clave ha sido enmascarado por seguridad).


Recomendaciones de Seguridad

  1. Validación y Sanitización de Entrada: Implementar validación estricta y sanitización de toda la entrada del usuario en las aplicaciones web, especialmente en funciones que interactúan con comandos del sistema (/ping). Utilizar listas blancas de caracteres permitidos y evitar la ejecución directa de comandos con entrada no confiable.

  2. Actualización de Software: Actualizar los servicios y frameworks a sus últimas versiones estables (vsftpd, OpenSSH, Apache 2.4.29, Node.js Express). Las versiones antiguas pueden contener vulnerabilidades conocidas que son explotables.

  3. Configuración de CORS: Revisar la configuración de CORS en el framework Node.js Express para restringir los orígenes permitidos y los métodos HTTP si no son necesarios para evitar posibles ataques CSRF o exfiltración de datos.

  4. Gestión de Credenciales: No almacenar credenciales de bases de datos o usuarios en archivos planos o de fácil acceso (utech.db.sqlite). Utilizar variables de entorno, servicios de gestión de secretos o configuraciones de acceso más seguras.

  5. Seguridad del Grupo Docker: La pertenencia al grupo docker debe ser estrictamente controlada, ya que equivale a tener privilegios de root en el sistema. Los usuarios que no requieran gestionar contenedores directamente no deben pertenecer a este grupo.

  6. Remoción de Información de Depuración: Eliminar la información de depuración y los stack traces detallados (TypeError: Cannot read property 'replace' of undefined) de los entornos de producción, ya que revelan rutas de archivos internas y detalles de la lógica de la aplicación que pueden ser explotados.

  7. Restricciones de Shell: Configurar el shell de manera que no permita la ejecución de comandos arbitrarios a través de operadores de redirección (``,;, &&, ||`, etc.) si no es estrictamente necesario, o usar funciones de ejecución de comandos que no invoquen un shell completo.

  8. Protección de Claves SSH: Las claves privadas SSH deben protegerse con contraseñas robustas y tener permisos de archivo restrictivos (chmod 600). Las claves de root no deben estar expuestas directamente en el sistema de archivos.

Última actualización