Backfire
Reconnaissance
Realizaremos un reconocimiento con Nmap para ver los puertos que están expuestos en la máquina Backfire. 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. Verificamos que al parecer se trata de una máquina Ubuntu que dispone de dos páginas de Nginx (puerto 443 y 8000) y el servicioSSH.
Procederemos a transformar 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
Revisando la página web de https://10.10.11.49, verificamos que nos carga una página con un error de 404 Not Found de Nginx.
Revisando la página web de http://10.10.11.49:8000, nos encontramos con dos archivos, los descargaremos para verificar el contenido de estos.
El archivo disable_tls.patch aplica cambios para deshabilitar TLS en las conexiones WebSocket del puerto de gestión 40056. Según los comentarios, el objetivo es probar que "sergej no está trabajando". Aclaran que el puerto solo permite conexiones locales mediante tunelización SSH, por lo que, según ellos, esto no comprometería la seguridad del servidor.
El archivo havoc.yaotl es una configuración para un equipo que utiliza el framework Havoc. Este archivo contiene información clave sobre la configuración del teamserver, las credenciales de los operadores, la configuración de los demonios y los listeners. El TeamServer se encuentra en un puerto interno 40056.
Initial Access
Exploitation SSRF HavocC2 - (CVE-2024-41570)
Durante la fase de investigación, identificamos una vulnerabilidad en HavocC2 relacionada con un SSRF (Server Side Request Forgery), documentada en el CVE-2024-41570. Para explorarla, utilizamos el siguiente repositorio público que contiene una prueba de concepto (PoC):
Según el blog del creador de la PoC, la vulnerabilidad permite explotar una solicitud maliciosa para interactuar con recursos internos del servidor, lo que potencialmente puede revelar información sensible, como direcciones IP internas o servicios en ejecución.
En este caso, nos clonamos el proyecto en nuestro equipo local.
Levantamos un servidor HTTP local para recibir las solicitudes provenientes de la explotación del SSRF.
Utilizamos el script exploit.py de la PoC para interactuar con el equipo objetivo y tratar de descubrir información interna.
Aunque el exploit se ejecutó correctamente, la solicitud realizada al servidor no reveló información adicional relevante. En lugar de una dirección IP interna, recibimos la respuesta HTTP estándar 404 File not found.
Creating a Python Script to exploit SSRF-RCE on the machine
Con la ayuda de ChatGPT, creamos el siguiente script en Python que aprovecha una vulnerabilidad de SSRF para lograr un RCE, adaptándose a las configuraciones observadas en el sistema objetivo. A continuación, se detalla su funcionamiento:
Registro del Agente
La función register_agent envía una solicitud cifrada con información del host comprometido, incluyendo nombre del usuario, IP interna y detalles del proceso. Esto registra al agente malicioso en el sistema.
Comunicación mediante WebSocket
Se establece un WebSocket autenticado utilizando las credenciales ilya:CobaltStr1keSuckz!. Posteriormente, se configura un listener para recibir conexiones del sistema objetivo.
Construcción del Payload SSRF-RCE
El payload malicioso utiliza la siguiente cadena para ejecutar comandos arbitrarios en el servidor
Crearemos nuestro archivo payload.sh el cual ejecuta una Reverse Shell hacía nuestro equipo. Lo compartiremos a través de un servidor web por el puerto especificado en el exploit.
Por otro lado, nos pondremos en escucha por el puerto indicado en la Reverse Shell.
Al ejecutar el exploit.py modificado, le indicaremos el target el cual será el objetivo https://10.10.11.49 y la dirección y puertos internos del WebSocket que encontramos en la configuración de HavocC2.
Verificamos que hemos logrado explotar la vulnerabilidad de SSRF combinaco con el rce para obtener acceso al equipo. Logramos verificar la flag de user.txt.
Uploading our public SSH key to the machine to connect with SSH
La Shell que hemos recibido, por un motivo u otro era bastante inestable y se cerraba al poco tiempo.
Por lo tanto, lo que decidimos es subir nuestra clave pública SSH al equipo para conectarnos mediante SSH sin proporcionar credenciales.
En nuestro equipo atacante, generaremos unas nuevas claves SSH.
Revisaremos el contenido de nuestra clave SSH pública.
Estando conectados en el equipo víctima, navegaremos al directorio /home/ilya/.ssh para añadir nuestra clave pública en el archivo authorized_keys.
Desde nuestro equipo atacante, nos conectaremos mediante SSH al equipo víctima con el usuario ilya y verificaremos que no nos requiere de credenciales de acceso.
Lateral Movement
Reviewing services on the machine and detecting running HardHat 2 services
Revisando el directorio de ilya, nos encontramos con el siguiente archivo hardhat.txt el cual informa que el usuario sergej dice haber instalado HardHatC2 para realizar pruebas y que no realizó ningún cambio a las configuraciones por defecto. También indica que espera que haya escogido el C2 de Havoc en vez del mencionado.
Buscamos información sobre HardHat C2, nos encontramos con el repositorio del framework en el cual nos informan de las características, configuraciones y demás. Entre la información obtenida del repositorio del framework, nos informa que normalmente utiliza los puertos 5000 y 7096.
Al verificar los puertos internos que se encuentran en ejecución en el equipo víctima, verificamos que estos puertos están abiertos de manera interna. Lo cual nos hace pensar que el framework de HardHat C2 se encuentra activo.
Revisando los procesos activos, verificamos que el usuario sergej es el que está levantando este framework.
Por otro lado, verificamos a través de los siguientes comandos que efectivamente el servicio se encuentre en ejecución.
Revisando el directorio /etc/systemd/system, nos encontramos con los archivos relacionados a HardHat C2.
Investigamos sobre el contenido de estos archivos, por si tuvieran alguna configuración que nos pudiese aportar información. En este caso, nos indican la misma información obtenida anteriormente.
SSH Port Forwarding to Share Internal Ports
Decidimos realizar SSH Port Forwarding para disponer de estos puertos en nuestro equipo local por los mismos puertos mencionados.
Verificaremos que los puertos se encuentren abiertos en nuestro equipo local, es decir, que se haya realizado el SSH Port Forwarding correctamente.
Desde nuestro navegador, probaremos de acceder a https://127.0.0.1:7096 y nos encontramos con el panel de inicio de sesión de HardHat C2.
Si investigamos sobre la página https://127.0.0.1:5000, no encontramos ningún tipo de información.
HardHatC2 AuthN Bypass
Al investigar vulnerabilidades en HardHatC2, encontramos información sobre varias fallas en este framework.
Por defecto, HardHatC2 genera automáticamente una contraseña para la cuenta HardHat_Admin, la cual se muestra solo una vez al inicio. Sin embargo, el sistema utiliza una clave estática de firma JWT almacenada en appsettings.json, que permite a los atacantes generar tokens JWT válidos sin necesidad de autenticación.
Con esta vulnerabilidad, se puede usar el JWT para forjar un token y crear usuarios administradores sin necesidad de autenticarse.
Basándonos en el acceso a los puertos y en el archivo .txt inicial, donde se mencionaba que el framework había sido instalado con configuración por defecto, decidimos probar esta vulnerabilidad
Al ejecutar el Bypass.py, verificamos que en un principio hemos logrado crear un usuario llamado gzzcoo.
Probaremos de autenticarnos en el panel de HardHat C2 y comprobamos que hemos logrado obtener el acceso correspondiente.
HardHatC2 Remote Code Execution (RCE)
En el mismo blog en el cual nos mencionaban diferentes vulnerabilidades, se nos informaba que una vez obtenido un usuario nuevo creado con permisos de Admin, podríamos llegar a explotar un Remote Code Execution (RCE).
Para ello, debeemos acceder ahttps://127.0.0.1:7096/ImplantInteract y dispondremos de una opción llamada "Terminal·" en la cual podemos ejecutar comandos arbitrarios.
Al probar dicha funcionalidad, comprobamos que el usuario que ejecuta el comando se trata de sergej.
Privilege Escalation
Abusing sudoers privileges (iptables && iptables-save)
Revisando maneras de escalar nuestros privilegios para convertirnos en usuarioroot, nos encontramos que el usuario sergej dispone de permisos sudoers sobre iptables && iptables-save.
Realizando una bíusqueda en internet, nos encontramos con el siguiente blog que nos muestran un PoC de cómo elevar nuestros privilegios disponiendo de ambos permisos sudoers que dispone el usuario actual.
Overwriting /etc/passwd to Add New Root User via sudoers (iptables & iptables-save)
En el PoC del blog mencionado, se nos informa que disponiendo de ambos permisos de sudoers, podemos intentar sobreescribir el archivo /etc/passwd para añadir una nueva entrada de un nuevo usuario root con una contraseña asignada por nosotros mismos.
En este caso, lo que realizaremos es copiar la entrada de nuestro /etc/passwd para tener la estructura de lo que deberemos añadir en el archivo de la máquina víctima.
Una vez tengamos la entrada de plantilla, lo que deberemos realizar es crear una contraseña en el formato de OpenSSL. Deberemos de reemplazar el valor x por el de la contreaseña generada, para lograr obtener el siguiente resultado --> root:$1$Gow86CXS$sHAPSqpiT4xePLCPO147m1:0:0:root:/root:/bin/bash
Inyectaremos la entrada rootfalsificada en un nuevo comentario de regla de iptables, verificaremos que se encuentra añadida esta línea en las reglas de iptables y procederemos a sobreescribir el archivo /etc/passwd para añadir esta nueva entrada del usuario root.
En este caso, por x motivos no logramos sobreescribir el archivo mencionado, nos indica que la operación no está permitida.
Overwriting /root/.ssh/authorized_keys to Upload Our Public SSH Key via sudoers (iptables & iptables-save)
Buscando otras maneras de aprovecharnos de estos privilegios de sudoers, pensamos en subir nuestra clave pública SSH al archivo authorized_keys del usuario root. En un principio no deberíamos tener problemas al ejecutar el iptables && iptables-save con permisos de sudo.
Copiaremos nuestra clave SSH pública que obtuvimos en los pasos anteriores.
Volveremos a realizar el PrivEsc aprovechándonos de estos permisos de sudoers. En este caso, crearemos un nuevo comentario que contenga nuestra clave SSH pública. Revisaremos que nos aparece el comentario en las reglas de iptables, y procederemos a sobreescribir el archivo mencionado.
Al intentar acceder mediante SSH con el usuario root, comprobamos que no se solicita credenciales. Al subir nuestra clave pública SSH al archivo /root/.ssh/authorized_keys, logramos conectarnos sin necesidad de proporcionar una contraseña, ya que la clave pública almacenada en ese archivo se comunica directamente con nuestra clave privada.
Logramos acceso a la máquina como usuario root y verificamos la flag de root.txt.
Última actualización
¿Te fue útil?