Log4j: Warum TYPO3 nur indirekt betroffen ist und warum ein SLA sinnvoll ist

Die Lücke in Log4j ist eine Zero-Day-Lücke. Das bedeutet: Die Sicherheitslücke ist weltweit bekannt, bevor der Softwareanbieter ein Sicherheitsupdate entwickeln kann. Die Zeit zwischen dem Bekanntwerden der Sicherheitslücke und dem Veröffentlichen des Sicherheitsupdates kann und wird von Hackern genutzt. Das gilt auch für die Zeit danach, da nicht jeder die zur Verfügung stehenden Sicherheitsupdates brav einspielt. Deshalb sollte man auch Webprojekte zur Sicherheit von einem Security-Team betreuen lassen, sozusagen einem Wachschutz für die virtuelle Firmenzentrale.

Jeder Website-Betreiber sollte ein Cybersecurity-Team im Bereitschaftsdienst zur Hand haben. Das kann und sollte durchaus auch die Digitalagentur sein: Wir als TYPO3-Agentur bieten unseren Kunden deshalb Service Level Agreements an, kurz SLA. Gegen eine kleine Monatspauschale halten wir laufend die Augen offen, ob es Sicherheitslücken und Sicherheitsupdates gibt. Wenn es reguläre Updates gibt, spielen wir diese im laufenden Betrieb ein. Das ist mit der Pauschale abgegolten. Doch sogar bei unvorhersehbaren Sicherheitsrisiken wie bei der Log4j-Lücke greift das SLA: Unser Bereitschaftsdienst ergreift sofort Notmaßnahmen, um die Website oder die App vor Schaden zu schützen. Im Anschluss wird geprüft, ob Hacker sich Zugang verschafft haben. Auch diese Leistungen sind mit dem SLA komplett abgegolten. Ein SLA kann sich eigentlich jeder leisten. Man kann es sich aber nicht leisten, keines zu haben.

Log4j ist eine Art Quasi-Standard und wird oft da verwendet, wo Java verwendet wird. Log4j ist Open Source und ein Projekt der Apache Software Foundation. Damit steckt es in vielen Software-Bibliotheken drin, die etwas mit Apache zu tun haben. Betroffen waren oder sind unter anderem Amazon AWS, Cloudflare, Citrix, Tencent, iCloud und – manchmal indirekt – TYPO3-Installationen. Theoretisch könnte über diese Schwachstelle jedes Java-basierte Fitzelchen an Software kompromittiert werden, sogar ohne Internet-Anbindung, und zwar per USB-Stick. Eine Liste betroffener Systeme gibt es unter diesem Link: gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

Achtung: Diese Liste ist ein Freiwilligen-Projekt und nicht verbindlich.
Betroffen ist in erster Linie Log4J der Version 2.x. In einigen Fällen aber auch die Uralt-Version 1.x, die dafür allerdings eine eher selten verwendete Konfiguration enthalten muss. 
Sehr gefährlich ist es, wenn Log4j ein fester Teil von Software ist, denn dann kann man die Log4j-Bibliotheken nur mit Spezialwissen austauschen oder muss auf ein Update des Software-Anbieters warten, wenn es diesen Anbieter überhaupt noch gibt.

TYPO3 basiert auf PHP und hat mit der Java-Welt nichts am Hut. Jedoch gibt es Extensions, die auf Java basieren. Betroffen sind unter anderem die Suchfunktion Solr, die wie Log4j von der Apache Software Foundation kommt, und Elastic Search. Mit dem Einspielen des Log4j-Sicherheitsupdates ist ein Teil der Arbeit schon erledigt, aber das ist nur der oberflächliche Teil.

Unser TYPO3-Team hat ab dem 10.12.2021 in einem mehrstufigen Verfahren unsere Kunden-Websites wie folgt abgesichert:

• Kunden-Websites und -Apps nach der Verwendung von Log4j abgesucht. Das geht unter anderem über die Suche nach bestimmten Java-Klassen und Spezial-Tools.
• Oft betroffen: Suchfunktionen. Diese haben wir deaktiviert. Das ist für User unschön, aber es ist im Vergleich zur Website-Abschaltung ein mildes Mittel.
• Suchen nach Schadcode, kompromittierten Logins, verdächtigen Aktivitäten auf dem Server und in den Server-Logs.
• Einspielen von Updates.
• Seit Montag, den 13. Dezember konnten Suchfunktionen teils wieder in Betrieb genommen werden.
• Weitere Prüfungen der Server laufen.

• Am 24. November wurde das Team von Apache vertraulich über eine Sicherheitslücke unterrichtet.
• Seit 1. Dezember gibt es auffallend viele Zugriffe auf Webserver, vermutlich von Hackern, um nach dem Vorhandensein der Lücke zu suchen.
• Am 6. Dezember wurde ein Log4j-Update veröffentlicht, Log4j 2.15.0-rc1
• Am 9. Dezember wurde die Sicherheitslücke öffentlich gemacht und Log4j 2.15.0-rc2 veröffentlicht
• Die Sicherheitslücke hat den Code CVE-2021-44228 und wurde „Log4Shell“ getauft.

Sie sehen: Mindestens 8 Tage lang konnten sich Hacker durch das Internet wühlen und nach potentiellen Opfer-Websites suchen – und sich vielleicht einnisten.

Hacker und Sicherheitsforscher suchen laufend nach Schwachstellen von Softwaresystemen, und mit einer Sicherheitslücke in Log4j stießen die Experten auf eine sehr ernste Bedrohung. Log4j kümmert sich um das Logging, also das Sammeln und Aufbereiten von Fehlermeldungen, beispielsweise in Websites und legt eine Art Logbuch an. Da dieses Werkzeug an vieles angebunden ist, wo Fehler geloggt werden sollen – beispielsweise Suchfunktionen oder Big-Data-Anwendungen – kann durch das Provozieren eines speziellen Fehlers die Logging-Funktion derart verwirrt werden, dass sie danach die Segel streicht und jeglichen Code an den Server durchleitet. Grob vereinfacht gesagt: Man gibt einen speziellen Suchbegriff in die Suchfunktion einer Website ein, die Suchfunktion kollabiert und gibt einen Fehler aus, der Logging-Dienst im Hintergrund kapituliert, und durch das gleichzeitige Hochladen von Schadcode kann man die Kontrolle einer kompletten Website an sich reißen. Das kann man als Hacker heimlich, still und leise machen und einfach Crypto-Mining auf dem gekaperten Server laufen lassen, wodurch dem Serverbetreiber finanzieller Schaden entsteht, der erst mit der nächsten Rechnung des Hosters auffällt. Oder man hackt sich nur für eine Minute ins System, legt sich heimlich einen Benutzer an – vielleicht mit einem unverfänglichen Namen wie „default admin“ – und lässt die gehackte Website ein paar Wochen in Ruhe, bis man Schadcode installiert. Oder man installiert Schadcode, der vertrauliche Informationen auf dem Server ausspähen soll. Oder man kann als Hacker die Geldströme eines Online-Shops anzapfen und auch sonst jede Art von Internet-Kriminalität ausüben. Selbst die aktuell häufig auftretenden Verschlüsselungen mit anschließender Erpressung hoher Geldsummen ist auf diesem Wege möglich. Alles in allem endet das also schnell in einer großen Katastrophe.
Ungepatchte Systeme könnten in Zukunft durch diesen Hack stark gefährdet sein. Deshalb sollte man die Augen aufhalten. Und wenn Sie noch kein SLA haben: Vereinbaren Sie eins. 
 

Dann nehmen Sie unkompliziert Kontakt mit uns auf und wir finden es gemeinsam heraus.