Vollständig weaponisiertes CVE-2021-40444

Bösartiger DOCX-Generator zur Ausnutzung von CVE-2021-40444 (Microsoft Office Word Remote Code Execution), funktioniert mit beliebigen DLL-Dateien.

Hintergrund

Obwohl im Internet bereits viele PoCs kursieren, habe ich beschlossen, selbst einen Versuch zu unternehmen, diese Schwachstelle zu weaponisieren, da das, was ich verfügbar fand, kaum wertvolle Informationen enthielt, die es wert sind, geteilt zu werden. Zudem hat Microsoft bereits einen Patch für diese Schwachstelle veröffentlicht.

Bislang sind die einzigen wertvollen Ressourcen, die ich für die Erstellung eines voll funktionsfähigen Generators gesehen habe:

• Blog von Ret2Pwn
• Tweet von j00sean

Die oben genannten Ressourcen beschreiben viele der Anforderungen, die für eine vollständige Angriffskette nötig sind. Um nicht zu viele unnötige Informationen zu wiederholen, fasse ich nur die relevanten Details zusammen.

Angriffskette

1. DOCX geöffnet
2. In document.xml.rels gespeicherte Beziehung verweist auf bösartiges HTML
3. Die IE-Vorschau wird gestartet, um den HTML-Link zu öffnen
4. Das JScript im HTML enthält ein Objekt, das auf eine CAB-Datei verweist, und einen Iframe, der auf eine INF-Datei verweist, versehen mit der Direktive „.cpl:“
5. Die CAB-Datei wird geöffnet, die INF-Datei im Verzeichnis %TEMP%\Low gespeichert
6. Aufgrund einer Path-Traversal-Schwachstelle (ZipSlip) in der CAB-Datei ist es möglich, die INF-Datei in %TEMP% zu speichern
7. Anschließend wird die INF-Datei mit der Direktive „.cpl:“ geöffnet, was das Side-Loading der INF-Datei über rundll32 bewirkt (falls es sich um eine DLL handelt)

Übersehene Anforderungen

Es gibt eine ganze Reihe übersehener Anforderungen, damit dieser Exploit funktioniert, die selbst guten PoCs, wie etwa dem von lockedbyte, ein ordnungsgemäßes Funktionieren verhindert haben.

Vielleicht hat niemand sie explizit „veröffentlicht“, um zu vermeiden, dass die Schwachstelle weiter ausgenutzt wird. Aber jetzt ist sie gepatcht, daher sollte es keine großen Probleme bereiten, die Details zu veröffentlichen.

HTML-Datei

Laut diesem Tweet von Will Dormann muss das HTML mindestens 4096 Bytes groß sein, um die „Vorschau“ in MS Word auszulösen.

CAB-Datei

Die CAB-Datei muss per Byte-Patch modifiziert werden, um Extraktionsfehler zu vermeiden und den ZipSlip zu erreichen:

• filename.inf sollte zu ../filename.inf werden
• filename.inf sollte exakt <12-Zeichen>.inf sein Nicht wirklich wahr, das Wichtige ist, coffCabStart zu modifizieren
• CFFOLDER.typeCompress sollte 0 sein (nicht komprimiert)
• CFFOLDER.coffCabStart sollte um 3 erhöht werden (aufgrund des hinzugefügten '../')
• CFFOLDER.cCfData sollte 2 sein
• CFFILE.cbFile sollte größer sein als der gesamte CFHEADER.cbCabinet
• CFDATA.csum sollte neu berechnet (oder auf null gesetzt) werden [OPTIONAL]

Die Gründe für diese Einschränkungen sind vielfältig, und ich habe nicht genug Zeit investiert, um alle tiefgehend zu verstehen, aber schauen wir uns die wichtigsten an:

