Company
Mailguns aktive Verteidigung gegen Log4j
Am 10. Dezember 2021 wurde die Welt von einer massiven Schwachstelle erschüttert, die Millionen von IT- und Sicherheitsfachleuten in Aufruhr versetzte. Die Schwachstelle, genannt Log4Shell, machte Assets für einen (lächerlich) einfachen Exploit anfällig, der zu einer Remote Code Execution (RCE) führte. Dieser Blogbeitrag ist kein technischer Artikel über die Schwachstelle selbst – dafür gibt es viele großartige Ressourcen, die nur eine Google-Suche entfernt sind. Stattdessen möchten wir teilen, wie Mailgun die Schwachstelle als unmittelbaren Vorfall behandelte und innerhalb von Stunden, nachdem wir unsere eigene Gefährdung erkannt hatten, zu einem aktiven Verteidigungsmodell überging…
Identifizierung
Sobald wir die Auswirkungen dieser Schwachstelle erkannten, mobilisierten wir unser internes Incident-Response-Team (IR). Wir behandeln neue Schwachstellen in der Regel über unseren standardmäßigen Schwachstellen-Managementprozess, bei dem schwerwiegende Common Vulnerabilities and Exposures (CVEs) innerhalb von sieben Tagen oder kritische Schwachstellen innerhalb von 48 Stunden gepatcht worden wären. Dies war jedoch keine „normale“ Schwachstelle.
Innerhalb von zwei Stunden nach der Benachrichtigung überprüfte unser IR-Team unser Asset-Inventar und die Software-Stückliste. Wir stellten fest, dass keine öffentlichen Assets von Mailgun von dieser Schwachstelle betroffen waren. Es gab jedoch mehrere interne Assets, die einige Aspekte der betroffenen Software aufwiesen. Einige dieser Assets waren durch den Einsatz des Java Security Managers geschützt.
Eine weitere, oft übersehene Komponente bei der Reaktion auf eine solch kritische Schwachstelle ist das Verständnis der Gefährdung durch Drittanbieter. Während unserer anfänglichen Identifizierungsphase leitete unser Compliance-Team eine Überprüfung der Anbieter ein. Alle Ihre Anbieter zu kontaktieren, ist kein einfacher Prozess, aber von entscheidender Bedeutung, um zu verstehen, ob der Datenzugriff einiger Ihrer Drittanbieter eingeschränkt werden muss.
Nach dieser ersten Überprüfung ging das Incident-Response-Team in eine Phase der Behebung und aktiven Verteidigung über.
Behebung
Auch hier stellten die Entwicklungsteams von Mailgun die ersten Patches für diese Schwachstelle innerhalb von Stunden bereit, nachdem wir unsere Gefährdung verstanden hatten. Aufgrund der kritischen Natur einiger dieser Assets mussten wir einen standardmäßigen Patch-Prozess durchlaufen und zunächst unsere Entwicklungs- und Staging-Umgebungen aktualisieren. Es ist jedoch erwähnenswert, wie wichtig diese Umgebungen sind. Viele Schwachstellen-Managementprogramme übersehen diese „unkritischen“ Umgebungen in ihrem Bestreben, agil zu sein. Angreifern ist das egal – sie werden diese Umgebungen trotzdem kompromittieren und missbrauchen, um Ihnen zu schaden.
Leider wurden im Laufe der nächsten Tage weitere CVEs und Exploits veröffentlicht, und wir mussten unsere Assets kontinuierlich neu bewerten und neue Patches oder Abhilfemaßnahmen bereitstellen. Unsere Entwicklungsteams waren dieser Herausforderung jedoch gewachsen und setzten das Patchen und die Überprüfung von Berichten in den folgenden Tagen fort.
Nachdem die Patching-Bemühungen begonnen hatten und unsere Entwicklungsteams involviert waren, ging das Sicherheitsteam zur aktiven Verteidigung über.
Aktive Verteidigung
Die nächste wichtige Phase bei der Bekämpfung einer derart kritischen CVE ist die aktive Verteidigung. Wir betrachten die aktive Verteidigung als aus einigen wenigen Elementen bestehend: Prävention, Erkennung und Honeypots. Glücklicherweise stellte die von Mailgun gewählte Web Application Firewall (WAF) bereits am ersten Tag Erkennungen für diesen Exploit bereit. Jeder gute Sicherheitsexperte wird jedoch erkennen, dass dies nicht gut genug ist und war. Es wurde fast unmöglich, mit der Anzahl an Permutationen für diese Schwachstelle Schritt zu halten …
Hier werden eine gute Protokollierung und das Schreiben einer soliden Erkennungslogik bei einem Vorfall entscheidend. Mailgun investiert stark in die Protokollierung von Anfragen, die an unsere Infrastruktur gesendet werden, und wir konnten sehen, wie gezielt diese Schwachstelle ausgenutzt wurde. Über Nacht sahen wir, wie die Zeichenfolge `${` in unseren Protokollen aufgrund von Versuchen, diese Schwachstelle auszunutzen, sprunghaft anstieg. Aufgrund des Ausmaßes des Angriffs erkannten wir, dass einfaches IP-Blocking nicht funktionieren würde. In Verbindung mit den Angriffspermutationen und der Flut neuer CVEs erkannten wir, dass wir unsere Bemühungen darauf konzentrieren mussten, diesen Angriffspfad vollständig zu entschärfen und Methoden bereitzustellen, um irrelevante Signale herauszufiltern. Weiter zu den Honeypots …
Die nächste Stufe in einer ausgereiften aktiven Verteidigung ist der Einsatz von Honeypots. Die Security-Community hat hier insgesamt hervorragende Arbeit geleistet. Innerhalb weniger Tage nach der gemeldeten Schwachstelle gab es zahlreiche veröffentlichte Honeypots, die in wenigen Minuten bereitgestellt werden konnten. Nach sorgfältiger Prüfung einiger dieser Optionen entschieden wir uns für die Bereitstellung eines kleinen Bash-Monitoring-Skripts, das einen Server in einen lauschenden Honeypot verwandeln konnte. Bereitgestellt in unseren internen Netzwerken und offen für fast alle (eingehenden) Server in der Umgebung, würden wir sehr schnell erkennen, wenn ein Angreifer in unseren privaten Netzwerken aktiv wäre.
Zusammenfassung
Bei Mailgun verfolgen wir den Ansatz „Wann, nicht ob“. Wir erkennen, dass wir bei dieser speziellen Schwachstelle das Glück hatten, keine exponierten externen Assets zu haben oder Assets, die durch diesen Exploit ohne internen Zugriff kompromittiert worden wären. Morgen haben wir vielleicht nicht mehr so viel Glück. Aber wir können uns weiterhin vorbereiten und darauf hinarbeiten, sicherere Systeme und bessere Funktionen zu entwickeln.
