Microsoft bestätigt: Windows patzt bei der Erkennung gefährlicher Treiber – Blocklisten nicht verteilt

Windows[English]Eigentlich sollte Windows bekannte, bösartige Treiber beim Laden blockieren, so dass diese keinen Schaden anrichten können. Zumindest hat Microsoft dies seit Jahren behauptet. Nun hat Microsoft unter der Hand zugegeben, dass man dort gepatzt hat. Denn die Updates, die für diese Blockierung in Windows verantwortlich sind, wurden wohl nie zuverlässig veröffentlicht bzw. aktualisiert. Administratoren können die Blocklisten aber manuell aktualisieren.


Anzeige

Ich wurde zum Wochenende durch Blog-Leser Robert per Mail auf das Thema hingewiesen, bin aber auch über die Serie nachfolgender Tweets von Dan Goodin auf den Sachverhalt gestoßen.

Windows doesn't detect malicious drivers

Die Kurzfassung aus den Tweets lautet: Jahrelang haben Microsoft-Mitarbeiter behauptet, Windows könne automatisch eine Liste bösartiger Treiber blockieren, die regelmäßig über Windows Update aktualisiert wird. Nun haben sie stillschweigend zugegeben, dass diese Updates nie veröffentlicht wurden. Auch Robert schrieb mir folgendes:

heute bin ich auf nachfolgenden Artikel gestoßen. Seit also drei Jahren funktioniert der Schutz vor Treiber-Attacken nicht, weil die Liste der gesperrten Treiber nicht aktualisiert wird.

Dieses Update lässt sich laut Artikel nachholen, ein zukünftiges Windowsupdate soll das irgendwann fixen…

Und die Kernisolierung sollte in Windows aktiviert sein – keine Ahnung was das für die Performance bedeutet.

Windwos Kernisolierung

Der Artikel How a Microsoft blunder opened millions of PCs to potent malware attack, auf den Rober G. sich bezieht, wurde von Dan Goodin bei Arstechnica veröffentlicht.

Worum geht es?

Zum Ansprechen von Geräten (Peripherie, Festplatten, Tastatur, Maus etc.) benötigt Windows entsprechende Treiber, de von Herstellern bereitgestellt werden. Viele Treiber laufen im Adressraum des Windows-Kernels bzw. tauschen mit dem Kernel Daten aus und müssen mit entsprechenden Berechtigungen laufen.

Von Malware wird daher eine als BYOVD ("bring your own vulnerable driver") bezeichnete Technik genutzt, um über vorhandene Schwachstellen in legitimen Windows Treibern die administrative Kontrolle über Windows oder ein Betriebssystem zu erhalten. Ich hatte zum Wochenende im Beitrag BlackByte Ransomware deaktiviert Sicherheitslösungen über Windows-Treiber über einen Fall berichtet, der genau diese Angriffstechnik verwendet.

Auch wenn die Treiberentwickler eine Schwachstelle patchen, bleiben die alten Treiberversionen oft auf Millionen Geräten im Einsatz, da die Treiber nicht aktualisiert werden. Microsoft behauptete daher seit Jahren, dass man eine Liste bekannter bösartiger Treiber pflege, die per Windows Update auf die Maschinen übertragen werde. Anhand der Treiberliste könne Windows das Laden solcher bösartigen Treiber blockieren.


Anzeige

Damit ist eigentlich die Gefahr gebannt – ein Argument, auf "neuer Windows-Versionen" umzusteigen, da nur dort die Technologie eingesetzt wird. Es gibt sogar Hinweise von Microsoft, wie man bestimmte Probleme mit der sogenannten Kernisolierung, die für diese Treiberblockade zuständig ist, in Windows beheben kann. Ich hatte 2020 im Blog-Beitrag Fix: Windows 10-Treiber durch Kernisolierung blockiert über einen solchen Fall berichtet.

Der Windows-Schutz funktioniert nicht

