Broker
Broker es una máquina Linux de fácil dificultad que aloja una versión de Apache ActiveMQ. La enumeración de la versión de Apache ActiveMQ muestra que es vulnerable a la ejecución de código remoto no autenticado, que se aprovecha para obtener acceso de usuario en el objetivo.
La enumeración posterior a la explotación revela que el sistema tiene una configuración incorrecta de sudo que permite al usuario activemq ejecutar sudo /usr/sbin/nginx, que es similar a la reciente divulgación de Zimbra y se aprovecha para obtener acceso de root.
Reconnaissance
Realizaremos un reconocimiento con Nmap para ver los puertos que están expuestos en la máquina Broker. 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 una página de Nginx y un servicio llamado ActiveMQ.
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.
Procederemos a intentar acceder a http://10.10.11.243/, verificamos que esta página web requiere de credenciales de acceso. Probando con admin/admin verificamos que ganamos acceso a la página web.
La página web al parecer habla sobre un servicio llamado ActiveMQ. Revisando información sobre este software nos encontramos lo siguiente.
Verificamos que en el resultado obtenido en Nmap, nos aparece la versión de este software: ActiveMQ.
Initial Access
ActiveMQ Exploitation - Deserialization Attack (CVE-2023-46604) [RCE]
Realizando una búsqueda sobre posibles vulnerabilidades de este software, nos encontramos con el siguiente CVE-2023-46604.
El protocolo Java OpenWire marshaller es vulnerable a la ejecución de código remoto. Esta vulnerabilidad puede permitir a un atacante remoto con acceso a la red a un corredor de OpenWire basado en Java o cliente ejecutar comandos de shell arbitrarios manipulando tipos de clase serializados en el protocolo OpenWire para hacer que el cliente o el corredor (respectivamente) instantáneamente cualquier clase en el camino de clase.
Se recomienda a los usuarios actualizar tanto a los corredores como a los clientes a la versión 5.15.16, 5.16.7, 5.17.6, o 5.18.3 que corrija este problema.
También nos encontramos con el siguiente repositorio de GitHub en la cual nos aparece el exploit para poder aprovecharnos de esta vulnerabilidad. Procederemos a descargarnos el repositorio en nuestro equipo atacante.
En el repositorio nos explica el funcionamiento del exploit. En este caso lo que nos indica es generar un binario malicioso ELF que nos proporcione una Reverse Shell, al ejecutar el exploit ganaremos acceso a la máquina víctima a través de que el ActiveMQ procesa el XML que disponemos del repositorio y al deserializarlo se logra explotar esta vulnerabilidad.
El primer paso a realizar, será crear un payload de la Reverse Shell con el formato .elf y el nombre test.elf, donde especificaremos nuestra dirección IP y el puerto donde estaremos en escucha con nc.
Del archivo que nos proporciona el repositorio, procederemos a modificar el archivo poc-linux.xml y modificaremos la IP por la nuestra, dejaremos el resto por defecto.
Levantaremos un servidor web con Python por el puerto 8001, el especificado en el archivo XML.
Por otro lado, nos pondremos en escucha por el puerto especificado en el payload generado con msfvenom.
Procederemos a explotar la vulnerabilidad indicando la dirección IP de la víctima, el puerto donde se encuentra el ActiveMQ (por defecto viene en el 61616) y la URL donde nosotros tenemos alojado el archivo XML malicioso que deserializará el ActiveMQ.
Verificamos que si volvemos a la terminal donde estabamos en escucha, recibimos correctamente la Reverse Shell hacía la máquina víctima. Verificamos los grupos y demás que disponemos sin ver nada que nos pueda servir para escalar privilegios.
Privilege Escalation
Abusing sudoers privilege (nginx)
Revisando si disponemos de algún permiso de sudo, verificamos que podemos ejecutar el Nginx como usuario root.
Realizando una búsqueda por Internet de como aprovecharnos de esta vulnrabilidad, nos encontramos con el siguiente repositorio de GitHub.
El siguiente repositorio nos proporcionaba el siguiente script para crear una configuración en Nginx maliciosa.
El siguiente script realizará una configuración de Nginx que habilite una página web por el puerto 1338. Se indicará que el servidor tenga capacidad para realizar un listado de directorios (directory listing) en el directorio raíz (/), dado que el usuario que ejecuta Nginx es root.Esto nos permitirá listar los archivos del sistema sin restricciones.
Además, se habilitará el método PUT para que se puedan subir contenidos a través de la página web vulnerable que estamos montando. Una vez configurado, procederemos a cargar la configuración del sitio web vulnerable.
Procederemos a darle permisos de ejecución al script realizado y a ejecutarlo para levantar el sitio web vulnerable.
Revisamos que si accedemos a http://10.10.11.243:1338 tenemos la capacidad de listar los directorios desde la raíz /.
Al verificar esto, y dado que hemos verificado en el escaneo inicial de Nmap de que el servicio de SSH se encuentra expuesto, el objetivo será crear en nuestra máquina atacante una clave pública que subiremos a través del método PUT al servidor web vulnerable en la ruta /root/.ssh/authorized_keys.
Mostraremos el contenido de la clave pública id_rsa.pubque hemos generado en nuestra máquina y a través de la herramienta cURL procederemos a subir este contenido dentro del archivo authorized_keys, esto con el objetivo de que nuestra clave pública se encuentre permitida en la máquina pública y nos podamos conectar como usuario root sin proporcionar credenciales.
Verificaremos que se ha subido correctamente el contenido dentro del archivo authorized_keys.
Procederemos a coenctarnos mediante SSH con el usuario root en la máquina víctima. Verificamos del acceso correctamente y de la flag user.txt.
Última actualización
¿Te fue útil?