[English]Nach der Entdeckung des Missbrauchs der Follina-Schwachstelle (CVE-2022-30190) über das Windows ms-msdt-Protokolls wird diese Bastion "sturmreif" geschossen. Ein Hacker hat sich den search-ms: URI Handler in Windows 10 angesehen und einen ähnlichen Exploit wie Follina entwickelt. Unter Zuhilfenahme von Office 2019 kann er die Windows-Suche über den Protokoll-Handler öffnen. Kollegen von Bleeping Computer haben bereits den Begriff SearchNightmare für diesen 0-day Exploit geprägt.
Anzeige
Auf Facebook wurde ich in einer privaten Nachricht auf den nachfolgenden Tweet von hackerfantastic.crypto hingewiesen. Er konnte unter Windows 10 mit Hilfe von Microsoft Office 2019 den search-ms: URI-Handler aufrufen und so SYSTEM-Rechte erlangen.
Die neue Zero-Day-Schwachstelle in der Windows-Suche kann verwendet werden, um durch den Start eines Word-Dokuments automatisch ein Suchfenster zu öffnen, in dem ferngesteuerte Malware ausgeführt werden kann. Das ist quasi ein ähnlicher Angriff wie über das Windows ms-msdt-Protokoll (Follina-Schwachstelle CVE-2022-30190). Denn Matthew Hickey hat einen modifizierten Exploits verwendet, der die Microsoft Office OLEObject-Schwachstelle mit dem Windows search-ms-Protokoll-Handler verkettet.
Der URI-Protokoll-Handler search-ms ermöglicht es Anwendungen und HTML-Links benutzerdefinierte Suchen auf einem Gerät zu starten. So lässt sich über den Exploit das Fenster der Windows-Suche öffnen, oder die Dateien auf Remote-Freigaben auflisten, indem ein Word-Dokument geöffnet wird. Die Kollegen von Bleeping Computer weisen hier darauf hin, das auch externe URLs in die Suche einbezogen werden können. Dies Sysinternals-Tools können über nachfolgenden Befehl von live.sysinternals.com als Netzwerkfreigabe gemountet werden, um Dienstprogramme zu starten. Um diese entfernte Freigabe zu durchsuchen und nur Dateien aufzulisten, die einem bestimmten Namen entsprechen, könnten Sie den folgenden "search-ms"-URI verwenden:
search-ms:query=proc&crumb=location:%5C%5Clive.sysinternals.com&displayname=Searching%20Sysinternals
Das Ganze funktioniert in Windows 7 SP1 bis hin zu Windows 11. Ein Angreifer könnte diesen Ansatz für böswillige Aktionen verwenden und beispielsweise in Phishing-E-Mails angebliche Sicherheitsupdates über search-ms-URI verlinken. Über die Links ließe sich dann eine Remote-Windows-Freigabe einrichten, über die als Sicherheitsupdates getarnter Malware gehostet wird.
Bedrohungsakteure können diese Methode nutzen, um ausgeklügelte Phishing-Kampagnen zu erstellen. Bei den Kampagnen werden Windows-Freigaben öffentlich gehostet. Dann ließe sich die Malware über die Windows-Suchfenster, die durch Phishing-Angriffe/schädliche Word-Dokumente geöffnet werden, remote verbreiten. Der Benutzer muss dann zwar den Link anklicken und die angezeigte Warnung beim Öffnen der Suche bestätigen (siehe Bild in folgendem Tweet).
Der Hacker gibt in nachfolgendem Tweet seine Schritte zur Abschwächung des Angriffswegs an:
Anzeige
1. Führen Sie die Eingabeaufforderung als Administrator aus.
2. Um den Registrierungsschlüssel zu sichern, führen Sie den Befehl "reg export HKEY_CLASSES_ROOT\search-ms filename" aus.
3. Führen Sie den Befehl "reg delete HKEY_CLASSES_ROOT\search-ms /f" aus
Die Schrittfolge entfernen den Eintrag für den search-ms URI-Protokoll-Händler aus der Registrierung. Wie auch bereits im Beitrag Follina: Angriff über Word-Dokumente und ms-msdt-Protokoll (CVE-2022-30190) angesprochen, reicht das Entfernen des Schlüssels nicht, um die Schwachstelle zu beseitigen. Der Protokoll-Handler könnte auch noch in anderen Registrierungszweigen (HKCU, HKLM) eingetragen sind.
Die Analyse und Abschwächung der Schwachstelle durch Sicherheitsforscher wird noch einige Erkenntnisse zu Tage fördern. Die Kollegen von Bleeping Computer haben hier einige Informationen dazu veröffentlicht. Benjamin Altpeter von der TU-Braunschweig hat bereits 2020 in in seiner Dissertation über die Sicherheit von Elektron-Anwendungen die beiden Schwachstellen mit ms-msdt-Protokoll und im search-m URI-Handler beschrieben.
Ähnliche Artikel:
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
2015
Guten Morgen,
gibts hier auch ne GPO Möglichkeit?
Oder ist, sofern tatsächlich nur Office 2019 betroffen, das System soweit sicher, wenn man z.B. Office 2013 nutzt?
Besten Dank und einen schönen Donnerstag
Sebastian
Du bist zu früh mit deinen Fragen – mir ist ad hoc unklar, was da ausgeführt wird – die Suche wird man aber per GPO nicht abdrehen wollen. Zudem sollte davon ausgegangen werden, dass alle Office-Versionen – und ich tippe auch mal wget aus der PowerShell – ausgenutzt werden kann.
Ergänzung: Bevor jemand mit dem folgenden Registrierungseintrag kommt – es scheint nicht zu helfen.
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windows Search]
"DisableWebSearch"=dword:00000001
Und das ist vermutlich nicht das Ende der Fahnenstange. Nachdem die ms-msdt-Protokollschwachstelle (Follina) bekannt wurde, gab es sofort die Vermutung, dass weitere Protokollhandler ebenfalls angreifbar wären. Der ms-search 0-day ist nur der Anfang.
Abhilfe? Goto Linux or macOS
Ist aber schon bekannt, dass in der Liste der Sicherheitslücken bei Linux aktuell mehr aufgelistet werden, als für Microsoft? Da kommst du vom Regen in die Traufe ;-)
Dass entsprechende Sicherheitslücken in Linux vorhanden sind, ist bekannt. Ich stufe das aber als weniger kritisch im Vergleich zur Black-Box Windows mit seiner Cloud-Orientierung ein (mag mich aber täuschen). Es ist schon bezeichnend, was uns in den letzten 2-3 Jahren an prinziellen Fehler und Patch-Problemen arg auf die Füße gefallen ist.
Das ist ja klar, denn bezüglich Linux wird nicht nur das Betriebssystem bewertet, sondern so gut wie alle vorhandenen Pakete.
"Abhilfe? Goto Linux or macOS" Wenn das so einfach wäre. Ich plage mich seit einem Jahr mit der Integration von MacOS ins Unternehmensnetzwerk mittels Jamf Pro. Aktuell geht das Drucken aus MacOS nicht. Extrem viele Fachanwendungen gibt es gar nicht und und und. Dabei wäre ich sofort für die Entwicklung einer Alternative zu Windows und Office. Es ist leider keine Abhilfe…
Ich würde eher davon ausgehen dass es nach unten hin schlimmer wird als besser.
Nicht wirklich elegent, aber ich habe den Eintrag per GPO gelöscht.
Löschen ist blöd, nach Patch der Lücke muss man den Ursprungszustand evtl. wieder her stellen weil sich irgendein User beschwert, dass irgendwas nicht funktioniert. Besser ist den Aufruf vorerst mal zu ersetzen, sprich aus dem gestrigen Beispiel in der Registry msdt.exe ein calc.exe oder Notepad.exe zu machen.
Vorher in Backup von RegKey erstellen. Der kann bei Bedarf dann per GPO bzw. GPP wiederhergestellt werden.
Oder for dem löschen exportieren. Dann kann er bei Bedarf zu einem späteren Zeitpunkt einfach wieder importiert werden.
Am Beispiel von MS-MSDT:
IF NOT EXIST C:\Programdata\Reg_Export MB C:\Programdata\Reg_Export
reg export HKEY_CLASSES_ROOT\ms-msdt C:\Programdata\Reg_Export\MS-MSDT__Backup.reg /y
reg delete HKEY_CLASSES_ROOT\ms-msdt /f
regedit /s C:\Programdata\Reg_Export\MS-MSDT__Backup.reg
Moin 1ST1, ich habe je wie erwähnt seit Gestern ein cmd+echo&pause drin. Man kann ja auch einen salonfähigen Powershell-Messagebox-Oneliner reinsetzen oder einen Mailer. Wie üblich muss ich dran erinnern, dass man nicht platt an HKCR ran geht sondern immer simultan an HKCU\Software\Classes und HKLM\Software\Classes. Via GPP also im Machine und User Branch. Anstatt eine Regdatei zu exportieren mache ich lieber ein reg copy nach search-ms-backup.
Diesmal ist es explorer.exe, den kann man nicht so schön global blockieren wie msdt.exe…
Habt ihr tatsächlich einmal ein ms-msdt unter HKCU oder HKLM gefunden?
In HKLM auf jeder Maschine bis auf einen Terminalserver mit Office 2013.
reicht es nicht den Schlüssel umzubenennen?
#disabled.ms-msdt
Dies hat den Vorteil, dass diese Aktion auch in der 'Datenbank' steht.
Bei Heise wird im Forum auch gesagt, dass man in der Windows-Firewall winword.exe blockieren kann für ausgehenden Traffic …
wäre das ggf. auch eine Lösung?
Sebastian
Würde es auch alternativ helfen den Windows Suchdienst zu stoppen und zu deaktivieren?
Da es bei der Suche nach IOC zur Eingrenzung des Zeitraums relevant ist: dass man das 'search-ms' Protokoll auf diese Weise zweckentfremden kann muss schon länger bekannt sein. In dieser Bachelorarbeit von August 2020 wird bereits auf msdt.exe und search-ms eingegangen: https://benjamin-altpeter.de/doc/thesis-electron.pdf (Seite 29)
Ich hab im HKCR Reg Schlüssel die calc.exe anstatt explorer.exe eingesetzt, dennoch öffnet sich der Explorer wenn ich über Ausführen folgenden Befehl absetze: search-ms:query=proc&crumb=location:c:
Der Pfad zur calc.exe stimmt („%systemroot%\system32\calc.exe")
Jemand eine Idee woran das liegt oder übersehe ich etwas? Die Änderung steht im Standardwert im Ordner Command.
Konnte es lösen indem ich den Wert "DelegateExecute" entfernt habe. Jetzt startet Notepad beim Aufruf des Befehls.
@nk, also erstmal geht man nicht zu hkcr, sondern zu hklm\software\classes.
(hkcr ist ein overlay aus hklm\software\classes und hkcu\software\classes.)
dann ist der unterschied bei search-ms zu ms-msdt, dass dort ein wert "DelegateExecute" ist, den du z.b. zu "_DelegateExecute" umbenennen könntest.
dann funktioniert die umleitung und du kannst sie testen mit start, ausführen, search-ms://hallo.
Merci!
Wie schaut es es mit der Klasse "search" also ohne "-ms" aus? Diese ist in meinen Augen identisch angelegt und kann auch mit search:query=proc&crumb=location:c: angesprochen werden???
Super Hinweis. Du hast recht. Muss auch gelöscht werden, da das Ziel am ende das gleiche ist. Eigentlich müsste man den eventDelegate blockieren.
Und ich frage mich ob man mit einer präparierten ".search-ms"-Datei als Download das gleiche erreichen könnte. 🤔
haha, ja, super, das ist wie mit bloßen händen fließendes wasser aufhalten.
(eigentlich nix neues in dem umfeld)
hier sind die drei treffer, wer gern um sich schlagen möchte :)
HKLM\SOFTWARE\Classes\Explorer.AssocProtocol.search-ms\shell\open\command
HKLM\SOFTWARE\Classes\search\shell\open\command
HKLM\SOFTWARE\Classes\search-ms\shell\open\command
Habe ich das richtig verstanden, dass das nur mit Office 2019 funktioniert ?!
Danke und Grüße,
MG
Interessanterweise schmiert bei Windows 11 22H2 (BETA) die Explorer.exe schon ab, wenn man mit Ausführen nur search-ms://hallo startet *LOL*
folgendes funktioniert aber…
search:query=proc&crumb=location:c:
Moin,
ich verstehe die Aufregung um dieses Thema nicht.
Meiner Meinung nach ist es nichtmal ne Lücke. Klar es sollte nicht möglich sein durch das öffnen eines Word Dokumentes eine Windows Suche zu starten.
Aber das diese Suche wiederrum auf Servern im Internet suchen kann ist ein Feature und keine Lücke. Und es ist auch nicht möglich die bei der Suche gefunden Dateien automatisch zu öffnen. Von daher auch keine kritische Lücke.
Admin oder System Rechte kann man sich damit auch nicht erschleichen – es sei denn es wird mit anderen richtigen kritischen Lücken kombiniert.
Und außerdem prüft der AV die bei der Suche gefundende Datei auch sofern man diese öffnen sollte.
Moin Mario,
Web-Ergebnisse haben in der Windows-Suche (mMn) auch nichts verloren, zumindest nicht im Enterprise-Umfeld. Daher bin ich bei Dir.
Danke für Deinen Kommentar.
Steht doch oben im Text:
Auf Facebook wurde ich in einer privaten Nachricht auf den nachfolgenden Tweet von hackerfantastic.crypto hingewiesen. Er konnte unter Windows 10 mit Hilfe von Microsoft Office 2019 den search-ms: URI-Handler aufrufen und so SYSTEM-Rechte erlangen.
Also entweder vertrauen wir der Aussage, dass jemand diese Schwachstelle schon ausnutzen konnte oder wir fragen uns, wie genau search-ms mit Systemrechten schlimme Dinge machen kann.
Bei ms-msdt war es ja offenbar auch möglich, obwohl das Tool eigenltich auch nur Hilfeinformationen anzeigen soll.
Ja es steht oben im Text. Doch wenn man sich mal das verlinkte Video/Gif anschaut sieht man das nachdem die Suche gestartet wurde eine Exe gefunden wird. Diese wird aber absichtlich händisch gestartet. Und ab dem Zeitpunkt hat das nichts mehr mit dieser Lücke zu tun.
Jemanden dazu zu verleiten eine verseuchte Datei zu öffnen hat meiner Meinung nach nichts mit Hacken zu tun.
mMn sollte die Policy-Settings zu Search dahin gehend angepasst sein, dass Web-Ergebnisse nicht in die Suche eingebunden werden können.
Dieses Setting hat zur Folge, dass die Ausführung von der oben aufgeführten Query ins Leere läuft.