Buenas!
Continuamos con la serie de write-ups de las máquinas de HackTheBox,. En este caso, se trata de la solución de la máquina retirada Stratosphere.
El write-up se divide en tres fases:
- Enumeración.
- Explotación
- Postexplotación
Enumeración
Enumeración de servicios
Para ello, empleamos nmap:
Se identifican los puertos/servicios:
- 22 – SSH
- 80 -HTTP
- 8080
En el puerto 8080 suelen encontrarse servidores de aplicaciones como phpmyadmin, tomcat,…muy interesante.
Enumeración de directorios
A continuación, empleamos nuestra tool favorita de reconocimiento de directorios para descubrir ficheros o directorios. En mi caso he empleado dirsearch:
Se identifican directorios curiosos como /manager, propio de tomcat. Accediendo al mismo, aparece el «pop-up» de autenticación básic propio requiriendo su autenticación.
Tras probar credenciales por defecto (tomcat/s3cret) o típicas no se logra acceder. Habrá que seguir buscando 😉
Se accede al directorio /Monitoring, que redirecciona a «Welcome.action» en dónde se identifica un enlace a un formulario de login y otro de registro.
En primer lugar, se accede al de login «Sign on» para verificar si es vulnerable a SQLi con objeto de bypassearlo y acceder a la parte de post-autenticación, pero da el siguiente error:
Como se puede ver esa parte no está desarrollada todavía. Idem para el registro.
Tras dar una vuelta sobre mi pasos, vi que el «welcome» tiene una extensión «.action» y buscando en Google vi que se trata de un Apache Struts.
Este servidor de aplicaciones sufrió dos vulnerabilidades muy graves de CVSS 10 durante el 2017 y hace poco apareció una nueva aunque no es tan trivial como las anteriores.
En primer lugar, antes de lanzar exploits a lo loco, se busca un pequeño script que chequeé si la versión instalada es vulnerable. Para ello, utilicé el siguiente: https://github.com/mazen160/struts-pwn
Se trata de un script que verifica si es vulnerable y en cuyo caso, tiene una funcionalidad para ejecutar comandos de forma remota sobre la máquina, lo que se conoce por las siglas RCE.
Como se observa, efectivamente es vulnerable y se ejecuta el comando pwd.
Tras identificar la vulnerabilidad y un vector de entrada finaliza la parte de enumeración y comienza la de explotación.
Explotación
Lo primero es saber qué usuario somos:
Como era de esperar se es el usuario «tomcat».
A continuación, se enumerar los usuarios de la máquina accediendo al fichero «/etc/passwd»:
Se identifica el usuario «richard».
Finalmente, se trata acceder a la carpeta del usuario para obtener la flag de user:
Sin embargo, no se tienen permisos.
Tras ello, se trató de obtener una shell reversa a través de todos los medios sin éxito, nada funcionó, no sé si quizás la máquina tuviera algún tipo de seguridad basada en iptables.
Otro camino tiene que haber! Al ser el usuario del servidor de aplicaciones, habrá que buscar en el propio servidor, es decir, /var/lib/tomcat8 algo que nos pueda ayudar.
Navegando por el mismo, se identifica el fichero «db_connect», muy rico. Accediendo a él, se identifican las credenciales de una base de datos.
Sin embargo, en la enumeración no se identificó ninguna base de datos dónde poder conectar. Entonces al disponer de un RCE, se trata de conectar a la BBDD que tiene que estar ejecutándose localmente tratando de enumerar las tablas de la misma:
Ahí está la base de datos users…dónde podría estar los credenciales de SSH para Richard.
La tool que está empleando ya no dispone de las funcionalidades necesarias para continuar por lo que se busca otra, obteniendo la siguient en exploitDB https://www.exploit-db.com/exploits/41570/:
Se continua enumerando las tablas de la BBDD»users«:
Se identifica la columna «accounts» de dónde se dumpea todo su contenido:
Ahí está el acceso de nuestro amigo Richard, oh yeah!
Por lo tanto, se procede a su conexión vía SSH:
Logrando acceder y obteniendo la flag de user!
Tras este paso, finaliza la parte de explotación y comienza la de post-explotación, en dónde el objetivo es ser el usuario con mayor rol, siendo en este caso, root!
Post-explotación
Examinando el propio directorio del user se identifica el fichero test.py:
Se pasa a analizar el código que parece un juego de romper hashes… pero al final se identifica una llamada al sistema operativo para ejecutar el fichero /root/success.py
Antes de pasar herramientas de enumeración como LinEnum y similares, se analizan los permisos de sudo, en dónde:
Como se observa la ejecución del fichero test.py no requiere contraseña para ejecutarse con permisos de sudo
Lo primero que se me viene a la cabeza es ver si sobre el fichero se tienen permisos de escritura para llamar mediante un netcat a una shell con permisos de root, pero sería demasiado bueno y como se puede ver en una de las capturas anteriores, sólo se tiene permisos de lectura y ejecución.
Volviendo al código, se identifica una llamada a la librería hashlib. Recuerdo que el otro día de cervezas me comentó @naivenom que python2 tiene un bug en el input que lo podía tratar como eval (), entonces triando del hilo encontré que python2 considera la carpeta en la que se está ejecutando el script por encima de la ruta de las librerías, lo que se puede aprovechar para crear a nuestro favor y secuestrar la ejecución. (habrá que pasarse a python 3 😉 )
En el siguiente post tenéis una explicación más en detalle y mucho mejor de la que puedo aportar yo: https://rastating.github.io/privilege-escalation-via-python-library-hijacking/
Para aplicarlo se crea un script llamado hashlib.py en la propia carpeta obteniendo la ejecución:
echo ‘import os;os.system(«/bin/bash»)’ > hashlib.py
y se ejecuta como sudo el fichero test.py
Y de esta manera, se obtiene la flag de root o como díria @Hartek, «Cariñooo tengo la flag!»
Espero que os haya gustado y resultado útil.
Nos vemos en la siguiente entrada 😉
Saludos.
N4xh4ck5
La mejor defensa es un buen ataque