[English]Liefert Microsoft am heutige 14. September 2021 ein Sicherheitsupdate zum Schließen der Schwachstelle CVE-2021-40444 in der Windows MSHTML-Bibliothek aus? Und vor allem: Falls ein Patch kommt, schließt der die Sicherheitslücke, oder ist das Ganze mal wieder "weiße Salbe"? Nachdem Exploits in Untergrundforen kursieren, möchte ich in einem Blog-Beitrag nochmals den aktuellen Sachstand zusammenfassen.
Anzeige
MSHTML Schwachstelle CVE-2021-40444
MSHTML (Trident) ist die HTML-Rendering-Engine des in allen bisherigen Windows-Versionen enthaltenen Internet Explorer. Diese in Windows enthaltene MSHTML-Bibliothek weist aber eine Schwachstelle CVE-2021-40444 auf, die eine Remote Code-Ausführung (RCE), u.a. über manipulierte Office-Dokumente ermöglicht. Bekannt war, dass Angreifer manipulierte Office-Dokumente verwendete haben, um die Schwachstelle in der HTML-Rendering-Engine über von Webseiten des Angreifers heruntergeladene und neu installierte ActiveX-Komponenten anzugreifen.
Microsoft hatte zwar zum 7. September 2021 eine Warnung zur der Remote Code Execution-Schwachstelle CVE-2021-40444 veröffentlicht. Im betreffenden Dokument wurden Hinweise gegeben, wie die Installation neuer ActiveX-Elemente per Internet Explorer verhindert werden könne. Zudem argumentierte Microsoft, dass in Office die Funktion „Geschützte Ansicht" die Schwachstelle entschärfe. Ich hatte im Blog-Beitrag Angriff über Office-Dokumente auf Microsoft MSHTML (ActiveX) RCE-Schwachstelle (CVE-2021-40444) auf den Sachverhalt hingewiesen.
Allerdings erwiesen sich die Microsoft-Ausführungen als ziemlicher Trugschluss. Bald kristallisiert sich heraus, dass die Schwachstelle wesentlich kritischer als gedacht war. Es braucht keine ActiveX-Komponenten, um die Schwachstelle auszunutzen. Ich hatte im Blog-Beitrag MSHTML-Schwachstelle CVE-2021-40444 kritischer als bekannt darauf hingewiesen, dass Sicherheitsforscher Will Dormann sich die Schwachstelle vorgenommen und mal mit RTF-Dateien getestet hat. Die Microsoft Schutzmechanismen, die aus dem Internet heruntergeladene Office-Dokument in der geschützten Ansicht öffnen sollen, lassen sich einfach umgehen.
Inzwischen ist es Sicherheitsforschern auch gelungen, .CPL-Dateien aufzurufen und so die Schwachstelle auszunutzen. Seit einer Woche eskaliert das Ganze, weil inzwischen Baukästen zum Erstellen manipulierter Word-Dateien im Internet abrufbar sind. Zudem werden Exploits zum Ausnutzen der MSHTML Schwachstelle CVE-2021-40444 im Hackerforen herumgereicht. Die Kollegen von Bleeping Computer haben in diesem Artikel gerade vor dieser Entwicklung gewarnt.
Die Tage bin ich über obigen Tweet gestolpert. Dort hat jemand die verfügbaren Exploit-Pakete für eigene Experimente verwendet und gezeigt, wie er über eine CAB-Datei die Sicherheitslücke ausnutzen konnte. Auch in diesem Tweet demonstriert jemand, wie er die Schwachstelle mit ein wenig JavaScript-Code ausnutzen kann. Ich gehe daher davon aus, dass bald mit einer größeren Angriffswelle zu rechnen ist.
Microsoft ist zu kurz gesprungen
Es lässt sich im Rückblick erkennen, dass Microsoft deutlich zu kurz bezüglich seiner Vorschläge zur Entschärfung der Schwachstelle gesprungen ist. Wenn die geschützte Ansicht sich aushebeln lässt, und die von Microsoft vorgeschlagen Deaktivierung der Möglichkeit, zur Installation neuer ActiveX-Dokumente nicht ausreicht, bleibt der Anwender im Regen stehen. Die von Microsoft nachgeschobene Anweisung, die Verknüpfung der Vorschau bestimmter Dokumentdateien durch Löschen von Registrierungseinträgen zu deaktivieren, klingt schlicht hilflos. Die haben es nicht im Griff, so mein Eindruck.
Anzeige
Die Twitter-Warnung von CERT-Bund ist da auch wenig zielführend. Zumindest deutet CERT-Bund an, dass man heute einen Patch erwartet. Lese ich mir aber die bisherigen, aber weitgehend untauglichen Vorschläge Microsofts zur Abschwächung der Sicherheitslücke durch, bin ich nicht sicher, ob das Ganze per Sicherheitsupdate geschlossen werden kann (die unendliche Geschichte zu PrintNightmare dümpelt im Hinterkopf).
Was aktuell teils schützt, sind Antivirus-Lösungen, die ggf. einen Angriff an Hand der verwendeten Dateien erkennen und blockieren. Aber es dürften bald Fälle auftreten, wo unbekannte Exploits die Virenscanner austricksen. Es kommt auf die Nutzer an, die darauf verzichten, Office-Dateien, die auch dem Internet stammen, zu öffnen. Irgendwie unbefriedigend.
Problem seit Jahren bekannt
Bereits im Blog-Beitrag Angriff über Office-Dokumente auf Microsoft MSHTML (ActiveX) RCE-Schwachstelle (CVE-2021-40444) wies Stefan Kanthak in diesem Kommentar darauf hin, dass die zur Abschwächung der Sicherheitslücke Microsofts, die Installation von ActiveX-Elementen per Registrierungseintrag zu blockieren, eher nicht wirklich zielführend seien. Er verwies auf die in KB4058123 beschriebene Möglichkeit, das Office COM-Kill-Bit in der Registrierung zu setzen. Das Office COM-Kill-Bit wurde mit dem Sicherheitsupdate MS10-036 eingeführt, um zu verhindern, dass bestimmte COM-Objekte ausgeführt werden, wenn diese in Office-Dokumente eingebettet oder mit ihnen verknüpft sind.
Die Funktionalität des COM-Kill-Bits wurde in KB3178703 aktualisiert, um die Aktivierung von COM-Objekten durch Office vollständig zu verhindern. Dieses Update ist eine Erweiterung des ursprünglichen Verhaltens, wobei zusätzlich zum Blockieren von COM-Objekten, die in Office-Dokumente eingebettet oder verknüpft sind, alle Instanzen von COM-Objekten blockiert werden, die innerhalb des Office-Prozesses über andere Mittel wie Add-Ins geladen werden. Zu diesen spezifischen COM-Objekten gehören ActiveX-Steuerelemente und OLE-Objekte. Über die Registrierung können Sie unabhängig steuern, welche COM-Objekte blockiert werden.
Mit diesem Ansatz könnten Nutzer ihre Systeme absichern. Microsoft hat 2008 sogar eine Kill-Bit-FAQ zu diesem Thema veröffentlich, die Stefan Kanthak in seinem Kommentar verlinkt hatte. Bei Microsoft finde ich in der Warnung zur der Remote Code Execution-Schwachstelle CVE-2021-40444 diesbezüglich aber nichts. Möglicherweise nimmt Microsoft da auf Firmen Rücksicht, die genau diese COM-Objekte und ActiveX-Elemente in ihren Intranet-Umgebungen noch einsetzen.
Wer seine Systeme in dieser Hinsicht etwas besser härten möchte, sollte sich die von Stefan Kanthak ab 2004 veröffentlichte und immer wieder aktualisierte Registrierungsdatei IE_safer.reg ansehen. Ansonsten gilt es abzuwarten, was uns in den kommenden Stunden aus dem Microsoft-Universum diesbezüglich präsentiert wird. Langfristig sollten sich IT-Verantwortliche eher Gedanken machen, ob man weiterhin auf diesen sicherheitstechnisch ziemlich kaputten Flickenteppich setzen will.
Ähnliche Artikel:
Angriff über Office-Dokumente auf Microsoft MSHTML (ActiveX) RCE-Schwachstelle (CVE-2021-40444)
MSHTML-Schwachstelle CVE-2021-40444 kritischer als bekannt
2015
Früher(tm) gab es für alle MS-Office-Produkte einen "Viewer", der vor bösen Dokumenten helfen sollte
Was ist daraus geworden und warum?
Einfach unlizenzierte Versionen nehmen, dann hast die Viewer wieder ;)
Ich wäre mir nicht sicher, daß das vor Codeausführung schützt.
Sehr geehrte Blog-Community,
Meine Frage richtet sich an die Datei mshtml.dll: Kann mir jemand von Ihnen sagen, ob sich diese Datei trotz deaktiviertem Windows-Feature (IE11) Updaten lässt? Kann oder wird diese Datei vielleicht über das kumulative Update der Windows Versionen verteilt oder muss die Datei mshtml.dll zwangsweise über ein Sicherheitsupdate für den IE11 gepatcht werden? Sie kennen ja hier vielleicht das Problem, dass die Komponente IE11 ja nicht unbedingt die Sicherste ist, deshalb und wegen des Support-Endes wird ja schon länger eine Deaktivierung empfohlen. Ich würde natürlich nur ungerne den IE11 wieder per Default aktiviert verteilen.
Besten dank und viele Grüße.
Ich gehe davon aus dass die mshtml.dll über ein Sicherheitsupdate per WU aktualisiert wird. Details wenn es soweit ist.
patch kommt heute bzw. ist schon da.
quizfrage an die wissenden: gibts im wsus schon produkt kategorie für windows server 2022? oder brauchts dafür einen wsus auf server 2022?
Die gibt es – heißt aber "Microsoft Server operating system-21H2"
also die hab ich bei den products nicht nur "Windows Server, version 1903 and later"
ist das gemeint?
sorry habs gefunden jetzt. danke nochmal. manchmal sieht man vor lauter bäumen den wald nicht
Die gibt es für Server der Version 21H2 und da kam heute auch ein kumulatives Update im WSUS 2019. Hatte aber noch keine Lust das in meiner Test-VM zu installieren
Ich habe gerade Update gemacht.
https://support.microsoft.com/de-de/topic/september-14-2021-kb5005565-os-builds-19041-1237-19042-1237-and-19043-1237-292cf8ed-f97b-4cd8-9883-32b71e3e6b44
Viel steht da aber nicht. Hier steht mehr:
https://www.bleepingcomputer.com/news/microsoft/windows-10-kb5005565-and-kb5005566-cumulative-updates-released/
Nix neues zu Printnightmare und mshtml/ActiveX – na tolll!
Bei MS schon:
https://msrc.microsoft.com/update-guide/releaseNote/2021-Sep
im unteren Drittel:
Windows MSHTML-Plattformen
Angeblich beide gefixt:
https://www.bleepingcomputer.com/news/microsoft/microsoft-fixes-remaining-windows-printnightmare-vulnerabilities/
https://www.bleepingcomputer.com/news/microsoft/microsoft-fixes-windows-cve-2021-40444-mshtml-zero-day-bug/
1.
bisher mögliche Dokumentenformate mit enthaltener Payload:
doc, docx, docm, rtf
2.
Payload (Schädlingsroutine innerhalb des Documents) mit GET nachladbar oder per direkt enthaltenem CAB bereits im Dokument vorhanden (injected file)
3.
bisher erfolgreich getestet (als eigentlicher Schädling):
CONTROL: cpl
MSHTA: hta
WSCRIPT: js,jse,vba,wsf
JAVAW: jar
MSIEXEC: msi
RegEdit: reg
twitter[.]com[slash]Max_Mal_[slash]status/1437564247324639234
CSCRIPT: bisher nicht erfolgreich
Man kann jede beliebige dll laden.
Es ist also nicht auf ActiveX oder OLE beschränkt, sondern potentiell sind sämtliche Injected files (Packages) möglich.
Im Explorer sollte man unter Ordneroptionen, Ansicht, "Immer Symbole statt Miniaturansichten anzeigen" anhaken, damit die Vorschau abgeschaltet wird.
In den Diensten sollte man den ActiveX-Installer (AxInstSV) deaktivieren.
Software Restriction Policies (siehe SAFER von Stefan Kanthak) schützt gegen das Ausführen der Payload aus vom Benutzer beschreibbaren Ordnern.
Ob der Patch von MS ausreicht darf bezweifelt werden, weil die nur ActiveX auf dem Schirm hatten und die Patches bei PrintNightmare auch mehrfach nachgebessert werden mussten.
Bist du sicher, dass der Dienst "ActiveX-Installer" zum Hardening beiträgt? Hast du da eine Referenz? In der Description steht nämlich folgendes: "This service is started on demand and if disabled the installation of ActiveX controls will behave according to default browser settings."
Oops, da hast du wahrscheinlich recht.
Dieser ActiveX-Installer-Service ist demnach also gar nicht für die eigentliche Installation der ActiveX-Komponenten zuständig, sondern nur für die Validierung der Berechtigungen (UAC, Group Policy).
Ich hatte fälschlicherweise angenommen, dass auch der IE-Browser zur Installation der ActiveX-Controls auf diesen Dienst angewiesen sei, aber das ist er nicht.
Dann muss man im IE unter Internetoptionen, Sicherheit, für alle 4 Stufen jeweils manuell die "Stufe anpassen", so dass die ActiveX-Controls deaktiviert werden (das sind jeweils mehrere Optionen).
Danke für den Hinweis.
Aber dann sollte man den Dienst doch abschalten, damit dieser nicht die Einstellungen im Browser umgehen kann, denn bei aktiviertem Dienst (manuell oder automatisch) bestimmt dann zuerst dieser Dienst, welche Regeln gelten (UAC, GPO) und nicht nur der Browser.
Ist der Dienst abgeschaltet, dann gelten nur die Einstellungen im Browser und wenn dort für alle 4 Zonen alle ActiveX-Optionen deaktiviert sind, dann sollte das hoffentlich auch tatsächlich aus sein.
Es reicht aber ncht aus, nur ActiveX abzuschalten, denn OLE und File-Injection funktioniert dann weiterhin mit den manipulierten Dokumenten.
Gern geschehen, die Plattform sehe ich hier auch als Mittel zum Wissenstransfer.
Zur Absicherung wäre in Unternehmensumgebungen besser die IE Settings über die GPO zu forcieren so dass es im IE nicht direkt wieder aktiviert werden kann. Es gibt für's Hardening außerdem eine Security Baseline für IE von MS.
Die Leute hören ja auch nicht auf, Windows zu benutzen. Also warum die Aufregung? Ich habe seit Jahren nur noch Mac- und Linux-Systeme.