In den vergangenen Jahren konnte Malware über die BYOVD-Technik eine Reihe erfolgreicher Angriffe durchführen. Dan Goodin zählt in seinem Artikel entsprechende Beispiele auf. Das Problem ist Microsoft natürlich bewusst und Redmond hat auch Abwehrmaßnahmen ergriffen, um diese Angriffsvektoren zu blockieren. Am 17. März 2022 hat Microsoft diesen Beitrag veröffentlicht, der aufzeigen soll, wie TPM 2.0, HVCI und weitere Sicherheitstechniken im vom Microsoft definierten "Secured PC" solche Angriffe ins Leere laufen lassen sollen.

Der gängigste Mechanismus zum Blockieren von Treibern ist eine Kombination aus Speicherintegrität und HVCI, schreibt Goodin. Das Kürzel HVCI steht für Hypervisor-Protected Code Integrity. Diese Funktion ist in Windows 10 und Windows 11 implementiert und soll verhindern, dass böswillige Treiber geladen werden und Schaden unter Windows anrichten können. Microsoft gibt im Supportbeitrag auch Hinweise, was Administratoren tun können, wenn die Schutzfunktion inkompatible Treiber blockiert und Windows nicht mehr wie erwartet funktioniert.

Über Jahre lautet das Credo Microsofts, dass man das Problem mit schädlichen Treibern durch die obigen Schutzmechanismen im Griff habe. Allerding beobachteten Sicherheitsforscher wie Will Dormann, dass verschiedene aus BYOVD-Angriffen als bösartig bekannte Treiber problemlos unter Windows, trotz aktivierter Schutzmechanismen, geladen wurden.

Windows loads malicious driver although HVCI is enabled

In obigem Tweet weist Will Dormann darauf hin, dass ein für Schwachstellen anfälliger Treiber namens WinRing0 auf seinen Laborrechnern, auch bei aktiviertem HVCI, problemlos geladen wurde. Dormann beklagt, dass die Dokumentation Microsofts verwirrend sei. Die  "Microsoft Vulnerable Driver Blocklist" bekommt nur der zu sehen, der eine Insider Preview Build von Windows 11 aus dem "Dev Channel"  verwendet. Andererseits gibt es bei Microsoft Artikel zu Windows 10 und Windows Server 2016, die die Verwendung der "Microsoft Vulnerable Driver Blocklist" erwähnen.

Goodin hatte sogar bei Microsoft nachgefragt, ob mehr Details zu den Schutzmechanismen erhältlich seien, bekam von Microsoft aber die Rückmeldung, dass man nichts mitzuteilen habe.

Aber durch die Beobachtungen von Dormann geriet das Thema ist den Fokus diverse Leute und schließlich musste ein Microsoft-Projektmanager zugeben, dass beim Aktualisierungsprozess für die Treiber-Blockliste etwas schief gelaufen war. Das Ganze geht aus nachfolgendem Tweet hervor, in dem Jeffry Sutherland von Microsoft auf einen Tweet von Brian in Pittsburg antwortet.

Windows driver block list not updated

Der Manager bestätigt, dass es Probleme mit der Verteilung der Blocklisten per Update gibt und dass man die Dokumentation aktualisiert habe. Microsoft werde "die Probleme mit seinem Wartungsprozess beheben, die verhindert haben, dass Geräte Updates für die Richtlinie erhalten".

Ergänzung: Dormann hat in diesem Tweet das Thema nochmals aufgegriffen und sieht sich bestätigt.

Manuelle Treiber-Blocklist-Updates

Zeitgleich mit obigem Tweet veröffentlichte Microsoft ein Tool (siehe Abschnitt Steps to download and apply the vulnerable driver blocklist binary) samt Anleitung, mit der Windows 10/11-Nutzer die seit Jahren nicht ausgerollten Blocklisten-Updates manuell bereitstellen können.

Goodin weist zudem auf eine PowerShell-Lösung von Will Dormann für Administratoren hin, mit der sich die Blocklisten-Updates manuell über WDAC aktualisieren lassen. Hierzu ist der folgende Befehl in einer administrativen Power-Shell-Konsole einzugeben:

ApplyWDACPolicy -auto -enforce

Das sind aber nur Lösungen, die diese Treiber-Blockliste einmalig aktualisieren. Administratoren müssen das Ganze zyklisch wiederholen, um die Liste aktuell zu halten. Aktuell ist unbekannt, wann diese Blocklisten-Updates automatisch verteilt werden. Dan Goodin schreibt in seinem ArsTechnica-Artikel, dass bei ihm nach einem manuellen Update der Blocklisten ein Treiber mit bekannten Schwachstellen, die von Malware ausgenutzt werden, unter Windows blockiert werden.

