Am 23. Mai 2023 gab Barracuda eine Schwachstelle (CVE-2023-2868) in seiner Email Security Gateway Appliance bekannt, die bereits im Oktober 2022 in freier Wildbahn ausgenutzt wurde. Am 15. Juni 2023 veröffentlichte Mandiant eine detaillierte Analyse der Aktivitäten und der an der Kampagne beteiligten Bedrohungsakteure, die CVE-2023-2868 aktiv ausnutzten. Daraufhin veröffentlichte das Emerging Threats-Team von Proofpoint eine Suricata-Erkennungsregel (SID 2046280) zur Erkennung der versuchten Ausnutzung der gemeldeten Sicherheitslücke. Während eines Treffens mit einem Kunden von Vectra AI wurde die Sorge geäußert, dass die bestehende Regel nicht wie erwartet funktioniert. Nach ersten Tests stellten wir fest, dass die Regel bei einem bestimmten Proof-of-Concept-Exploit keinen Alarm auslöste, obwohl die Nutzdaten des Exploits erfolgreich übermittelt wurden.
Wir analysierten die Regel und den zugehörigen Exploit und identifizierten die spezifische Erkennungslücke, die durch eine nicht-deterministische Reihenfolge der mit dem Exploit zusammenhängenden Inhalte innerhalb der Nutzlast verursacht wurde (weitere Einzelheiten finden Sie im Abschnitt "Ein kurzer Blick auf den Proof-of-Concept-Exploit" weiter unten). Nachdem wir die Lücke identifiziert hatten, konnten wir eine Regel umschreiben, um die erforderliche Erkennungsabdeckung zu gewährleisten. Nachdem wir unsere Ergebnisse an das EmergingThreats-Team von Proofpoint weitergeleitet hatten, wurde eine neue M2-Erkennungsregel veröffentlicht. In diesem Bericht wird der Analyse- und Regelerstellungsprozess für die M2-Erkennungsregel erläutert, mit der der bestätigte Fehlalarm beseitigt wurde.
TL;DR
Die ET-Regel von Proofpoint ist fehlerhaft, da sie davon ausgeht, dass sich jeder an die Regeln hält, auch diejenigen, die sich nicht daran halten. Bei dieser Analyse sind wir auf ein manipuliertes TAR-Archiv gestoßen, das eine Nutzlast an der ET-Erkennungsregel für CVE-2023-2868 vorbeischleust, weil der Autor des Exploits die Regeln nicht befolgt hat. Und selbst mit einer verbesserten Erkennungsregel bleibt die Sorge bestehen: Wenn wir morgen auf eine andere manipulierte Dateistruktur stoßen, könnte diese die Erkennungsregeln von ET wieder umgehen?
1. Anatomie von CVE-2023-2868
Der Bericht von Mandiant enthält eine Erläuterung der Schwachstelle, aber der Einfachheit halber haben wir sie in der folgenden Abbildung zusammengefasst. Wie Sie sehen können, sind bestimmte Versionen der Barracuda Email SecurityAppliance anfällig für eine Injektionsschwachstelle.
Um diese bösartige Nutzlast zu identifizieren, entwickelte das Emerging Threats Research Team einen Erkennungsraum, der in bestimmten Pakettypen nach dem "'`" (einfaches Anführungszeichen) und "`'" (Anführungszeichen, einfache Anführungszeichen) in bestimmten Pakettypen suchte. Wie wir noch sehen werden, konnten einige Proof-of-Concepts unentdeckt bleiben.
2. Ein kurzer Blick auf den Proof-of-Concept-Exploit
Als wir uns dem hier verfügbaren Proof-of-Concept-Exploit (PoC) zuwandten, begannen wir damit, die zugrunde liegende Nutzlast zu identifizieren, die die Emerging Threats Detection Rule auslösen sollte. Wie unten dargestellt, verwendet die "CMD"-Variable dieselbe grundlegende Befehlsstruktur, die im Mandiant-Bericht beschrieben wurde:
Beachten Sie, dass die Variable "PAYLOAD" mit einem einfachen Anführungszeichen und einem hinteren Haken beginnt und die Variable "CMD" mit einem hinteren Haken und einem einfachen Anführungszeichen endet. Dadurch wird die Befehlsinjektion ausgelöst.
Ein Blick auf den PoC über das Kabel in Hex
Hier ist die Ausgabe einer hexadezimalen Darstellung des erzeugten tar-Archivs, das die oben gezeigte Nutzlast enthält:
"PAYLOAD", die die Injektionsmuster darstellen, sind rot hervorgehoben. Die der Variablen "CMD" zugewiesene Befehlsfolge ist blau hervorgehoben:]
Beachten Sie ganz oben im Archiv, dass einige Reste der CMD-Variablen vorhanden sind, ebenso wie die Injektionsmuster \x60\x27 (hinteres Häkchen, einfache Anführungszeichen). Wir werden später auf diesen wichtigen Teil zurückkommen.
Eine normale Tar-Archivstruktur
Bevor wir uns mit den Fehlern der Erkennungsregel beschäftigen, ist es wichtig, die Struktur eines regulären tar-Archivs zu verstehen. Tar-Archive sind in Blöcken von 512 Bytes organisiert. Das Format eines tar-Archivs ist im Wesentlichen wie folgt:
- Der "Header" enthält den Namen der Datei und einige zusätzliche Metadaten.
- Der "Inhalt" enthält die eigentlichen Daten in der Datei.
Ein Blick in ein normales Tar-Archiv über den Draht in Hex
Ein "normales" Tar-Archiv ist eine Datei, die von einem Dienstprogramm erstellt wurde, das die Regeln befolgt und entweder das TAR-Format von UNIX-Systemen oder das USTAR-Format des POSIX-Standards 1003.1 respektiert. Dies ist ein hexadezimaler Dump eines normalen Tar-Archivs, das drei reguläre Dateien mit den Namen 1, 2 und 3 enthält und mit dem Dienstprogramm tar erstellt wurde:
Wir sehen die Datei mit dem Namen 1, gefolgt von einigen Byte-Codes und dem Inhalt der Datei "Hallo 1", gefolgt von der Datei mit dem Namen 2 und so weiter. Das Dienstprogramm zur Erstellung eines tar-Archivs ordnet die Kopf- und Inhaltsdaten in absteigender Reihenfolge nach den Dateinamen an. Mit anderen Worten, es beachtet die vom Dateiformatstandard diktierten Regeln und respektiert sie.
Die Dateistruktur unterscheidet sich von derjenigen, die vom Exploit erzeugt und im ersten Abschnitt vorgestellt wurde. Der PoC-Exploit enthält eine Reihe von Befehlen in der Kopfzeile anstelle von Dateinamen, wie erwartet. Um dies zu ermöglichen, musste der Autor des Exploits ein wenig trickreich vorgehen.
Zerlegung des R7-Exploits
Der vom Rapid7 Security Researcher Team geschriebene Exploit hat einen eigenen Teil mit Kommentaren zur Ruby-Klasse "TarWriter":
Dieser Exploit setzt die Überprüfung der Dateigröße außer Kraft, die ursprünglich von der Funktion "split_name()" durchgeführt wird :
3 "if"-Anweisungen wurden aus der ursprünglichen Funktion entfernt. Diese 3 Anweisungen lösen "TooLongFileName" aus, um zu überprüfen, ob:
1. Der Dateipfad ist zu lang
2. Der Dateiname ist zu lang
3. Der Basispfad der Datei ist zu lang
Ein Blick auf die Nutzlast des Exploits und das Zählen der Zeichen ergibt 129 Bytes:
Basierend auf dem Code im PoC wird der auszuführende Befehl, wenn er mehr als 100 Byte umfasst, auf mehrere "Dateieinträge" im tar-Archiv aufgeteilt. Wir setzen "Dateieinträge" in Anführungszeichen, weil das bösartige tar-Archiv eigentlich keine Dateien enthält - es enthält eine Escape-Sequenz und eingebettete Befehle, die der Angreifer ausführen möchte.
Wenn wir uns den Hexdump des bösartigen tar-Archivs noch einmal ansehen, können wir jetzt verstehen, warum der erste Eintrag im tar-Archiv ein hängendes `' (hinteres Häkchen, einfaches Anführungszeichen) und das Ende der CMD-Variable ist, das am Ende des Befehls stehen sollte.
Da der Befehl die 100-Byte-Grenze überschreitet, die der Dateinamenstruktur für den Header einer Datei auferlegt ist, wurde der Befehl in zwei Dateieinträge aufgeteilt, wobei der zweite Dateieintrag nur die Endung p"`' (Buchstabe p, doppeltes Anführungszeichen, hinteres Häkchen, einfaches Anführungszeichen) enthält. Dieser Dateieintrag erscheint am Anfang des tar-Archivs, weil der Inhalt des tar-Archivs in absteigender Reihenfolge sortiert ist und eine Zeichenkette p"`' (Buchstabe p, doppeltes Anführungszeichen, rückwärtiges Häkchen, einfaches Anführungszeichen) in absteigender Reihenfolge vor einer Zeichenkette '`s (einfaches Anführungszeichen, rückwärtiges Häkchen, Buchstabe s) steht:
Während die Reihenfolge innerhalb eines tar-Archivs konsistent ist, ist die Reihenfolge der Escape-Sequenz und des Befehlsinhalts der Exploit-Nutzlast aus Sicht der Erkennungsregel nicht deterministisch, da die Reihenfolge von der kombinierten Länge und den in den Befehlen innerhalb der Nutzlast verwendeten Zeichen abhängt.
3. Erläuterung der Erkennungsregel auf hohem Niveau:
Nachdem wir die Schwachstelle besser verstanden hatten, was nötig ist, um sie auszunutzen, und bestätigt hatten, welche Muster innerhalb des Exploits unterschieden werden müssen, wandten wir unsere Aufmerksamkeit der Erkennungsregel aus der Datei emerging-exploit.rules zu:
Vereinfacht gesagt, sucht diese Regel nach 3 Mustern:
1. Alle SMTP-Pakete, die von irgendwoher kommen und für jeden SMTP-Server bestimmt sind, der in der$SMTP_SERVERS -Zuordnung enthalten ist. Beachten Sie, dass Suricata standardmäßig $SMTP_SERVERS auf $HOME_NET abbildet, so dass jeder interne SMTP-Server von der Regel erfasst wird.
a. die einen gültigen tar-Archiv-Anhang enthält; der Anhang muss mit den magischen Dateinummern eines TAR-Archivs übereinstimmen.
b. Diese enthält die beiden Muster "|27 60|" und "|60 27|".
Die gesuchten Schlüsselwörter sind die hexadezimale Darstellung der folgenden ASCII-Zeichen:"'`" (einfaches Anführungszeichen, hinterer Haken) und "`'" (Anführungszeichen, einfaches Anführungszeichen). Die Zeichen "'`" (einfaches Anführungszeichen, Backtick) werden verwendet, um die Befehlsausführung auszulösen, wie zuvor erläutert. Nachfolgend sehen Sie die hexadezimale Darstellung des Exploits mit den 3 hervorgehobenen Mustern, nach denen die Erkennungsregel sucht:
Ein Blick zurück auf die Regel zeigt, dass es auch einen "Abstand"- und einen "Innerhalb"-Parameter gibt, die zur Feinabstimmung einer Regel miteinander kombiniert werden können. Die Parameter werden wie folgt verwendet:
- Abstand: Setzt den Cursor auf die Stelle, an der die Analyse beginnen soll.
- Abstand: 0 bedeutet, dass das Muster an einer beliebigen Stelle nach der vorherigen Übereinstimmung +0 Bytes liegen kann. Also direkt nach \x27\x60 in unserem Beispiel oben.
- Innerhalb: Begrenzt, wie weit nach dem letzten Spiel die Regel nach vorne schauen muss.
- Innerhalb: 500 bedeutet, dass es nur dann eine Übereinstimmung gibt, wenn der Inhalt mit der Nutzlast innerhalb von 500 Bytes übereinstimmt.
Die Parameter Within und Distance werden in der Suricata-Dokumentation erläutert.
4. Bei der ursprünglichen Regel beobachtete Mängel im Vergleich zu unserem Exploit
Wie das Sprichwort sagt, "ein Bild sagt mehr als tausend Worte", zeigt ein Dump unten, wie sich die Erkennungsregel im Rapid7-Exploit verhält:
Dieser Auszug aus der Vorschrift:
Anhand des obigen Auszugs lässt sich leicht erkennen, warum die Erkennungsregel nie ausgelöst wird: In unserem Beispiel wird sie das andere Muster nie finden, da es am Anfang des Archivs steht.
5. Eine Variante der M2-Erkennungsregel für diesen unentdeckten Exploit
In Anbetracht der oben genannten Erkenntnisse wurde am 29. September eine neue Erkennungsregel M2, Revision 2, vom Emerging Threats Team von Proofpoint als SID 2048146 veröffentlicht:
Nachfolgend finden Sie eine Übersicht über die Überprüfungen der M2-Erkennungsregel, wobei dieselbe Hexadezimal-Darstellung des gleichen tar-Archiv-Exploits wie zuvor verwendet wird:
6. Auflösung
Angesichts der offensichtlichen Unzulänglichkeiten der ursprünglichen ET-Regel von Proofpoint (SID 2046280) wird deutlich, dass das ausschließliche Vertrauen auf feste Regeln und Standards in der sich ständig weiterentwickelnden Cybersicherheitslandschaft seine Grenzen hat. General MacArthurs zeitlose Weisheit "Rules are mostly made to be broken" (Regeln sind meist dazu da, um gebrochen zu werden) ist eine deutliche Erinnerung daran, dass böswillige Akteure jede Schwachstelle ausnutzen werden, auch starre Regeln.
Durch diese Analyse haben wir ein Paradebeispiel für die Grenzen dieses Ansatzes erlebt, und zwar durch die Manipulation einer TAR-Archivstruktur, die es einer Nutzlast ermöglichte, an der ursprünglichen Erkennung von CVE-2023-2868 durch ET vorbeizukommen. Dieses Ereignis unterstreicht die Dringlichkeit, eine anpassungsfähigere und dynamischere Sicherheitsstrategie einzuführen.
Mit Blick auf die Zukunft ist es unerlässlich, dass wir unseren Fokus von der Starrheit abwenden und ein ganzheitlicheres, proaktives Sicherheitsparadigma annehmen. Anstatt nur über die Wahrscheinlichkeit eines weiteren Regelverstoßes nachzudenken, sollten wir aktiv danach streben, unsere Cybersicherheitsmaßnahmen zu verbessern, indem wir unsere Erkennungs- und Abwehrmechanismen ständig weiterentwickeln. Indem wir die Grenzen fester Regeln anerkennen, können wir uns besser auf eine ungewisse Zukunft vorbereiten, in der sich Cyber-Bedrohungen ständig weiterentwickeln. Auf diese Weise können wir unsere Sicherheitslage verbessern und uns besser vor böswilligen Akteuren schützen, die immer wieder versuchen, die Regeln zu umgehen. Die Annahme einer Strategie, die über das alleinige Vertrauen in regelbasierte Technologien hinausgeht, steht nicht nur im Einklang mit dem vielschichtigen Ansatz von Defense-in-Depth, sondern regt den Leser auch dazu an, die derzeit wirksamsten Strategien, einschließlich des Zero-Trust-Modells, zu übernehmen.
Um eine sofort umsetzbare Empfehlung zu geben, bieten wir die folgende Anleitung an:
Für Suricata-Implementierungen, die die Datei emerging-all.rules verwenden und eine automatische Verwaltung von Regelsatz-Updates haben, sollte die überarbeitete Erkennungsregel bereits vorhanden sein, vorausgesetzt, der Updater wurde nach dem 29.9.23 ausgeführt. Um zu überprüfen, ob der aktuell verwendete Regelsatz die überarbeitete Erkennungsregel enthält, suchen Sie in Ihren lokalen Regelsatzdateien nach "2048146". Wenn die SID 2048146 in keinem der aktuell angewandten Regelsätze enthalten ist, aktualisieren Sie die Regelsätze auf die neueste verfügbare Quelle von Emerging Threats.
Zeitleiste:
- 19.9.23: Einreichung der Ergebnisse über das ET-Portal. Keine Rückmeldung über die Einreichung erhalten.
- 21.9.23: Ich habe eine E-Mail an support@emergingthreats.net geschickt, um die Meldung zu protokollieren und das Team für neue Bedrohungen über die Google-Richtlinie zur verantwortungsvollen Offenlegung zu informieren, die hier befolgt wird.
- 21.9.23: ET Security Researcher hat mir eine E-Mail geschickt und zugestimmt, eine M2-Version der Erkennungsregel als Teil ihrer täglichen Veröffentlichung heute um 19 Uhr ET zu veröffentlichen.
- 21.9.23: Es wurde festgestellt, dass die neu veröffentlichte Regel zur Erkennung von M2-Varianten keine Warnung vor dem R7-Exploit auslöst.
- 21.9.23: E-Mail an ET Security-Forscher über das Versagen bei der Erkennung der Exploit-Nutzlast mit der neu veröffentlichten M2-Erkennungsregel.
- 29.9.23: Eine Revision 2 der M2-Variante wurde um 19.00 Uhr ET veröffentlicht und erkennt erfolgreich dieR7-Exploit-Nutzlast.
Referenz:
Suricata Dokumentation: https://docs.suricata.io/en/suricata-6.0.1/rules/payload-keywords
html#innerhalbhttps://docs.suricata.io/en/suricata-6.0.1/rules/payload-keywords.html#distance
Github POC ausnutzen: https://github.com/cfielding-r7/poc-cve-2023-2868/blob/main/poc_cve_2023_2868.rb
Exploit erklärt: https://www.mandiant.com/resources/blog/barracuda-esg-exploited-globally
ET-Regel: http://rules.emergingthreats.net/open/suricata-5.0/emerging-all.rules