[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.
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.
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.
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:
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:
- Ü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.
- Löschen Sie das Schema „ms-msdt“ aus der Registrierung [siehe oben].
- 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
- 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)
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
GPO ist keine Lösung laut MSRC!
https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/
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.
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.
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
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…
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
Applocker, Software-Restriction-Policy, evtl. auch was im Bereich Antivirus/Application-Control.
oder per GPO die Dateiberechtigung der Powershell Exe für User entfernen.
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.
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…
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.
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.
Danke für den Tipp!
Laut MSRC nicht!
https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/
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.
Beachtet meinen Nachtrag im Text – und vor ALLEM – die Linkliste am Artikelende mit dem Status vom 9. Juni 2022 – das Thema ist eine wandelnde Baustelle.
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
Gibt es diese Richtlinie auch für den SBS 2003?
Der SBS 2003 hat keine Exploits, der IST ein Exploit und sollte nicht mehr im Einsatz sein!!!
John Hammond, Huntres:
https://www.youtube.com/watch?v=dGCOhORNKRk
aus dem Gedächtnis: Ein Sample ist frei verfügbar (Schweiz)
| 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!
@Stefan Kanthak
Das gleiche habe ich, wenn auch weniger Detailiert weiter oben auch schon angemerkt: https://www.borncity.com/blog/2022/05/31/follina-angriff-ber-word-dokumente-und-ms-msdt-protokoll-cve-2022-30190/#comment-126689
Und ich finde, dass Herr Born das UNBEDINGT im obigen Artikel mit Warnung erwähnen müsste. Der Workaround seitens MS ist hier schkicht ne Nullnummer. (Mal abgesehen davon, dass man ja per Computer-GPO das MSDT eifach deaktivieren kann. Ist mir ein Rätsel, warum MScdas nicht so empfiehlt!!)
Steht im obigen Artikel. Weil auch das nicht mehr ausreicht – siehe WGET über PS! Allerdings stellt sich hier die Frage, wie man das unterbinden soll – Powershell abschalten scheint nicht zu helfen.
Ich habe den einfachen Exploit mit wget von Huntress ausprobiert und bekomme ihn mit aktivierter GPO nicht zum Laufen! Ohne GPO wird der Calc gestartet.
Wo genau steht (in den hier verlinkten), dass die GPO nicht ausreicht? Ich konnte das aus den verlinkten Artikeln nicht herauslesen.
Ich bin weiterhin der Ansicht, dass die GPO die beste Lösung ist.
PS: Der (Standard-)Windows-Defender löscht aber auch bereits die Dateien bzw. blockiert die Ausführung.
Die GPO für das Unterbinden der Onlinehilfe ist definitiv der beste Schutz, aber es scheint nach dieser Meldung
https://twitter.com/wdormann/status/1531619222295568384
nicht auszureichen. Oder habe ich hier was überlesen?
@Heiko: Möglicherweise hast Du meine Ergänzung im Artikel – Hinweisblock – überlesen?
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!
Moin js,
welchen Pfad hast du genau gesperrt? Das ist für mich die beste Möglichkeit :).
Gruß
Mathias
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
Bei mir kommt beim Ausführen von „msdt://hallo“ mit und ohne GPO Setting immer der gleiche Screen, dass eine App zum Öffnen eines msdt-Links benötigt wird.
https://i.imgur.com/i8lZqQm.png
Was bedeutet es denn?
Ist mein Rechner auch schon ohne GPO Setting nicht gefährdet?
Du hast den Befehl falsch geschrieben.
falsch:
„msdt://hallo“
richtig:
„ms-msdt://hallo“
@ja danke :)
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?
Oliver Pergler von PEAKNET GmbH hat mir eben auch noch folgende Information per Mail zukommen lassen:
[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.]
[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.]
@Günter
Laut MSRC ist das deaktivieren von MSDT per GPO keine Lösung. Evtl. im Artikel ergänzen?
https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/
Hm. Scheinbar gibt es da leichte Diskrepanzen welche GPO jetzt evtl. funktioniert und welche nicht. MSRC spricht wohl von einer anderen GPO als der Rest der Welt….
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….