Busqueda
Busqueda es una máquina Linux de dificultad fácil que implica explotar una vulnerabilidad de inyección de comandos presente en un módulo Python. Al aprovechar esta vulnerabilidad, obtenemos acceso a nivel de usuario a la máquina. Para escalar privilegios a root, descubrimos credenciales dentro de un archivo de configuración Git, lo que nos permite iniciar sesión en un servicio Gitea local. Además, descubrimos que un script de verificación del sistema puede ser ejecutado con privilegios root por un usuario específico. Al utilizar este script, enumeramos los contenedores Docker que revelan las credenciales para la cuenta Gitea del usuario administrador. Un análisis más detallado del código fuente del script de verificación del sistema en un repositorio Git revela un medio para explotar una referencia de ruta relativa, lo que nos otorga Ejecución remota de código (RCE) con privilegios root.
Reconnaissance
Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Busqueda. 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.
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 la siguiente entrada en nuestro archivo /etc/hosts.
Web Enumeration
Realizaremos una comprobación de las tecnologías que utiliza el sitio web.
Revisaremos las cabeceras de la página web, podemos confirmar que utiliza como servidor Werkzeug y Python.
Realizamos una enumeración de directorios y páginas web a través de feroxbuster, logramos obtener el siguiente resultado.
Accedemos a http://searcher.htb y verificaremos la siguiente página web.
Esta plataforma nos permite realizar búsquedas en múltiples motores, como Google, YouTube, DuckDuckGo y eBay, entre otros.
Además, nos ofrece la posibilidad de monitorizar menciones públicas en redes sociales y la web, facilitando el seguimiento de nuestra presencia en línea desde un panel centralizado.
Para usarla, solo necesitamos:
Seleccionar el motor de búsqueda.
Escribir nuestra consulta.
Hacer clic en "Search".
Si activamos la opción de redirección automática, seremos llevados directamente a los resultados. De lo contrario, obtendremos la URL de la búsqueda para utilizarla como queramos.
Realizaremos una búsqueda básica para ver el funcionamiento de la página web.
En el resultado obtenido, verificamos que se ha realizado la siguiente búsqueda.
Initial Access
Searchor 2.4.0 - Command Injection (CVE-2023-43364)
En la propia página web de Busqueda, nos encontramos que la página web utiliza Flask y Searchor 2.4.0.
Realizando una búsqueda por Internet de posibles vulnerabilidades sobre esta versión, nos encontramos con el siguiente CVE-2023-43364.
main.py en Searchor anterior a 2.4.2 usa eval en la entrada CLI, lo que puede provocar la ejecución inesperada de código.
Por otro lado, nos encontramos con el siguiente repositorio de GitHub que automatiza la explotación de la vulnerabilidad otorgándonos una Reverse Shell.
Nos pondremos en escucha con nc para recibir la Reverse Shell.
Realizaremos la explotación indicando el target vulnerable y nuestra dirección y puerto donde recibiremos la Reverse Shell.
Verificamos que hemos ganado el acceso correctamente al equipo.
Para realizar la explotación manual, interceptaremos con BurpSuite la solicitud de http://searcher.htb/search?engine=Google&query=. Inyectaremos el siguiente comando, al enviar la solicitud, comprobamos en la respuesta por parte del servidor recibimos el resultado de la ejecución de comandos.
El siguiente paso, será lograr obtener una Reverse Shell. Para ello, crearemos en nuestro equipo un archivo llamado shell.sh que contiene la Reverse Shell, compartiremos el script a través de un servidor web.
Desde otra terminal nos pondremos en escucha con nc.
Realizaremos la siguiente inyección de comando para que realize la petición concURL de nuestro script shell.sh y lo ejecutará en una bash.
Verificamos que finalmente ganamos acceso al sistema con el usuariosvc y logramos comprobar la flag de user.txt.
Privilege Escalation
Information Leakage to access Gitea
Al acceder al equipo, verificamos que al revisar los permisos de sudoers nos requiere ingresar las credenciales del usuario, las cuales no disponemos actualmente. Revisamos los grupos a los que forma parte y tampoco disponemos de algún grupo que podamos abusar para escalar nuestros privilegios.
Enumerando el directorio /var/www/app nos encontramos con un repositorio de /.git en el cual contiene un archivo de configuración con lo que parecen ser credenciales de acceso del usuario cody.
Enumerando el directorio personal del usuario svc también observamos un archivo .gitconfig el cual contiene la configuración del usuario cody.
Revisaremos los puertos internos del equipo, y logramos encontrar el puerto 3000 abierto, que normalmente es utilizado para Gitea.
Realizamos una petición con cURL al servidor 127.0.0.1:3000 en el cual nos devuelve información de la página web relacionada con Gitea.
El siguiente objetivo será realizar Port Forwarding con chisel para lograr tener acceso a la página web de Gitea. Para ello, compartiremos el binario de chisel a través de un servidor web.
Desde el equipo comprometido, nos descargaremos el binario de chisel y le daremos los permisos de ejecución correspondientes.
En nuestro equipo local, configuraremos chisel para que actúe como servidor.
Desde el equipo comprometido, configuraremos chisel para que actúe como cliente de nuestro servidor y compartiremos el puerto 3000 interno a que sea el puerto 80 de nuestro equipo local.
Añadiremos la siguiente entrada en nuestro archivo /etc/hosts.
Accederemos a http://gitea.searcher.htb y probaremos de acceder con las credenciales del usuario cody localizadas anteriormente.
Enumerando el Gitea, logramos encontrar un repositorio propio de nuestro usuario.
Revisamos el repositorio que disponemos, y comprobamos que se trata del archivo de Searchor, la página web desde la cual obtuvimos el acceso inicial al sistema.
Abusing sudoers privilege + Information Leakage in Docker Containers
Probamos de validar si las credenciales del usuario cody de Gitea servían para el usuario svc y comprobamos que son sus credenciales correctas.
Al analizar si disponíamos de privilegios de sudoers, nos encontramos que podemos ejecutar el siguiente script en /opt/scripts/system-checkup.py.
Enumeramos el directorio /opt/scripts en los cuales aparecen diversos script de Bash y Python, al intentar comprobar el contenido de estos archivos se nos indica Permission denied.
Probamos de ejecutar el script de Python como sudo y nos aparece un mensaje indicando que no disponemos del acceso para ejecutar el binario.
Al intentar poner otro valor a la hora de ejecutar el script, verificamos que nos permite ejecutar diversos comandos de Docker, como listar los contenedores en ejecución, inspeccionar y realizar un escaneo del sistema.
A través del siguiente comando, comprobaremos mediante el script system-checkup.py los contenedores de Docker en ejecución, entre los que encontramos contenedores de Gitea y MySQL.
Al intentar inspeccionar el contenedor, se nos indica el uso correcto de la herramienta, se nos requiere especificar el formato y el nombre del contenedor.
Por la estructura del comando, parece ser comandos de Docker nativos. Con lo cual, decidimos consultar la información oficial de Docker sobre el comando de docker inspect
En este caso, inspeccionamos el contenedor de Gitea para que nos muestre el resultado en formato JSON. En el resultado obtenido, nos aparecen credenciales de una base de datos llamada gitea.
Inspeccionamos el contenedor mysql para enumerar la configuración de dicho contenedor, la información era bastante amplia.
Al realizar la ejecución del último comando, se nos indicaba que había ocurrido algún error, intentamos añadir algún parámetro, etc pero obtuvimos siempre le mismo resultado.
Enumeramos la configuración de red que disponía el contenedor de mysql. En el resultado obtenido, comprobamos que el contenedor de mysql operaba a través de la IP 172.19.0.3.
Revisamos la interfaz de docker0 que tenía el equipo comprometido y verificamos que estuviese y tuviese conectividad con la que operaba el MySQL.
Probamos de acceder al MySQL del contenedor de Docker con el usuario gitea y las credenciales localizadas en la configuración del contenedor gitea a través de la dirección IP 172.19.0.3.
Logramos obtener el acceso correspondiente y enumerar las tablas, entre las cuales aparecía la tabla users.
Al enumerar los valores de la tabla users, nos encontramos con las credenciales del usuario administrator para Gitea.
Accessing on Gitea with Administrator's user
Volvimos a nuestro equipo local donde tenemos acceso al Gitea mediante Port Forwarding. Probamos de acceder con las credenciales del usuario Administrator localizadas en el punto anterior y comprobamos del acceso correspondiente. También, logramos verificar que disponíamos de un repositorio llamado scripts.
Al acceder al repositorio de scripts, logramos visualizar diferentes archivos/scripts que parecen ser los que se encontraban en /opt/scripts que inicialmente no podíamos visualizar su contenido.
El primer script que logramos visualizar es el de check-ports.py el cual después de revisarlo, no logramos sacar nada relevante.
A continuación, se muestra el contenido de full-checkup.sh.
Contenido del script install-flask.sh
Contenido del script system-checkup.py.
Relative Path Exploitation in Script
Después de una revisión exhaustiva de los scripts encontrados, nos encontramos que el script full-checkup.sh podíamos llegar a obtener acceso como root debido a una mala configuración.
En el archivo del script, se mencionaba la función full-checkup en la cual probaba de ejecutar un script llamado full-checkup.sh. De la manera que está representado este valor, no se le indica la ruta absoluta del archivo de Bash, con lo cual nos puede permitir crear un archivo con el mismo nombre que realice otra acción que deseemos. Recordemos que este script lo ejecutamos como usuario sudo, con lo cual podríamos llegar a modificar archivos, etc para lograr acceso al sistema.
Por lo tanto, decidimos de crear un archivo llamado full-checkup.sh que lo que realizaría es otorgar al binario /bin/bash permisos de SUID.
Al ejecutar el script con la función full-checkup, al disponer del script malicioso en el mismo repositorio, se nos indicó el mensaje de Done.
Revisamos los permisos de /bin/bash y comprobamos que tiene permisos de SUID. Nos aprovechamos de esto para convertirnos en usuarioroot y visualizar la flag de root.txt.
Última actualización
¿Te fue útil?