log4shell (CVE-2021-44228) – was kann man tun?

Wieder einmal dominiert eine IT-Schwachstelle die Schlagzeilen der Medien. Wenn sogar normale Tageszeitungen darüber schreiben, dann wird die Verwirrung meist umso grösser. Ich möchte hier einordnen, wie schlimm es wirklich ist und wie man sich schützen kann oder konnte.

Im Apache Log4j Logging-Framework für Java wurde eine Remote-Code-Execution (RCE) gefunden. Die Vulnerability lässt sich vergleichsweise sehr einfach ausnutzen. Die sehr weite Verbreitung von Log4j in vielen Projekten macht die Sache so schlimm. Das Framework wird in tausenden von Software-Projekten eingesetzt. Ein Angreifer muss nur einen String an die Applikation senden, welche dann geloggt wird. Das Logging-Framework interpretiert diesen String und verbindet sich dann auf einen LDAP(s) Server und lädt von dort Code nach.

Grundsätzlich ist es verheerend, dass eine so kritische Vulnerability (CVSS Score 10/10) seit 7 Jahren unentdeckt in einem so weit verbreiteten Framework steckt. Leider ist es nicht ausgeschlossen, dass staatliche Akteure schon länger von der Vulnerability wussten und diese für Angriffe benutzten. Die Auflistung der betroffenen Firmen wie z.B. Google, Apple oder Cloudflare zeigen, wie weit verbreitet das Framework ist. Log4shell wird vermutlich die Diskussion um Security-Reviews von Open-Source Software wieder anheizen. Fairerweise muss man sagen, dass die grossen IT-Firmen da schon einiges tun, offensichtlich aber noch zu wenig. Hier stellt sich auch die Frage, ob das wirklich den grossen Tech-Firmen überlassen werden kann oder soll.

Die gute Nachricht ist, dass wenn man grundlegende Schutz-Massnahmen implementiert hatte, man wohl kaum von log4shell betroffen sein dürfte. Dies ist jetzt aber nicht falsch zu verstehen, die Chance, dass die verwundbare Komponente in Ihrem Netzwerk vorkommt, liegt nahe bei 100%. Sie sollten also die relevanten Systeme identifizieren und patchen. Das Umsetzen von einigen simplen Best-Practices verhindern aber das aktive Ausnutzen der Schwachstelle.

Das ist eigentlich recht simpel. Angreifer müssen über LDAP(s) Code nachladen. Das heisst automatisch, dass wenn dies nicht möglich ist, dann kann die Schwachstelle auch nicht aktiv ausgenutzt werden. Wer also seine Server nicht ins Internet lässt, oder halt nur über einen Proxy, der dürfte schon deutlich ruhiger schlafen. Wer seine Server aus Bequemlichkeit doch unbedingt ins Internet lassen will, der sollte zumindest die Protokolle auf HTTP(s) einschränken. Mir fällt wirklich kein Grund ein, warum ein Server LDAP mit der ganzen Welt sprechen sollte. Wichtig dabei ist, dass auf der Firewall nicht einfach nur Port 80/443 offen sind, sondern dass die Firewall auch eine Protokoll-Erkennung durchführt. Damit ist sichergestellt, dass in der Verbindung auf Port 80 auch wirklich eine HTTP Session und halt nicht LDAP abläuft.

Ein zweiter Angriffsvektor läuft über RMI (Remote Method Invocation). Dies kann verwendet werden, um einen vulnerable System Code auf einem anderen System auszuführen. Hier hilft vor allem eine Netzwerk-Segmentierung. In der Regel gibt es keinen Grund, warum ein System, welches aus dem Internet erreichbar ist, mit anderen Servern über RMI sprechen kann.

Dazu gibt es noch einige Parameter, welche man auf den betroffenen Systemen setzen kann, um das Problem zu beheben. Dazu gibt es schon diverse Informationen im Netz, daher hier nicht mehr dazu.

Es gibt mittlerweile recht gute Open-Source Scanner, die alle Java Libraries nach den vulnerable Log4j Versionen absuchen. Besser fahren Kunden mit einer Vulnerability Management Lösung wie z.B. Tenable. Die hatten direkt nach dem Wochenende einen Report im Postfach mit einer Auflistung aller betroffenen Systeme. Eventuell wäre jetzt der richtige Zeitpunkt, eine solche Lösung zu testen.

Das Ausnutzen der Schwachstelle ist vergleichsweise einfach zu erkennen. Auch hierzu gibt es im Netz schon sehr viele Informationen. Am einfachsten werden die Logs der betroffenen Systeme durchsucht. Alternativ gibt es auch frei verfügbare IOC (Indicator of Compromise) Listen, welche helfen können.

Ganz klar ist log4shell eine verheerende Lücke, die viele Unternehmen treffen wird. Wer sich aber vorrangig an Best Practices gehalten hat, dürfte deutlich ruhiger schlafen als andere. Nichtsdestotrotz ist es angesagt, die anfälligen Systeme schnellstmöglich zu identifizieren und das Problem nachhaltig zu beseitigen.