Editorial
Editorial es una máquina Linux de dificultad fácil que cuenta con una aplicación web de publicación vulnerable a Server-Side Request Forgery (SSRF). Esta vulnerabilidad se aprovecha para obtener acceso a una API interna en ejecución, que luego se aprovecha para obtener credenciales que conducen al acceso SSH a la máquina. Al enumerar el sistema, se revela además un repositorio Git que se aprovecha para revelar las credenciales de un nuevo usuario. El usuario root se puede obtener explotando CVE-2022-24439 y la configuración sudo.
Reconnaissance
Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Editorial. 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 Nginx.
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.
Añadiremos en nuestro archivo /etc/hosts la siguiente entrada correspondiente.
Web Enumeration
Realizaremos una comprobación de las tecnologías que son utilizadas en el sitio web.
Accederemos a http://editorial.htb y nos encontramos con la siguiente página web. Al parecer, se trata de una página de libros.
Realizaremos una enumeración de páginas y directorios de la aplicación web, en el cual se nos muestra el siguiente resultado obtenido.
Initial Access
Server Side Request Forgery (SSRF) Exploitation + Internal Port Discovery
Al acceder a http://editorial.htb/upload nos encontramos con la siguiente página web en la cual al parecer nos permite subir nuestro propio libro para que la editorial nos lo revise.
Entre los campos que nos permite añadir o modificar, se nos indica que podemos añadir una URL de nuestra cover de nuestro libro, subir el libro y añadir la descripción correspondiente.
Lo primero se nos ocurre es en probar si la URL que podemos indicar, puede ser la de nuestro servidor web que nos montaremos a continuación. Por ello, nos levantamos a través de python un servidor web.
Ingresamos nuestra URL de nuestro servidor web que apunte a un recurso (inexistente) y al darle a la opción de Send book info no obtenemos resultado ninguno en nuestro servidor web.
Probamos de darle a la opción de Preview para verificar si a través de esta opción recibíamos algún tipo de solicitud en nuestro servidor web.
Comprobamos en nuestro servidor web que se ha recibido correctamente la solicitud por el método GET a nuestro servidor web a través de la dirección IP del servidor víctima.
Teniendo esto en cuenta, se nos pueden ocurrir probar diferentes tipos de ataque, como por ejemplo, un Server-Side Request Forgery (SSRF).
Para ello, primero interceptaremos la solicitud a través de BurpSuite al darle a la opcioón de Preview y modificaremos la URL para que apunte a un servidor web interno por el puerto 80. En la respuesta por parte del servidor, se nos proporciona un resultado, pudiendo confirmar la existencia de un posible SSRF.
Para realizar un escaneo de posibles puertos internos abiertos que pudieran haber en la máquina víctima, haremos uso de la herramienta de ffufpara realizar fuzzing.
Para ello, nos guardaremos el contenido de la petición que se tramita por POST en BurpSuite e indicaremos donde queremos que se aplique el fuzzing, en este caso, en donde hemos indicado la palabra FUZZ.
Realizaremos el fuzzing a través de ffuf sobre la URL indicada pasándole nuestro archivo de la petición que disponemos para que realice el fuzzing e indicaremos también que realice una secuencia entre el 0 y 65365 que son el nº de puertos existentes.
En el resultado obtenido, comprobamos que nos aparece que ha encontrado el puerto 5000.
Al revisar manualmente con BurpSuite sobre el SSRF sobre la dirección http://127.0.0.1:5000, también nos devuelve una información.
API Enumeration trough SSRF
Realizaremos un cURL sobre el resultado anteriormente obtenido. En el resultado que se nos muestra, nos aparece la existencia de una API con diferentes endpoints.
Realizaremos una enumeración a través del SSRF en combinación con la API para comprobar los diferentes endpoints.
En este caso, el endpoint que probamos es /api/latest/metadata/messages/authors que según comprobamos anteriormente, se almacenan los mensajes enviados a los nuevos autores. En el resultado obtenido en la respuesta del servidor, obtenemos el siguiente resultado.
Realizamos un cURL sobre el resultado obtenido en la respuesta por parte del servidor y comprobamos el siguiente contenido. En el resultado obtenido se comprueba que se nos proporcionan credenciales de acceso al sistema.
Probamos de autenticarnos con estas credenciales obtenidas al equipo a través de SSHy logramos obtener acceso. Por otro lado, también conseguimos obtener la flag de user.txt.
Pivoting to user prod
Private Github Project Enumeration + Information Leakage
Revisamos si el usuario dev disponía de algún permiso de sudoers, pero no era el caso, y tampoco formaba parte de ningún grupo interesante. Por otro lado, también comprobamos los usuarios que disponían de una bash, entre los que encontramos que existía un usuario llamado prod, con lo cual nos hizo pensar que quizás antes de realizar la escalada al usuario root, debíamos pivotar al usuario prod.
Por lo tanto, decidimos realizar una enumeración más exhausta del sistema, explorando archivos, directorios, etc.
Enumerando el directorio /opt/internal_apps nos encontramos con diferentes directorios entre los cuales con el usuario dev no disponíamos del acceso.
Realizando una enumeración en el directorio /home/dev/apps nos encontramos con un directorio privado de .git en el cual al realizar un git status se nos mostró el siguiente resultado.
A través del comando git log, revisaremos los logs de los diferentes commit que se han ido realizando.
Para obtener la misma información, pero más resumida en una única línea, haremos uso del siguiente comando.
Mediante el comando de git diff comprobaremos diferencias entre los diferentes commits que existen. En la compración entre los siguientes commits, comprobamos que aparecen las credenciales del usuario dev y el usuario prod.
Verificamos si las credenciales del usuario prod son válidas para autenticarse al SSHdel equipo víctima. Finalmente comprobamos el acceso al sistema con el usuario prod logrando correctamente realizar el pivoting.
Privilege Escalation
Abusing sudoers privilege
Revisando los permisos de sudoers para comprobar si el usuario prod disponía de alguno, nos encontramos con el siguiente resultado. Al parecer, podemos ejecutar como el usuario root un script de Python3 ubicado en /opt/internal_apps/clone_changes/clone_prod_change.py.
El script clone_prod_change.py está escrito en Python y utiliza la librería GitPython para clonar un repositorio desde una URL proporcionada como argumento. A continuación, desglosamos su funcionamiento:
Importación de módulos: Se importan las librerías
os,sysygit(deGitPython), lo que indica que el script interactúa con Git y el sistema de archivos.Cambio de directorio: Se cambia el directorio de trabajo a
/opt/internal_apps/clone_changes, lo que sugiere que todas las operaciones se realizarán en esta ruta.Obtención de la URL: El script toma la URL del repositorio que se quiere clonar desde el primer argumento de la línea de comandos (
sys.argv[1]).Inicialización del repositorio: Se crea un repositorio vacío (
bare=True) en el directorio actual usandoRepo.init().Clonación del repositorio: Se clona el repositorio especificado en la carpeta
new_changesmedianter.clone_from(), con la opción-c protocol.ext.allow=always, lo que permite protocolos de transporte personalizados en Git.
GitPython 3.1.29 Exploitation - Remote Code Execution [RCE] (CVE-2022-24439)
Revisamos la versión exacta de la libreria de gitpython que se está utilizando en el script y nos encontramos con la versión 3.1.29.
Realizando una búsqueda por Internet, nos encontramos con la siguiente vulnerabilidad de GitPython 3.1.29 reportada como CVE-2022-24439.
Todas las versiones del paquete gitpython son vulnerables a la ejecución remota de código (RCE) debido a una validación incorrecta de la entrada del usuario, lo que hace posible inyectar una URL remota creada con fines malintencionados en el comando de clonación. Es posible explotar esta vulnerabilidad porque la librería realiza llamadas externas a git sin una sanitización suficiente de los argumentos de entrada.
Por otro lado, nos encontramos con el siguiente blog el cual nos muestran cómo poder realizar la explotación correctamente. En nuestra primera prueba, lo que realizamos es realizar la ejecución del script como sudo y le indicamos 'ext::sh -c touch% /tmp/pwned' que sería la inyección a realizar. En este caso, al realizar la ejecución del script con el payload malicioso, se comprueba que se ha creado correctamente el archivo /tmp/pwned y el propietario es root. Con lo cual, hemos confirmado la existencia de un Remote Code Execution que es ejecutado con el usuario root.
Por lo tanto, realizaremos el siguiente script en Bash que lo que realizará es proporcionar permisos de SUIDal binario /bin/bash. Creamos el archivo, le damos los permisos de ejecución correspondientes.
Verificamos que antes de realizar la ejecución de la vulnerabilidad, el binario /bin/bashno dispone de permisos de SUID. Una vez verificado, realizamos la ejecución del script inyectándole nuestro payload malicioso 'ext::sh -c /tmp/exploit.sh' para que ejecute el script que hemos creado en el punto anterior.
Al ejecutar el script, verificamos que el binario /bin/bash dispone de permisos de SUID, con lo cual, a través del parámetro -p podemos convertirnos en el propietario del binario que en este caso es root.
Comprobamos el acceso como el usuario rooty la visualización de la flag root.txt.
Última actualización
¿Te fue útil?