Esta máquina contempla una intrusión web a través de NODE-RED y una escalada de privilegios en sistema abusando de sudo.
Como primer paso inicial, y común en los CTF con estructura virtualizada en local, (véase este documento para más información) se ejecuta la orden de sistema "arp-scan" con el objetivo de identificar la IP relacionada con la máquina víctima.
Para la enumeración de servicios y puertos se utiliza nmap, con una parametrización enfocada en: extraer información y versionado de estos mediante los parámetros "-sCV", a todos los puertos TCP existentes (65535) con "-p-", con un mínimo de paquetería enviada por segundo de 4500 paquetes y guardando el output en un archivo grepeable.
Es una buena práctica comprobar las tecnologías e información dependiente del servicio web con la herramienta WhatWeb para la shell. Existen otras alternativas para el navegador como Wappalyzer
El servicio de Apache en puerto 80, alberga el index correspondiente a la configuración del gestor web. Se realiza una búsqueda de archivos (con extensiones) y directorios obteniendo el archivo "index.html" y sin resultados por parte de los directorios. (Para comprender el uso de wfuzz léase este documento).
┌──(root㉿maritrini)-[/home/kali]└─#wfuzz-c--hc=404-w/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt-u192.168.1.69/FUZZ /usr/lib/python3/dist-packages/wfuzz/__init__.py:34: UserWarning:Pycurl is not compiled against Openssl. Wfuzz might not work correctly when fuzzing SSL sites. Check Wfuzz's documentation for more information.
********************************************************* Wfuzz 3.1.0 - The Web Fuzzer *********************************************************Target:http://192.168.1.69/FUZZTotalrequests:220546=====================================================================ID Response Lines Word Chars Payload
=====================================================================000045226: 200 368 L 933 W 10701 Ch "http://192.168.1.69/"
000095510: 403 9 L 28 W 277 Ch "server-status"
000190041: 404 9 L 31 W 274 Ch "126575"
Totaltime:361.7233ProcessedRequests:191736FilteredRequests:191734Requests/sec.:530.0625
┌──(root㉿maritrini)-[/home/kali]└─# wfuzz -c --hc=404 -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -z list,html-php-css-js -u 192.168.1.69/FUZZ.FUZ2Z
/usr/lib/python3/dist-packages/wfuzz/__init__.py:34: UserWarning:Pycurl is not compiled against Openssl. Wfuzz might not work correctly when fuzzing SSL sites. Check Wfuzz's documentation for more information.
********************************************************* Wfuzz 3.1.0 - The Web Fuzzer *********************************************************Target:http://192.168.1.69/FUZZ.FUZ2ZTotalrequests:18860=====================================================================ID Response Lines Word Chars Payload
=====================================================================000000094: 403 9 L 28 W 277 Ch ".htaccess - php"
000000090: 403 9 L 28 W 277 Ch ".hta - php"
000000097: 403 9 L 28 W 277 Ch ".htpasswd - html"
000000096: 403 9 L 28 W 277 Ch ".htaccess - js"
000000093: 403 9 L 28 W 277 Ch ".htaccess - html"
000000095: 403 9 L 28 W 277 Ch ".htaccess - css"
000000092: 403 9 L 28 W 277 Ch ".hta - js"
000000098: 403 9 L 28 W 277 Ch ".htpasswd - php"
000000089: 403 9 L 28 W 277 Ch ".hta - html"
000000100: 403 9 L 28 W 277 Ch ".htpasswd - js"
000000091: 403 9 L 28 W 277 Ch ".hta - css"
000000099: 403 9 L 28 W 277 Ch ".htpasswd - css"
000008765: 200 368 L 933 W 10701 Ch "index - html"
Totaltime:31.29138ProcessedRequests:18860FilteredRequests:18847Requests/sec.:602.7218
El archivo index.html da como respuesta 200 a la petición por protocolo HTTP, con "curl" se comprueba las cabeceras y respuestas, desde el navegador también se puede visualizar el contenido, resultando en el propio archivo de configuración por defecto del gestor web Apache.
En este punto, evidentemente después de comprobar con el resultado de nmap que el servidor tiene un servicio de "Node" con Intercambio de recursos de origen cruzado (CORS) - HTTP, lo más seguro es que tenga disponible algún tipo de gestión que me permita algún tipo de maniobra abusando de este concepto. Pero antes, no está de más comprobar si la aplicación en red de SSH tiene vulnerabilidades, se puede apoyarse en la herramienta "searchsploit" para enumerarlas.
No se encuentra ninguna vulnerabilidad por versión para el servicio SSH, por lo que directamente se continúa por la tecnología y servicio de "Node.js Express Framework" en el puerto 1880.
Como siempre, a cada tecnología que se descubre, se investiga sobre la misma en internet, principalmente para ser pragmático y resolutivo dado que, si se comprueba la documentación se podrá comprender mejor por dónde se debe encaminar la enumeración.
Generalmente en estos WriteUps es añadida una tabla con información importante sobre la tecnología a tocar (esta opción me parece interesante para mis lectores ya que, quizás algún recurso no lo habéis ojeado pero os interesa guardarlo en vuestra wiki).
Aunque los CVE como tal son de versiones anteriores al Node-Red que está desplegado en este servidor, se encuentran dos técnicas de explotación que sí pueden ejecutarse en esta versión, estas son LFI y RCE.
Se prueba el LFI (aunque lo marca para versiones 2.x intento de igual forma la técnica) a través de curl con la intención de leer el fichero /etc/passwd alojado en el servidor, pero no se consigue ningún resultado dado que la respuesta HTTP es de 404 ("Not found") y no existe ningún otro directorio dependiente de este framework que tenga permisos para realizar la técnica LFI. (Esta técnica está explicada en el enlace correspondiente de la tabla anterior, en la pestaña de LFI).
Se realizan varios intentos sin resultado como se muestra a continuación:
┌──(kali🐼maritrini)-[~]└─$curl"http://192.168.1.69:1880/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc%2fpasswd"<!DOCTYPEhtml><html lang="en"><head><meta charset="utf-8"><title>Error</title></head><body><pre>Cannot GET /..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc%2fpasswd</pre></body></html>
Según la lectura de la documentación, se pueden generar estructuras de funciones atribuidas a la comunicación de hardware, servicios e interacciones con API's a través del flujo del propio editor web de Node-Red, como se puede ver en la siguiente captura.
Después de leer la documentación sobre vulnerabilidades (disponible al principio de esta sección) y de realizar alguna prueba, encuentro la conexión de 3 funciones que ofrecen una escalada al sistema a través del usuario "dev".
Existen un par de formas de conectar una Reverse Shell, como por ejemplo por protocolo UPD o TCP, en este caso las pruebas realizadas por UDP no dieron resultado (porque no se puede o porque yo soy muy manco y no lo he hecho bien) así que se aprovecha del protocolo TCP para generar en primer lugar un "TCP IN" que mande una petición de conexión a mi IP, en esta petición de conexión comunico un nodo "EXEC" para ejecutar un "Netcat" y enviar una Shell de Bash a mi IP, como último paso creo otro nodo "TCP OUT" que genera una conexión TCP por el puerto 6969 hacía mi IP de nuevo (sí, has entendido bien, se necesitan dos puertos en escucha, uno para entablar la petición TCP y otro para recibir la Shell de Bash).
Y el resultado de esta configuración sería la siguiente:
Como se ha comentado anteriormente, se necesita ejecutar dos Netcat a la escucha, uno en el puerto 3333 para entablar la conexión TCP y otro con el puerto 6969 para recibir la shell de bash por TCP también.
En la parte superior derecha del panel web de Red-Node está ubicado el botón de "Deploy" que permite ejecutar las conexiones creadas con los nodos, se despliega la configuración anterior y recibo una shell remota con el usuario "dev".
Para obtener esta Shell se debe aceptar con un "ENTER" en la conexión de Netcat por puerto 3333, lo que genera directamente la conexión con la máquina remota a través del otro puerto 6969 como se aprecia en la siguiente captura.
Netcat puerto 3333:
┌──(kali🐼maritrini)-[~]└─$nc-lvnp3333listeningon [any] 3333 ...connectto [192.168.1.62] from (UNKNOWN) [192.168.1.69] 38122id
Enumerando con sudo y buscando por permisos especiales se descubre que se puede ejecutar el binario node como usuario root sin contraseña por lo que buscando este binario en la página GTFOBins. Se obtiene el abuso de este binario para ejecutar una Shell de bash bajo usuario privilegiado.
Finalmente puede accederse como usuario root y, oficialmente, esta máquina está deliciosamente hackeada.
Este es el primer WriteUp de esta wiki pero poco a poco encontrarás más contenido sobre VulNyx. Si quieres estar al día de las publicaciones puedes seguirme en Twitter o través de nuestro servidor de Discord. Saludos y delicioso hack para tod@s.