Ausnutzung von Schwachstellen
Log4j, was nun?
Log4j ist eigentlich ein nützliches Tool, doch stellt es die IT vor einige Herausforderungen. Wir zeigen einige taktische Maßnahmen für den sofortigen Einsatz und strategische Hinweise, was nach dem Abklingen der unmittelbaren Krise zu tun ist.
Save to Folio
Originalbeitrag von William Malik, VP, Infrastructure Strategies
Es gibt so viele Stellen im Java-Code, an denen ein Programmierer Daten in einen Log oder eine andere Art von Repository für spätere Aktionen legen möchte. Log4j widmet sich dieser Aufgabe und ist ein sehr nützliches Werkzeug, das häufig im Java-Code integriert ist. Das Tool nimmt eine Zeichenkette und kopiert sie von einem Ort (z. B. das Feld userid in einem Anmeldebildschirm) an einen anderen (z. B. den Eingabebereich für einen Authentifizierungsprozess). Log4j kann jedoch viel mehr als ein einfaches CTL-C/CTL-V. Log4j untersucht auch die Zeichenkette und interpretiert sie. Log4j stellt die IT vor einige große Herausforderungen. Wir zeigen einige taktische Maßnahmen für den sofortigen Einsatz und strategische Hinweise, was nach dem Abklingen der unmittelbaren Krise durch die Angriffe auf die Schwachstelle Log4Shell zu tun ist.
Die Interpretation ist generell riskant, denn wenn das Programm den Code nicht bereinigt, kann einiges schief gehen. Log4j säubert keine Eingaben. Dies zeigt auch der brillante XKCD-Comic „Exploits of a Mom“:
Quelle: https://xkcd.com/327/
Taktische Maßnahmen
Die erste Herausforderung besteht darin, herauszufinden, wo der Code und die Anwendungen die Sicherheitslücke aufweisen könnten. Es gibt Tools zum Scannen auf das Vorhandensein der Zeichenfolge „log4j“, so Snyk und andere. Diese finden alle Stellen in Quellcode-Bibliotheken, die Aufrufe zu diesem Code enthalten.
Der nächste Schritt besteht darin, zu überprüfen, ob dieser Quellcode jemals in der eigenen Produktionsumgebung eingesetzt wurde. Manchmal verwenden Entwickler das Logging während der Codeentwicklung, um einen Snapshot der Variablen und der Schlüsselpunkte zu machen, nur um sicherzustellen, dass sich das Programm angemessen verhält. Wenn der Code dann bereitgestellt wird, werden die Snapshots deaktiviert - und nie in der realen Welt ausgeführt.
Wenn Sie Code mit Log4j in Produktion gebracht haben, sollten Sie eine der folgenden Maßnahmen in Betracht ziehen:
- Erstellen Sie ein Rebuild des Pakets mit der aktuellsten Version von Log4j neu, im Moment 2.17.xx. Prüfen Sie jedoch bei der Apache Foundation den aktuellsten Stand der Korrekturen.
- Deaktivieren Sie die Anwendung oder den Server bzw. die virtuelle Maschine, auf dem/der sie ausgeführt wird, bis Sie den Build korrigieren haben.
- Installieren Sie eine IPS-Regel, die Eingaben mit der Zeichenkette „log4j“ blockiert. Achtung jedoch, böswillige Akteure entwickeln Möglichkeiten, diese Zeichenkette zu verschleiern, z.B. indem sie sie in base64 kodieren, damit sie einen Text-Scan übersteht, usw.
- Deaktivieren Sie das Logging, bis der Code korrigiert ist. Unter Umständen müssen Sie die Log4j-Referenz auskommentieren, was dazu führen kann, dass die Anwendung einige Funktionen verliert - z.B. können Sie möglicherweise keine Nachrichten von einem Benutzer an einen anderen mehr verarbeiten. Hier wurde der Fehler übrigens zum ersten Mal gemeldet: Spieler in Minecraft entdeckten, dass Befehle an Log4j, die sie in das Nachrichtenfeld einfügten, nicht gesendet, sondern tatsächlich ausgeführt wurden.
Andere Tools können die Eingabefelder einer Anwendung testen, um zu prüfen, ob sich die Anwendung korrekt verhält. Diese Werkzeuge stellen dafür eine sichere, harmlose Zeichenkette bereit, die den Fehler offenbart ohne Schaden anzurichten. Der Test kann eine Zeichenkette in ein Eingabefeld eingeben, die als ungültig zurückgewiesen werden sollte, wenn alles ordnungsgemäß abgesichert ist. Gibt es den Fehler, so wird die Meldung „Hallo Welt“ angezeigt.
Sobald Sie Anwendungen in der Produktion identifiziert haben, die die Schwachstelle aufweisen, gibt es die gleichen Möglichkeiten wie bei einer Anwendung mit anfälligem Quellcode: Abschalten, eine IPS-Regel einrichten, um (die meisten) Angriffe zu blockieren, die Protokollierung stoppen oder den Server herunterfahren, auf dem die Anwendung läuft.
Strategische Leitlinien
Logging ist keine schlechte Idee, sondern in der Tat ein wesentliches Element vieler Anwendungen. Anwendungen verarbeiten Benutzerkennungen, Kennwörter, Nachrichten und Protokolleinträge mit Hilfe von log4j (in Java) oder etwas Ähnlichem (in anderen Programmierumgebungen). Der Trick besteht darin festzulegen, welche Arten von Nachrichten der Anwender verarbeiten will und ob das Protokollierungswerkzeug eine Interpretation der Nachricht vornehmen soll.
Das Problem wird dadurch komplexer, dass Ihre Software nicht in einem Vakuum läuft, sondern in einem Kontext, der durch viele andere Software aus vielen anderen Quellen bereitgestellt wird. Abhilfe kann hier die Erstellung einer Software Bill of Materials (SBOM) sein, in der alle Komponenten aufgelistet sind, die zur Erstellung der Anwendung verwendet werden. Eine SBOM hilft dabei, bösartige Software zu diagnostizieren, und zwar über das hinaus, was der Anwender aus der heutigen Software Asset Management-Datenbank erfahren kann. Viele Unternehmen verfügen noch nicht über eine umfassende SAM DB. Dies zu ändern, sollte angesichts der aktuellen Probleme eine höhere Priorität erhalten.
Für Sicherheitsteams, die rund um die Uhr an der Reaktion auf die log4j-Schwachstelle arbeiten, steht ein kostenloses Bewertungstool zur Verfügung.