Betroffene Produkte
Log4j ist eine Open Source Logging-Lösung, die in enorm vielen Cloud- und Softwarelösungen eingesetzt wird. Von der Lücke sind die Log4j Versionen 2.0-beta9 bis 2.14.1 betroffen.
Eine inoffizielle Liste des Users SwitHak mit bekanntermassen betroffener Software bzw. Rückmeldung der Hersteller zu der Lücke gibt es auf github (s. Weitere Informationen unten).
Angriffsvektor
| Risikostufe 1 – Von extern ausnutzbar | X |
| Risikostufe 2 – Aus Firmennetz ausnutzbar | x |
| Risikostufe 3 – Auf lokaler Maschine ausnutzbar | x |
Art des Angriffs
Remotecodeausführung: über gewisse Lognachrichten, sei es der Name des Gerätes, der Fehlercode, die Uhrzeit oder eine andere protokollierte Zeichenfolge kann Schadcode von externen Servern geladen und ausgeführt werden.
Handlungsempfehlung
Es ist in Zusammenarbeit mit den Herstellern umgehend zu prüfen, welche eingesetzten Produkte Log4j einsetzen und ob eine befallene Version verwendet wird* , befallene Produkte sollten schnellstmöglich mit Sicherheitsupdates vom Hersteller gegen die Lücke geschützt werden. Abhängig vom System kann oder muss Log4j ggf. auch in Eigenregie auf die Version 2.15.0 aktualisiert werden, um die Lücke zu schließen.
Anstelle des Updates gibt es auch den Workaround (s. Weitere Informationen), über das setzen von Systemvariablen das Feature welches die Lücke verursacht abzuschalten.
Wenn beides nicht möglich ist, sollte eine Risikoanalyse durchgeführt und betroffene Systeme wenn möglich isoliert oder heruntergefahren werden. Betroffene Systeme können mit einer Web-Application-Firewall und entsprechenden Regeln zwar theoretisch vor Angriffen geschützt werden, in der Praxis gibt es aber viel zu viele Variationsmöglichkeiten um alle abzudecken. Derartige Schutzmechanismen bspw. von Hosting-Anbietern sind also prinzipiell begrüßenswert, sollten allerdings keine Sicherheit vorgaukeln – ein qualifizierter oder gar gezielter Angriff kann diese sicherlich umgehen.
*Das problematische Feature existiert bereits seit 8 Jahren, daher ist sofern Log4j eingesetzt wird davon auszugehen dass die verwendete Version von der Lücke betroffen ist
Weitere Informationen
Inoffizielle & unvollständige Liste betroffener Software & Hersteller (sowie Feedback nicht betroffener Hersteller):
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
Hotfix & Beschreibung des Workarounds von Apache:
https://logging.apache.org/log4j/2.x/security.html