HTB

HTB- Caché

Hola a todos,

Continuamos con la serie de writeup’s de HacktheBox incorporando las máquinas que van retirando en las últimas semanas. En esta ocasión es el turno de Cache. Otra máquina bastante didáctica categorizada con una dificultad medio-baja.

El write-up se divide en tres fases:

  • Enumeración
  • Explotación
  • Escalada de privilegios

Enumeración

En primer lugar, para identificar los servicios y puertos abiertos se ejecuta la herramienta nmap:

Nmap scan report for 10.10.10.188
Host is up (0.14s latency).

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 a9:2d:b2:a0:c4:57:e7:7c:35:2d:45:4d:db:80:8c:f1 (RSA)
| 256 bc:e4:16:3d:2a:59:a1:3a:6a:09:28:dd:36:10:38:08 (ECDSA)
|_ 256 57:d5:47:ee:07:ca:3a:c0:fd:9b:a8:7f:6b:4c:9d:7c (ED25519)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
| http-methods:
|_ Supported Methods: POST OPTIONS HEAD GET
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Cache
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Se cuenta con acceso remoto SSH y web por HTTP.

Accediendo vía web se encuentra un login, que tras hacer un intento de login, salta un pop-up de js:

Lo que hace sospechar que podría existir una validación en el lado del cliente.

Viendo el tráfico con burp se identifica una consulta, en donde se identifican hardcodeadas las credenciales 😉

Tal que se logra acceso pero página en construcción…

Análogamente, se comprueba por SSH por si hubiera reutilización de contraseñas, pero no hay suerte.

Entonces se vuelve a atrás a enumerar que algo se ha podido escapar. Lo más destacado en el about son la siglas HMS, que hacen referencia un CMS de gestión de hospitales.

Esto parece un poco idea feliz, por lo que se tira un cewl para posteriormente hacer fuzzing por si saliese este valor:

Tras añadirlo en el hosts, se accede a la interfaz de administración:

A nivel personal es la primera vez que veo este CMS. Buscando info:

Explorando el github, se busca la versión instalada:

Explotación

Precisamente la versión instalada es vulnerable al RCE, pero requiere la contraseña.

Se hace fuzzing a ver si sale algún recurso accesible:

Ahora, hay que buscar las credenciales.

Buscando info en Google, se encuentran estas referencias:

https://www.open-emr.org/wiki/images/1/11/Openemr_insecurity.pdf

Parece que tiene un SQLi en el registro de usuarios e incluso hay una PoC en youtube en el que se explica paso a paso. nice 🙂

Siguiendo los pasos se identifica un SQLi en el parámetro eid:

http://hms.htb/portal/add_edit_event_user.php?eid=​1′

Automatizando con sqlmap se explota la vulnerabilidad:

sqlmap -r sql_cache -p eid -b –dbs –threads=5

Hay 234 tablas. Buscando la tabla de credenciales:

A continuación, se realiza cracking con john y se obtiene la contraseña:

Ahora, ya con las credenciales es posible autenticarse:

Se hace uso del exploit: https://www.exploit-db.com/exploits/45161

Llegando la shell:

Una vez logrado el acceso, finaliza la fase de explotación y comienza la de escalada de privilegios.

Escalada de privilegios

Tras detectar el usuario ash en el equipo, se intentan reutilizar las credenciales del primer login:

Al ser un CMS se revisa en /var/ en busca del fichero config con las credenciales harcodeadas de la base de datos:

Pero no se pueden reutilizar para el siguiente usuario.

Revisando los puertos locales se detecta el puerto 11211, que llama la atención:

tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN off (0.00/0/0)

Se busca info del servicio por Internet:

Siguiéndolo se obtiene la contraseña en texto plano:

que debería pertenecer a luffy, permitiendo escalar:

Tampoco está en sudoers.

luffy@cache:~$ id
id
uid=1001(luffy) gid=1001(luffy) groups=1001(luffy),999(docker)

Llama la atención que pertenece al grupo de docker. Nuevamente consultando, se puede ejecutar como sudo el lolbin «docker»:

https://gtfobins.github.io/gtfobins/docker/#sudo

Aprovechando esto es posible escalar a root:

Destacar que no se es root de la máquina, sino del contenedor, aunque se tiene el sistema de ficheros entero montado. Una vez aquí, se podría editar el fichero sudoers o bien /etc/passwd añadiendo el usuario al grupo root y posteriormente, acceder por SSH.

Nos vemos en el próximo post!

Saludos.

N4xh4xk5

La mejor defensa, es un buen ataque