Der Fall wirft natürlich ein Licht auf den Umstand, dass bei der Unternehmenskultur von Microsoft einiges im Argen liegt. Ohne die Tests von Will Dormann und anderen Sicherheitsforschern hätte sich in diesem Fall nichts geändert. Microsoft hätte sein Potemkinsches Dorf der sicheren HVCI-Umgebung weiter gepflegt, aber die Systeme der Anwender wären weiterhin diesbezüglich offen wie ein Scheunentor und ungeschützt geblieben.

Ähnliche Artikel
Windows 10 V1803: HCVI verursacht plötzlich Teiberfehler 39
Fix: Windows 10-Treiber durch Kernisolierung blockiert
BlackByte Ransomware deaktiviert Sicherheitslösungen über Windows-Treiber


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit, Windows abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

35 Antworten zu Microsoft bestätigt: Windows patzt bei der Erkennung gefährlicher Treiber – Blocklisten nicht verteilt

  1. Stephan sagt:

    Die Idee, daß Gerätehersteller die Treiber machen, ist schon völlig absurd, wenn man weiß, wie ein Betriebssystem funktioniert. Ein «Recipe for Disaster» geradezu.
    Noch dümmer ist die Idee, daß die Hersteller diese Treiber selbst verteilen und die Nutzer diese selber finden und installieren sollen (statt über automatische Mechanismen).
    Aber die Tatsache, daß man diesen Blödsinn dann mit Blacklisting beheben wollte, schießt den Vogel ab.

    • mw sagt:

      Wer sonst außer den Geräteherstellern sollte denn einen Treiber programmieren? Nur die Gerätehersteller kennen ihre Geräte bis ins Detail und sind damit in der Lage entsprechende Gerätetreiber zu entwickeln. Und wer sonst sollte sie verteilen, als die Geräterhersteller, die auch die Geräte vertreiben?. Dumm ist die Idee sowas zentral oder automatisch tun zu wollen. Das geht vlt. in einem geschlossenen System, nicht aber in einer heterogenen, offen Welt. Blacklisting ist leider keine gute Maßnahme, denn das schlechte Design der Treiberschnittstelle wird damit nicht korrigiert und es öffnet der Zensur Tür und Tor. Denn einzig der Nutzer kann entscheiden, was auf seiner Maschine ausgeführt werden darf und was nicht. Open Source hilft, denn dann kann man sehen, was ein Treiber macht und was nicht.

      • 1ST1 sagt:

        Opensource hilft eben nicht. Auch wenn theoretisch jeder da reingucken kann, macht es doch augenscheinlich kaum jemand. Am Wochende ist gerade rausgekommen, dass das ganze Wifi-Konstrukt von Linux für Remotecode-Execution aus dem WLAN, der Angreifer muss nicht mal mit dem WLAN verbunden sein, möglich ist. Und den Wifi-Code pflegen richtige Linux-Koriphaen des engsten Kreises der Kernel-Entwickler…

        https://www.heise.de/news/Schwachstelle-im-Linux-Kernel-ermoeglicht-Codeschmuggel-im-WLAN-7309762.html

        Im heise-Forum hat sich dann jemand mit eher schlechten C-Kenntnissen den betroffenen Code mal angesehen und der konnte die Schwachstelle recht schnell nachvollziehen. Ist demnach recht leicht zu verstehen, aber trotzdem hat es bisher niemand der angeblichen "ist opensource und jeder kann da reingucken" Befürwortern getan. Interessant ist noch die Frage, wieviele Jahre diese Lücke schon wieder im ach so sicheren Linux offen ist. Und man bedenke, auch Android ist ein Linux und die Smartphones suchen auch ständig nach WLANs zum Anmelden, das Ding betrifft also grob milliarden mal so viele Geräte wie es Windows-Systeme mit WLAN gibt.

        • Stephan sagt:

          Sicherheitslücken findet man sowieso nicht durch Quellcode, von daher ist die Gegenüberstellung nicht sinnvoll.

          Bei Open Source können aber die Distributionen den Bug fixen, selbst wenn der Hersteller das Gerät nicht mehr unterstützt.

        • McAlex777 sagt:

          Hallo,

          @Günter ich weis ist vollkommen Offtopic, daher nur Kurz:

          @1ST1:
          >> Opensource hilft eben nicht…
          >> Am Wochende ist gerade rausgekommen

          Das Beispiel zeigt wunderbar das OpenSource offensichtlich doch wirkt: Das Problem wurde entdeckt, innerhalb von Tagen gefixt. Dank zentralen Repositorys dürften intwischen alle größeren betreffenden Distributionen gefixt sein.

          Unter Windows kann ich Glück haben das der Treiber über das Windows-Update reinkommt – ansonsten bekomm ich die Sicherheitslücke im Zweifel garnicht mit.

      • Stephan sagt:

        Die Tatsache, daß sich das in der Microsoft-Intel-PC-Welt so etabliert hat, heißt nicht, daß es jemals eine gute Idee war. Die OEMs und Nutzer hätten diese Konstellation niemals akzeptieren dürfen.
        Eigentlich müßten HP, Lenovo und Co. für jede unbehandelte Sicherheitslücke in ihren Produkten haften, so wäre das in jeder anderen Branche. Schrotthardware von unzuverlässigen Herstellern darf man gar nicht erst verbauen, wenn man sein Produkt ordentlich supporten will.

        Ansonsten sei noch dazu gesagt, daß bis auf wenige Ausnahmen wie Grafik die Hardwareschnittstellen weitgehend standardisiert sind. Es gibt überhaupt keinen Grund, warum ich für eine Maus oder einen Kopfhörer einen Treiber von irgendeinem Hersteller installieren sollte. Findet man aber oft. Die sollen gefälligst ordentliche Geräte mit Standardschnittstellen herstellen.

        • 1ST1 sagt:

          Die Mäuse funktionieren ja doch auch mit Standardtreibern. Aber wenn eine Gamer-Maus mit 104 Tasten daherkommt (mir reichen üblicherweise 3), muss halt ein Treiber dabei sein, der Windows irgendwie beibringt, was es mit so vielen Tasten sinnvoll anstellen kann.

    • Paul sagt:

      Da die Treiber von MS singiert sein müssen, ist es völlig wurscht wie die Treiber auf System kommen und wer sie geschrieben hat.
      MS hätte viel zutun, wenn sie jeden Treiber selbst schreiben müßten.
      Das ist auch völlig unüblich, da manche Hersteller keine Informationen zu ihrer Hardware herausgeben können, weil diese sofort in Konkurrenz- oder Fake- Produkte wandern würden.

      • Stephan sagt:

        Bist du sicher, daß die nicht nur der Hersteller signiert?

        Und wenn Microsoft sie sowieso signieren muß, warum verteilt Microsoft sie dann nicht automatisch systematisch?

        • Paul sagt:

          Das habe ich mich auch schon gefragt.
          Evtl. gilt das nur für Treiber die MS "geprüft" hat (HCL))?

          Ich hoffe mal das es nicht reicht das ich mir ein Cert bei Letsencrypt oder so hole
          und MS das dann akzepiert ohne selbst als CA darin zustehen.
          Dann könnte ja jeder…

          Aber ist auch wurscht, solange die certs 99+ Jahre gültig sind und nie wieder auf ein "revoke" geprüft werden,

          Aber es ist natürlich auch unbequem für den Kunden:
          Er benötigt z.B. einenWacom-Stick, der nur mit einem Kernel-Treiber läuft (warum auch immer..) und nun wird der Treiber gesperrt wegen BYOVD.
          Kunde kann erstmal nicht mehr arbeiten, auch wenn es für ihn ja keine aktute Gefahr gibt…
          Das kostet Marktanteile, weil dieser Kunde sich beim nächsten mal einen Apple kaufen wird…

    • 1ST1 sagt:

      Intel, AMD und die ganzen PC- und Board-Hersteller bieten Tools an, die muss man nur installieren, z.B. Dell/HP-Support-Assist, Intel-Driver-Assist, die einen über Treiber (und BIOS) -Aktualisierungen informieren und das Update auch durchführen können. Außerdem kommen gelegentlich auch über Windows-Updates Treiberupdates auch für Hardware, die nicht von Microsoft stammt. Bei mir wurde zuletzt das BIOS meines HP-notebooks per Windows-Update aktualisiert, das kam schneller als der HP-Support-Assistant das bemerkt hatte, was dieses Tool in dem Fall zur 2. Rückfallebene für diesen Zweck deklassiert hat. (Normalerweise ist der HP-Support-Assistant schneller).

      Wenn man möchte, dann ist es also heute schon möglich, das völlig automatisiert zu machen.

      • Stephan sagt:

        Diese Tools sind auch unvollständig und chaotisch. Der von HP hinkt zum Beispiel bei den extrem gefährlichen Schwachstellen in der Intel Management Engine mehrere Versionen hinterher.

        • 1ST1 sagt:

          Naja, dann halt noch den Intel Driver Assist installieren…

          • Buster sagt:

            Ja, und die anderen 20 Assistenten anderer Hersteller. Wie wäre es, wenn der Betriebssystemhersteller, der ohnehin schon eine Updateinfrastruktur bereitstellt, diese zentral anbietet und nutzt, um alle Treiber bereitzustellen. Es gibt noch Computernutzer, die machen nicht viele Jahre Ausbildung und haben dennoch ein Grundrecht auf die Unverletzlichkeit ihrer IT-Systeme.

  2. Anonymous sagt:

    Könnte diverse aktive Staatstrojaner, Spionagenetze, uä. aufdecken, spannend.

    • Stephan sagt:

      Habe hier schon seit Jahren kommentiert, warum signierte Programme (ohne weitere Mechanismen) keine Sicherheit bringen. Ein Angreifer kann immer eine alte verwundbare Version mitbringen und ausnutzen.

      Bei Debian bringen sie was, weil gerade nicht die Pakete sondern die Updatelisten signiert sind. Das ist Absicht. Und die Security-Listen laufen auch schnell ab aus genau demselben Grund.

      Bei Apple bringen sie was, weil die Signaturen schnell ablaufen. Die Entwickler bzw. der Store muß immer neu signieren. Und Kernel-Treiber werden von Apple immer weniger zugelassen. Die Treiber von NVidia wurden von Apple selbst verteilt, NVidia konnte nicht einfach selbst welche veröffentlichen und dem Nutzer die Verantwortung überlassen.

      Bei Microsoft hingegen ist ein 20 Jahre altes Programm weiterhin gültig, es ist ja vom Hersteller signiert. Dasselbe gilt für Treiber, die richtig hohe Berechtigungen im System haben.

      Das wurde immer als unrealistisch betrachtet. Tatsächlich ist es seit Jahren schon gelebte Praxis, wie sogar Microsoft beschreibt:
      https://www.microsoft.com/security/blog/2020/03/17/secured-core-pcs-a-brief-showcase-of-chip-to-cloud-security-against-kernel-attacks/

      • Anonymous sagt:

        Man hatte es ja mal anders versucht: NSAKEY

      • Paul sagt:

        @Stephan
        "Habe hier schon seit Jahren kommentiert, warum signierte Programme (ohne weitere Mechanismen) keine Sicherheit bringen. Ein Angreifer kann immer eine alte verwundbare Version mitbringen und ausnutzen."

        Um einen Treiber, der hohe Rechte hat,
        installieren zu können muß der Angreifer bereits Adminrechte haben. Warum sollte ein Angreifer das tun? Er hat dan doch bereits Adminrechte. (Mit denen er auch die Signierungs-Prüfung zumindest zeitweise ausschalten könnte komplett einen eigenen Treiber installieren könnte.)

        Und, falls der User den den kaputten Treiber bereits installiert hat, sollte Windows eigentlich eine Schwarze Liste haben…
        Und das das nicht passiert ist der

        S k a n d a l !

        • Stephan sagt:

          Blödsinn. Es reicht schon viel weniger, damit Windows von von sich aus einen Treiber lädt. Man denke auch an die Geschichten mit den verwundbaren Installern.

          Davon abgesehen sind Kernelrechte noch höher als Adminrechte.

          • Paul sagt:

            Der Treiber ist aber vorher installiert worden oder benötigt keine hohen Rechte.

          • Stephan sagt:

            Man muß nichts installieren. Manche Treiber werden sogar direkt vom angesteckten USB-Gerät geladen.

            Zumal Windows sowieso DLLs usw. von allen möglichen Orten lädt, nicht nur aus geschützten Orten im System, wo eine Installation erforderlich wäre.

      • 1ST1 sagt:

        Was veraltete Anwendungen angeht, das ist natürlich schwierig. Und je mehr Anwendungen man insgesamt installiert hat, um so größer wird die Challenge. Aber es gibt auch Lösungen, der MS-Appstore aktualisiert automatisch, teils auch nicht über den Store installierte Sachen. Viele Programme haben auch eigene Mechanismen. Und dann gibts da noch "winget upgrade –all –silent" was man halt monatlich als Privatuser ausführen sollte, ist schon erstaunlich wieviel das inzwischen abdeckt, und dann habe ich kürzlich für mich noch "Patch my PC" (danach googeln…) für mich entdeckt, für Privatanwender kostenlos verwendbar, was immerhin auch noch mal rund 350 Anwendungen im Blick hat und ggf. aktualisiert. Bei weniger verbreiteter Software hilft das alles allerdings auch nicht.

  3. Micha45 sagt:

    Ich nutze seit Jahren nur die Treiber von Windows Update und habe damit nie Probleme gehabt. Gibt es dort keinen Treiber dann wird das entsprechende Teil ersetzt. So einfach ist das.

    • Günter Born sagt:

      Knapp am Ziel vorbei ist halt auch daneben. Es geht nicht darum, was Du mit deinen Treibern veranstaltest und ob Du persönlich keine Probleme hast. Das Kernthema dreht sich darum, dass Microsoft seit 2020 behauptet, etwas zu schützen und bekannte Treiber mit Schwachstellen zu blockieren, was nie funktioniert hat, weil die Blocklisten nicht verteilt wurden …

      • Paul sagt:

        Emm, wieso erst seit 2020?
        Schon bei Windows 7 konnte man nicht "einfachso" unsignierte Treiber installieren.
        Ich war davon ausgegangen, das es es natürlich eine Schwarzeliste gibt, die böses Treiber aus dem Speicher kickt.
        Was sollte denn sonst dieser WooDoo?

        Oder haben sie das funktionierende System erst 2020 kaputt gemacht?

        Wird mir nicht so klar.

        • Stephan sagt:

          Seit 2020 gibt es diese automatische Blacklist angeblich.

          Aber du hast schon recht, schon vorher hätte man ordentlich Revocation implementieren müssen, sonst wäre das ganze noch blöder.
          Revocation deckt aber in erster Linie geleakte Keys ab, nicht Treiber mit bekannten Schwachstellen. Geleakte Keys, die von Malwarebanden benutzt wurden, gab es ja auch schon oft.

  4. Dennis sagt:

    Spannend ist auch:

    – Neuer Treiber kommt raus (bspw. Lenovo, HP, Intel).
    – Manuelle Installation auf Testrechner
    – Windows Update bügelt einen älteren Treiber drüber, der dann von MS statt vom Hersteller ist

    Ah, ok cool.

    • Paul sagt:

      Eigentlich sorgen diese Hersteller dafür das ihre Treiber auch bei Windows-Update stehen, wenn sie schon durch Windows Updates verbreitet werden müssen.

      M.W. wird der User auch gefragt.

      • Stephan sagt:

        Er hat aber Recht, daß da auch Chaos herrscht. Die aktuelleste Version bei NVidia ist zum Beispiel selten gleich der aktuellsten Version in Windows Update. Keine Ahnung, wer von den beteiligten daran schuld ist, aber das ist das Ergebnis.

        Mein Firmenrechner hat zusätzlich noch ein gräusliches Updatetool von HP, das auch nochmal andere Sachen installieren will. Für einen Laien wäre das unmöglich, das einigermaßen sinnvoll zu handhaben.

Schreibe einen Kommentar zu Stephan Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.