Follina: Angriff über Word-Dokumente und ms-msdt-Protokoll (CVE-2022-30190)

Windows[English]Seit dem Wochenende ist ein neuer Angriffsvektor bekannt, der das Microsoft Support Diagnostics Utility über das ms-msdt:-Protokoll missbraucht, um bösartige Word-Dokumente (oder Excel-Arbeitsblätter) aus dem Web herunterzuladen und zu missbrauchen. Microsoft hat inzwischen ein Support-Dokument für CVE-2022-30190 herausgegeben. Ich habe mal den letzten Erkenntnisstand zusammen gefasst.


Anzeige

Kurzer Rückblick der Historie

Einem Sicherheitsforscher mit dem Nick nao_sec ist ein Upload aus Weißrussland (Belarus) auf Virustotal aufgefallen, der die in Microsoft Word mögliche Auflösung von externen Links missbraucht, um ein HTML-Dokument herunterzuladen. Von dort wird dann das ms-msdt-Protokoll missbraucht, um über ein PowerShell-Script Schadfunktionen auszuführen. Das Ganze ist in einem Tweet zum 27. Mai 2022 öffentlich geworden.

Follina attack on Office

Sicherheitsforscher Kevin Beaumont hat dann die Schwachstelle "Follina" genannt und das Ganze zwei Tage später im Artikel Follina — a Microsoft Office code execution vulnerability genannt. Beaumont schreibt, dass das hochgeladene Word-Beispiel die Word-Remotevorlagenfunktion verwendet, um eine HTML-Datei von einem entfernten Webserver abzurufen, der wiederum das MSProtocol-URI-Schema ms-msdt verwendet, um Code zu laden und PowerShell auszuführen.

Das sollte nicht möglich sein, es handelt sich also um eine Sicherheitslücke in Microsoft Word. Denn dieser Angriffsvektor funktioniert auch, wenn Makros in Word deaktiviert sind. Beaumont kommt zum Schluss, dass es sich um eine Zero-Day-Schwachstelle handelt, die die Ausführung von Code in Office-Produkten ermöglicht – egal, ob Makros deaktiviert sind oder nicht.

Der Name Follina für die Schwachstelle leitet sich aus einem Muster 0438 in der Datei ab,  was der Vorwahl von Follina in Italien entspricht. Das über das Protokoll ms-msdt aufgerufene Tool msdt.exe (Microsoft Support Diagnostics Utility) ermöglicht dem Microsoft Support bestimmte Probleme zu untersuchen (siehe hier).

Beaumont weist in seinem Beitrag mehrere Vorstufen nach, in denen Follina für Angriffstests versucht wurde. Dann hat Beaumont das Ganze auf verschiedenen Geräten getestet und festgestellt, dass es häufiger funktioniert. Er zeigt ein Beispiel unter Windows 10, wo er nicht nicht als lokaler Administrator angemeldet ist und mit vollständig deaktivierten Makros, mit Defender, mit Office 365 Semi-Annual Channel, testet. Beim Öffnen eines (infizierten) Word-Dokuments wird der Windows Rechner Calc gestartet – das Angriffskonzept funktioniert also.

Wer ist betroffen?

Kevin Beaumont schreibt, dass die Schwachstelle sich mit RTF-Dateien in allen Versionen von Office 365 ausnutzen lässt. Die Sicherheitslücke wurde in Office 2013, 2016, 2019, 2021, Office ProPlus und Office 365 nachgewiesen. Sie gilt auch für Windows selbst, z. B. kann sie von .lnk-Dateien aufgerufen werden. Beaumont gibt weitere Beispiele und Referenzen an, die die Ausnutzung belegen.

Deactivate ms-msdt

Sicherheitsforscher Will Dormann legt Administratoren in obigem Tweet nahe, das ms-msdt-Protokoll zu deaktivieren. Das lässt sich mit folgenden, von Dormann geposteten, Anweisungen realisieren:


Anzeige

Windows Registry Editor Version 5.00

[-HKEY_CLASSES_ROOT\ms-msdt]

Wer den obigen Schlüssel in der Registrierung mit dem Befehl löschen will, sollte sich vorher im Registrierungseditor den Inhalt in eine .reg-Datei importieren.

