MonitorsTwo
MonitorsTwo es una máquina Linux de dificultad fácil que muestra una variedad de vulnerabilidades y configuraciones erróneas. La enumeración inicial expone una aplicación web propensa a la ejecución de código remoto (RCE) previa a la autenticación a través de un encabezado X-Forwarded-For malicioso. La explotación de esta vulnerabilidad otorga un shell dentro de un contenedor Docker. Un binario capsh mal configurado con el bit SUID establecido permite el acceso de root dentro del contenedor. El descubrimiento de las credenciales de MySQL permite el volcado de un hash, que, una vez descifrado, proporciona acceso SSH a la máquina. Una enumeración adicional revela una versión vulnerable de Docker (CVE-2021-41091) que permite a un usuario con pocos privilegios acceder a los sistemas de archivos del contenedor montados. Aprovechando el acceso de root dentro del contenedor, se copia un binario bash con el bit SUID establecido, lo que resulta en una escalada de privilegios en el host.
Reconnaissance
Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina MonitorsTwo. 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.
Initial Foothold
Cacti 1.2.22 Exploitation - Remote Code Execution [RCE] (CVE-2022-46169)
Realizaremos una comprobación de las tecnologías que son utilizadas en el sitio web.
Accedemos a http://10.10.11.211 y verificamos que se trata de un panel de inicio de sesión de Cacti en la cual se puede verificar que la versión del software es la 1.2.22.
Buscamos a través de searchsploit si existe alguna vulnerabilidad conocida para dicha versión y nos encontramos con el siguiente resultado.
Revisando en profundidad sobre la vulnerabilidad reportada anteriormente, nos encontramos con el siguiente CVE-2022-46169.
Cacti es una plataforma de código abierto que proporciona un framework de gestión de fallos y supervisión operativa robusta y extensible para los usuarios. En las versiones afectadas, una vulnerabilidad de inyección de comandos permite a un usuario no autenticado ejecutar código arbitrario en un servidor que ejecuta Cacti, si se seleccionó una fuente de datos específica para cualquier dispositivo monitoreado. La vulnerabilidad reside en el archivo remote_agent.php. Se puede acceder a este archivo sin autenticación. Esta función recupera la dirección IP del cliente a través de get_client_addr y resuelve esta dirección IP en el nombre de host correspondiente a través de gethostbyaddr. Después de esto, se verifica que existe una entrada dentro de la tabla poller, donde el nombre de host corresponde al nombre de host resuelto. Si se encuentra dicha entrada, la función devuelve "verdadero" y el cliente está autorizado. Esta autorización se puede omitir debido a la implementación de la función get_client_addr. La función se define en el archivo lib/functions.php y verifica las variables serval $_SERVER para determinar la dirección IP del cliente. Un atacante puede establecer arbitrariamente las variables que comienzan con HTTP_. Dado que hay una entrada predeterminada en la tabla poller con el nombre de host del servidor que ejecuta Cacti, un atacante puede omitir la autenticación, por ejemplo, proporcionando el encabezado Forwarded-For: . De esta forma, la función get_client_addr devuelve la dirección IP del servidor que ejecuta Cacti.
La siguiente llamada a gethostbyaddr resolverá esta dirección IP en el nombre de host del servidor, que pasará la verificación del nombre de host poller debido a la entrada predeterminada. Después de omitir la autorización del archivo remote_agent.php, un atacante puede desencadenar diferentes acciones. Una de estas acciones se llama "polldata". La función llamada poll_for_data recupera algunos parámetros de solicitud y carga las entradas correspondientes de poller_item de la base de datos. Si la acción de un poller_item es igual a POLLER_ACTION_SCRIPT_PHP, la función proc_open se usa para ejecutar un script PHP. El parámetro controlado por el atacante $poller_id se recupera mediante la función get_nfilter_request_var, que permite cadenas arbitrarias. Esta variable luego se inserta en la cadena pasada a proc_open, lo que genera una vulnerabilidad de inyección de comando. Por ejemplo, al proporcionar poller_id=;id, se ejecuta el comando id. Para llegar a la llamada vulnerable, el atacante debe proporcionar un host_id y un local_data_id, donde la acción del poller_item correspondiente está configurada en POLLER_ACTION_SCRIPT_PHP. Ambos identificadores (host_id y local_data_id) pueden ser fácilmente forzados por fuerza bruta. El único requisito es que exista un poller_item con una acción POLLER_ACTION_SCRIPT_PHP.
Es muy probable que esto ocurra en una instancia productiva porque esta acción se agrega mediante algunas plantillas predefinidas como "Device - Uptimeo "Dispositivo - Polling Time". Esta vulnerabilidad de inyección de comandos permite a un usuario no autenticado ejecutar comandos arbitrarios si se configura unpoller_itemcon el tipoaction POLLER_ACTION_SCRIPT_PHP (2). La omisión de autorización debe evitarse al no permitir que un atacante haga que get_client_addr(archivolib/functions.php) devuelva una dirección IP arbitraria. Esto podría hacerse al no respetar las variables HTTP_... $_SERVER. Si se deben conservar por razones de compatibilidad, al menos se debe evitar falsificar la dirección IP del servidor que ejecuta Cacti. Esta vulnerabilidad se ha solucionado en las versiones 1.2.x y 1.3.x, siendo 1.2.23` la primera versión que contiene el parche.
Realizamos una búsqueda básica por Internet y logramos encontrar diferentes repositorios en los cuales parece ser que nos muestran el exploit.
Nos descargaremos el siguiente repositorio de GitHub.
Nos ponemos en escucha con nc para recibir la Reverse Shell.
Ejecutaremos el exploit para proporcionarnos una Reverse Shell hacía el equipo vulnerable.
Verificamos que nos encontramos en el equipo, pero por lo que parece ser, nos encontramos dentro de un contenedor Docker.
Realizaremos la siguiente configuración para disponer de una TTY interactiva y poder mejorar nuestra experiencia utilizando la terminal.
Initial Access
Capsh SUID Binary Exploitation to gain root access
Nos encontramos con el usuario www-data en un contenedor de Docker del equipo víctima. Por lo tanto, realizaremos una enumeración para encontrar alguna vía para elevar nuestros privilegios.
Para ello, haremos uso de linpeas.sh el cual compartiremos a través de un servidor web.
Desde el equipo comprometido, nos descargaremos el binario de linpeas.sh y le daremos los permisos correspondientes.
Después de ejecutar el escaneo, verificamos que se nos muestra el binario /sbin/capsh el cual dispone de privilegios de SUID.
A través de la herramienta de searchbins, realizaremos una consulta para verificar la manera de abusar de este binario que tiene privilegios de SUID para lograr acceso como root.
Realizaremos el comando que se nos indicaba para realizar la explotación, comprobamos finalmente que nos hemos podido convertir en usuario root del contenedor de Docker.
SQL Enumeration
Realizando una enumeración de archivos en el directorio /var/www/html/include, nos encontramos con el archivo config.php el cual contiene las credenciales en texto plano para acceder al MySQL.
Nos conectaremos al MySQL del hostname db y verificaremos las bases de datos que disponemos.
Enumeraremos la base de datos nombrada cacti en la cual dispone de una tabla llamada user_auth.
Al revisar el contenido de la tabla user_auth, logramos encontrar credenciales en formato hash de diferentes usuarios.
A través de john logramos crackear el hash de las credenciales del usuario marcus.
Probamos de autenticarnos con el usuario marcus al SSH del equipo víctima. Finalmente obtenemos el acceso correspondiente y visualizamos la flag de user.txt.
Privilege Escalation
Docker 20.10.5+dfsg1 Exploitation (CVE-2021-41091)
Revisaremos si el usuario marcus dispone de algún grupo o permisos de sudoers interesantes, pero no obtenemos resultado.
Después de enumerar diferentes directorios, enumerar el equipo con linpeas.sh, etc no logramos obtener resultado. Por lo que decidimos revisar los binarios instalados en el equipo, entre los que se encontraba el de Docker con la siguiente versión.
Al realizar una búsqueda por Internet de posibles vulnerabilidades de esa versión de Docker, nos encontramos con el siguiente CVE-2021-41091.
Moby es un proyecto de código abierto creado por Docker para permitir la contención de software. Se encontró un error en Moby (Docker Engine) en el que el directorio de datos (normalmente "/var/lib/docker") contenía subdirectorios con permisos insuficientemente restringidos, lo que permitía a usuarios de Linux no privilegiados saltar el contenido del directorio y ejecutar programas. Cuando los contenedores incluían programas ejecutables con bits de permiso extendidos (como "setuid"), los usuarios no privilegiados de Linux podían detectar y ejecutar esos programas. Cuando el UID de un usuario de Linux no privilegiados en el host colisionaba con el propietario o el grupo de un archivo dentro de un contenedor, el usuario de Linux no privilegiados en el host podía descubrir, leer y modificar esos archivos. Este bug ha sido corregido en Moby (Docker Engine) versión 20.10.9. Usuarios deberían actualizar a esta versión lo antes posible. Los contenedores en ejecución deben ser detenidos y reiniciados para que los permisos sean corregidos. Para usuarios que no puedan actualizar, limite el acceso al host a usuarios confiables. Limite el acceso a los volúmenes del host a los contenedores confiables
Al intentar enumerar si había algún contenedor en ejecución con el comando docker ps, nos devolvió un mensaje de error de acceso denegado.
Por lo tanto, decidimos revisar a través del comando mount de revisar los puntos de montaje de Docker. Finalmente, comprobamos dos overlay que podrían ser los contenedores en ejecución.
Al revisar el contenido de ambos contenedores, nos encontramos que al parecer el segundo es el de cacti, el cual teníamos acceso como usuario root.
Probaremos de verificar si la vulnerabilidad está presente, crearemos un nuevo archivo gzzcoo.txt en el directorio /tmp del contenedor de Docker. Al crear dicho archivo, verificamos que posteriormente lo podemos visualizar accediendo a él.
Por lo tanto, para poder aprovecharnos de esta vulnerabilidad, lo que realizaremos es darle permisos de SUID al binario /bin/bash del contenedor de Dcoker el cual obtuvims anteriormente acceso como root.
Una vez asignado los permisos correspondientes, ejecutaremos el /bin/bash accediendo directamente desde /var/lib/docker/overlay2. Verificamos que finalmente nos hemos convertido en usuario root en el equipo objetivo y no en el de Docker.
Logramos obtener finalmente la flag de root.txt.
Por otro lado, nos encontramos con el siguiente exploit en Bash que nos guiaba en la explotación, ya que está realizado de una manera más automatizada.
Al ejecutar el exploit, se nos indica que le hayamos otorgado el setuid al /bin/bash del contenedor de Docker. Una vez realizada esta verificación, se nos indicará el Vulnerable Path y cómo abusar de esta vulnerabilidad.
Ejecutaremos la bashmodificada del contenedor de Docker y logramos obtener el acceso como usuario root en el sistema objetivo y no el contenedor de Docker.
Última actualización
¿Te fue útil?