Pentests y Log4J: Cómo explotar un sistema vulnerable

En este artículo, probamos un sistema vulnerable y demostramos cómo se puede obtener un shell remoto utilizando un exploit de código abierto de Log4j que está disponible para cualquier persona.

Introducción

Esta vulnerabilidad crítica, etiquetada como CVE-2021-44228, afecta a una gran cantidad de clientes, ya que el componente Apache Log4j se usa ampliamente tanto en software comercial como de código abierto. Además, los atacantes de ransomware están armando el exploit Log4j para aumentar su alcance a más víctimas en todo el mundo.

Nuestra demostración se proporciona con fines educativos para una audiencia más técnica con el objetivo de brindar más conocimiento sobre cómo funciona este exploit.

Raxis cree que una mejor comprensión de la composición de los exploits es la mejor manera para que los usuarios aprendan a combatir las crecientes amenazas en Internet.

Explotación de Log4j Guión Gráfico

La vulnerabilidad Apache Log4j, CVE-2021-44228 ( https://nvd.nist.gov/vuln/detail/CVE-2021-44228 ), afecta a una gran cantidad de sistemas y los atacantes actualmente están explotando esta vulnerabilidad para conectarse a Internet. sistemas en todo el mundo.

Para demostrar la anatomía de tal ataque, Raxis proporciona una demostración paso a paso del exploit en acción. Dentro de nuestra demostración, hacemos suposiciones sobre el entorno de red utilizado para el servidor de la víctima que permitiría que se produjera este ataque.

Sin duda, hay muchas maneras de evitar que este ataque tenga éxito, como usar configuraciones de firewall más seguras u otros dispositivos de seguridad de red avanzados; sin embargo, seleccionamos una configuración de seguridad "predeterminada" común para demostrar este ataque.

Servidor víctima

Primero, nuestro servidor víctima es un servidor web Tomcat 8 que usa una versión vulnerable de Apache Log4j y está configurado e instalado dentro de un contenedor docker.

El contenedor docker nos permite demostrar un entorno separado para el servidor víctima que está aislado de nuestro entorno de prueba. Nuestro servidor Tomcat aloja un sitio web de muestra que se puede obtener en https://github.com/cyberxml/log4j-poc y está configurado para exponer el puerto 8080 para el servidor web vulnerable.

No se exponen otros puertos de entrada para este contenedor acoplable que no sea 8080. El contenedor acoplable permite el tráfico saliente, similar a la configuración predeterminada de muchas redes de servidores.

Tenga en cuenta que este repositorio de GitHub en particular también presentaba una versión integrada del código de ataque Log4j y la carga útil; sin embargo, lo deshabilitamos para nuestro ejemplo para proporcionar una vista de las pantallas tal como las ve un atacante. Solo usamos las partes del servidor web Tomcat 8, como se muestra en la siguiente captura de pantalla.

Figura 1: Código de ejecución del servidor web de demostración Tomcat 8 de la víctima vulnerable al exploit Log4j

A continuación, debemos configurar la estación de trabajo del atacante. Utilizando el código de explotación de https://github.com/kozmer/log4j-shell-poc, Raxis configura tres sesiones de terminal, llamadas Netcat Listener, Python Web Server y Exploit, como se muestra a continuación.

Oyente de Netcat, puerto 9001

La sesión de Netcat Listener, indicada en la Figura 2, es un Netcat listener que se ejecuta en el puerto 9001. Esta sesión es para capturar el shell que nos pasará desde el servidor de la víctima a través del exploit.

Figura 2: Netcat Listener del atacante en el puerto 9001

Servidor web Python, puerto 80

La sesión del servidor web de Python en la Figura 3 es un servidor web de Python que se ejecuta en el puerto 80 para distribuir la carga útil al servidor de la víctima.

Figura 3: servidor web Python del atacante para distribuir la carga útil

Código de explotación, puerto 1389

La sesión de Exploit, que se muestra en la Figura 4, es el código de explotación de Log4j de prueba de concepto que opera en el puerto 1389, creando un servidor LDAP armado.

Este código redirigirá al servidor de la víctima para descargar y ejecutar una clase de Java que se obtiene de nuestro servidor web Python que se ejecuta en el puerto 80 anterior.

La clase Java está configurada para generar un shell en el puerto 9001, que es nuestro oyente de Netcat en la Figura 2.

Figura 4: Código de explotación de Log4J del atacante

Ejecutar el ataque

Ahora que el código está preparado, es hora de ejecutar nuestro ataque. Nos conectaremos al servidor web de la víctima usando un navegador web Chrome.

Nuestra cadena de ataque, que se muestra en la Figura 5, explota JNDI para realizar una consulta LDAP a la sesión de explotación del atacante que se ejecuta en el puerto 1389.

Figura 5: Sitio web de la víctima y cadena de ataque

La cadena de ataque explota una vulnerabilidad en Log4j y solicita que se realice una búsqueda en el servidor LDAP armado del atacante.

Para hacer esto, se realiza una solicitud de salida desde el servidor de la víctima al sistema del atacante en el puerto 1389. La sesión de explotación en la Figura 6 indica la recepción de la conexión LDAP entrante y la redirección realizada al servidor web Python de nuestro atacante.

Figura 6: Sesión de explotación del atacante que indica conexión entrante y redirección

La sesión Exploit ha enviado una redirección a nuestro servidor web Python, que está entregando una clase Java armada que contiene código para abrir un shell.

Esta clase de Java en realidad se configuró desde nuestra sesión de Exploit y solo está siendo atendida en el puerto 80 por el servidor web de Python. El registro de conexión se muestra en la Figura 7 a continuación.

Figura 7: servidor web Python del atacante que envía el shell de Java

El último paso de nuestro ataque es donde Raxis obtiene el caparazón con el control del servidor de la víctima. La clase de Java enviada a nuestra víctima contenía un código que abría un shell remoto a la sesión de netcat de nuestro atacante, como se muestra en la Figura 8.

El atacante ahora tiene el control total del servidor Tomcat 8, aunque limitado a la sesión del docker que habíamos configurado en este escenario de prueba.

Figura 8: Acceso del atacante al servidor de la víctima que controla el shell

Conclusión

Como hemos demostrado, la vulnerabilidad de Log4j es un proceso de varios pasos que se puede ejecutar una vez que tenga las piezas correctas en su lugar. Raxis está viendo este código implementado en bots de ataque de ransomware que buscan sistemas en Internet para explotar.

Sin duda, este es un problema crítico que debe abordarse lo antes posible, ya que es cuestión de tiempo antes de que un atacante alcance un sistema expuesto.

También publicado aquí