• TypeCompress: Wenn die CAB-Datei komprimiert ist, schlägt der Trick fehl, sie in einem Objekt-Element zu öffnen, um das Schreiben der INF-Datei auszulösen Falsch, mir ist das gleiche Ergebnis mit einer MSZIP-komprimierten Probe gelungen
• CoffCabStart: CoffCabStart gibt die absolute Position der ersten CFDATA-Struktur an. Da wir ein '../' hinzugefügt haben, müssten wir diesen Wert um 3 erhöhen, um auf die Datei zu zeigen (das ist eher eine Vermutung)
• cCfData: Da es nur 1 Datei gibt, sollten wir nur 1 CFDATA haben, ich bin mir nicht ganz sicher, warum dies auf 2 gesetzt werden muss In der Tat können wir es auf 1 belassen
• cbFile: Interessanterweise wird die INF-Datei von WORD zum Löschen markiert, wenn die CAB-Extraktion ohne Fehler endet, was den Exploit zunichtemacht. Der einzige Weg, dies zu verhindern, besteht darin, WORD glauben zu lassen, die Extraktion sei fehlgeschlagen. Wenn der cbFile-Wert größer als die CAB-Datei selbst definiert ist, erreicht der Extraktor einen EOF, bevor alle in cbFile definierten Bytes gelesen wurden, was einen Extraktionsfehler auslöst.
• [OPTIONAL] Dieser Wert scheint von MS Word nicht geprüft zu werden. Um eine korrekte CAB-Datei zu haben, sollte der csum-Wert jedoch neu berechnet werden. Glücklicherweise kann dieser Wert, wie von j00sean angemerkt und laut MS-Dokumentation, 0 sein.

HINWEIS1: Defender erkennt inzwischen, ob die CAB-Datei eine PE enthält, indem er den _IMAGE_DOS_HEADER.e_magic-Wert als Signatur verwendet, wodurch möglicherweise verhindert wird, dass PE-Dateien in die CAB-Datei eingebettet werden. Kann diese Signatur umgangen werden? Ich bin mir nicht sicher, aber wie bereits beobachtet, ist dies eine gepatchte Schwachstelle, daher habe ich nicht vor, viel mehr Zeit darauf zu verwenden. Es liegt am neugierigen Leser, dies weiterzuentwickeln.

HINWEIS2: Microsofts Patch blockiert beliebige URI-Schemata, offenbar mithilfe eines Blacklist-Ansatzes (das ist nur eine Vermutung)

DLL-Angriff

Die Hauptangriffskette im Zusammenhang mit CVE-2021-40444 ist der DLL-Angriff, der über das .cpl-URI-Schema geladen wird. Um dies auszunutzen, muss ein Angreifer eine speziell präparierte DLL erzeugen. Wenn du es testen möchtest, probiere mein Skript evildll-gen aus.

JScript, VBScript, Javaw, MSIexec, ...

Wie von Max Maluin angemerkt, ist es möglich, mit mehreren Dateitypen zu interagieren, indem man IE und das zugehörige, auf Dateierweiterungen basierende URI missbraucht. Das mag zwar ein guter Weg sein, IE auszunutzen, hat aber Einschränkungen.

Es sollte darauf hingewiesen werden, dass die im Exploit verwendete Methode zum Herunterladen von Dateien auf ActiveX-Control-Updates basiert und nicht zum Herunterladen beliebiger Dateien verwendet werden kann.

Laut Microsoft-Dokumentation kann das codebase-Tag nur auf einige Dateitypen verweisen: OCX, INF und CAB.

Selbst wenn wir eine OCX- oder INF-Datei direkt herunterladen können, können wir nicht sicher sein, dass die Datei am richtigen Ort im System abgelegt wird. Mit dem CAB-Exploit ist es möglich, die .inf-Datei mithilfe der Path Traversal an einen bekannten Pfad zu verschieben, aber in jedem anderen Fall wird die Datei in einem zufälligen Verzeichnis gespeichert, was es praktisch unmöglich macht, darauf zu verweisen.

Bis heute habe ich keinen Weg gefunden, Download und Ausführung OHNE eine CAB-Datei zu verketten.

Hinweis: Wenn man nur IE betrachtet, könnte HTML-Smuggling ein mögliches Szenario sein, um die Schwachstelle auszunutzen.

Dateiangriff ohne CAB-Datei mithilfe einer hybriden RAR-Datei

Diese Technik wurde erstmals von Eduardo Braun auf Twitter veröffentlicht und in diesem Paper näher erläutert.

Bitte beachte, dass sich die Angriffskette bei dieser Technik etwas unterscheidet. Dieser Angriff erfordert, dass der Benutzer eine speziell präparierte RAR-Datei herunterlädt, die durch Verkettung eines gültigen WSF-Skripts und einer gültigen RAR-Datei entsteht. Beim Öffnen enthält die RAR-Datei eine DOCX-Datei mit einem Verweis auf ein HTML, das wiederum versucht, die RAR-Datei als WSF-Skript zu laden.

Zusammenfassung: