Kleine Information zum Wochenende: Sicherheitsforscher von Google haben eine Sicherheitslücke in Windows 10 S entdeckt, mit der sich Schutzmechanismen aushebeln und .NET-Klassen laden lassen. Die Sicherheitslücke wird als mittelschwer klassifiziert.
Anzeige
Was ist Windows 10 S
Für Leute, denen der Begriff neu ist, ein paar kurze Informationen. Windows 10 S ist der Versuch von Microsoft, Windows 10 auf die Ausführung von Apps aus dem Microsoft Store zu beschränken. Das soll vor allem die Sicherheit erhöhen.
Mit dem kommenden Windows 10 Version 1803 kann das Betriebssystem bei der Installation im Windows 10 S-Modus eingerichtet werden. Benutzer können aber problemlos von Windows 10 S auf Windows 10 Pro aktualisieren.
Die Sicherheitslücke in Windows 10 S
Mitglieder von Googles Projekt Zero haben die Sicherheitslücke am 19. Januar 2018 entdeckt und nach der 90-Tage-Frist automatisch Details im Chromium-Bugtracker veröffentlicht. Hier die technische Beschreibung der Sicherheitslücke:
The WLDP COM Class lockdown policy contains a hardcoded list of 8 to 50 COM objects which enlightened scripting engines can instantiate. Excluding issues related to the looking up of the correct CLSID (such as previously reported abuse of TreatAs case 40189). This shouldn't be a major issue even if you can write to the registry to register an existing DLL under one of the allowed COM CLSIDs as a well behaved COM implementation should compare the CLSID passed to DllGetObject against its internal list of known objects.
Die WLDP COM Class Lockdown-Richtlinie enthält eine hartkodierte Liste von 8 bis 50 COM-Objekten, die von zugelassenen Scripting-Engines instanziiert werden dürfen.
Es gibt nur einige Ausnahmen im Zusammenhang mit der Suche nach der korrekten CLSID (wie z.B. der zuvor gemeldete Missbrauch von TreatAs Fall 40189).
Nach Ansicht der Google-Sicherheitsforscher sollte es kein großes Problem sein, die notwendigen Einträger in die Registry zu schreiben, um eine bestehende DLL unter einer der erlaubten COM-CLSIDs zu registrieren. Diese COM-Implementierung sollte die an DllGetObject übergebene CLSID mit ihrer internen Liste bekannter Objekte vergleichen können. Und weiter:
Turns out .NET is not one of these well behaved COM implementations. When a .NET COM object is instantiated the CLSID passed to mscoree's DllGetClassObject is only used to look up the registration information in HKCR. At this point, at least based on testing, the CLSID is thrown away and the .NET object created. This has a direct impact on the class policy as it allows an attacker to add registry keys (including to HKCU) that would load an arbitrary COM visible class under one of the allowed CLSIDs. As .NET then doesn't care about whether the .NET Type has that specific GUID you can use this to bootstrap arbitrary code execution by abusing something like DotNetToJScript.
Es stellte sich heraus, dass .NET keine dieser als zulässig erachteten COM-Implementierungen ist. Wird ein .NET COM-Objekt instanziiert, wird die CLSID, die an das DllGetClassObject von mscoree übergeben wird, nur verwendet, um die Registrierungsinformationen in HKCR nachzuschlagen. Zu diesem Zeitpunkt wird die CLSID zumindest aufgrund von Tests verworfen und das .NET-Objekt erstellt.
Dies hat einen direkten Einfluss auf die Klassenrichtlinie, da es einem Angreifer erlaubt, Registrierungsschlüssel (auch zu HKCU) hinzuzufügen. Dies ermöglicht eine beliebige sichtbare COM-Klasse unter einer der erlaubten CLSIDs zu laden. Da .NET sich dann nicht darum kümmert, ob der .NET-Typ diese spezifische GUID hat, können Angreifer dies verwenden, um die Ausführung von beliebigem Code zu starten.
Die Sicherheitsforscher haben ein Proof of Concept (PoC) erstellt, das aus zwei Dateien, eine INF-Datei zum Einrichten der Registry und eine SCT-Datei besteht. Die INF-Datei war erforderlich, da der alte Trick unter Windows 10S 1709, REGINI dafür zu verwenden, nicht mehr klappt. REGINI wird in Windows 10 S blockiert aber die .INF-Datei ist zugelassen (wird ja zur Treiberinstallation gebraucht).
Anzeige
Die INF-Datei kann verwenden werden, um die notwendigen Registrierungsschlüssel zu installieren. Die SCT-Datei (Script-Datei) ist nur ein Beispiel aus der DotNetToJScript-Tool-Sammlung des Google Sicherheitsforschers. Diese lädt eine nicht vertrauenswürdige .NET-Assembly in den Speicher. Diese zeigt im PoC nur einfache Nachrichtenbox an. Offensichtlich könnte die .NET-Assembly viel mehr als das. Die Beschreibung auf Chromium enthält den Download für das PoC sowie Anweisungen, wie man das ausnutzen könnte.
Nur mittelschweres Problem
Neowin schreibt, dass die Sicherheitslücke nur Systeme betrifft, auf denen Device Guard aktiviert ist – in erster Linie Windows 10 S. Die Schwachstelle kann nicht Remote, also nicht aus der Ferne ausgenutzt werden. Ein Angreifer müsste den Code bereits auf dem System laufen haben, um Registrierungseinträge zu ändern, was die Ausnutzbarkeit erheblich beeinträchtigt. Google gibt daher die Sicherheitslücke als Mittelschwer an, sofern andere mögliche Bypass-Methoden wie Remote Code Execution (RCE) in Edge behoben wurden.
Die Datumsangaben zur Offenlegung der Schwachstelle ist sehr interessant. Google meldete den Fehler am 19. Januar an Microsoft. Diesen gelang es aber nicht, die Schwachstelle vor dem April Patchday zu schließen. Microsoft bat Google um eine 14-tägige Verlängerung, und teilte Google mit, dass ein Fix beim Mai-Patchday (8. Mai 2018) ausgerollt werde. Google lehnte den Antrag von Microsoft ab und veröffentlichte die Details.
Google wies Microsoft darauf hin, dass das hier diskutierte Problem nicht ganz ernst ist und dass es noch andere Bypass-Methoden gibt, die noch nicht behoben wurden. Letzte Woche beantragte Microsoft erneut eine Fristverlängerung mit der Behauptung, dass die Sicherheitslücke im Redstone 4 (RS4) Update gelöst werden würde. Dies lehnte Google aber ab, da kein festes Release-Datum für das Redstone 4-Release existiert. "RS4 würde sowieso nicht als ein allgemein verfügbarer Patch angesehen werden". An dieser Stelle musste ich schmunzeln, weil mir – wenn ich über Verzögerungen berichte, mir immer vorgehalten wird 'ist doch gut, wenn Microsoft eine funktionierende Qualitätssicherung hat – und Windows 10 V1803 kommt, wenn es fertig ist'. Dann schießt mir immer 'wenn ihr wüsstet' durch den Kopf. Nun ist einer der Fälle, wo die Finger noch klebrig vom Honigtopf sind, ruchbar geworden.
Da die Standardfrist von 90 Tagen seit dem 19. April 2018 überschritten wurde, hat Google diesen Fehler, der hauptsächlich Windows 10 S betrifft, öffentlich bekannt gegeben. Es wird interessant sein zu sehen, ob Microsoft gezwungen ist, einen Hotfix zu veröffentlichen, oder ob es immer noch plant, den Fix am 8. Mai mit dem Patch herauszubringen.
Ähnliche Artikel:
Windows 10 S und Surface Laptop vorgestellt
Windows 10 S: Test für Alle?
Windows 10 S–Schlag ins Wasser oder Chromebook-Killer?
Windows 10 S: Sicher und Trojaner-resistent? Mitnichten
Funktionsupdate ändert Windows 10 S zu Pro
Microsoft: Die Mehrheit der Kunden wird Windows 10 S nutzen
Windows 10 S: Kommt mit Windows 10 V1803
2015
Und dieser ganze Zirkus nur um vom eigenen OS/Android abzulenken.
Bei MS gibt es ja wenigstens Updates, wenn auch vielleicht etwas spät. Die Update-Politik bei Google ist dagegen unterirdisch, denn nur die eigenen und ganz wenige andere Geräte bekommen ein Update. Bei Google-Chrome gibt es dagegen immer neue Updates, sonst währen sie wohl schon wegen der Sicherheit bei MS gesperrt worden.
Na, wenn Schadenfreude als Auszeichnung und Leistung gesehen wird, dann spricht das Bände, aber irgendwas muss man ja haben, wenn sonst mehr heiße Luft drin ist.
Dass Microsoft gerne herumtrödelt, auf einem sehr hohen Ross sitzt und nicht mehr zurechtkommt mit dem selber geschaffenen Druck, scheint als ausgemacht, die Erwähnung von RS4 erscheint auch mir als Ausflucht.