Beachtet die Hinweise, dass entsprechende Protokoll-Einträge in der Registry auch unter HKCU und HKLM existieren können. Ich habe gerade unter Windows 7 geschaut, da ist der Eintrag nicht zu finden – laut nachfolgendem Kommentar gibt es den Protokolleintrag erst seit Windows 8. In diesem Artikel wird eine GPO zum Deaktivieren des Tools beschrieben (siehe auch diesen Tweet). Aber auch hier der Hinweis, dass inzwischen erweiterte Angriffsmöglichkeiten per WGET und PowerShell bekannt sind (siehe diese Tweet von Will Dormann).

Ergänzung: Das Thema "Mitigation" birgt wohl viele Fallen. Der Ratschlag Microsoft, den ms-msdt-Eintrag in der Registrierung zu löschen, wurde hier ja in den Kommentaren als nicht ausreichend verworfen. Der Einsatz einer Gruppenrichtlinie (GPO), siehe obigen Tweet, wird dagegen von Microsoft in der FAQ des Blog-Beitrags Guidance for CVE-2022-30190 Microsoft Support Diagnostic Tool Vulnerability als ungeeignet angesehen.

Hinweise vom ICS/SANS und von Microsoft

Über meine Kanäle ist mir folgendes Statement von Dr. Johannes Ullrich vom Internet Storm Center, dass zum SANS Technology Institute gehört, dazu zugegangen:

Bösartige Office-Dokumente sind ein beliebtes Mittel zum Einschleusen von Malware. In der Vergangenheit geschah dies in der Regel über Makros. Microsoft hat Office-Makros eingeschränkt, um den Missbrauch zu erschweren.

Die neue Sicherheitslücke umgeht diese Beschränkungen. Der bösartige Code wird ausgeführt, sobald der Benutzer das Dokument öffnet, und es wird keine Warnung angezeigt. Der Angriff wurde in Beispielen entdeckt, die bei Virustotal eingereicht wurden, einer von Google betriebenen Website, die bösartigen Code sammelt. Microsoft hat das Problem zwar ohne öffentliche Ankündigung in den allerneuesten Versionen von Office gepatcht, die meisten älteren Versionen sind jedoch noch anfällig.

Ein weiteres Dokument, das dieses Problem ausnutzt, wurde am 27. Mai von einem anonymen Benutzer auf Virustotal hochgeladen. Der Upload erfolgte von einer weißrussischen IP-Adresse aus. Ein Forscher ("nao_sec") entdeckte das Dokument und bemerkte die neue Technik und alarmierte die Öffentlichkeit über Twitter. Das Internet Storm Center von SANS hat die Schwachstelle untersucht und gibt Empfehlungen zur Verteidigung, bis MSFT einen Patch herausgibt.

Im ICS SANS-Forum gibt es dazu diesen Eintrag, der die Erkenntnisse zur Schwachstelle (CVE-2022-30190) zusammen fasst. Vom ICS SANS gibt es zudem folgende Tipps zur Behebung der Schwachstelle bis der Patch verfügbar ist:

  1. Überprüfen Sie die Parent-Child-Beziehung: Eine gute Idee ist es, msdt.exe-Prozesse zu verfolgen, die von übergeordneten Prozessen wie word.exe oder excel.exe gestartet werden.
  1. Löschen Sie das Schema "ms-msdt" aus der Registrierung [siehe oben].
  1. Verhindern Sie, dass Office Child-Prozesse erzeugt, indem Sie eine ASL-Regel erstellen:
    Set-MpPreference -AttackSurfaceReductionRules_Ids d4f940ab-401b-4efc-aadc-ad5f3c50688a -AttackSurfaceReductionRules_Actions Enabled
  1. Darüber hinaus sollten Sie Ihre Benutzer darin schulen, verdächtige Dokumente gar nicht erst zu öffnen.

Inzwischen gibt es von Microsoft den auf den 30. Mai 2022 datierten Blog-Beitrag Guidance for CVE-2022-30190 Microsoft Support Diagnostic Tool Vulnerability der ebenfalls die Entfernung des ms-msdt-Protokoll-Handlers entfernt.

Auf Twitter finden sich zudem Meldungen, die darauf hinweisen, dass der Windows Defender inzwischen solche Dateien findet. Kevin Beaumont schreibt zum 31. Mai 2022, dass der Windows Defender inzwischen eine Signatur für diese Schwachstelle besitzt. Das wird von Microsoft im Blog-Beitrag Guidance for CVE-2022-30190 Microsoft Support Diagnostic Tool Vulnerability  bestätigt. Der Microsoft Defender erkennt ab der Build 1.367.719.0 oder neuer der Signaturdateien folgende Schädlinge:

