BountyHunter
BountyHunter es una máquina Linux sencilla que utiliza la inyección de entidades externas XML para leer archivos del sistema. Poder leer un archivo PHP en el que se filtran las credenciales brinda la oportunidad de obtener un punto de apoyo en el sistema como usuario de desarrollo. Un mensaje de John menciona un contrato con Skytrain Inc y habla de un script que valida los boletos. La auditoría del código fuente del script de Python revela que utiliza la función eval en el código del boleto, que se puede inyectar, y como el script de Python se puede ejecutar como root con sudo por el usuario de desarrollo, es posible obtener un shell de root.
Reconnaissance
Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina BountyHunter. Este resultado lo almacenaremos en un archivo llamado allPorts.
A través de la herramienta de extractPorts, la utilizaremos para extraer los puertos del archivo que nos generó el primer escaneo a través de Nmap. Esta herramienta nos copiará en la clipboard los puertos encontrados.
Lanzaremos scripts de reconocimiento sobre los puertos encontrados y lo exportaremos en formato oN y oX para posteriormente trabajar con ellos. En el resultado, comprobamos que se encuentran abierta una página web de Apache y el servicioSSH.
Transformaremos el archivo generado targetedXML para transformar el XML en un archivo HTML para posteriormente montar un servidor web y visualizarlo.
Accederemos a http://localhost y verificaremos el resultado en un formato más cómodo para su análisis.
Web Enumeration
Realizaremos a través de la herramienta de whatweb un reconocimiento inicial de las tecnologías que utiliza la aplicación web.
Accederemos a http://10.10.11.100/ y comprobaremos la siguiente página web, que ofrece 3 páginas de About, Contact y Portal.
Realizaremos una enumeración de directorios y páginas PHP. En el resultado obtenido, verificamos diferentes páginas web y directorios los cuales revisaremos posteriormente.
Por otro lado, también realizaremos la misma enumeración pero esta vez a través de la herramienta de gobuster. En el resultado obtenido, verificamos diferentes páginas PHP como las siguientes:
portal.php
db.php
index.php
Al acceder a la sección de Portal de la página principal, somos redirigidos a la página web http://10.10.11.100/portal.php la cual nos muestra un mensaje indicando que el portal está en desarrollo. También se nos indica que para acceder al Bounty Tracker accedamos al hipervínculo que se nos muestra.
Al acceder al enlace, somos redirigidos a la siguiente página web de http://10.10.11.100/log_submit.php. En la siguiente página web se nos indica un sistema de reporting de BugBounty en el cual nos permiten indicar diferentes campos.
Initial Access
XXE (XML External Entity Injection) Exploitation
Indicaremos unos datos randoms para verificar el funcionamiento de la aplicación web. Al indicar los datos, se nos muestra en el output de la aplicación web el resultado obtenido.
Al interceptar la solicitud con BurpSuite, comprobamos que al darle a la opción de Submit lo que se tramita es una variable llamada data con un código codificado en Base64. Al seleccionar el código, la propia herramienta de BurpSuite nos lo descodifica automáticamente.
En este caso, al descodificarlo, se nos muestra la estructura de una archivo XML, con lo cual, lo primero que se nos ocurre es en intentar probar un XML External Entity Injection (XXE).
Descoficaremos el valor también en Cyberchef para comprobar que efectivamente se trata de un archivo XML codificado en Base64 y URL Encode para evitar problemas con los carácteres especiales como =,+, etc.
Probaremos diferentes payloads para intentar comprobar si la aplicación web es vulnerable a XXE. En este primer intento para comprobar si es vulnerable, lo que realizaremos es codificar el siguiente contenido XML en Base64 para ingresarlo en lo que espera la aplicación web que se le indique.
Con este archivo XXE comprobaremos si podemos definir una entidad nueva llamada example con el contenido GzzcooXXE y indicar que se muestre entre las etiquetas <cwe> como ejemplo.
Enviaremos en la variable data nuestro archivo XML malicioso y al enviar la solicitud, en la respuesta por parte del servidor comprobamos que ha interpretado la nueva entidad y se ha mostrado el contenido, con lo cual confirmamos que la aplicación web es vulnerable a XML External Entity Injection (XXE).
El contenido del archivo XML debe estar codificado como hemos comentado en Base64 y también deberemos de aplicar un URL Encode para no tener problemas. Para ello, seleccionamos el contenido en Base64 que hemos indicado en BurpSuite y haremos Ctrl+Upara aplicar el URL Encode y no tener problemas con los carácteres especiales, etc.
A continuación, el siguiente paso será intentar leer archivos arbitrarios del sistema. La siguiente estructura XML la codificaremos en Base64 y URL Encode y al enviar la solicitud desde BurpSuite, comprobaremos que finalmente hemos logrado listar el archivo /etc/passwd del servidor vulnerable.
Por lo tanto, tenemos una vía potencial de poder leer archivos arbitrarios del sistema.
XXE PHP File Read - Base64 Wrapper
El problema con la lectura de archivos en una aplicación web es que, si intentamos leer un archivo PHP, este se interpretará y no podremos ver su contenido en texto plano.
Para evitar este comportamiento, podemos usar wrappers de PHP para codificar el contenido que queremos listar. En este caso, utilizaremos un wrapper que convierte el archivo a Base64. Esto nos permite leer archivos PHP sin que el servidor los ejecute, ya que la aplicación solo mostrará el contenido codificado como una cadena de texto. Luego, simplemente decodificamos el resultado para obtener el archivo original.
Por ejemplo, al utilizar el siguiente payload, podemos leer el archivo /etc/passwd, que se nos devolverá en Base64.
Nos guardaremos el contenido en Base64 obtenido en el punto anterior y lo guardaremos en un archivo, por ejemplo, data.
El siguiente paso, será lograr descodificar el contenido de Base64 en el cual comprobaremos el archivo original de /etc/passwd.
Python Script to perform XXE Base 64 Wrapper Exploitation
Para automatizar el proceso de explotación XXE sin necesidad de codificar manualmente el archivo XML malicioso, enviar la petición a BurpSuite y decodificar la respuesta en Base64, hemos desarrollado el siguiente script en Python.
Este script construye automáticamente la solicitud a la aplicación web, inyecta una estructura XML con XXE, recupera la respuesta en Base64 y la decodifica para mostrar el contenido del archivo objetivo de forma legible.
Ejecutamos el script con el objetivo de obtener el contenido del archivo /etc/passwd y verificar que la herramienta funcione correctamente. Al ejecutar el comando, confirmamos que el script devuelve con éxito el contenido del archivo, lo que demuestra que, al proporcionar la ruta de cualquier archivo, el proceso se realiza automáticamente y obtenemos el resultado esperado.
En el resultado obtenido, comprobamos la existencia de un usuario llamado developer que dispone de bash.
Ahora que tenemos la capacidad de leer archivos PHP a través de XXE combinado con el wrapper PHP en Base64 gracias al script que hemos implementado, podemos automatizar la lectura de archivos sensibles en la aplicación. En la enumeración de la página web, recordamos que, al usar herramientas como Gobuster, encontramos una página llamada db.php. Este archivo podría contener información valiosa, como la configuración de la base de datos o incluso las credenciales de acceso.
Al ejecutar el script sobre db.php, efectivamente hemos obtenido el siguiente contenido, que incluye las credenciales de la base de datos:
Probamos de autenticarnos al SSH con estas credenciales y con el usuario development que encontramos en el archivo /etc/passwd que disponía de bash para comprobar si esta contraseña es reutilizada o no.
Finalmente logramos obtener acceso al sistema y logramos visualizar la flag user.txt.
Privilege Escalation
Abusing sudoers privilege
Revisando si el usuario developer disponía de algún permiso de sudoers, nos encontramos que puede ejecutar como sudo sin proporcionar credenciales un script de Python ubicado en /opt/skytrain_inc/tickerValidator.py.
Al acceder al directorio /opt/skytrain_inc nos encontramos con un directorio llamado invalid_tickets en el cual contenía diferentes archivos con extensión .md (Markdown). Comprobamos el contenido de uno de ellos el cual contiene una estructura de Markdown con lo que parece ser un ticket con una estructura personalizada.
Este script valida un archivo de ticket de Skytrain Inc verificando ciertas condiciones en su contenido.
Carga del archivo: El script abre un archivo especificado por el usuario si tiene la extensión
.md. Si el archivo no es un archivo Markdown, muestra un mensaje de error y termina la ejecución.Evaluación del ticket: El script analiza el contenido del archivo en busca de ciertas líneas:
La primera línea debe comenzar con
# Skytrain Inc.La segunda línea debe ser un encabezado con la forma
## Ticket to [destino].La línea que contiene
__Ticket Code:__es identificada para extraer el código del ticket.El código del ticket debe ser un número y, si al dividirlo por 7 da como resto 4, se evalúa su validez usando la expresión contenida en esa línea. Si el valor calculado es mayor que 100, el ticket es considerado válido.
Resultado: Después de evaluar el ticket, el script imprime si el ticket es válido o no según las condiciones definidas.
En resumen, el script valida un archivo de ticket basado en un formato específico de texto y reglas de validación predefinidas.
El script utiliza la función eval para evaluar una expresión dentro de un ticket.
Este uso de eval permite la ejecución de código arbitrario en el sistema si el contenido del ticket incluye una expresión que pueda ser evaluada, lo cual es un vector de vulnerabilidad. En este caso, si el ticket incluye una instrucción maliciosa como la que veremos en el siguiente ejemplo, eval ejecutará esa instrucción, permitiendo potencialmente la ejecución de código no deseado en el servidor.
Aquí se muestra un ticket que explota la vulnerabilidad del script al permitir la ejecución de código arbitrario. Un ticket malicioso podría tener el siguiente formato.
En este ejemplo, el ticket contiene una expresión en la línea Ticket Code que, al ser evaluada, no solo realiza una operación matemática, sino que además ejecuta el comando os.system('id'), lo que puede permitir ejecutar comandos arbitrarios en el sistema vulnerable.
Cuando el script evalúa la expresión del ticket que contiene código malicioso, la instrucción eval no sanitiza el contenido, por lo que el comando __import__('os').system('id') se ejecutará. Este código malicioso ejecuta el comando id en el sistema, lo que devolverá información sobre el usuario actual. La ejecución de este código en el script tendría el siguiente resultado.
El comando id es ejecutado en el sistema, lo que potencialmente compromete la seguridad del entorno. En un escenario real, un atacante podría utilizar esta vulnerabilidad para ejecutar comandos maliciosos en el servidor donde se ejecuta el script.
Al ejecutar el archivo gzzcoo.md con el script ticketValidator.py, el sistema evalúa el código del ticket que contiene la expresión 31+410+86. Al ejecutar el script, muestra la siguiente salida.
En este caso, el código del ticket no pasa la validación, ya que el resultado de la operación 31 + 410 + 86 no cumple con los requisitos para ser considerado válido, lo que lleva a que el script devuelva el mensaje "Invalid ticket".
En el archivo gzzcoo.md que se presenta a continuación, intentamos explotar la vulnerabilidad en la función eval del script ticketValidator.py. Al introducir una expresión maliciosa como parte del código del ticket, podemos ejecutar comandos arbitrarios en el sistema.
Aquí, hemos modificado el Ticket Code para incluir un comando Python que invoca la función os.system('id'), lo cual ejecuta el comando id en el sistema operativo. Esta es una forma de aprovechar la vulnerabilidad en el uso de eval que no sanitiza la entrada.
Al ejecutar el script ticketValidator.py con un archivo de ticket malicioso, observamos que se ejecuta el comando id a través de la vulnerabilidad en la función eval. El resultado muestra que, aunque el script indica "Invalid ticket", el comando id sigue ejecutándose, revelando que el sistema está corriendo con privilegios de root.
Dado que tenemos permisos de sudoers, y en el punto anterior comprobamos que el resultado del comando id era root, si conseguimos ejecutar la reverse shell, obtendremos una shell como el usuario root. Esto se debe a que el script ticketValidator.py se ejecuta con privilegios de root, lo que nos permite ejecutar comandos con estos privilegios sin restricciones. Así, al inyectar el comando de la reverse shell en el ticket, la ejecución nos otorgará acceso a la máquina como root.
Nos ponemos en escucha ocn nc para recibir la conexión de la Reverse Shell.
Ejecutaremos el script como sudo ya que disponemso de permisos de sudoers para ejecutar el script como sudo. Indicaremos la ruta de nuestro archivo gzzcoo.md el cual contiene la inyección para vulnerar la función eval del script tal y como comentamos anteriormente.
Comprobamos que recibimos la Reverse Shell como el usuario root y logramos visualizar finalmente la flag root.txt.
Última actualización
¿Te fue útil?