Neue Microsoft Office Schwachstellen?

[English]Wie es ausschaut, gibt es in allen Versionen von Microsoft Office Schwachstellen durch eingebettete Objekte, über die sich (remote) Code auf einer lokalen Maschine ausführen lässt. Hier ein Überblick über das Thema – als Info für Admins im Unternehmensumfeld.

Ich wurde vor wenigen Stunden durch einen Tweet von Sicherheits-Experte Kevin Beaumont auf das Thema aufmerksam.

Speaking of Microsoft 0day, here's a new Office code execution technique (all versions) which MS aren't planning to fix by @yorickkoster https://t.co/JvAsj1QJdo pic.twitter.com/f7mROqf8JC

— Kevin Beaumont (@GossiTheDog) 28. August 2018

Es lässt sich offenbar Code über ein Word-Dokument dazu missbrauchen, Programme und Befehle auszuführen. Dort wird diskutiert, ob das neu oder alt sei – wobei sich herauskristallisiert, dass neue Angriffsvektoren entdeckt wurden. Im Blog securify.nl hat Yorick Koster die Details im Beitrag Click me if you can, Office social engineering with embedded objects zusammen getragen.

Eingebettete Objekte in Office-Dokumenten

Der Angriffsvektor ist nicht wirklich neu, die größte Schwachstelle in Microsoft Office stellen die Möglichkeiten dar, Objekte in Dokumente einzubetten und dann deren Funktionen für Angriffe zu missbrauchen. Yorick Koster hat in seinem Blog-Beitrag einige Ansätze zusammen getragen und weist dabei auf neue Bedrohungen hin.

Das Objekt Shell.Explorer.1

Das Shell.Explorer.1 OLE-Objekt (CLSID {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}) fungiert in Office-Dokumenten als eingebetteter Windows Explorer oder eingebetteter Internet Explorer. Wird dieses OLE-Objekt in Office-Dokumente eingebettet, wird es als persistentes Objekt im Dokument gespeichert. Dabei wird ein proprietäres Format zum Speichern des persistenten Shell.Explorer.1-Objekts verwendet. Koster ist eine bekannte Struktur bei Offset 76 (0x4C) aufgefallen, aus der er schließt, dass dort eine ShellLink (LNK)-Struktur gespeichert wird.

Wird ein Ordnerpfad angegeben, verhält sich das Objekt wie der Windows Explorer. Es ist möglich, durch Dateien oder Ordner zu blättern und sogar Dateien per Doppelklick auszuführen. Missbraucht ein Angreifer dies und bettete den Windows Explorer in ein Office-Dokument ein, ließe sich eine entfernte Freigabe mit einer eine ausführbaren Datei öffnen. Allerdings ist der Angriff schwierig, denn das Opfer müsste davon überzeugt werden, eine vom Angreifer kontrollierte Datei aus der Freigabe per Doppelklick zu öffnen. Das setzt auch voraus, dass das Objekt vom Opfer aktiviert werden muss. Dann ließe sich allerdings Code von dieser entfernten Freigabe ausführen.

(Quelle: securify.nl)

Das Einbetten eines Windows-Explorer-Objekts kann aber in Situationen sinnvoll sein, in denen die Administratoren den Zugriff auf bestimmte Ordner oder Laufwerke eingeschränkt haben. Ist beispielsweise der Zugriff auf das Laufwerk C: eingeschränkt, kann ein lokaler Benutzer laut Yorick Koster ein Office-Dokument mit eingebettetem Windows Explorer verwenden, um diese Einschränkung zu umgehen.

Internet Explorer als eingebettetes Objekt

Yorick Koster beschreibt ein interessanteres Szenario, wenn das Shell.Explorer.1-Objekt als eingebetteter Internet Explorer fungiert. Neben der Möglichkeit, einen Webbrowser in ein Dokument einzubetten, ermöglicht es auch das Durchsuchen von Dateien auf dem lokalen Rechner und das Durchsuchen von Dateien an entfernten Standorten (Freigaben und Websites). Dies ist ohne Benutzerinteraktion nicht möglich.

(Quelle: securify.nl)

Es ist zwar ein Klicken zum Aktivieren in diesem Modus erforderlich. Der Klick auf das Objekt löst aber die Datei-Download-Funktionalität des Internet Explorers aus, so dass dem Benutzer ein Datei-Download-Dialog angezeigt wird. Klickt der Benutzer auf Ausführen oder Öffnen klickt (je nach Dateiformat), wird die Datei ausgeführt. Einige Dateitypen (wie .exe-Dateien) lösen zwar eine Warnung in einem Dialogfeld aus. Dies ließe sich aber über andere Dateitypen vermeiden. Im Blog-Beitrag wird SettingContent-ms angegeben. Diese Schwachstelle (siehe Windows 10: Schwachstelle .SettingContent-ms) wurde m.W. aber kürzlich durch Microsoft geschlossen (siehe Microsoft-Sicherheitssplitter 30.7.2018). Aber Koster führt aus, dass auch andere Dateitypen in diesem Zusammenhang funktionieren.

Proof of Concept per PowerShell

Yorick Koster stellt auf seiner Webseite ein Proof of Concept (PoC) bereit. Per PowerShell wird versucht, ein Word-Dokument mit eingebettetem Internet Explorer anzulegen.

(Quelle: securify.nl)

Öffnet der Nutzer das Word-Dokument und klickt auf das eingebettete Objekt, erscheint eine Warnung. Bestätigt er diese mit Öffnen, wird der Rechner von Windows geöffnet. Das PoC muss dann nur noch mit geeigneten Methoden an den Nutzer gebracht werden. Neu an diesem Szenario wohl die Möglichkeit, auch eine URL mit den 'bösen' Dateien in einem Word-Dokument einzubetten.

Yorick Koster beschreibt in seinem Blog-Beitrag weitere Szenarien unter Verwendung des Microsoft Forms 2.0 HTML Control. Er weist auch darauf hin, dass aus dem Web geladene Inhalte üblicherweise entsprechend markiert sind und daher im geschützten Anzeigemodus in Office geladen werden. Dann sind die betreffenden Objekte blockiert und können nicht ausgeführt werden. Administratoren in Unternehmensumgebungen sollten sich den Original Blog-Beitrag von Kostner aber durchlesen, um vor solchen Szenarien ggf. gewappnet zu sein. Wie ich den Tweet von Kevin Beaumont interpretiere, ist nicht mit einem Patch von Microsoft zu rechnen.

Ähnliche Artikel:
Apache Struts-Schwachstelle CVE-2018-11776 aktiv genutzt
Neue Schwachstelle in OpenSSH gefunden (24.8.2018)
"Turning Tables" Bypass für Windows Kernel-Schutz
Neue Windows ALPC Zero-Day-Schwachstelle entdeckt
Chaos-Tage: Microsoft Microcode-Updates zurückgezogen?