Trojan:Win32/Mesdetty.A
Trojaner:Win32/Mesdetty.B
Verhalten:Win32/MesdettyLaunch.A
Verhalten:Win32/MesdettyLaunch.B
Verhalten:Win32/MesdettyLaunch.C

Auch der Microsoft Defender für Endpoint bietet die Erkennung und Warnung vor solchen Angriffen. Im Microsoft 365 Defender-Portal können folgende Warnmeldungen auf Bedrohungsaktivitäten im Netzwerk hinweisen:

Verdächtiges Verhalten einer Office-Anwendung
Verdächtiges Verhalten von Msdt.exe

Weitere Details lassen sich Blog-Beitrag Guidance for CVE-2022-30190 Microsoft Support Diagnostic Tool Vulnerability von Microsoft nachlesen.

Artikelreihe:
Follina: Angriff über Word-Dokumente und ms-msdt-Protokoll (CVE-2022-30190)
Follina-Schwachstelle (CVE-2022-30190): Status, Erkenntnisse, Warnungen & Angriffe
0Patch Micro-Patch gegen Follina-Schwachstelle (CVE-2022-30190) in Windows
Follina (CVE-2022-30190): Angriffswelle ausgeblieben, aber Kampagnen auf EU/US und andere Ziele
Follina-Schwachstelle (CVE-2022-30190): Neue Erkenntnisse, neue Risiken (9.6.2022)


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Office, Sicherheit, Windows abgelegt und mit Office, Sicherheit, Windows verschlagwortet. Setze ein Lesezeichen auf den Permalink.

