HackTheBox - Delivery
Creado

Máquina Linux nivel fácil, jugaremos con osTicket creando tickets que nos servirán para ¿obtener emails externos en el propio status del ticket? ¿khE? (jajaj, sip), nos moveremos entre archivos y bases de datos MySQL y curiosamente usaremos las reglas para romper cosas con HashCat y John The Ripper :)
TL;DR (Spanish writeup)
Creada por: ippsec. El master craster faster :D
Bueno bueno bueeeeno, encontraremos dos servicios, uno que nos permite generar tickets que serán enviados a una mesa de ayuda (software osTicket) y otro que nos permitirá comunicarnos con nuestros equipos de trabajo (software Mattermost)… Jugando con los dos, encontraremos que cuando generamos un ticket, crea un email asociado a ese ticket. Peeero que si validamos el status de ese ticket e interactuamos con ese email externamente, podremos llegar a obtener correos enviados a ese email en el status del ticket 🙃 Una vaina loca!
Apoyados en esto lograremos validar una cuenta creada en el servicio Mattermost, en el dashboard encontraremos un chat correspondiente a un equipo de trabajo, en esos mensajes tendremos unas credenciales, una referencia a reutilización de contraseñas y a reglas de hashcat. Las credenciales nos servirán para entrar al panel de control donde están todos los tickets y también nos permitirán obtener una sesión por medio de SSH como el usuario maildeliverer en la máquina.
Enumerando los directorios de los servicios web, encontramos en la raíz de Mattermost unas credenciales del usuario que mantiene la base de datos MySQL, recorreremos la base de datos mattermost para encontrar una contraseña encriptada en formato bcrypt asociada a un usuario llamado root del servicio web.
Jugando con las reglas tanto de hashcat como de john lograremos crackear el hash del usuario root. Probando esa contraseña en el sistema contra el usuario root obtendremos una sesión como él.
Clasificación de la máquina
Escribo para tener mis “notas”, por si algun dia se me olvida todo, leer esto y reencontrarme (o talvez no) :) además de enfocarme en plasmar mis errores y exitos (por si ves mucho texto), todo desde una perspectiva más de enseñanza que de solo plasmar lo que hice.
…
Tonces!
…
Enumeración #
Hacemos un escaneo inicial para obtener los puertos abiertos y que servicios aparentemente estás corriendo sobre ellos:
Parámetro | Descripción |
---|---|
-p- | Escanea todos los 65535 |
–open | Solo los puertos que están abiertos |
-v | Permite ver en consola lo que va encontrando |
-oG | Guarda el output en un archivo con formato grepeable para usar una función de S4vitar que me extrae los puertos en la clipboard |
Encontramos:
Puerto | Descripción |
---|---|
22 | SSH |
80 | HTTP |
8065 | No sabemos aún |
Ahora validemos si existen versiones y scripts relacionados para esos servicios corriendo:
Parámetro | Descripción |
---|---|
-p | Escaneo de los puertos obtenidos |
-sC | Muestra todos los scripts relacionados con el servicio |
-sV | Nos permite ver la versión del servicio |
-oN | Guarda el output en un archivo |
Y ahora obtenemos las versiones:
Puerto | Servicio | Versión |
---|---|---|
22 | SSH | OpenSSH 7.9p1 |
80 | HTTP | nginx 1.14.2 |
8065 | HTTP | unknown - Pero parece un servidor web |
Bueno, profundicemos en cada uno de ellos (:
…
Puerto 80 - osTicket ⌖
Un simple servicio web, si posicionamos el cursor sobre HELPDESK, vemos que nos redirige a un dominio: helpdesk.delivery.htb
, agreguémoslo al archivo /etc/hosts para que cuando hagamos una petición hacia ese dominio nos resuelva hacia la IP 10.10.10.200, así logra el servicio web entender hacia donde debe ir a buscar la info del dominio:
(Aprovechemos para agregar el dominio **delivery.htb, por si algo)**
Si nos dirigimos hacia el dominio, vemos:
Valeee, estamos ante un servicio llamado osTicket, que se encarga de brindar soporte al cliente, facilitando el orden y administración de los tickets enviados a mesa de ayuda, entre otras cosas…
Tenemos varios apartados, a la vista tres: abrir un nuevo ticket, verificar el status de un ticket y logearnos en osTicket. Si nos dirigimos a abrir un ticket nos pide una dirección email, así que veamos si podemos crearnos una:
Vemos aparentemente dos nuevos apartados, uno en donde podemos registrar una cuenta y otra que nos dirige a un nuevo login, en este caso (según lo que vimos) para los “agentes”, echemos un ojo rápidamente:
Probando credenciales por default no logramos nada, así que volvamos y registremos una cuenta.
Registramos y nos redirige a una ventana que nos indica que nos enviara un email de verificación para hacer efectivo el registro :( (Acá pensé en tomar un email temporal online y volver a registrarnos, pero no llega ningún correo, así que esto no debe ser relevante. Si intentamos logearnos con las credenciales registradas obtenemos:
Así que F, reconfirmamos que probablemente no sea necesario crear una cuenta para explotar la máquina ;)
Ahora sí, creemos un ticket con el email que registramos a ver si vemos algo, llenamos los campos necesarios, damos clic en Create Ticket y nos responde con:
Varias cositas interesantes:
- Crea un ticket con lo que parece ser un número aleatorio,
- pero ese mismo número lo usa para generar un email con dominio
delivery.htb
…
Si intentamos ver el status del ticket nos vuelve a responder con Account confirmation required :(
Jmmm, despues de muchas pruebas (listo 2, pero uff, lo que probé jaja), como estas:
- Crearnos un correo que tenga el dominio
delivery.htb
, crear ticket y validar su estado. - Usar el correo que nos da al crear el ticket y registar una cuenta con él.
No logramos ver ningún ticket.
Se me dio por probar a crear un ticket como el usuario admin@delivery.htb (que no sabía que existía, pero son pruebas que se deben hacer) y con el sí podemos ver el status del ticket.
Como ejemplo creamos uno y nos devuelve:
- ID: 9827830.
- email: 9827830@delivery.htb.
Llegamos a:
Bien, tenemos un usuario válido para ver tickets… No podemos hacer mucho con el contenido del ticket, así que tamos perdidos de nuevo :)
Probando cosas (de nuevo) no conseguimos nada, así que movámonos de servicio mientras tanto, quizás encontramos algo útil para volver.
…
Puerto 8065 - Mattermost ⌖
Nos redirige al apartado /login
y efectivamente tenemos un login 😜 del servicio Mattermost, que nos ayuda a comunicarnos con un (o muchos) equipo(s) de trabajo.
En la imagen vemos la opción de crear una cuenta, la creamos y nos muestra como respuesta:
De nuevo tenemos que validar el email :(
…
Explotación #
Estuve también probando varias cosas, pero en un momento intente algo curioso y loco (muy loco):
- Crear una cuenta asociada a este email: 9827830@delivery.htb, que fue el que obtuvimos al crear el ticket.
Hasta acá todo normal y nada loco… Pero actualice la página donde teníamos el status del ticket 9827830 y la info cambio, ahora tenemos esto:
Exacto, así quede. WtfFFFFFFFFFfdfffFffffffffffffff.
Tenemos el link para activar nuestra cuenta recientemente creada en el servicio Mattermost… Entendamos el porqué:
1. Creamos un ticket en el servicio osTicket y ese ticket genera un email, en la respuesta al generar el ticket vemos:
If you want to add more information to your ticket, just email 9827830@delivery.htb.
No lo vimos relevante pero ahora toma sentido.
2. Creamos una cuenta con el email anterior en el servicio Mattermost y como respuesta el servicio envía un correo para validar la cuenta.
3. Como vimos en el punto 1, prácticamente estamos “añadiendo” más información al ticket, donde esa “más información” es el correo enviado por Mattermost, por lo que entendemos que toda info enviada a ese correo actualizara el estado del ticket :) Bingo!
Perfecto, ya entendemos que está pasando, y que locura eh! Podemos seguir (:
En el correo enviado por Mattermost nos referencian el link para activar la cuenta:
Si vamos hacia él, obtenemos:
Listones, tamos verificaos’, colocamos la contraseña, enviamos la petición yyyy:
Nos pide seleccionar un equipo, dejamos el que esta por default llamado internal, damos clic sobre él, despues nos hace un tutorial y finalmente llegamos a toda la info sobre el equipo internal:
Vale, varias cositas interesantes:
- Nos da unas credenciales de “un servidor”, tenemos 3 logins para probar y un SSH, así que tamos bien…
- Dice que están usando la misma contraseña en todos los sitios :o Y que las contraseñas están relacionadas con PleaseSubscribe!.
- Y vemos una referencia a reglas de hashcat, que relacionando el anterior punto, tiene mucho sentido :)
Bien, pues primero validemos las credenciales que nos dieron a ver donde funcionan.
Probándolas en el login de los agentes vemos que son válidas:
Encontramos tooooooooooooooooodos los tickets creados y su histórico, entre muchas cosas más, como el Admin Panel en la parte superior (:
Probándolas contra el servicio SSH obtenemos una sesión:
…
Escalada de privilegios #
Despues de enumerar algunos archivos, encontramos los objetos fuente del servicio Mattermost y una carpeta de configuración:
Echando un ojito al archivo config.json, vemos algo interesante:
Ehh opa, conseguimos lo que parecen ser unas credenciales del servicio MySQL (gestor bases de datos):
- mmuser:Crack_The_MM_Admin_PW, una pw bastante extraña.
Al parecer es un atributo propio de Mattermost y no algo hecho a posta por ippsec: mattermost - config-in-database.
Probemos a ver si son válidas:
(Solo quería mostrarles dos maneras de hacerlo :P)
Son válidas e.e Pues enumeremos las bases de datos y su información…
…
Buscando en MySQL
Tenemos:
Varias tablas, pero veamos Users inicialmente:
Jmmm, un montón de usuarios y al haber tantos campos, pues se ve horrible todo :o Pero más o menos el formato de la tabla es así:
Donde en la contraseña vemos un hash tipo bcrypt según la wiki de ejemplos de hashcat.
Claramente no voy a jugar con un usuario que yo cree :P, pero si con uno interesante que vi:
Dos cositas interesantes de este usuario:
- Pos que se llama root e.e
- Pero más importante, en la columna Roles, tiene asignados: system_admin y system_user. ¿Cuál es el importante y porque es relevante este usuario?
Listones, tomemos ese hash y guardémoslo en un archivo:
Y procedamos a crackearlo, podríamos usar el famoso diccionario rockyou.txt, pero recordemos lo que nos encontramos en los mensajes del equipo:
PleaseSubscribe! may not be in RockYou but if any hacker manages to get our hashes, they can use hashcat rules to easily crack all variations of common words or phrases.
Todas las contraseñas están asociadas o tienen que ver con PleaseSubscribe! y que esa palabra no está en el diccionario rockyou.txt…
Entonces, sabemos que debe estar asociada a PleaseSubscribe! (este sería nuestro diccionario), podemos hacer uso de reglas (como bien nos lo indica el mensaje citado) para indicar que tome nuestro diccionario y empiece (depende de la regla) a modificar cada palabra del diccionario agregándole, borrándole, cambiando a mayúsculas, minúsculas, moviendo letras, agregando números, símbolos, etc. Todo lo que podamos imaginarnos con respecto a manipular una palabra lo hacen las reglas. Entonces por cada modificación va validando si ese resultado hace match con el hash…
Haremos el ataque basado en reglas usando hashcat y JohnTheRipper:
HashCat - Rule Based Attack
Empecemos por hashcat.
Las reglas están en el directorio /usr/share/hashcat/rules/
:
Bien, siguiendo el estudio referenciado antes, usaremos la regla InsidePro-PasswordsPro.rule
:
Entonces, tenemos la regla y el hash, creamos un archivo llamado dic.txt
que tenga la cadena PleaseSubscribe!, para así contar con todos los elementos para empezar a jugar…
Teniendo todo ejecutamos:
Donde:
- -m: Tiene el tipo de hash a crackear, en este caso 3200:bcrypt.
- -r: Tiene la regla a usar.
- Pasamos el archivo que contiene el hash.
- Pasamos el diccionario, el cual contiene la cadena PleaseSubscribe!.
- -o: Le indicamos que si crackea el hash, nos guarde el resultado en el archivo llamado
cracked.txt
.
Despues de un rato obtenemos respuesta:
Con una cadena en texto plano: PleaseSubscribe!21. La cual sería la contraseña del usuario root del servicio Mattermost, peeeero intentando rehusarla contra la máquina y el usuario root, obtenemos:
Una sesión como él :))))))))) Ahora hagamos el mismo procedimiento pero con John The Ripper:
John The Ripper - Rule Based Attack
Con john encontramos un lindo recurso con el que nos guiaremos:
En esta herramienta debemos actualizar (si quieren crear su propia regla) un archivo, en mi caso /etc/john/john.conf
y agregarle lo que quieran, un punto superinteresante es que las reglas usadas en hashcat y john pueden ser las mismas, esto facilita mucho el aprendizaje. Además podemos ver como actúan las reglas en una cadena, esto está genial como aprendizaje de cada regla…
Creo una regla llamada Lanz:
En este caso le pasamos la regla T (Cambia entre mayúscula a minúscula y al revés :P) y un numero, donde ese numero es la posición donde queremos que se efectúe la regla (: Y le pasamos la regla $, que agrega al final algo, donde sé algo es lo que esta despues de dicho símbolo, por ejemplo $1, agregara al final de la cadena el número 1, veamos la regla en ejecución:
Le pasamos la regla que creamos anteriormente (--rules
), el diccionario (--wordlist
) y que nos muestre por pantalla lo que probaría (--stdout
).
Perfecto, vemos como se va modificando nuestro diccionario según la regla (eso esta buenaso), ahora probemos contra el hash:
Y si, también hace la tarea de jugar con las reglas para finalmente darnos la cadena PleaseSubscribe!21 como válida ante el hash :) Y por consiguiente volvernos a conectar como root y leer las flags :)
Pa leer: Otro recurso que habla de las reglas con respecto a john.
…
Como conclusión ippsec nos deja una nota:
…
Me gusto bastante el ataque inicial una vez entendido, brutalidad eh! Como de algo tan pequeño explotan cosas gigantes ufff. El tema de las reglas es algo que puede ser muuuuy peligroso, me encanta como trabajan y modifican la data, que loco (:
Weno, hemos llegado hasta acá pero nos queda mucho por explorar, pero también nos queda como siempre seguir rompiendo de todooooo! Gracias por leer <3
Comments