[English]Vor einigen Tagen hat Microsoft einen Sicherheitshinweis zur Schwachstelle CVE-2021-40444 in der in Windows enthaltenen MSHTML-Komponente offen gelegt. Es hieß, es gebe den Versuch, die Schwachstelle in freier Wildbahn über präparierte Office-Dokumente auszunutzen. Aber Office-Nutzer seien eigentlich durch die geschützte Ansicht vor dieser Bedrohung geschützt. Nun wird bekannt, dass dieser Schutz löchrig ist und oft nicht wirkt.
Anzeige
In diesem Sicherheitshinweis warnt Microsoft vor gezielten Angriffen über speziell gestalteter Microsoft Office-Dokumente, die in freier Wildbahn beobachtet wurden (siehe diesen Tweet). Bei den Angriffen wird versucht, die RCE-Schwachstelle CVE-2021-40444 in der Windows-Komponente MSHTML auszunutzen. Erfolgreiche Angreifer können dann Remote Code ausführen. Ich hatte im Blog-Beitrag Angriff über Office-Dokumente auf Microsoft MSHTML (ActiveX) RCE-Schwachstelle (CVE-2021-40444) darüber berichtet. Microsoft schreibt in seinem Sicherheitshinweis, dass Office-Dokumente ja standardmäßig im geschützten Modus geöffnet würden – der Angriff läuft dann ins Leere. Inzwischen warnt auch das BSI vor dieser Sicherheitslücke.
Geschützter Modus ausgehebelt
Sicherheitsforscher Will Dormann hat sich die Schwachstelle vorgenommen und mal mit RTF-Dateien getestet. Das Ganze hat er in nachfolgendem Tweet mit einem Video und Folge-Tweets dokumentiert.
Anzeige
Die Kollegen von Bleeping Computer hatten bei Will Dormann, Schwachstellenanalyst des CERT/CC, nachgefragt, wie die Funktion "Geschützte Ansicht" die Schwachstelle entschärft. Dormann wies darauf hin, dass die Benutzer in der Vergangenheit regelmäßig solche Schutzmechanismen umgingen und den Schutz über die Schaltfläche "Bearbeitung aktivieren" deaktivieren.
Zudem lässt sich das MoTW-Flag, welches aus dem Internet heruntergeladene Dateien kennzeichnet und die geschützte Ansicht bewirkt, austricksen. Befindet sich das Dokument in einem Container, der von einem Programm verarbeitet wird, das nicht MoTW-fähig ist, wirkt der Schutz nicht mehr. Öffnet der Benutzer z. B. ein 7-Zip Archiv, welches aus dem Internet stammt, geht diese Information über das MotW-Flag verloren. Die geschützte Ansicht wird durch Office beim Laden nicht mehr verwendet. Es gibt weitere Fälle (wie ISO-Dateien), wo der Schutzmechanismus versagt.
Zudem entdeckte Dormann, dass die geschützte Ansicht (Protected View) bei RTF-Dateien nicht wirkt, und stuft die Angriffsmöglichkeiten gefährlicher als Makros ein. Denn es kann Code durch einfaches Öffnen einer Office-Dokumentdatei ausgeführt werden.
Microsoft hat zwar Maßnahmen wie dass Blockieren neuer ActiveX-Steuerelemente zur Installation und Ausführung im Internet Explorer vorgeschlagen. Sicherheitsforscher Kevin Beaumont hat aber bereits eine Möglichkeit entdeckt, die aktuellen Schutzmaßnahme von Microsoft zu umgehen, und diese Sicherheitslücke auszunutzen. So stört sich die Vorschau im Explorer nicht an dem MoTW-Flag und die geschützte Ansicht ist wirkungslos.
Ergänzung: Inzwischen hat Microsoft den Text seines Sicherheitshinweises zu CVE-2021-40444 ergänzt. Es finden sich Hinweise, um die Dateitypenzuordnungen für Word-Dateien aus der Registrierung auszutragen, so dass Explorer-Vorschau und RTF-Dateityp nicht mehr per Doppelklick geöffnet werden können. Beachtet auch die Kommentare unten – so wäre es denkbar, die Vorschau per GPO im Explorer zu deaktivieren. Die Holzhammer-Methode bestände darin die MSHTML.dll-Dateien umzubenennen – nur weiß ich nicht, was dann alles unter Windows klemmt.
Die Schwachstelle wird seit einigen Tagen aktiv ausgenutzt, wie Beaumont hier mitteilt. Details sind in den Tweets sowie bei Bleeping Computer zu finden.
Ähnliche Artikel:
Angriff über Office-Dokumente auf Microsoft MSHTML (ActiveX) RCE-Schwachstelle (CVE-2021-40444)
MSHTML-Schwachstelle CVE-2021-40444 kritischer als bekannt
Desaster Windows MSHTML-Schwachstelle CVE-2021-40444, hoffentlich kommt heute ein Patch
Anzeige
"Es finden sich Hinweise, um die Dateitypenzuordnungen für Word-Dateien aus der Registrierung auszutragen, so dass Explorer-Vorschau und RTF-Dateityp nicht mehr per Doppelklick geöffnet werden können."
Echt jetzt? Was kommt als nächstes? Ein Eintrag in den Autostart, welcher den PC sofort nach dem Start wieder herunterfährt? Nicht alles was die Ausnutzung einer Lücke verhindert ist auch ein praktikabler Workaround.
Anderseits haben wir ja auch alle unsere Drucker-Spooler deaktiviert. Also, was will ich mit Word eigentlich noch?
Gruß Singlethreaded
Mails überhaupt nach gefährlichen Anhängen filtern zu müssen ist auch schon so eine Krücke, nur weil Microsoft seine Hausaufgaben seit 25 Jahre nicht macht.
naja was für einen Grund sollte es den geben "fremde Office Dokumente" direkt aus dem Browser starten zu müssen ohne diese vorher durch einen Virenscanner und ne Sandbox zu jagen? Also mir fällt da keiner ein! Selbst als Firma ist da nicht nötig! Macht man es doch ist man auch an jedweder Infektion selbst schuld!
"Fremd" bedeutet durchaus auch bekannte Absenderadressen wenn die nicht explicit vorher angefordert wurden!
Da das Ganze auch vollkommen automatisiert erfolgen kann verlierst du da auch keine Zeit, zumindest sehr sehr viel weniger als wenn du dein kompromitiertes System nachher wieder zum laufen bringen musst und sonstige Schadensbegrenzung betreiben musst.
Bequemlichkeit vs Sicherheit das leidliche Thema!
Bequemlichkeit & Dummheit die Hauptgründe für 98% der Malware da draußen.
Nen Mailanhang der ungefiltert beim Enduser aufschlägt, da gehört der verantwortliche ITler fristlos gekündigt!
Die Zeiten sind doch längst vorbei, wo man fremde Dokumente so einfach identifizieren kann. Es ist doch längst Standard, daß Malware von befallenen Arbeitsplätzen aus Mails an Kollegen und Geschäftspartnern verschickt und dabei auf echte E-Mails antwortet.
Mal abgesehen davon ist eine Vorschau oft schon dran, bevor die Entscheidung getroffen wurde, ob man dem Absender vertraut.
In einem sicheren System kann man jede Datei ohne Probleme öffnen. Ausführen ist eben nicht öffnen. Wenn man auf einem typsichen Enterprise-Linux-Desktop ein Skript oder Programmbinary anklickt, dann fragt er bestenfalls, mit welchem Editor man das öffnen will, aber führt das eben nicht einfach aus. Die Vermischung von Öffnen und Ausführen ist ein Grundübel von Windows, das schon zu Zeiten von Floppies zu Katastrophen geführt hat.
Du musst jetzt GAAAANZ stark sein: {Libre,Microsoft,Open}Office-Dokumente sind KEINE ausführbaren Dateien, sondern Daten-Dateien. Wenn diese {Python,LUA,Java,…}-Skripts bzw. "aktive" Inhalte enthalten, die das zum Öffnen missbrauchte Programm interpretiert/ausführt, stehst Du mit Deinem ach so sicher geglaubten Linux-Frickelzeux VÖLLIG bescheuert da.
JFTR: das gilt selbstverständlich auch für HTML-Dateien, deren JavaScript der Browser ausführt, PostScript-Dateien, die beispielsweise CUPS mit Ghostscript "öffnet", "gesourcte" Shell-Skripts, awk- und sed-Skripts, Installationspakete *.pkg/*.rpm/*.deb/*.apk/…,
Kurz: WEHRET DEN AHNUNGSLOSEN ANFÄNGERN!
Stephan, aus deinem Beitrag spricht leider die selbstherrliche Arroganz eines praktisch Unwissenden. Kleine Betriebe besitzen keine "ITler", sie haben gar nicht die Mittel, Fachleute zu bezahlen. Und an welche Fachleute sollten sich Privatuser wenden? Abgesehen davon sind auch viele "Fachleute" mit den aktuellen Exploits und den notwendigen vertrackten Workarounds völlig überfordert, wie man den einschlägigen Foren entnehmen kann. Ich bin mir sicher, die Mehrheit versteht auch die englischsprachigen Tutorials und Beschreibungen von Microsoft nicht.
Meinst du, ein Handwerksbetrieb oder eine Zahnarztpraxis frickelt an Registry-Einträgen rum oder weiß überhaupt, was das ist? Die haben ihre Windows-Rechner, für die Arbeitsdaten ein QNAP oder Synology und einen 1&1-Mailaccount und das alles geschützt mit Defender oder einer alternativen AV. Alles wird in der Standardconfig verwendet. Die sind verständlicherweise überfordert alleine mit der Meldung "geschützte Ansicht" nach dem Erhalt eines Worddokuments. Dann wird auf "Bearbeitungsmodus" geklickt, weil man in der geschützten Ansicht nicht einmal Drucken kann! Das ist typischer Microsoft-Wahnsinn (wobei das auch für PDF in geschützter Ansicht zutrifft). Uneindeutige Warnhinweise, deren Brisatz der Durchschnittsanwender gar nicht erfassen kann. Dann ist es dem Anwender auch möglich, mit einem Klick den rudimentären Basisschutz auszuhebeln, was er aufgrund des fehlenden Verständnisses natürlich auch tut.
Windows ist mittlerweile ein grundlegender Designfehler und eine akute Gefahr für alle Nutzer. Und nein, ich bin kein Linux-Fanboy. Ich benutze selbst diesen Windows-Murks.
Sorry, ich meine nicht Stephan sondern "Lucifer".
Naja dann bin ich damit eben arrogant, aber ich bleibe dabei: entweder man hat Ahnung von dem was man tut oder man lässt das von jemanden machen der Ahnung hat, ansonsten ist man schlichtweg selbst Schuld!
Aber bei Kundendaten wie sie bei Ärzten auftreten sorry da fehlt mir das Mitleid wenn die mit meinen Daten schlampen, das ist dann grob fahrlässig. Wenn nen Schreiner seine Daten verliert und dann keine Rechnung mehr schreiben kann ok, Pech gehabt! Gesundheitsdaten der Patienten sind aber wiederum ne andere Sache.
Sorry auch um sein EDV sauber und sicher zu halten bedarf es auch keines Studiums, nur das wollen sich mal damit zu beschäftigen! Da reichen einfache Grundregeln. Eine davon ist das man solche Daten nicht ungeprüft öffnet und wer nicht begreift was geprüft bedeutet hat an ner EDV mit Kundendaten nix zu suchen!
Wir leben in 2021 und nicht in den 1950 als das gerade Neuland war!
Ich erwarte nicht von einem Arzt das er sich mit IT auskennt, aber das er intelligent genug ist das einem Fachmann anzuvertrauen! Schließlich hat er studiert!
Leider sehe ich meinen Ärzten bzw. den Praxen aber nicht an, ob sie Fachmänner da ran gelassen haben oder nicht…
Eine Frage hätte ich dazu noch, da ich das aus den Artikeln nicht wirklich rauslesen kann.
Sind die entsprechenden office Dokumente dann mit Makros versehen oder handelt es sich dabei wirklich nur um normale office Dokumente wie *.docx die dann die schadsoftware nachladen?
Ich denke ja es ist eher zweiteres:(
Die erste Demo war wohl mit Makro und ActiveX, aber weitere Untersuchung hat gezeigt, daß es auch ohne geht. Deshalb sind auch die Workarounds wirkungslos. Es reicht sogar schon RTF, das gibt es keine Makros.
Danke!
Wir blockieren bisher sowieso schon RTF Anhänge in unsere Mail Gateway. Wir blockieren nun alle Office Dokumente und prüfen diese manuell.
Die zeitliche Verzögerung bei der Zustellung nehmen wir da gerne in kauf un die User müssen das akzeptieren. Bei uns kommen im durchschnitt so 20-30 Mails mit Office Anhängen pro Tag rein.
RTF nicht, aber die in RTF eingebetteten Objekte können Makros beinhalten und die Objekte können separat im RTF aktiviert werden vom Anwender. RTF sind und waren nie "sicherer" als DOC.
Danke für die Korrektur bzw. Präzisierung!
"die in freier Wildbahn"
was soll das eig. immer mit der "freien Wildbahn"?! Gibts auch ne unfreie – und wie wär die dann?
Das ist wohl eher ne Art sprachlicher Durchfall…
Es bedeutet, daß echte kriminelle Angreifer solche Dateien herumschicken und nicht nur Forscher.
Nur den Downloads-Ordner mit so einer RTF drin zu öffnen reicht:
https://twitter.com/jq0904/status/1436155700212744211
CVE-2021-40444 wurde ja um folgende Registry-Anpassung erweitert "Disabling Shell Preview prevents a user from previewing documents in Windows Explorer. Follow these steps for each type of document you want to prevent being previewed".
Gleiche Wirkung würde man doch auch erzielen, wenn das Preview Pane gleich via GPO deaktiviert werden würde? Gilt dann natürlich für alle Dateitypen.
User Configuration > Administrative Templates > Windows Components > File Explorer > Explorer Frame Pane "Turn off Preview Pane" auf "Enabled
Hallo Gregor,
die GLEICHE Frage wollte ich soeben auch stellen ;-) …
Mir stellt sich dabei nur die Frage, ob dadurch das PreviewPane nur 'versteckt' (nicht angezeigt) wird und dass vielleicht die 'Funktionalität' im Background dennoch ausgeführt wird? Dann würde nur ein Entfernen der Registry Einträge helfen.
Vielleicht weiß hier jemand (oder Herr Born selbst) mehr, wie dies unter der Haube funktioniert und ob diese GPO ausreicht?
Also ich hab das mal getestet. Wenn ich die GPO aktiviere, dann wird die Vorschau deaktiviert, wenn sie aktiv war und graut den Möglichkeit aus das Vorschaufenster wieder zu aktivieren. Von daher würde ich in meinem jugendlichen Leichtsinn behaupten, dass dann auch nichts mehr im Hintergrund ausgeführt. Das wäre ziemlich dämlich von Microsoft.
Der Unterschied zwischen den Reg Keys und der GPO ist halt, dass du mit den Reg Keys expliziet ausgewählte Dateitypen in der Vorschau ausschalten kannst.
Mit der GPO wird halt global alles deaktiviert.
So würde ich es verstehen.
Tja, wer schon Lücken -wie beim Exchange- und in der Vergangenheit der letzten Monate produziert, dem ist… ;-)
UI Elemente kann man ja Enablen/Disablen bzw. auch einen Hide/Unhide. Wenn da nur ein 'Hide' drauf ist, dann würde es weiterhin seinen Dienst tun (was wirklich 'dämlich' wäre)…
In Ermangelung des Explorer-Source-Codes kann man da nur hoffen, oder wirklich die Sachen aus der Registry schmeissen.
Dewegen ja auch meine Frage, ob das per GPO 'ausreicht', oder ob wir hier auch die Registry-Keule brauchen..?
Mir würde mal noch interessieren wie das in der Vorschau bei Outlook ist…..
@Günter: verstehst Du laaaaangsam, warum ich gestern "Desinformation" schrieb?
Sowohl Vorschau als auf RTF wurden schon vor 15 Jahren zum Füttern (nicht nur) des MSHTML-ActiveX-Steuerelements mit gefährlichen Daten benutzt. Und die Trantüten beim MSRC haben wie immer KEIN Gedächtnis bzw. keine Phantasie, auch mal SELBSTÄNDIG andere Angriffsvektoren in Betracht zu ziehen als den einen, der gerade genutzt wird…
Das ist wohl auch der ganze Grund für diesen Trend zur Telemetrie. Microsoft denkt gar nicht mehr daran, alle Bugs zu fixen, sondern schaut nur via Telemetrie, welche Bugs häufig genug bei wichtigen Kunden auftreten.
Für diese CVE ist der Quell-Text derWebseite auf "www.Abuse." (tld müßt ihr kennen/raten) verfügbar. Der Java-Script-Code ist schwer lesbar.
äh .. und was ist mit der Vorschau von .dot usw … ?
ActiveX ist eben ein defktes Konzept, wie so vieles bei Microsoft. Anstatt ständig den Problemen hinterher zu rennen, wäre es angebracht mal auf bessere Ecosystem zu wechseln und Windows nicht länger weiter zu nutzen.
Bin ich absolut bei dir – es bröckelt zwar mit dem Windows-Marktanteil auf dem Desktop – aber die Leut wollen diesem Eco-System nicht in Massen von der Fahne gehen, sondern hecheln sogar noch in Richtung Windows 11 ;-).
Und bewahre, ohne dieses Eco-System würde ich vor Langeweile umkommen, denn ich hätte nix mehr über IT zu bloggen, müsste viel spazieren gehen, noch mehr Sport treiben, und aus lauter Verzweiflung meine Blogs für 50Plus, über Bücher und Reisen befüllen …
Gott-sei-Dank, gerade hat der Wecker geklingelt und ich bin schweißgebadet aus diesem Alptraum aufgewacht … ;-).
Jemand ne Idee warum die von Microsoft vorgeschlagenen Reg Einträge in CLASSES_ROOT nicht funktionieren?
Habe das mal für RTF versucht, aber die Vorschau Funktion im Explorer bleibt… auch nach Neustart.
Vielleicht kann mir hier einer auf die Sprünge helfen.
Wenn ich den Inhalt des RegKeys "Computer\HKEY_CLASSES_ROOT\.rtf\ShellEx\{8895b1c6-b41f-4c1c-a562-0d564250836f}" lösche, funktioniert die Preview trotzdem.
Selbst wenn der gesamte Key ".rtf" gelöscht wird, zeigt der Windows Explorer weiterhin die Vorschau an.
Rechner wurde neu gestartet, getestet mit Domänen-Computer und ohne Domäne.
Die Vorschau lässt sich durch die RegKey-Anpassung bei mir nicht deaktivieren.
Du sollst nicht den kompletten Key löschen sondern nur den Inhalt des "Standard" Werts entfernen – so das dieser Wert leer ist.
Danach wird sofort keine Vorschau mehr im Explorer angezeigt.
Danke erstmal. Das hatte ich jedoch wortwörtlich im ersten Satz geschrieben. Bei mir geht die Vorschau trotzdem weiterhin, auch wenn ich nur den Wert lösche.
Ne, das hast du nicht geschrieben.
Du hast geschrieben, dass du den Inhalt von "Computer\HKEY_CLASSES_ROOT\.rtf\ShellEx\{8895b1c6-b41f-4c1c-a562-0d564250836f}" gelöscht hast.
Du sollst aber den Inhalt des "(Standard)" Werts löschen.
Das ist schon ein Unterschied ;-)
Bzgl. RTF wird nach der Registry Änderung WordPad für die Vorschau verwendet anstelle von Word. Dies kann man sehen, falls das RTF spezielle Formatierungen enthält, hier sieht man dann entsprechende Unterschiede bei der Darstellung im Vorschaufenster.
Danke für diesen Hinweis. Das scheint der Knackpunkt zu sein.
Frage:
Was bedeutet es, wenn die folgenden, im Workaround von Microsoft genannten, Registry-Einträge bezüglich der Vorschau im Windows-Explorer überhaupt zu existieren scheinen?
For Word documents:
HKEY_CLASSES_ROOT.docx\ShellEx{8895b1c6-b41f-4c1c-a562-0d564250836f}
HKEY_CLASSES_ROOT.doc\ShellEx{8895b1c6-b41f-4c1c-a562-0d564250836f}
HKEY_CLASSES_ROOT.docm\ShellEx{8895b1c6-b41f-4c1c-a562-0d564250836f}
Gilt das Ganze nur für Windows 10?
Die Dateitypen sind in allen Windows-Versionen registriert.
Sorry, ich hatte ein "nicht" vergessen.
Diese Einträge gibt es in meiner Registry (unter Windows 7) aber nicht.
MS hat sich hier verschrieben, es muss
HKEY_CLASSES_ROOT.docx\ShellEx\{8895b1c6-b41f-4c1c-a562-0d564250836f}
usw heißen
zusätzlich fehlen aber noch die .dot , powerpoint,excel usw
Aber unter HKEY_CLASSES_ROOT.docx (bzw. .doc, .docm und .rtf) existiert nicht einmal "ShellEx".
Sind diese Dateitypen denn nur registriert, wenn man auch Microsoft Office installiert hat?
Das ist leider immer noch falsch, denn auch nach ROOT (vor dem Punkt der Dateierweiterung) muss ein Backslash sitzen.
Unter Windows 7 habe ich den Pfad "ShellEx" gar nicht. Schalte ich die Vorschau im Explorer über das Icon rechts oben ein, bekomme ich für .doc und .docx keine Vorschau, wohl aber für .rtx!
Ich habe da allerdings auch kein MS Office mehr installiert, sondern nur Open Source Alternativen. Vielleicht wird der "ShellEx" Pfad erst von MS Office angelegt. Dennoch funktioniert hier die Vorschau für .rtx, wie oben geschrieben, obwohl auch da der Pfad "ShellEx" nicht existiert!
Edit @Scyllo
Ich sah Deinen Post erst, nachdem ich meinen gesendet hatte. Wie Du siehst, habe ich mich genau das auch gefragt.
@Martin: Bei mir ist auch nur OpenOffice installiert.
Zudem ist das Vorschaufenster im Windows Explorer deaktiviert. Ist man dadurch (vom ersten Teil des Workarounds seitens Microsoft (To disable ActiveX controls on an individual system via regkey) mal abgesehen) bereits auf der etwas "sichereren" Seite?
@Scyllo
Ich habe Folgendes getestet und fürchte, dass die Ansicht nur ausgeblendet ist und das RTF (dass ich oben zweimal .rtx schrieb, war natürlich ein Versehen) trotzdem im Hintergrund geladen wird.
– Process Monitor gestartet und folgende Filter angelegt:
– "Pfad enthält wordpad.exe"
– "Process ist explorer.exe"
Im Explorer dann:
-Vorschau aus (Standard bei Windows 7 Explorer).
– Ein RTF angeklickt und der Process Monitor erzeugt 24 Einträge mit wordpad.exe.
– Vorschau einschalten und es gibt keinen neuen Eintrag im Process Monitor, obwohl das RTF nun angezeigt wird.
Bei .doc zeigt der Process Monitor gar keine Einträge an, bei .odt erstaunlicherweise totzdem, obwohl Wordpad das ja gar nicht anzeigen kann. Offenbar wird es aber versucht.
@Martin:
"Aktiviert man die GPO während die Vorschau das RTF gerade anzeigt und wechseit zu einer Datei die ohnhehin nicht angezeigt werden könnte, bleibt das vorherige RTF in der Vorschau. Wechselt man dann zurück zur RTF zählt der Process Monitor 69 Dateiaktionen zwischen explorer.exe und winword.exe."
Also, wenn man dies aktiviert, während schon 'Aktivitäten' stattgefunden haben, glaube ich nicht, dass die bereits gestarteten Prozesse wieder verschwinden. Probiere doch mal bitte, die Vorschau-/Detail-Fenster mittels GPO zu deaktivieren, mache einen Reboot und teste dann mal, was passiert…
Wie (LEIDER) üblich macht das MSRC schon wieder weniger als halbe Sachen: "shell extensions" wie Vorschau-Handler sowie Kontextmenüeinträge können nicht nur unter [HKEY_CLASS_ROOT\.extension] alias [HKEY_CURRENT_USER\Software\Classes\.extension] bzw. [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.Extension] registriert werden, sondern auch unter [HKEY_CLASSES_ROOT\progid] (wobei progid EINER der vielen "programmatic identifer" ist, die .extension zugeordnet sind [ACHTUNG: diese Zuordnungen sind system- und benutzer-spezifisch]), [HKEY_CLASSES_ROOT\*], [HKEY_CLASSES_ROOT\Applications], [HKEY_CLASSES_ROOT\SystemFileAssociations] …
Kurz: die "shell" alias der File Explorer bildet die transitive Hülle ALLER irgendwie zutreffenden Einträge.
Das macht deutlich, weshalb Windows (7) auch ohne MS Office und fehlendem "ShellEx" Pfad unter den von MS genannten Registryeinträgen ein RTF in der Explorer-Vorschau anzeigt und das offensichtlich auch ausführt, wenn die Vorschau gar nicht eingeschaltet ist. (Siehe Antwort an Scyllo obendrüber.)
@Martin: hast Du schon mal versucht, das Vorschau- und Detail-Fenster per GPO zu blocken? Werden dann immer noch wordpad-Prozesse gestartet?
Ich erinnere mich, dass vor geraumer Zeit mal Adobe ein Problem hatte und da sollte man mittels GPO wegen einer Sicherheitslücke das Vorschau- und Detail-Fenster blocken. Wenn das damals geholfen hat, sollte es auch hier helfen. Also nicht nur im Explorer ausschalten, sondern per GPO, oder die Policies direkt setzen:
unter Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows
\CurrentVersion\Policies\Explorer
einfach 2 Einträge:
NoPreviewPane REG_DWORD auf 1 setzen
und
NoReadingPane REG_DWORD auf 1 setzen
Probiere es mal bitte aus…
@Martin (Nachtrag): ach ja, noch was…
wenn ich in meinem Windows 11 das Vorschau-Fenster ausgeschaltet habe. KEINE GPO bzgl. des Vorschau-Fensters verwende (also nix blocke) und clicke ein RTF an, dann habe ich keinen wordpad.exe bzw. winword64.exe process. Was mache ich falsch ;-) ?
@Robert
Mit der aktivierten GPO zeigt der Process Monitor exakt die gleichen Aktionen von explorer.exe zu wordpad.exe.
War vor dem Aktivieren die Vorschau mit einem RTF aktiv, bleibt der Inhalt dieses RTF angezeigt, wenn man mit dann aktivierter GPO ein anderes RTF markiert. Der Inhalt der Vorschauanzeige ändert sich dann also nicht mehr. Demnach scheint also nicht nur der reine Vorschaubutton entfernt zu werden. Aber weshalb zeigt der Process Monitor in *allen* Fällen immer die gleichen 24 Aktionen mit zwischen explorer.exe und wordpad.exe an?
Nachtrag @Robert:
Gib mal beim Pfad statt "wordpad.exe" einfach nur "word" ein. Das erfasst dann auch winword, falls man MS Office intalliert hat.
Auf meiner Win10 Test-VM ist ein Test MS-Office installiert. Da zeigt der Process Monitor mit aktiver Vorschau 78 Dateisystem-Aktivitäten zwischen explorer.exe und winword.exe, ohne eingeschaltete Vorschau sind es 66. Beides ohne aktive GPO!
Aktiviert man die GPO während die Vorschau das RTF gerade anzeigt und wechseit zu einer Datei die ohnhehin nicht angezeigt werden könnte, bleibt das vorherige RTF in der Vorschau. Wechselt man dann zurück zur RTF zählt der Process Monitor 69 Dateiaktionen zwischen explorer.exe und winword.exe.
Wobei dieses Szenario natürlich keines ist, was sonst vorkommt, denn nach dem Schließen und neu Öffnen des Explorers sind es 66, also wie einfach bei über die Schaltfläche des Explorers deaktvierter Vorschau.
Die Frage ist nun: Kann ein entprechendes RTF auch bei deaktivierter Vorschau noch Schaden anrichten, da ja der Explorer offenbar noch einiges mit Wordpad/Winword macht?
sorry, hatte zu weit OBEN gepostet, also nochmal HIER :)
@Martin:
„Aktiviert man die GPO während die Vorschau das RTF gerade anzeigt und wechseit zu einer Datei die ohnhehin nicht angezeigt werden könnte, bleibt das vorherige RTF in der Vorschau. Wechselt man dann zurück zur RTF zählt der Process Monitor 69 Dateiaktionen zwischen explorer.exe und winword.exe."
Also, wenn man dies aktiviert, während schon ‚Aktivitäten' stattgefunden haben, glaube ich nicht, dass die bereits gestarteten Prozesse wieder verschwinden. Probiere doch mal bitte, die Vorschau-/Detail-Fenster mittels GPO zu deaktivieren, mache einen Reboot und teste dann mal, was passiert…
@Robert:
Ich kann Windows 7 derzeit nicht neu starten, aber ich habe es auf der VM mit Win 10 und deren Neustart getestet: Macht absolut keinen Unterschied. Das erste Markieren einer RTF nach einem Win 10 Neustart mit aktiver GPO triggert 110 Dateiaktionen der explorer.exe mit winword.exe. Das zweite Mal sind es dann die 66.
Ich gehe davon aus, dass das unter Win 7 leider nicht anders sein wird.
Blog-Leser Tobias hat mir noch einen einen Link zu einem PowerShell-Script bereitgestellt, welches die Registry-Einträge gemäß den Microsoft-Vorgaben anpasst.
Ansonsten ist mir gerade der obige Tweet zu einem PoC auf GitHub unter die Augen gekommen. Dort findet sich ein bösartiger docx-Generator zur Ausnutzung von CVE-2021-40444 (Microsoft Office Word Remote Code Execution). Es dürfte bald ungemütlich werden.
https://www.bleepingcomputer.com/news/microsoft/windows-mshtml-zero-day-exploits-shared-on-hacking-forums/
Daraus: "However, researchers have been able to modify the exploit not to use ActiveX, effectively bypassing Microsoft's mitigations."
Kann man sich nun das gesamte "Rumgefrickel" an der Registry also eigentlich sparen?
Zudem ich leider immer noch nicht weiß, was nun ein "normaler" User macht, bei dem die oben genannten ShellEx-"Einträge" überhaupt nicht vorhanden sind.
Das Problem ist ja offenbar, dass alleine eine RTF-Datei über die Vorschau im Explorer Schaden anrichten kann und es jede Menge Möglichkeiten in der Registry gibt, die dem Explorer die Möglichkeit zur Vorschau bieten, wie Stefan Kanthak schrieb (was Registry und Explorer anbelangt).
Hier fragt jemand: "Via Wordpad or Office?" und Will Dormann antwortet darauf mit "Office".
https://twitter.com/randomdross/status/1436013645981356034?s=20
Wordpad kann nichts nachladen, denke ich. Damit sollte man ohne MS-Office raus sein.
Habe soeben die neuen Updates installiert, bei "Microsoft 365 Apps for Enterprise" (Click-2-Run Version) und bei "Office 2016 Professional Plus" (Click-2-Run Version).
Für die 2016er VL-Versionen (welche sich über Windows Update installieren) sind leider noch keine Updates da. Vermutlich kommen die erst heute um 19:00 Uhr mit den 'normalen' Windows-Updates heraus. Mal abwarten…
Weiß leider nicht, ob das Problem jetzt bei den zwei Click-2-Run Versionen gefixt wurde…