Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
hotpatch-for-apache-log4j2 — Un agente per applicare una patch a caldo alla RCE di log4j da CVE-2021-44228. | Kitploit
Strumenti/GitHubGitHub/corretto/hotpatch-for-apache-log4j2
Strumenti DifensiviAnalisi delle VulnerabilitàExploitSicurezza della Supply ChainRisposta agli Incidenti
GitHubcorretto/hotpatch-for-apache-log4j2

hotpatch-for-apache-log4j2

Un agente per applicare una patch a caldo alla RCE di log4j da CVE-2021-44228.

Vedi Repository

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi
497723 anni faRevisionato da Kitploit

Log4jHotPatch

Questo è uno strumento che inietta un agente Java in un processo JVM in esecuzione. L'agente tenta di correggere il metodo lookup() di tutte le istanze caricate di org.apache.logging.log4j.core.lookup.JndiLookup per restituire incondizionatamente la stringa "Patched JndiLookup::lookup()". È progettato per affrontare la vulnerabilità di esecuzione remota di codice CVE-2021-44228 in Log4j senza riavviare il processo Java. Questo strumento affronta anche la CVE-2021-45046.

È stato attualmente testato solo con JDK 8, 11, 15 e 17 su Linux!

Compilazione

Gradle

Per compilare su Linux, Mac e Windows Subsystem for Linux

root@kitploit:~
./gradlew build

Per compilare su Windows

root@kitploit:~
.\gradlew.bat build

A seconda della piattaforma su cui stai compilando. Questo genererà build/libs/Log4jHotPatch.jar

Maven

Per compilare usando Maven usa

root@kitploit:~
mvn clean package

Questo genererà un target/Log4jHotPatch.jar.

Esecuzione

JDK 8

root@kitploit:~
java -cp <java-home>/lib/tools.jar:Log4jHotPatch.jar Log4jHotPatch <java-pid>

JDK 11 e successivi

root@kitploit:~
java -jar Log4jHotPatch.jar <java-pid>

Esecuzione dell'agente statico

Aggiungi semplicemente l'agente alla tua riga di comando Java come segue:

root@kitploit:~
java -classpath <class-path> -javaagent:Log4jHotPatch.jar <main-class> <arguments>

Testare l'agente

C'è un insieme di test che possono essere eseguiti al di fuori di Gradle o Maven.

root@kitploit:~
build-tools/bin/run_tests.sh Log4jHotPatch.jar <JDK_ROOT>

Problemi noti

Se ricevi un errore come:

root@kitploit:~
Exception in thread "main" com.sun.tools.attach.AttachNotSupportedException: The VM does not support the attach mechanism
	at jdk.attach/sun.tools.attach.HotSpotAttachProvider.testAttachable(HotSpotAttachProvider.java:153)
	at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
	at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
	at Log4jHotPatch.loadInstrumentationAgent(Log4jHotPatch.java:115)
	at Log4jHotPatch.main(Log4jHotPatch.java:139)

significa che la tua JVM sta rifiutando qualsiasi tipo di supporto perché è in esecuzione con -XX:+DisableAttachMechanism.

Se ricevi un errore come:

root@kitploit:~
com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
	at sun.tools.attach.LinuxVirtualMachine.<init>(LinuxVirtualMachine.java:106)
	at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:63)
	at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:208)
	at Log4jHotPatch.loadInstrumentationAgent(Log4jHotPatch.java:182)
	at Log4jHotPatch.main(Log4jHotPatch.java:259)

significa che stai eseguendo come un utente diverso (incluso root) rispetto alla JVM target. JDK 8 non può gestire la correzione come utente root (e attiva un thread dump nella JVM target, che è innocuo). In JDK 11, applicare la correzione a un processo non root da un processo root funziona perfettamente.

Se ricevi un errore come questo nel processo target:

root@kitploit:~
Exception in thread "Attach Listener" java.lang.ExceptionInInitializerError
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:386)
        at sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:411)
Caused by: java.security.AccessControlException: access denied ("java.util.PropertyPermission" "log4jFixerAgentVersion" "write")
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
        at java.security.AccessController.checkPermission(AccessController.java:886)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
        at java.lang.System.setProperty(System.java:794)
        at Log4jHotPatch.<clinit>(Log4jHotPatch.java:66)

significa che il processo target ha installato un security manager. Cerca questa opzione della riga di comando nel processo target:

root@kitploit:~
-Djava.security.policy=/local/apollo/.../apollo-security.policy

Se incontri questo errore, assicurati di utilizzare l'ultima versione dello strumento

Importante: Se hai tentato di applicare la correzione come utente sbagliato, potresti dover eliminare i file .attach_pid<pid> (che si trovano in /tmp e/o nella directory di lavoro corrente del processo VM) prima di riprovare. Questi file devono avere la proprietà corretta affinché l'attach abbia successo.

Scarica lo strumento