37 Antworten zu Follina: Angriff über Word-Dokumente und ms-msdt-Protokoll (CVE-2022-30190)

  1. MWC sagt:

    Super: wer z.B. Word Vorschau im Explorer aktiviert hat bekommt es unter Umständen schon ohne direktes Öffnen wenns heruntergeladen wurde.
    GPO setzen welche MSDT deaktiviert hilft auf jeden Fall. Die MS-Problemlösung sollten sowieso nur der Admin machen / aufrufen ;)

    Besser GPO als etwas aus der Registry zu löschen IMHO

  2. Roger H sagt:

    Interessant, auf unseren Terminal Servern (alles (noch) Windows Server 2012R2) mit Office 2013 existiert dieser Registry-Key nicht, auf einem Kunden Terminal Server mit Windows Server 2022 und Office 2021 existiert der Key hingegen.

    Sind die 2012R2 Server mit Office 2013 demnach nicht von der Lücke betroffen?
    Die Infos von MS sind schon etwas gar dünn geraten.

    • Jan Vauseweh sagt:

      Auf unseren Citrix XenApps (CVAD) unter Server 2012 R2 und Server 2016, beide mit Office 2016 sind diese Registry-Keys ebenfalls nicht vorhanden (auch nicht unter HKCU\Software\Classes). Selbst nach manuellem Aufruf der msdt.exe (die GUI vom Microsoft Support Diagnose-Tool wird geöffnet) wird in der Registry der Key nicht angelegt.

      Ja, die Infos dazu sind dünn.

  3. Steffen sagt:

    Bloß gut, dass sich dieses Problem einigermaßen unproblematisch beheben lässt. GPO zum Verhindern von Powershell für User, GPO zum einmaligen Exportieren und Entfernen des Reg-Eintrags.

    Und ich wusste schon/doch, warum ich Dateien nur als Symbole und nicht als Miniaturansichten per GPO festgelegt habe.

    VG, Steffen

    • 1ST1 sagt:

      Deine GPO für User um Powershell nicht starten zu können, nützt garnichts. Öffne auf so einem Desktop mal den Notepad, gehe auf Date, Öffnen, klicke unten rechts auf Anzeige von *.*, hangle dich zur Powershell.exe durch, klicke darauf mit der rechten Maustaste, wähle Öffnen aus dem Kontextmenü, und staune.

      Kannst auch das Startmenü aufklaben und einfach lostippen:

      forfiles /c powershell.exe

      Und schon ist sie offen…

      • Steffen sagt:

        Okay. bei "forfiles /c" hast du recht. Übern Editor wird das Öffnen von PS auf Grund der Policy abgewiesen.

        Welche Möglichkeit bleibt mir gegen PS via "forfiles"?

        VG, Steffen

  4. Chris sagt:

    Bei Office 2013 scheint der Key nicht an diese Stellen in der Registry zu existieren, was aber nicht bedeutet das er evtl. an einer anderen Stelle zu finden ist.

  5. 1ST1 sagt:

    Welche Nachteile hat das, wenn man die msdt.exe auf diese Weise ausknockt? Für was wird die überhaupt gebraucht?

    Edit: https://www.der-windows-papst.de/2014/12/10/microsoft-support-diagnostic-tool/

    Benutzt man doch gelegentlich…

    • Günter Born sagt:

      Schau mal im Hinweiskasten unter der Erklärung, wie Follina als Name der Schwachstelle entstanden ist. Da hatte ich auch auf einen MS-Beitrag verlinkt. Aufrufen lässt sich das Programm z.B. mit Windows-Taste+R und dann msdt.exe angeben. Bei mir werden aber Admin-Rechte per UAC angefordert.

  6. nk sagt:

    Wer nicht direkt in die Registry eingreifen möchte, der kann die Diagnose per GPO abschalten: https://www.pwndefend.com/2022/05/30/office-microsoft-support-diagnostic-tool-msdt-vulnerability-follina/
    Richtlinie: https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.ScriptedDiagnostics::ScriptedDiagnosticsExecutionPolicy

    Laut Benjamin Delphy entschärft das Deaktivieren von msdt den Angriffsvektor.

  7. Heiko sagt:

    Um hier mal ein paar Dinge klar zu stellen:

    Der Registrykey gehört nicht zu Office. Er gehört zu Windows und is eine Dateiprotokollzuordnung. "ms-msdt:" ist ein Protokollhandler ähnlich wie "http:" oder "ms-store:" der die Windows-Shell (Explorer) anweist, eine Anwendung zu starten und damit eine Datei/Webseite/Aktion auszuführen. (Dieses Feature gibt es seit Win8!)

    Und einfach nur den Protokollhandler-Eintrag unter HKCR zu löschen reicht meiner Meinung nicht aus, denn Dateizuordnungen können auch unter HKCU definiert werden, wo der normale Benutzer schreibrechte hat.

    Sinniger ist es, die komplette msdt.exe per GPO zu blockieren. Diese GPO liegt unter User\Administrative Templates\System und heißt "Ausführung bestimmter Programm blockieren". (Name und Pfad aus dem Gedächtnis.) – Die GPO weißt zwar drauf hin, dass das nur beim Aufruf der Exe aus dem Explorer funktioniert, aber das Stört hier nicht. Grund dafür, dass es in dem Fall geht, ist folgender: Die Protokollhandler werden am Ende immer von der (Explorer) Shell interpretiert und ausgeführt.

    Was passiert also: Word lädt ein Dokument mit Verweis auf ein externes html. In dem html steht die Anweisung den Protokollhandler mit bestimmten Parameterwerten aufzurufen. In diesen Parameterwerten steht ein Powershell-Befehl (codiert), welcher dann über die msdt.exe (ms-msdt:) ausgeführt wird und somit die Ausführungsrichtlinie der Powershell umgeht.

    Ich hoffe einige wird das Technische dahinter jetzt Klarer.

    @Günter Borm, das können Sie gerne im Artikel ergänzen.

  8. Jörg sagt:

    Hallo,
    falls jemand den von Benjamin Delphy empfohlenen Weg zum Entschärfen des Exploits per GPO auf einem deutschen Windows gehen möchte hier der Pfad zur Gruppenrichtlinie:

    Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Problembehandlung und Diagnose\Skriptdiagnose

    Hier: Problembehandlung: Zugriff und Ausführung von Problembehandlungs-Assistenten durch Benutzer zulassen

    auf DEAKTIVIERT setzen.

    Grüße,

    Jörg

  9. Aninym sagt:

    John Hammond, Huntres:
    https://www.youtube.com/watch?v=dGCOhORNKRk

    aus dem Gedächtnis: Ein Sample ist frei verfügbar (Schweiz)

  10. Stefan Kanthak sagt:

    | Das lässt sich mit folgenden Anweisungen realisieren:
    |
    | Windows Registry Editor Version 5.00
    |
    | [-HKEY_CLASSES_ROOT\ms-msdt]

    AUTSCH: nein, das genügt im Zweifelsfall NICHT!

    Wie M$FT seit über 20 Jahren in https://technet.microsoft.com/en-us/library/cc739822.aspx sowie https://msdn.microsoft.com/en-us/library/ms724498.aspx dokumentiert, ist HKEY_CLASSES_ROOT ein wirrtueller Registry-Zweig.
    Sollte im Konto des diese "Anweisungen" per *.REG-Datei an den Registry-Editor verfütternden Benutzer der Schlüssel [HKEY_CURRENT_USER\Software\Classes\ms-msdt] existieren, dann wird nur dieser gelöscht, jedoch NICHT der Schlüssel [HKEY_LOCAL_NACHINE\SOFTWARE\Classes\ms-msdt], d.h. das Protokoll bleibt dann für alle Konten registriert; ausserdem hat Löschen des letztgenannten Schlüssels KEINE Wirkung in anderen Benutzerkonten, in denen der Schlüssel [HKEY_CURRENT_USER\Software\Classes\ms-msdt] existiert!
    EINMAL mit Profis arbeiten!

  11. js sagt:

    Also ich habe via Softwarerestrictionpolicy msdt.exe als Pfadregel geblockt, so spare ich mir Registry Hacks und kann das irgendwann genauso leicht wieder aufheben.

    Edit: Bei HKCR habe ich mir auch schon an den Kopf geklatscht!

    • Mathias sagt:

      Moin js,
      welchen Pfad hast du genau gesperrt? Das ist für mich die beste Möglichkeit :).

      Gruß

      Mathias

      • js sagt:

        Mathias, der Pfad lautet "msdt.exe". Starte anschließend nach einem "gpupdate /force" zum Test einfach diesen Executable und Du wirst eine Meldung á la "Der Systemadministrator mag Dich nicht" erhalten.

        …übrigens ist der ideale test: Start, Ausführen, ms-msdt://hallo

  12. Florian Diehl sagt:

    D.h. am besten erstellt meine eine GPO mit zwei Einstellungen:
    System/
    "Ausführung folgender Programme aus der Hilfe nicht zulassen"
    Und trägt msdt.exe ein als gesperrtes Programm.

    System/Problembehandlung und Diagnose/Skriptdiagnose/
    "Problembehandlung: Zugriff und Ausführung von Problembehandlungs-Assistenten durch Benutzer zulassen"

    Auf Deaktiviert setzen.

    Damit sollte der Exploit unterbunden werden, sehe ich das richtig?

    • Günter Born sagt:

      Oliver Pergler von PEAKNET GmbH hat mir eben auch noch folgende Information per Mail zukommen lassen:

      Neben einem trivialen Script (per SCCM verteilt z.B.), das das Microsoft Windows Support Diagnostic Tool lahmlegt, ist ein GPO Setting eher ratsam. Ein Script wäre z.B. mit folgenden Befehlen umsetzbar

      reg export HKEY_CLASSES_ROOT\ms-msdt "C:\ms-msdt.reg"
      reg delete HKEY_CLASSES_ROOT\ms-msdt /f

      so kann später nach einem Patch wieder importiert werden.

      [GB: Hier gibt es aber das Problem, welches bereits gestern hier im Beitrag diskutiert wurde, dass der Schlüssel in weiteren Zweigen vorkommen kann. Zudem scheint es den Schlüssel auf Terminal- und Windows Servern nicht zu geben. Die bessere Alternative ist der Eingriff per GPO, den Oliver auch vorschlägt.]

      Eleganter wäre in einer geeigneten Computer GPO folgendes Setting:

      Troubleshooting: Allow users to access and run Troubleshooting Wizards (admx.help)

      DISABLE

      Quelle u.a.: dieser Artikel von pwndefend.com

      [GB: Den Artikel – der inzwischen erweitert wurde und auch die von mir in obigem Text angesprochene wget-Problematik aufgreift – es wird die GPO als auch der Registry-Eintrag zum Deaktivieren des msdt besprochen – hatte ich schon im 1. Beitrag verlinkt.]

  13. Rene sagt:

    Sehr gut erklärt ist es auch hier:
    https://www.iok.net/deepdive-poc-cve-2022-30190-follina

    Inkl. einem PoC, wie man selbst testen kann, ob die eingestellten Settings auch wirklich greifen….

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.