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
Log4j_Vulnerability_Demo — Un programa sencillo para demostrar cómo se puede explotar la vulnerabilidad Log4j (CVE-2021-44228) | Kitploit
Herramientas/GitHubGitHub/chandanshastri/log4j_vulnerability_demo
Análisis de VulnerabilidadesExplotaciónSeguridad WebAprendizaje y EducaciónAnálisis de Registros
GitHubchandanshastri/log4j_vulnerability_demo

Log4j_Vulnerability_Demo

Un programa sencillo para demostrar cómo se puede explotar la vulnerabilidad Log4j (CVE-2021-44228)

Ver Repositorio
3hace 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

Log4j_Vulnerability_Demo

Un programa sencillo para demostrar cómo se puede explotar la vulnerabilidad de Log4j ( CVE-2021-44228 )

Ejecutar la demo :

Para iniciar el programa, simplemente ejecute start.sh ( en sistemas UNIX ) o start.bat en Windows.

La entrada del usuario se leerá y se registrará en la consola utilizando el framework Log4j.

Por defecto, los mensajes de registro generados por la librería Log4j no proporcionan errores de servidor inalcanzable / host no encontrado para las sustituciones JNDI. ( Y supongo que esa es también una razón importante por la que esta vulnerabilidad puede explotarse de forma sigilosa )

También intente usar subdominios, como ${jndi:ldap://test29.google.com/blah} , a veces la llamada JNDI esperará la respuesta del servidor remoto y por eso el programa parece que está bloqueado mientras que en realidad ha realizado un intento de conexión en segundo plano. Si usa subdominios que no existen, la llamada JNDI terminará rápidamente después de realizar un intento de conexión y el programa continuará.

Le recomiendo ejecutar el programa en una shell, y ejecutar el comando " tcpdump -i any | grep google " en otra shell en paralelo y luego proporcionar entradas al programa para ver si el programa ha realizado un intento de conexión.

Sustituciones de Log4j en acción :

image

Intentando conexiones remotas:

image

image

Algunas entradas de ejemplo :

testing ( Cadena normal )

Ejemplos que pueden ser más que un simple mensaje de registro :

${env:USER} ( UNIX )

${env:USERNAME} ( Windows )

${jndi:ldap://test.java.net}

${jndi:ldap://localhost:12000}

--

Monitorización :

tcpdump -i any | grep -i "java.net"

ncat -k -vv -c "echo hi" -l 12000

--

Eliminar la clase JndiLookup para mitigar la vulnerabilidad :

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Esto eliminará JndiLookup.class del jar principal de Log4j.

Ejecute el mismo programa después del paso anterior, el programa no debería realizar ningún intento de conexión / sustitución JNDI.

--

Otra forma de deshabilitar las búsquedas JNDI

export LOG4J_FORMAT_MSG_NO_LOOKUPS=true

Esta variable de entorno deshabilitará las búsquedas JNDI para la sesión actual.
Descargar herramienta