Umgehung der Windows-Treibersignierung ermöglicht möglicherweise die Installation von Kernel-Rootkits
(bleepingcomputer.com)- Selbst bei Windows-Systemen, auf denen scheinbar die neuesten Patches installiert sind, kann eine Kompromittierung des Windows-Update-Prozesses dazu führen, dass auf ältere Kernel-Komponenten zurückgesetzt wird, was in einer Umgehung der Driver Signature Enforcement und der Verteilung von Kernel-Rootkits enden kann
- Der SafeBreach-Forscher Alon Leviev demonstrierte auf BlackHat und DEFCON einen Downgrade-/Versions-Rollback-Angriff; die Übernahme von Windows Update ist weiterhin nicht vollständig gepatcht
- Ein Angreifer mit Administratorrechten kann selbst unter aktuellem Windows 11 ci.dll durch eine ungepatchte Version ersetzen und so das Laden nicht signierter Kernel-Treiber ermöglichen
- Virtualization-based Security stützt sich auf UEFI-Sperre und Registry-Einstellungen; in Konfigurationen ohne Mandatory-Flag können Registry-Änderungen oder der Austausch zentraler Dateien einen Umgehungspfad eröffnen
- Microsoft entwickelt ein Sicherheitsupdate, das alte VBS-Systemdateien ausmustert, aber wegen Untersuchungen zu betroffenen Versionen, Kompatibilitätstests und der Vermeidung von Regressionen ist unklar, wann es veröffentlicht wird
Downgrade-Angriffe, die den aktuellen Patch-Status aushebeln
- Angreifer können den Windows-Update-Prozess kontrollieren und in ein scheinbar aktuelles System alte, verwundbare Komponenten erneut einschleusen
- Das Betriebssystem wirkt weiterhin vollständig gepatcht, ist tatsächlich aber erneut Schwachstellen ausgesetzt, die bereits behoben waren
- Zu den Zielen eines Downgrades gehören DLLs, Treiber und der NT kernel
- Alon Leviev veröffentlichte das Tool Windows Downdate, um zu zeigen, dass sich benutzerdefinierte Downgrades erstellen lassen
Umgehung der Driver Signature Enforcement und Rootkit-Risiko
- Leviev demonstrierte, dass sich Driver Signature Enforcement (DSE) auch nach der Härtung der Kernel-Sicherheit noch umgehen lässt
- Gelingt die Umgehung von DSE, kann ein Angreifer nicht signierte Kernel-Treiber laden
- Solche Treiber können zur Verteilung von Rootkit-Malware genutzt werden, die Sicherheitskontrollen deaktiviert und die Erkennung einer Kompromittierung erschwert
- Leviev bezeichnete seine Methode als
"ItsNotASecurityBoundary" DSE bypass- Dabei handelt es sich um eine Form des Downgrades des Exploits ItsNotASecurityBoundary
- Dieser Exploit nutzt eine von Gabriel Landau von Elastic identifizierte Klasse von Windows-Schwachstellen der false file immutability aus und ermöglicht die Ausführung beliebigen Codes mit Kernel-Rechten
Austausch von ci.dll und Neustart-Bedingungen
- In neuer Forschung zeigte Leviev, dass ein Angreifer mit Administratorrechten den Windows-Update-Prozess missbrauchen kann, um den DSE-Schutz selbst auf einem vollständig aktualisierten Windows 11 zu umgehen
- Der Kern der Methode ist der Austausch von ci.dll, die DSE erzwingt, durch eine ungepatchte Version, die Treibersignaturen ignoriert
- Nachdem die Komponente auf eine verwundbare Version herabgestuft wurde, ist wie bei einem normalen Update-Vorgang ein Neustart des Systems erforderlich
- Leviev veröffentlichte eine Demonstration, in der er auf einem vollständig gepatchten Windows-11-23H2-System den DSE-Patch per Downgrade zurücksetzt und anschließend die betreffende Komponente ausnutzt
Umgehungspfade bei schwacher VBS-Konfiguration
- Leviev behandelte auch Methoden, um Virtualization-based Security (VBS) von Microsoft zu deaktivieren oder zu umgehen
- VBS erzeugt eine isolierte Umgebung, um essenzielle Ressourcen und Sicherheitswerte von Windows zu schützen
- Zu den geschützten Zielen gehören skci.dll, der Mechanismus für Codeintegrität im Sicherheitskernel, sowie authentifizierte Benutzeranmeldeinformationen
- VBS stützt sich in der Regel auf Schutzmechanismen wie UEFI-Sperre und Registry-Konfiguration
- Wenn VBS nicht mit dem „Mandatory“-Flag als maximaler Sicherheitseinstellung konfiguriert ist, kann es durch Änderungen an gezielten Registry-Schlüsseln deaktiviert werden
- Wenn VBS nur teilweise aktiviert ist, können zentrale VBS-Dateien wie SecureKernel.exe durch kompromittierte Versionen ersetzt werden, um die VBS-Funktion zu stören
- Dieser Zustand kann einen Pfad für die Umgehung „ItsNotASecurityBoundary“ und den Austausch von ci.dll eröffnen
Microsofts Reaktion und verbleibende Lücken
- Die bei BlackHat und DEFCON offengelegten Downgrade-Angriffe mit CVE-2024-21302 und CVE-2024-38202 wurden behandelt, aber das Problem der Übernahme von Windows Update besteht weiter
- Microsoft bewertete dies nicht als Überschreitung einer definierten Sicherheitsgrenze und kam zu dem Schluss, dass das Erlangen von Kernel-Codeausführung mit Administratorrechten keine Verletzung einer Sicherheitsgrenze darstellt
- Leviev betonte, dass Sicherheitslösungen Downgrade-Angriffe überwachen und erkennen sollten, bis Microsoft das Problem behebt
- Microsoft erklärte, aktiv an Gegenmaßnahmen zu arbeiten, um dieses Risiko zu verhindern
- Das Unternehmen entwickelt ein Sicherheitsupdate, das alte und ungepatchte VBS-Systemdateien ausmustert
- Dazu gehören die Untersuchung aller betroffenen Versionen, die Entwicklung des Updates und Kompatibilitätstests
- Zum Schutz der Kunden und zur Minimierung von Betriebsunterbrechungen müssen Integrationsfehler und Regressionen vermieden werden
- Wegen der Komplexität des Problems ist unklar, wann das Update bereitgestellt wird
- In einem Update vom 27. Oktober wurde klargestellt, dass der Angriff Administratorrechte erfordert; außerdem wurden Informationen ergänzt, um Missverständnisse zu verringern, wonach Microsoft keine Gegenmaßnahmen ergreife
1 Kommentare
Meinungen auf Hacker News
Microsoft sagt, UAC sei keine Sicherheitsgrenze; dabei geht es darum, dass manche Nutzer zu Administratorrechten aufsteigen.
Wenn es aber wie in diesem Fall auch keine Sicherheitsgrenze sein soll, von Administrator zu Kernel zu gelangen, Microsoft zugleich aber Driver Signature Enforcement als Sicherheitsfunktion bezeichnet,
dann hätte ich gern eine in sich schlüssige Erklärung dafür, warum ausgerechnet diese Funktion hier umgangen wird und das trotzdem keine Sicherheitsgrenze überschritten haben soll.
UAC ist für Nutzer gedacht, die bereits zur Administratorengruppe gehören, nicht als Funktion, durch die „manche Nutzer Administratoren werden“.
Die Sicherheitsgrenze verläuft nicht um Administratornutzer herum, sondern um Standardnutzer.
Das mag einem nicht gefallen, aber wenn man eine Sicherheitsgrenze will, sollte man Nutzer eben nicht in die Gruppe Administrators aufnehmen.
Bei Meinungsverschiedenheiten gibt es meist Unstimmigkeiten bei Definitionen und Unstimmigkeiten bei Wertesystemen.
In diesem Fall legt Microsoft Wert darauf, dieses Problem kleinzureden; wenn das ganz oben auf der Prioritätenliste steht, können ihre Entscheidungen nach diesem Maßstab konsistent wirken.
Definitionsunterschiede sind vergleichsweise leicht zu lösen. Wenn etwa alle beim Entwurf von Softwaresystemen in Begriffen von Design Patterns sprechen, aber jeder A als A′ oder A″ unterschiedlich versteht, kann große Verwirrung entstehen.
Bei unternehmensverwalteter Open-Source-Software ist es genauso.
Die eigentliche Frage ist, warum Leute ihre geistige Energie nicht in die Verbesserung von Desktop-Linux stecken, sondern kostenlose Sicherheitsforschung für Microsoft betreiben.
UAC und sudo sind beide eher Cookie-Einwilligungsdialoge auf Betriebssystemebene, und meiner Ansicht nach wäre es besser, alle drei abzuschaffen.
Nutzerbasierte Rechteerhöhung wie UAC/sudo sollte man aufgeben und stattdessen wie Android und iOS nicht Nutzer, sondern Apps sandboxen.
Interessant ist auch, dass lokale Konten mit normalen Rechten sowohl unter Windows als auch unter Linux in der Praxis fast wie root-äquivalente Rechte funktionieren.
Unter Linux werden Nutzer darauf trainiert, vor systembezogene Aufgaben sudo zu setzen, unter Windows darauf, UAC-Prompts wegzuklicken.
Wann hat sudo zuletzt jemandem aus einem anderen Grund als einem Tippfehler beim Passwort „nein“ gesagt?
UAC ist insofern etwas besser, als es eine vom System verwaltete UI ist, während sudo nur ein Programm ist; ein Angreifer könnte sudo durch ein bösartiges Shell-Alias ersetzen und so das Passwort stehlen.
In der Standardkonfiguration wäre es für Nutzer angenehmer und entspräche dem tatsächlichen Sicherheitszustand eher, sudo und UAC abzuschaffen und nicht so zu tun, als gäbe es zwischen root und dem lokalen Konto des Hauptnutzers eine harte Sicherheitsgrenze.
Auch im Terminal kann man statt sudo pkexec verwenden.
Statt beliebige Befehle als root auszuführen, können Anwendungen vordefinierte Aktionen wie
org.freedesktop.udisks2.filesystem-mountnutzen und dem Nutzer in einer lokalisierten Meldung zeigen, was die App tun möchte, damit er entscheiden kann, ob er es erlaubt.Systemadministratoren können außerdem festlegen, dass für bestimmte Aktionen wie Flatpak-Updates keine Authentifizierung erforderlich ist, oder umgekehrt bestimmte Aktionen vollständig blockieren.
Dahinter steckt die Annahme, dass der Nutzer, der die Installation durchgeführt hat, das System kontrollieren sollte. Schließlich hätte er es auch gar nicht erst installieren müssen.
sudo ist ebenso wenig wie UAC ein Mechanismus, der einer Person „nein“ sagt. Beide sind dafür da, dass eine Person „nein“ sagen kann, wenn ein Administrator eine unerwartete Verwaltungsaufgabe ausführen will.
Wer keine Administratorrechte hat, aber solche Aufgaben erledigen muss, braucht die Zustimmung eines Administrators.
Wenn es kein Ein-Personen-System ist, sollte die Person, die den Rechner einrichtet, ein eingeschränktes Konto für den Alltagsgebrauch anlegen.
Ich muss nicht oft root werden, und wenn doch, dann meist für mehrere Aufgaben hintereinander.
sudo ist auf Mehrbenutzerrechnern nützlich, etwa auf firmeneigenen und verwalteten Computern, wenn ein Administrator bestimmten Nutzern nur begrenzte privilegierte Aufgaben erlauben will.
Der Hauptgrund, immer ein anderes Konto als root zu verwenden, ist weniger Sicherheit als der Schutz vor Fehlern: Man will vermeiden, unbeabsichtigt Dateien zu löschen oder zu überschreiben.
Deshalb ist es völlig gerechtfertigt, für den seltenen Rollenwechsel ein Passwort eingeben zu müssen.
Allerdings gibt es dort keinen Trick à la „Drücken Sie zum Bestätigen Strg+Alt+Entf“.
Windows hat den Vorteil, dass man nicht alles skripten muss.
Wenn man will, kann man alle Werkzeuge mit
runas/System.Management.Automation.PSCredentialkapseln, aber in den meisten Fällen ist das nicht nötig.Die Struktur scheint so zu sein, dass der Kernel beim Öffnen einer Datei alle offenen Datei-Handles durchgeht, um kollidierende Mandatory Locks zu prüfen und so die Filesharing-Regeln durchzusetzen, dabei aber Memory Mappings mit kollidierenden Rechten nicht prüft.
Das ist zwar ein Fehler, aber die Korrektur wirkt relativ einfach.
Interessanterweise hat Linux gerade die letzten Spuren von Mandatory Locking entfernt. Jetzt gibt es kein EBUSY mehr, wenn man in eine geladene ausführbare Datei schreibt.
Spannend ist, dass dieselbe Funktion in einem Betriebssystem ein tragender Teil der Sicherheitsinfrastruktur ist und in einem anderen ein Legacy-Überbleibsel, das entfernt werden soll.
Ich bin kein Sicherheitsexperte und verstehe nur die Grundlagen, aber ich habe das Gefühl, dass hier ein konzeptionelles Modell fehlt.
Ich frage mich, warum Windows so leicht zu hacken ist.
Windows ist ein lohnendes Ziel und insbesondere in Unternehmensumgebungen das am weitesten verbreitete Desktop-Betriebssystem, daher fließen viel Zeit und Investitionen in Angriffe darauf.
Es wurde nicht genug investiert, um eine wirklich sichere Computing-Plattform zu schaffen.
Eine ideale Sicherheitsplattform müsste reproduzierbare Builds auf öffentlich überprüfbarer Infrastruktur wie fdroid bereitstellen, alle nicht vertrauenswürdigen Anwendungen in einer Sandbox virtualisieren und ein Least-Privilege-Modell umsetzen.
Derzeit ist der Sicherheitszustand maximal schlecht. In allen Ringen läuft undurchsichtiger und vermutlich unzureichend getesteter unsicherer Code, von der ME der CPU über UEFI-Komponenten bis hin zu Drittanbieter-Treibern des Betriebssystems.
SeL4 hat zwar einen vollständig verifizierten Kernel, virtualisiert aber noch nicht.
Ein großer Teil der Windows-Malware stützt sich irgendwann auf verwundbare Kernel-Treiber von Drittanbietern.
Unter Linux dagegen sind Kernel-Module von Drittanbietern selten und gelten als schlechte Praxis, unter macOS sind sie sogar ganz verboten.
Und es ist viel zu leicht, Nutzer dazu zu bringen, irgendetwas mit erhöhten Rechten auszuführen.
Erst 2022, nachdem der CERT-Analyst Will Dormann gefragt hatte, warum das so ist, wurde es angegangen.
Inzwischen wird sie regelmäßig aktualisiert, aber das ist wirklich absurd. https://www.bleepingcomputer.com/news/microsoft/microsoft-fi...
In diesem Fall stimme ich der Position von Microsoft bis zu einem gewissen Grad zu.
Administratoren können auf einem Computer beliebige Dinge tun, das ist nichts Neues.
Ich weiß nicht, ob es hier Details gibt, die die Schwere erhöhen.
Auch Raymond Chens Beitrag zu dieser Art von Angriff ist lesenswert.
https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
Wenn jemand bereits beliebige DLLs auf dem System austauschen kann, sind die Voraussetzungen dafür, dass dieser „Exploit“ funktioniert, bereits erfüllt, und an diesem Punkt ist ohnehin alles vorbei.
Die Fähigkeit, Treibersignaturen zu umgehen, dürfte dann wahrscheinlich zu den geringsten Sorgen gehören.
Der Angriff wirkt verdächtig simpel.
Er täuscht den Update-Prozess dazu, eine alte Kernel-Komponente mit bekannter Schwachstelle zu installieren.
Auch ohne Experte zu sein würde man erwarten, dass Microsoft so etwas bereits bedacht hat und Mechanismen wie eine Sperrliste oder ein Deprecation-Verfahren besitzt.
Entscheidend ist, ob die Ursache ein grundlegendes Designproblem des Betriebssystems ist oder ein Prozessversagen, bei dem defekte oder schädliche Hashes nicht an der richtigen Stelle eingetragen wurden.
Letzteres wäre deutlich leichter zu beheben, aber wie so oft scheint die etwas beschönigende Sicherheitsmitteilung eher Ersteres zu behaupten.
Kaum zu glauben, dass Microsoft widerspricht, obwohl es eine Demo gibt.
Auf diesem Vimeo-Konto gibt es viele weitere Sicherheitsfunde. Zum Beispiel eines, bei dem WhatsApp ein Python-Skript ausführt; ich frage mich, ob das echt oder Betrug ist.
Es gibt die Vorgabe, dass „Administratorprozesse und Nutzer als Teil der Trusted Computing Base (TCB) von Windows gelten und daher nicht stark von der Kernel-Grenze isoliert sind“ [0].
Es gibt auch einen anderen aktuellen Fall.
https://arstechnica.com/security/2024/03/hackers-exploited-w...
[0] https://www.microsoft.com/en-us/msrc/windows-security-servic...
Das erinnert mich an die Mühen, die alle bei [1] hatten, als Microsoft unter Windows erstmals Treibersignaturen verlangte.
Wir entwickelten einen Deep-Packet-Inspection-Treiber für [2], und auf den ersten Blick wirkte der Prozess sogar strenger als die App-Freigabe im Apple Store, zudem war die Dokumentation überhaupt nicht klar.
Wenn man bedenkt, wie viele Ressourcen Unternehmen aufgewendet haben, um Microsofts Anforderungen zu erfüllen, fühlt es sich wie ein großer Rückschritt an, dass es auf diese Weise ausgenutzt wurde.
Schwachstellen wird es immer geben, aber es wäre beruhigend gewesen, wenn jemand das früher entdeckt hätte.
Applaus für Alon Leviev und SafeBreach, die es gefunden haben.
[1] https://www.nektra.com/
[2] https://www.verizon.com/business/en-nl/products/security/man...
Dass es „möglich ist, als Administrator Kernel-Code-Ausführung zu erlangen“, heißt am Ende nur ganz banal: Ein Root-Benutzer kann ein Rootkit installieren.
Man darf nur nicht vergessen, dem Ganzen einen coolen Namen zu geben. Ach ja, der Forscher hat bereits ein Tool namens Windows Downdate veröffentlicht.
Die 0xF Minuten Ruhm sind also gesichert – insofern gut gemacht.
Auch Benutzerkonten sind nur Objekte innerhalb des Betriebssystems, und selbst wenn man das Superuser-Konto einschränkt, kann man ein Betriebssystem entwerfen, das bestimmte Regeln für alle Benutzerkonten erzwingt.
Es kann zum Beispiel legitime Gründe geben, bestimmte Geheimnisse wie bei einem TPM auch dann zu schützen, wenn ein Administratorkonto kompromittiert wurde, oder zu verhindern, dass ein Administrator das System versehentlich in einen nicht mehr bootfähigen Zustand versetzt.
Ein kontroverseres Ziel ist auch das Erzwingen von DRM.
Genau das versucht Microsoft bei Windows: Das Betriebssystem soll verhindern, dass ein Administratorkonto in den Kernel eingreift oder ein Rootkit installiert.
In dieser Diskussion ist es immer wichtig, zwischen dem Administrator-Benutzerkonto innerhalb des Betriebssystems und der „Administrator“-Person mit physischem bzw. Hardware-Zugriff zu unterscheiden.
0xFsteht, obwohl 15 einfacher gewesen wäre.Es ist nicht falsch, aber eine merkwürdige Wahl, die neugierig macht. Ich frage mich, ob es einfach Stil war.
Wenn ich Windows benutzen muss, gehe ich immer davon aus, dass der Rechner bereits kompromittiert ist.