[English]Seit dem Wochenende ist eine neue Schwachstelle CVE-2022-30190 unter dem Namen Follina unter Windows in Kombination mit Microsoft Office bekannt. Inzwischen warnen das US CISA und auch das BSI vor dieser Schwachstelle – während Sicherheitsforscher erste Angriffe über diese 0-day-Schwachstelle durch chinesische APTs beobachtet haben. Inzwischen ist auch klar, dass diese Angriff auch ohne Microsoft Office funktionieren. Die Schwachstellen CVE-2022-30190 könnte das nächste große Ding in Sachen Sicherheit werden, wenn auch Virenschutzlösungen infizierte Dokumente erkennen. Hier ein Überblick über die aktuellen Erkenntnisse.
Anzeige
Die Schwachstelle CVE-2022-30190
Die Schwachstelle CVE-2022-30190 ermöglicht das Microsoft Support Diagnostics Utility über das ms-msdt:-Protokoll zu missbrauchen, um bösartige Word-Dokumente (oder Excel-Arbeitsblätter) aus dem Web herunterzuladen. Ich hatte diesen Sachverhalt im Blog-Beitrag Follina: Angriff über Word-Dokumente und ms-msdt-Protokoll (CVE-2022-30190) erwähnt. Nachfolgender Tweet zeigt eine Übersicht, welche Office-Versionen angeblich angreifbar sind und welche nicht – wobei die Aussagen (z.B. zu Office 2021) den Ausführungen von Sicherheitsforscher Kevin Beaumont, die ich in meinem obigen Artikel zitiere, wiedersprechen. Ich gehe davon aus, dass im Zweifel alle Office-Versionen angreifbar sind.
Microsoft hat inzwischen ein Support-Dokument Guidance for CVE-2022-30190 Microsoft Support Diagnostic Tool Vulnerability für CVE-2022-30190 herausgegeben. Dort gibt es auch einige Diskussionen im Hinblick auf die Abschwächung der Schwachstelle. Zudem erkennt der Microsoft Defender ab der Build 1.367.719.0 oder neuer über seine Signaturdateien solche Angriffe.
Die Schwachstelle wird ausgenutzt
Microsoft hat in einem per Mail verteilten Security Advisory zu CVE-2022-30190 darauf hingewiesen, dass diese Schwachstelle bereits ausgenutzt werde. Arstechnica weist in diesem Artikel darauf hin, dass diese Schwachstelle seit sieben Wochen ausgenutzt wird, wie die Sicherheitsforscher von Shadow Chaser entdeckt haben.
Anzeige
Sicherheitsforscher Kevin Beaumont weist in obigem Tweet auf eine Meldung von Proofpoint hin, dass chinesische APTs die Schwachstelle CVE-2022-30190 bereits aktiv ausnutzen. Die Angreifer geben sich als "Women Empowerments Desk" der Central Tibetan Administration in Angriffskampagnen Kampagnen aus und verwenden die Domain tibet-gov.web[.]app. Über eine URLs wird versucht, ein in ein ZIP-Archiv gepacktes Word-Dokument herunterzuladen. Im Dokument wird die Folloinia-Schwachstelle ausgenutzt. Beaumont hat inzwischen seinen Beitrag Follina — a Microsoft Office code execution vulnerability vom 29. Mai 2022 entsprechend ergänzt.
Sicherheitsforscher Will Dormann hat in einer Serie von Tweets nochmals die Ausnutzung der Schwachstelle analysiert und schreibt, dass das Muster der vor Monaten entdeckten MSHTML-Schwachstelle CVE-2021-40444 ähnelt. In nachfolgendem Tweet gibt er an, dass sich mit wget per PowerShell ein Redirect auf einen Exploit erzwingen lässt – es ist kein Office erforderlich.
US-CERT und BSI/CERT-Bund warnen
Das US-CERT, eine amerikanische Sicherheitsbehörde warnt laut nachfolgendem Tweet in diesem Dokument vor der Schwachstelle und empfehlen Administratoren sich mit dem Microsoft Support-Dokument Guidance for CVE-2022-30190 Microsoft Support Diagnostic Tool Vulnerability zu CVE-2022-30190 zu befassen.
Vom BSI/CERT-Bund gibt es laut nachfolgendem Tweet inzwischen diese Warnung von der Schwachstelle Follina/CVE-2022-30190. Nach dem Common Vulnerability Scoring System (CVSS) wird der Schweregrad der Sicherheitslücken auf 7.8 eingestuft (CVSSv3.1).
Frank Carius weist zudem über Twitter auf diesen Beitrag von nospamproxy.de hin, der erläutert, wie man sich über den Nospam-Proxy vor Follina schützen kann.
Ergänzung: Ein Video mit einer Demo des PoC findet sich hier. Eine Aufstellung der Zeitleiste findet sich in diesem Tweet sowie bei Fortinet in diesem Beitrag.
Ergänzung 2: Beachtet die folgende Link-Liste, wo weitere Artikel nachgetragen wurden – das Thema entwickelt sich dynamisch.
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)
Anzeige
Danke für die weiterführenden Infos.
Mir ist die Schwachstelle zu heiß, deshalb habe ich den RegKey per GPP gelöscht.
Ich habe die Regkeys (es sind 2, siehe s.kanthaks Beitrag) nicht gelöscht, sondern den Zweig aufgeklappt, und den Command-Eintrag von msdt.exe auf notepad.exe geändert. Außerdem gibts noch einen GPO-Eintrag, mit dem man das Diagnosetool ausschalten kann (alternativ auch per Reg-Key) und dann ist msdt.exe im Applocker auf deny gestellt. Fertig. Funzt einwandfrei.
auch von mir ein herzliches Dankeschön!
den genannten Schlüssel habe ich auf meinem Rechner gefunden und entfernt. Aber bei einem anderes System, ein RDP-Server, den ich betreue, ist der Schlüssel nicht vorhanden und ich frage mich ob ich die Funktion versehentlich mit einer Richtlinie deaktiviert habe… ich habe mal gesucht und der einzige Eintrag, der dazu passen könnte ist 'Windows-Fehlerberichterstattung deaktivieren'. Installiert ist in allen Fällen Office365 im current channel und auf dem aktuellen Stand
'Telemetrie zulassen' steht auf dem kleinsten Wert '0', das sollen andere machen.
Hallo Robert, ich habe leider keine Antwort, aber stehe vor der gleichen Frage. Ich schaue gerade diverse Systeme durch und kann den Key bisher auf keinem Terminalserver finden.
Hallo Zusammen!
Ich habe auch festgestellt, dass der ms-msdt KEY auf keinem Terminalserver zu finden ist.
Nun habe ich Stichprobenartig weiter gesucht und konnte den Eintrag auf keinen Server bisher finden…
Kann es sein, dass der Eintrag generell nicht auf Servern existiert? Hat das noch Jemand einmal geprüft?
Gruß
Stefan
Den Key habe ich auf Win10 21H2 auch nicht, aber einen extra Registry key gesetzt.
Schauen Sie doch später nochmal hier rein, falls Herr Born meinen diesbzgl. Kommentar mit Key und Quelle freischaltet.
Mich würde interessieren ob das deaktivieren von MSDT per GPO das Problem ebenfalls sicher mitigiert. Laut einigen Twitter Posts soll das wohl der Fall sein aber dann frage ich mich warum MS das nicht kommuniziert :/
https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.ScriptedDiagnostics::ScriptedDiagnosticsExecutionPolicy
Das wäre im Enterprise Umfeld wesentlich besser umsetzbar als regkeys zu löschen…
Vom Bauchgefühl her würde ich die MSDT per GPO erst einmal deaktivieren – hilft ja auch in den Fällen, wo der Registrierungsschlüssel nicht gefunden wird. Das Ganze Thema ist aber ein wandelndes Ziel, was sich gerade entwickelt. Ich denke, das MSRT untersucht gerade und ist noch am Schwimmen – das gesamte Ausmaß ist imho noch nicht absehbar.
Was gut ist: Zumindest der Defender hat Signaturen, um bestimmte Angriffe zu erkennen – und es gibt bereits Regeln, um Angriffe in SIEM-Systemen zu erkennen und zu blockieren.
Hallo,
habe mir von hier https://github.com/chvancooten/follina.py Test runtergeladen und probiert.
Word Document geöffnet .. er läd aber die Problembehandlung geht dann nicht auf weil wegen Richtlinie nicht erlaubt.
Verschiedene Versuche waren ohne Erfolg, zum Glück.
NoSpamProxy erkennt über Cyren auch div. Testläufe von mir.
Ein Test ausgehend einer solchen Mail mit diesem Anhang, verweigerte schon der Exchange Server mit seinem Schadstoffilter.
Frank: Danke für die Tests und Ergänzungen.
…damit Andere nicht erst suchen müssen:
cmd.exe als Administrator, dort diesen Befehl ausführen (ohne »«):
»reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\ScriptedDiagnostics" /t REG_DWORD /v EnableDiagnostics /d 0«
Quelle: Den Links aus dem Bornblog gefolgt bis zu https://www.pwndefend.com/2022/05/30/office-microsoft-support-diagnostic-tool-msdt-vulnerability-follina/
Danke sehr!
Kleine Ergänzung,
…EnableDiagnostics /d 0
das letzte Zeichen ist völlig richtig eine 0 (Null, sieht hier eher aus wie ein Oh)
Was in allen Berichten der Sicherheitsforscher, Medien und Microsoft selbst bislang nicht nachvollziehbar erläutert wurde – was konkret passiert hier?
In welcher Form muss das entsprechende Office-File manipuliert sein? Makros? Doch wohl nicht. Oder doch? Wie genau setzt sich der schädliche Prozess denn in Gang? Es muss doch vermutlich eine Payload heruntergeladen werden nach Aktivierung des manipulierten Dokuments. Ausführbare Daten sollten generell geblockt werden. Diese Gefahr ist also gebannt in fast jedem System. Nun liest man, auch die Powershell kann vom Angreifer genutzt werden? Wie kann das vom Angreifer initialisiert werden?
Wenn Du den Tweets von Will Dormann und Kevin Beaumonts folgst, wird der Angriffsvektor klar. Hatte die Nacht auch einen Tweet gesehen, wo jemand so was wie einen Exploit-Generator für die Word-Files für Tests erstellt hat – finde diesen aber nicht mehr (vermutlich zurückgezogen).
Von Huntress gibt es eine detaillierte technische Beschreibung.
Ein POC-Beispiel findet man auf GitHub
Ansonsten: Palo Alto Unit 42 Artikel oder Tenable.
Irgendwie leicht zu finden – sehe hier im Blog aber eher nicht die Notwendigkeit die Exploits im Detail zu analysieren, sondern eher:
– Das Problem benennen und die Maßnahmen zur Abschwächung des Problems zu benennen
– bzw. durch Moderation der Antworten von Administratoren,
– ggf. als Zusammenfassung in weiteren Artikeln aufzubereiten.
Aber vielleicht wird das von der Leserschaft anders gesehen (meine Erfahrung ist aber, dass Artikel, wo ich Details zu so was ausgrabe, eher weniger oft abgerufen werden – lohnt also den Aufwand nicht).
Danke für die Hinweise. Ich habe mittlerweile ein erklärendes Video gefunden und es folgendermaßen verstanden: Nein, es handelt sich nicht um Makro. Das manipulierte Office-Dokument initialisiert bei Ausführung ein extern bezogenes HTML-File, das wiederum Code enthalten kann, der auf dem Zielsystem zur Ausführung gelangt unter Ausnutzung der beschriebenen MS-Sicherheitslücke. Darunter können sich auch Kommandozeilen für Webshell-Befehle befinden und das System gefährden…
… als GPO habe ich
Computer \ Richtlinien \ Administrative Vorlagen \ System \ Problembehandlung und Diagnose /Skriptdiagnose
Deaktivieren von:
# Problembehandlung: Benutzerzugriff auf Onlineinhalt zur Problembehandlung auf Microsoft-Servern über die Systemsteuerung für die Problembehandlung zulassen (über den Windows-Problembehandlungs-Onlinedienst)
# Problembehandlung: Zugriff und Ausführung von Problembehandlungs-Assistenten durch Benutzer zulassen
Habt Ihr noch andere Einträge gesetzt?
Ich habe "Problembehandlung: Zugriff und Ausführung von Problembehandlungs-Assistenten durch Benutzer zulassen" deaktiviert.
danke für die Übersetzung ;-)
mit einem Filter auf 'diagcab' habe ich das später auch gefunden…
Vergesst nicht, die Policies zu testen mit: Start, Ausführen, ms-msdt://hallo
Hmm guter Tipp, bei usn kommt da die UAC hoch und will admin rechte.. ist der Exploit nur als Admin ausnutzbar?
Wenn der Internet Explorer als Standardbrowser festgelegt ist erhalte ich als nicht privilegierter Standardbenutzer ebenfalls einen UAC Dialog. Ändere ich dies auf Edge Chromium oder Google Chrome ab, dann entfällt UAC und der Exploit wird ohne weitere Benutzerinteraktion ausgeführt.
Kann ich nicht bestätigen, hier per GPO überall Edge als Standard. Dennoch kommt die UAC hoch.
Frage in die Runde:
Ein Blocken der executable über entsprechende AV Software, wäre doch auch ein gangbarer Weg?
Vorteil: Es erfolgt ein Logging im Bereich der Sicherheitsdienste und die Betreuer der Sicherheitsdienste bekommen das auch relativ schnell und ohne Umwege mit.
Aus dem Bauch würde ich sagen es schadet zumindest nicht, ich habe sie über die SRP geblockt. Wirklich sicher ob man sie dann über Umwege nicht doch noch aufrufen kann bin ich mir aber nicht.
Hallo Marc, davon bin ich ganz schwer überzeugt und habe anstatt dessen via GPO überall mit einer Softwarerestriction Pfadregel msdt.exe blockiert.
Das funktioniert wunderbar.
Wer sollte sich denn nun sonst um die Protokollverarbeitung kümmern?
Und wenn man unbedingt diesen halbgaren Registry-Löschversuchen nachgehen möchte, sollte man lieber sauber und korrekt an ZWEI Stellen ÜBERSCHREIBEN anstatt zu LÖSCHEN, also z.B. statt msdt.exe notepad.exe einsetzen, dann kriegt man auch gleich einen Angriff mit ;)
SO:
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ms-msdt\shell\open\command" /ve /t REG_EXPAND_SZ /d "notepad.exe" /f
reg add "HKEY_CURRENT_USER\SOFTWARE\Classes\ms-msdt\shell\open\command" /ve /t REG_EXPAND_SZ /d "notepad.exe" /f
Testen kann man das alles mit: Start, Ausführen, ms-msdt://hallo
Und Deinen "Sicherheitsteams" könntest Du auch mit einem (anstatt notepad.exe) darüber eingeklinkten Skript informieren, welches die Kommandozeilenparameter gleich mit dazu mailt ;)
Das Blocken über die AV Lösung ist aktuell unsere Variante. Im Lab haben wir heute nachmittag noch Tests bzgl. Applocker gemacht. Das war sehr positiv. Vor allem die grandiosen Möglichkeiten per Applocker sind einfach very, very cool!
Ich weiß jetzt nicht wie es bei Softwarerestriction ist; Applocker schreibt schön sauber ins EventLog rein. Die entsprechenden Events, können wir dann über ein anderes System abgrasen und in ein separates Log schreiben, welches von unserem Monitoring System überwacht wird. Dort haben wir dann alles gesammelt und können die Meldungen bequem über verschiedene Wege rausgeben. So bekommt man es auch mit, sobald etwas geblockt ist. Es ist zwar schön wenn man sicher ist, aber noch besser fühle ich mich, wenn ich weiß, bei welchem Gerät und bei welchem User so etwas aufgetreten ist. Vor allem wenns sich mal wiederholen sollte…. Sowas solls ja auch geben.
Danke für den Austausch!
Hi, SoftwarerestrictionPolicies werden nicht mehr "weiter entwickelt", sie sind markiert als "Deprecated". Allerdings werden sie sie nicht einstampfen, weil es sich um sicherheitsrelevante Policies handelt.
Sie möchten, dass man die Anforderungen mit Applocker konfiguriert.
Allerdings wird der Applocker nur von Edu/Enterprise verarbeitet, aber nicht von Pro!
Falls das für genau dieses konkrete Konfigurationsdetail anders sein sollte und Ihr im Labor die Blockade bei einem Pro-Client seht, korrigiere mich bitte!!
Ich habe an eigenen Systemem zum Spaß bei "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ms-msdt\shell\open\command" folgendes eingetragen und werde das nun auch bei "search-ms" tun und auf Nebenwirkungen prüfen: "%SystemRoot%\system32\cmd.exe" /k "echo.The Troubleshooter functionality ist currently disabled.&echo.If you see this without having started anything, someone may have tried to hack you.&echo.However, probably no harm was done yet.&echo.Please inform your admin and do not touch anything.&pause"
Nein, stimmt so.
Applocker hatte ich vor Jahren getestet, aber wegen der Pro Clients doch auf die SRP gesetzt. Applocker ist auf jeden Fall mächtiger, die SRP haben dann mit vermutlich mehr Arbeit aber ein für mich gutes Ergebnis gebracht.
Ich hatte ursprünglich bei uns SRP umgesetzt, und als wir uns dann endlich zu Enterprise durchgerungen habe, habe ich auch Applocker aktiviert, erstmal quasi mit den gleichen Regeln wie SRP, aber Applocker ist inzwischen 1000 mal ausgefeilter. SRP ist aber noch aktiv, für die Übergangszeit, wenn ein System neu im AD ist, und die Lizenz noch nicht in Enterprise umgewandelt wurde.
Zwei Dumme, gleicher Gedanke, auch ich habe das Command durch Notepad ersetzt!
Nach meinen Tests lässt sich ms-msdt auch nur ausführen, wenn man lokale Admin-Rechte besitzt. Auch ein Ansatzpunkt…
Falls in deinem Testsetup IE als Standardbrowser konfiguriert sein sollte, ändere dies mal ab und teste erneut.
Noch eine leicht reversible Variante den Start des MSDT zu unterbinden:
reg.exe ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\msdt.exe" /v "Debugger" /d "%SystemRoot%\System32\taskkill.exe" /t REG_SZ /f
ja, die methode finde ich auch gut, besonders um super temporär und unterbrechungsfrei unerwünschte eingebettete setup-komponenten zu unterdrücken. sehr effektiv und ortsunabhängig, würde hier auch gut passen, aber mit einem kleinen restrisiko für malware detection. so, dann mal sehen, mit welchen neuen späßchen dieser spuk in 2 wochen durch das cumulative update ausgetauscht wird…
Hier etwas zum gezielten Blockieren einzelner Preview Handler für RTF Dateien. Es empfiehlt sich in seiner jeweiligen Umgebung zu prüfen, ob die GUIDS ggf. abweichen. Diese lassen sich z.B. mit dem Tool "ShellEx View" von Nirsoft anzeigen.
Blockiert Preview Handler "Microsoft Word" (welcher für RFT Dateien eingetragen wird, wenn Office installiert ist):
reg ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked" /v "{84F66100-FF7C-4fb4-B0C0-02CD7FB668FE}" /t REG_SZ /f
Blockiert Preview Handler "Windows RTF Previewer" – nur um sicher zu gehen:
reg ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Blocked" /v "{a42c2ccb-67d3-46fa-abe6-7d2f3488c7a3}" /t REG_SZ /f
Bei all den vielen kreativen Lösungen;
Sobald Eure Lösung aktiv greift, solltet ihr eine Info haben. Ob Logfile, Email, whatever. Alleine schon um zu wissen, welcher Bereich oder welche MA ggf eine Auffrischung im Kontext IT-Sicherheit benötigen + X
Hi Marc, wie Du sicher schon gesehen hast, gehts jetzt wie erwartet mit search-ms los. Ich habe hier noch meine obige cmd+echo Kreativlösung drin und man musste zusätzlich den DelegateExecute Eintrag löschen/umbenennen. Ich schreibe das hier nur, weil man an der Stelle schlecht die AV-Lösung und Softwarerestriction-Lösung gegen explorer.exe ansetzen kann. Hoffentlich gehen die zukünftigen Löschvorschläge in Zukunft auf HKCU\Software\Classes und HKLM\Software\Classes ein und nicht schlampigerweise auf deren Overlay HKCR.
Hi Leute,
und was ist jetzt mit dem Zeugs hier – muss da auch gemacht werden, oder reicht die GPO Geschichte "Problembehandlung: Zugriff und Ausführung von Problembehandlungs-Assistenten durch Benutzer zulassen"?
Microsoft gibt Tipps, die vor Follina schützen sollen. User sollen das MSDT-URL-Protokoll deaktivieren, indem sie die Eingabeaufforderung als Administrator starten und mit zwei Befehlen den Registrierungsschlüssel sichern und anschließend löschen.
reg export HKEY_CLASSES_ROOT\ms-msdt filename
reg delete HKEY_CLASSES_ROOT\ms-msdt /f
Thx
cu
Wolfgang
Wichtige Info, per GPO lässt sich die Sicherheitslücke NICHT schließen.
Microsoft hat dazu endlich Infos publiziert:
https://web.archive.org/web/20230130212546/https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/
Nur das Microsoft von zwei völlig anderen GPO Einstellungen schreibt, als die, die von anderen Experten empfohlen wurde und tatsächlich auch den MSDT deaktiviert.
Ich habe mal den Text, der die Nacht "in a hurry" entstand, noch etwas überarbeitet und erweitert. Ob die angesprochene Richtlinie zum Deaktivieren der Diagnose ausreicht, vermag ich aktuell nicht zu beurteilen.
Da es um MS geht könnte ich das auch nicht mit absoluter Sicherheit beurteilen, aber wenn man versucht es per MSDT aufzurufen, dann erscheint die Meldung, dass es per Gruppenrichtlinie deaktiviert wurde.