[English]Ein Sicherheitsforscher von SafeBreach hat sich die Update-Architektur von Microsoft Windows vorgenommen. Dabei ist er auf Schwachstellen in der Update-Funktion des Betriebssystem gestoßen (es sind im Grunde gravierende Design-Fehler), die einen Downgrade-Angriff ermöglicht. Ein Angreifer kann so bereits installierte Sicherheit-Updates zurückrollen, und sogar die Installation weiterer Updates verhindern. so die vermeintlich gepatchte Schwachstellen weiter existieren. Diese Manipulation ist nicht erkennbar und wird nicht gemeldet. Microsoft ist seit Februar 2024 darüber informiert, hat aber noch nichts im Hinblick auf ein Sicherheitsupdate unternommen. Ergänzung: Wenn meine Ersteinschätzung zutrifft, ist das Ganze auch nicht mit einem kleinen Patch zu erledigen, sondern rüttelt an den Grundfesten der Betriebssystemarchitektur. Aktuell hat Microsoft nur zwei Security Advisories zur Mitigation von 0-days zeitnah veröffentlicht.
Anzeige
Was sind Downgrade-Angriffe?
Es handelt sich um eine clevere Angriffsmethode, die im Prinzip auf eine sehr unschöne Geschichte hinaus läuft, die die Sicherheit von Windows gefährdet. Bei Downgrade-Angriffen wird die Software (also hier Windows) gezwungen, auf eine ältere, und durch Schwachstellen anfällige Version zurückzukehren. Bei Windows wäre dies beispielsweise, dass Updates deinstalliert werden, und die Installation neuer Updates verhindert wird. Zudem könnte der Angriff so erfolgen, dass der Anwender dies nicht mal bemerkt, weil die Software meldet, auf dem neuesten Stand zu sein.
MS hat BlackLotus Downgrade-Angriffe gesperrt
Mit der Sicherheit von Windows ist es nicht immer zum Besten bestellt. Im Jahr 2023 tauchte das berüchtigte BlackLotus UEFI-Bootkit auf, das den Windows-Bootmanager auf eine ältere Version herabstuft, um Secure Boot zu umgehen (siehe BlackLotus UEFI-Bootkit überwindet Secure Boot in Windows 11). Sicherheitsforscher von ESET hatte das Problem gefunden.
Im Kontext des BlackLotos UEFI-Bootkits hat Microsoft reagiert. Einmal gibt es einen Patch zum Schließen der Schwachstelle. Und Windows ist mit einem Schutz vor ungewolltem Downgrade des Secure Boot nachgerüstet worden.
Downgrade-Angriffe über Windows Update
Sicherheitsforscher Alon Leviev von den SafeBreach Labs hat sich, auf Grund des Black Lotus-Angriffs, den Update-Prozess von Microsoft Windows genauer angesehen. Er stellt sich die Frage, ob Downgrade-Angriffe, wie man sie bei BlackLotus gesehen hat, per Windows Update möglich sind. Auf der Suche nach einem unentdeckbaren Downgrade-Fluss untersuchten die Sicherheitsforscher dann Windows Update genauer. Der Update-Mechanismus ist wohl die am wenigsten verdächtige Einheit für die Ausführung von Downgrade-Angriffen.
Anzeige
Dabei ist Leviev auf Schwachstellen gestoßen, die es ihm ermöglichen, installierte Sicherheitsupdates zu deinstallieren und so bereits geschlossene Schwachstellen aufzureißen. Er hat also die Achillesferse von Windows Update identifizierte, die es ermöglicht, die vollständige Kontrolle über den Update-Vorgang zu übernehmen.
Dem Sicherheitsforscher ist es gelungen, Downgrade-Updates für Windows zu erstellen und dabei alle Überprüfungsschritte während der Update-Installation zu umgehen. Dies beinhaltet auch die von Windows erzwungene Durchsetzung der Verwendung von Trusted Installer, schreibt Levie. So gelang es dem Sicherheitsforscher, das Betriebssystem in einen älteren Patch-Versionsstand zurück zu rollen.
Mit den von dem Sicherheitsforschern entwickelten Techniken gelang es, kritische Betriebssystemkomponenten, einschließlich DLLs, Treiber und sogar den NT-Kernel, bezüglich des Update-Status herunterzustufen. Anschließend meldete das Betriebssystem, dass es vollständig aktualisiert wurde und nicht in der Lage war, künftige Updates zu installiere. Dabei konnten die Wiederherstellungs- und Scan-Tools keine Probleme erkennen.
Die Forscher haben dann die Windows Interna weiter gesucht und festgestellt, dass auch der gesamte Virtualisierungs-Stack gefährdet ist. Es gelang den Hypervisor von Hyper-V, den Secure Kernel und den Isolated User Mode-Prozess von Credential Guard erfolgreich herunter zu stufen. Dies ermöglicht es, frühere Schwachstellen bei der Privilegienerweiterung aufzudecken.
Vorstellung auf der BlackHat 2024 in den USA
Sicherheitsforscher Alon Leviev von den SafeBreach Labs stellt dieses Problem auf der gerade stattfindenden BlackHat 2024-Konferenz vor. Für den 7. August 2024 ist ein Beitrag Windows Downdate: Downgrade Attacks Using Windows Updates zum Thema angekündigt.
Leviev hat zum 7. August 2024 in der oben verlinkten Session gezeigt, welche Schwachstellen diesbezüglich existieren. Wenn ich es richtig interpretiere, sind diese Schwachstellen für unprivilegierte Nutzer ausnutzbar [Nachtrag: Initial hatte Leviev aber wohl Administratorrechte]. O-Ton des Sicherheitsforschers:
Durch ein Downgrade war ich in der Lage, einen vollständig gepatchten Windows-Rechner für Tausende von Sicherheitslücken aus der Vergangenheit anfällig zu machen, behobene Sicherheitslücken in Zero-Days zu verwandeln und den Begriff "vollständig gepatcht" auf jedem Windows-Rechner der Welt bedeutungslos zu machen.
Leviev hat auch auf der defcon einen Beitrag geliefert, der über diesen Link abrufbar ist.
Kein Patch verfügbar
Microsoft weiß seit Februar 2024 um das Problem, da das Unternehmen von Leviev informiert wurde. Als der Sicherheitsforscher die Schwachstelle meldete, wurde er darüber informiert, dass Microsoft noch nichts im Hinblick auf ein Sicherheitsupdate unternommen habe – das Ganze ist nach bisherigen Erkenntnisse bis zum heutigen Tag ungepatcht.
Microsoft hat lediglich CVE-2024-21302 und CVE-2024-38202 veröffentlicht — und folgendes Statement an Leviev geschickt:
"We appreciate the work of SafeBreach in identifying and responsibly reporting this vulnerability through a coordinated vulnerability disclosure. We are actively developing mitigations to protect against these risks while following an extensive process involving a thorough investigation, update development across all affected versions, and compatibility testing, to ensure maximized customer protection with minimized operational disruption."
Mehr Details verfügbar
Ergänzungen: Der obige Beitrag ist die Nacht entstanden und wurde zwischenzeitlich in einzelnen Formulierungen nochmals überarbeitet. The Register hat diesen Beitrag (inzwischen hierhin verlagert) zum Sachverhalt veröffentlicht, weil Sicherheitsforscher Leviev in einem Interview vorab einige Informationen geteilt hat.
Bei The Register habe ich zwischenzeitlich auch den Link zum Artikel Windows Downdate: Downgrade Attacks Using Windows Updates vom 7. August 2024 im Safebreach-Blog gefunden, wo weitere Details genannt werden. Nachfolgender Tweet verlinkt mittlerweile auch (den gab es die Nacht noch nicht).
Der Beitrag ist sehr lesenswert, weil er Ross und Reiter benennt und ausführt, wie Angriffe über den Windows Update-Mechanismus (Action-Lists, Pending.xml etc.) durchgeführt werden können. Bei der Analyse des Sachverhalts ist der Sicherheitsforscher beispielsweise auf folgendes gestoßen:
- Nur die Katalogdateien, die die Updates enthalten, sind digital signiert.
- Die Dateien für das Manifest und die MUMs sind nicht explizit signiert, sondern werden von den Katalog-Dateien signiert.
- Beim Update verwendete Differentialdateien sind ebenfalls nicht signiert.
Die Differentialdateien kontrollieren auch den Inhalt der endgültigen Aktualisierungsdatei. Gelingt es, diese Dateien zu manipulieren, hat man quasi den Schlüssel zum Tresor. Dem Sicherheitsforscher ist es gelungen, Windows Update mit einem Downgrade-Angriff komplett zu übernehmen hier die Kernaspekte:
- Fully undetectable/Völlig unauffindbar: Da der Downgrade-Angriff auf legitime Weise durchgeführt wurde, sind keine bösartigen Aktivitäten entdeckbar.
- Invisible/Unsichtbar: Beim Downgrade-Angriff wird das System technisch "aktualisiert", so dass es vollständig aktualisiert erscheint.
- Persistent/Hartnäckig: Der Sicherheitsforscher hat entdeckt, dass der Aktionslisten-Parser poqexec.exe nicht digital signiert ist. Daher konnte er einen Patch erstellen, der leere Updates installiert, was bedeutet, dass alle neu verfügbaren Updates fehlerhaft installiert werden (nach außen sieht alles ok aus, aber der Patch wird nicht installiert).
- Irreversible/Unumkehrbar: Der Sicherheitsforscher hat auch festgestellt, dass das Integritäts- und Reparaturprogramm SFC.exe nicht digital signiert ist. Durch eine gepatchte Version sorgte der Sicherheitsforscher dafür, dass SFC keine Beschädigungen mehr erkennt.
Es gibt zwar noch DISM.exe, welches aber Beschädigungen im Komponentenspeicher erkennt. Daher gibt es keinen Grund dieses Programm zu ändern, der Komponentenspeicher ist ja intakt – der Downgrade-Angriff über Windows Update setzt ja im Update-Installationsprozess an und sorgt dafür, dass der Trusted Installer die Fixes nicht ausführen kann – beim Update auszutauschende Dateien werden einfach nicht mehr aktualisiert, aber Windows meldet ein erfolgreich installiertes Update.
Obige Informationssplitter zeigen, warum Microsoft das "Problem" nicht mal schnell patchen kann. Aktuell kann ich noch nicht abschätzen, wie einfach der Angriff ist (beispielsweise: ist er remote oder nur lokal durchführbar). Zumindest deutet sich an, dass die gesamte Update-Architektur von Windows wackelt. Microsoft fallen die Versäumnisse der letzten Jahrzehnte mächtig auf die Füße, so meine Einschätzung.
Für Cyber-Angreifer stellt sich nur die Frage: Wie hoch ist der Aufwand, und kann ich auf einfachere Art zum Ziel einer Penetration kommen. Aber staatliche Akteure werden sich die neuen Erkenntnisse sehr genau anschauen und entsprechende Strategien entwickeln. Mal schauen, wie Microsoft reagiert – es könnte das nächste große Erdbeben im Windows-Universum geben.
Microsoft hat zwar eine Secure Future Initiative angekündigt (siehe Microsoft Ankündigung einer Secure Future Initiative). Ich fürchte, das wird verpuffen bzw. es ist viel zu spät. Schaue ich mir die nachfolgende Link-Liste zu Beiträgen hier im Blog an, gibt es inzwischen doch alle paar Wochen einen großen Vorfall bzw. eine Katastrophe. Mit obigen Erkenntnissen können Administratoren nicht mehr sicher sein, dass ein als "voll gepatcht" angezeigtes Betriebssystem auch wirklich auf diesem Stand ist. Es gilt: Augen zu und hoffen. Bleibt die Frage: "Wer ist der Elefant im Raum?"
Ähnliche Artikel
BlackLotus UEFI-Bootkit überwindet Secure Boot in Windows 11
Windows und das (BlackLotus) Secure Boot-Desaster: Wie ist bei euch der Status?
KB5025885: Secure Boot-Absicherung gegen Schwachstelle CVE-2023-24932 (Black Lotus)
Ausfall von Microsoft 365 und weltweite Störungen – wegen CrowdStrike-Update, was zum BSOD führt?
Wieso weltweit zahlreiche IT-Systeme durch zwei Fehler am 19. Juli 2024 ausfielen
CrowdStrike-Analyse: Wieso eine leere Datei zum BlueSceen führte
Nachlese des CrowdStrike-Vorfalls, der bisher größten Computerpanne aller Zeiten
CrowdStrike: Untersuchungsbericht; Schadenssumme und Entschädigungen; Schuldzuweisungen
Microsofts Analyse des CrowdStrike-Vorfalls und Empfehlungen
China-Hacker (Storm-0558) in Microsofts Cloud, Outlook Online-Konten gehackt
Nachlese zum Storm-0558 Cloud-Hack: Microsoft tappt noch im Dunkeln
Nach CISA-Bericht zum Storm-0558-Hack stellt Microsoft Kunden erweitertes Cloud-Logging bereit
GAU: Geklauter AAD-Schlüssel ermöglichte (Storm-0558) weitreichenden Zugang zu Microsoft Cloud-Diensten
Hewlett Packard Enterprise (HPE) von Midnight Blizzard seit Mai 2023 gehackt
Whistleblower: Microsoft ignorierte Warnungen vor Azure AD-Bug; wurde 2020 bei SolarWinds-Hack ausgenutzt
Microsoft übt sich in Schadensbegrenzung bei Kongress-Anhörung (13.6.2024): Sicherheit habe Vorrang vor KI
Microsoft Ankündigung einer Secure Future Initiative
Microsoft durch russische Midnight Blizzard gehackt; E-Mails seit Nov. 2023 ausspioniert
Wie Midnight Blizzard-Hacker in Microsofts E-Mail-System eindringen konnten
Microsoft bestätigt: Russische Spione (Midnight Blizzard) haben Quellcode beim Zugriff auf Systeme gestohlen
Microsoft: Neues vom Midnight Blizzard-Hack – auch Kunden möglicherweise betroffen
Midnight Blizzard-Hack bei Microsoft: US-Behörden und Großkunden suchen Alternativen
Midnight Blizzard-Hack-Benachrichtigung: Microsoft schickt Kunden Mail die in SPAM-Ordnern landet
Anzeige
Windows ist doch nur noch ein Witz.
Löchrig wie ein schweizer Käse.
Wenn es eine gute alternative zu Windows Exchange geben würde, dann wäre bei uns schon alles auf Linux umgestellt.
Die gibt es doch! Wo ist das Problem?
So geht das nicht weiter Günter. Du fängst ja an Horrorszenarien zu verbreiten. Hier nimm eine Pille, Nimm dieses übrig gebliebene Windows-Kissen von der Comdex, schau Dir drei mal das "Developer" Video von Steve Ballmer an und kipp eine Lage teuer eingekauftem Schlangenöl über alles. Mit {Cloud, Blockchain, NFT, KI} wird alles gut…
Alles nur Hokuspokus und VIEL zu klompiziert: seit Anbeginn der eNTe können Dateien per "PendingFileRenameOperations", seit mindestens XP auch noch "PendingFileRenameOperations2", beim Systemstart ersetzt, verschoben oder gelöscht werden. Ausgeführt werden diese Aktionen vom "Session Manager" alias SMSS.exe, dem ERSTEN, vom Kernel gestarteten und NATIVEN Benutzer-Prozess.
Apropos "Downgrade": da Windows Update überholte/ersetzte Updates und Treiber in den Unter-Verzeichnissen des "Side-by-Side Stores" %SystemRoot%\WinSxS\ sowie des "Driver Staging Store" %SystemRoot%\System32\DriverStore\ NICHT löscht lungern dort beliebig viele VERALTETE, UNSICHERE, wunderbar für Angriffe missbrauchbare System-Komponenten!
Und das Thema schon auf der Blackhat vorgestellt, und live vorgeführt, was man damit alles anstellen kann? An MS gemeldet? Fänd ich gut!
In der Sache gebe ich Dir Recht, man muss da aber auch irgendwo anerkennen, dass diese für (Offline) Rollbacks bei fehlgeschlagenen Updates vorgehalten werden. Kann man bestimmt schöner lösen und vor allem für die Anwender transparenter lösen, das steht außer Frage.
Ein regelmäßiges Dism.exe /online /Cleanup-Image /StartComponentCleanup mildert diese Selbst-Vermüllung etwas…
"Kann man bestimmt schöner lösen und vor allem für die Anwender transparenter lösen, …"
AMEN!
Das Problem ist (wie bei M$FT leider üblich) HYSTERISCH gewachsener Schrott!
0) Die mit Windows NT eingeführten NTFS-Zugriffsrechte lauteten bis NT4 VOLLZUGRIFF für ALLE (noch heute werden Dateien "ausführbar" angelegt).
1) M$FT hat ("Dank" VOLLZUGRIFF für die Benutzergruppe JEDER) Entwicklern^WÜBELSTEN FRICKLERN freie Hand gelassen, ihren Schrott im "Windows"- bzw. "System"-Verzeichnis %SystemRoot%\[System32\] zu installieren und dabei Systemdateien zu überschreiben: die Folge war u.a. "DLL-Hölle"
2) Zum Entschärfen der "DLL-Holle" haben sie mit Windows XP (und nachträglich Windows 2000) den "Side-by-Side Store" &SystemRoot%\WinSxS\ eingeführt und durch die Manifest-Hölle ersetzt (Pest->Cholera, Teufel->Belzebub)
3) Mit Vista hat M$FT "Component Based Servicing" eingeführt, und STRUNZDUMMERWEISE den "Side-by-Side Store" dafür vergewaltigt (wegen 0) sind alle dort herumlungernden Dateien ausführbar).
4) Ebenfalls mit Vista hat M$FT den "DriverStore" als "STAGING AREA" eingeführt, aus dem Treiberdateien an ihren Einsatzort KOPIERT werden (wegen 0) sind alle dort herumlungernden Dateien ausführbar) und ein Rollback erlaubt.
5) VOLLIDIOTEN von AMD, Intel und nVIDIA frickeln seit Jahren Grafiktreiber mit HUNDERTEN Megabytes; da deren SAUBERE Installation Speicherplatz doppelt belegt und ein paar Sekunden länger dauert haben sie den "DriverStore" vergawaltigt und führen ihren Schrott jetzt dort direkt aus (womit KEIN Rollback mehr möglich ist).
EINMAL mit Profis arbeiten…
so siehts aus…
zu 5) in Ergänzung: Das ist auch häufiger Quell für wirklich dumme PE (ich habe da so ein paar 200 MB Razor "Maustreiber" in Erinnerung (sind mehr eher Werbe-Telemetrie-Wir-greifen-alles-ab-Treiber)
Ich sehe wir haben die gleiche Meinung hinsichtlich Softwareentwicklern und der IT Branche ;-)
ad 5) Microsofts GLORREICHE WHQL-Prüfung/Zertifizierung lässt Treiber, die den "DriverStore" durch in-situ-"Installation" aushebeln, passieren.
Nicht ALLE Softwareentwickler sind üble Frickler, nur gefühlte 99%
Das ist in der Tat eine ziemlich üble Info. Die Blackhat ist zwar jetzt gerade vorbei und die Info in der Welt, der Hack ist sicher aber so komplex nachzumachen, dass potentielle Angreifer noch eine Weile brauchen, um so weit zu sein. Noch besteht also die Hoffnung, dass MS inzwischen was vorbereitet hat, nächste Woche ist ja Patchday.
Wohl dem, der seine Umgebung mit einem Inventarisierungstool monitort und so mit einem einfachen Report die Versionsstände der Systeme abrufen kann, da fällt so ein Downgrade dann schnell auf. Z.B. mit Lansweeper kann man das mit den monatlich erscheinenden Patchday-Repots, da sieht man auf einen Blick welche Systeme noch/wieder nicht uptodate sind.
Sofern die Version auch fällt…
>>> Z.B. mit Lansweeper kann man das mit den monatlich erscheinenden Patchday-Repots, da sieht man auf einen Blick welche Systeme noch/wieder nicht uptodate sind. <<<
Sie glauben wohl an den Weihnachtsmann. community.lansweeper.com ist voll von Fällen, in denen Benutzer auch schon ohne Rookit genügend Probleme mit dem Version Reporting haben.
Aus
https://www.bleepingcomputer.com/news/microsoft/windows-update-downgrade-attack-unpatches-fully-updated-systems/
"
As the company explains, the CVE-2024-38202 Windows Backup privilege escalation vulnerability enables attackers with basic user privileges
to "unpatch" previously mitigated security bugs or bypass Virtualization Based Security (VBS) features.
Attackers with admin privileges can exploit the CVE-2024-21302 privilege escalation flaw to replace Windows system files with outdated and vulnerable versions.
"
Aus
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21302
"
Microsoft was notified that an elevation of privilege vulnerability exists in Windows based systems supporting Virtualization Based Security (VBS) including a subset of Azure Virtual Machine SKUS;
enabling an attacker with administrator privileges to replace current versions of Windows system files with outdated versions.
"
Aus
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38202
"
Microsoft was notified that an elevation of privilege vulnerability exists in Windows Backup, potentially enabling an attacker with basic user privileges to reintroduce previously mitigated vulnerabilities
or circumvent some features of Virtualization Based Security (VBS).
However, an attacker attempting to exploit this vulnerability requires additional interaction by a privileged user to be successful.
"
Danke, der obige Beitrag ist eh "work in progress" – als ich die Ursprungsfassung die Nacht verfasst habe, lag nur die Black Hat 2024-Ankündigung vor – nun gibt es bereits die verlinkten Beitrag des Sicherheitsforschers mit Details und zwei CVEs von Microsoft zu 0-day-Schwachstellen.
> Virtualization Based Security (VBS)
Heuristik für's alt werden. Ich kannte die Abkürzung VBS bisher nur im Kontext von Visual Basic Script
Ging mir auch so – da VBS (Visual Basic Script) deprecated ist, hat man das Kürzel VBS recycled und es jetzt für Virtualization-based Security.
vbs war und ist nicht mehr als eine filename extension von Dateien die VBScript Code beinhalten. Von Microsoft-Offiziellen (vs. Kunden die in Supportforen Fragen stellen und sich ausbreiten) wurde VBS nie als Abkürzung für VBScript verwendet.
mag zwar in der Theorie so sein, die Realität ist aber eine andere.
Bei der Gelegenheit auch schön (oder eben ganau auch nicht) zu wissen:
Classic ASP (also VBScript) inkl. dem Zugriff auf jede beliebige SystemDLL via ISAPI bleibt obwohl seit Jahrzehnten deprecated, weiterhin im Windows 2025 Server enthalten.
Ist das nicht schön? Ich kann meine VB6 DLLs via ASP aus dem Jahr 1999 bis ins Jahr 2030 weiter im Netz betreiben. Ich habe sogar noch einen Kunden mit einem angemieteten 2003 Rootserver in einem NOC, der die vergammelte Scheisse auch noch nutzt, den ich hier öffentlich natürlich nicht verlinke ;-)
"Attackers with admin privileges can exploit the CVE-2024-21302 privilege escalation flaw to replace Windows system files with outdated and vulnerable versions."
Diese Aussage von M$FT/MSRC ist (wieder mal) VÖLLIG FALSCH und hanebüchener Schwachsinn: ein Benutzer mit Administrator-Privilegien kann IMMER die Privilegien Backup, Restore, Security und TakeOwner aktivieren, und ebenso beliebige Programme unter SYSTEM- oder TrustedInstaller-Konto ausführen.
Siehe https://skanthak.hier-im-netz.de/tidbits.html#process, https://skanthak.hier-im-netz.de/tidbits.html#twiddler sowie https://skanthak.hier-im-netz.de/tidbits.html#sysiphos
Die Frage, die ich mich stelle: Wie weit und oft trifft diese Lücke auf? Je nach Einstellungen (GPO/Registry/AD), wie könnte ein Rollback möglich sein, ohne dass der Anwender bzw. der Admin nichts davon bemerken? Also, ich finde die Panikmache zwar berechtigt, aber die Voraussetzungen, um diese Attacke zu betreiben, sind schon sehr hoch, denn ohne Admin-Rechte geht diese mal ganz und gar nicht. Ich denke, dass bei der Suche nach Haaren auf die Eier stets Lücken in Anwendungen zu finden sind. Und das wird auch so bleiben, selbst mit Quantentechnologie, sogar vielleicht noch schlimmer. Bei den Millionen Programmierzeilen versuche mal keine Haare zu finden. Viel Spaß dabei.
Du hast zwar insofern Recht, als bisher keine Ausnutzung bekannt ist – wegen "work in progress" laufen ja ständig neue Informationen in obigen Text ein. So sind von Microsoft zwei 0-Day-Schwachstellen adressiert, die diese Administratorberechtigungen ermöglichen.
Auf meine hier im Blog häufiger angesprochenen UAC-By-Passing-Methoden und das Problem, dass alle Nutzer standardmäßig mit Administratorkonten unter Windows unterwegs sind (wenn beim Anlegen nichts anderes vorgegeben wurde) und nur per UAC halbwegs geschützt sind, mag ich schon gar nicht mehr hinweisen.
Was an obigem Sachverhalt der "shocking part" ist: Es gibt die Schönsprechseite des MS-Marketing mit "alles sicher, VBS, Secure Boot etc. als Schutz). Und dann schaut jemand genauer hin und sieht ein verrottetes Fundament, so dass das Gebäude jeden Moment einstürzen kann. Die Tage habe ich über Schwachstellen in SmartScreen und Smart App Control berichtet, zwei beworbene Sicherheitsfeatures, die man einfach so umgehen kann.
Ich weiß, hilft dem Admin, der den Klump in Funktion halten soll, nicht weiter. Die IT-Entscheider hätte vor Jahren reagieren müssen und haben es immer noch nicht kapiert, wie neueste Entwicklungen bei kommunaler IT in Bayern und BaWü zeigen. Und da sind wir wieder beim "Elefant im Raum".
"Auf meine hier im Blog häufiger angesprochenen UAC-By-Passing-Methoden und das Problem, dass alle Nutzer standardmäßig mit Administratorkonten unter Windows unterwegs sind (wenn beim Anlegen nichts anderes vorgegeben wurde) und nur per UAC halbwegs geschützt sind, mag ich schon gar nicht mehr hinweisen."
Im Privatbereich und bei n>10 Betrieben (ich nehme mal 10 an) ohne vernünftige IT-Administration mag das zu 99% so sein, aber heutzugae in besseren Umgebungen eben nicht mehr, außer evtl. einige einflussreiche/trotzige Einzelbenutzer.
Ist es wirklich so, dass die Administratoren mit Standardbenutzerkonten unterwegs sind? Solange ich nicht in die Einstellungen-Seite muss, lässt sich das per UAC regeln. Aber mir fällt schlicht auf, dass die in der Systemsteuerung enthaltene Möglichkeit, eine UAC-Abfrage für bestimmte Befehle auslösen zu lassen, seit Windows 10 in den Einstellungen fehlt. Da werden unter einem Standard-Benutzerkonto schlicht keine Links in den Einstellungen eingeblendet, wenn die Funktion administrative Berechtigungen benötigt.
Jetzt zähle ich mal 1+1 zusammen: Ein Admin kann zwar vieles per PowerShell und GPOs regeln. Aber geht der niemals nicht in die Einstellungenseite? Falls Karl Valentin Recht hatte, wird der Admin genervt sein, weil die gesuchten Einträge im Fall der Fälle fehlen – und ist beim nächsten Mal mit einem Benutzerkonto aus der Gruppe der Administratoren unterwegs. Ich mag mich aber irren.
Zumindestens wenn die Kisten im AD sind und die User im AD angelegt werden, und in der lokalen "Administrator" Gruppe nicht absichtlicherdummerweise z.B. die Gruppen "everyone", "authenticated Users", "Domain Users" eingetragen wurden, dann nicht. Dann wären es Einzelberechtigungen oder irgendwelche Gruppen mit bestimmten Usern (Entwickler sieht man da gerne, die glauben ja oft, alles können zu müssen) – zum Glück und leider gleichzeitig ist Windows ja so flexibel dass man sowas sehr klug oder sehr dumm regeln kann.
So sieht's aus…
Meine natürlich rein subjektive, aber über die letzten 25 Jahre verfestigte Beobachtung: Die typischen WWW (Wald-Wiesen-Windows) Admins im typischen mittelständischen Unternehmen arbeiten nicht nur mit vollen lokalen Adminrechten sondern meist auch als Mitglied der Domänen-Admingruppe. Manchmal zusätzlich auch noch die Geschäftsführer.
Gehe in eine Arzt-Praxis oder ein Krankenhaus und prüfe/frage, ob dort JEDER Benutzer sein eigenes STANDARD-Benutzerkonto hat, oder die vom Patientenverwaltungssystem missbrauchte (SQL-)Datenbank Zugriffe nur nach "need to know"-Prinzip erlaubt.
Solange der Standardbenutzer keine Adminrechte hat ist das doch halb so wild. Man kann nur nicht mehr nachvollziehen, wer wann was gemacht hat, sprich Audit geht schief.
Damit Admins nicht mit unnötigen Rechten unterwegs sein müssen gibt es seit ca..55 Jahren den Befehl "su" resp.."sudo"
Auch darf ein Administrator niemals Emails mit seinem priviligiertem Account lesen. Er darf das exe dafür gar nicht starten…und er hat auch kein Postfach. Irre, gell
Ein Administrator ohne Email? Wie soll dass denn gehen und warum?
Uuups. Da habe ich mich jetzt aber vertan.
An einem su bastelt sie domimante Weltfirma Microsoft erst seit 2 Jahren und bekommt es nicht him.
Klar, eine neue Lage Schlangenöl verkaufen trägt mehr zu den Milliarden Gewinnen bei
..
irgendwas ist immer
>>> seit ca..55 Jahren den Befehl "su" resp.."sudo" <<<
Jo, und seit ca. 25 Jahren gibt es SELinux, welches Opas Lieblinge su/sudo über Bord geworfen hat.
Da mal drüber nachdenken, statt das schimmlige Zeugs als Vorbild für das nicht minder schimmlige Windows verkaufen zu wollen.
In vernünftigen Umgebungen, egal was für ein Betriebssystem hat eine natürliche Admin-Person mehrere Accounts, je nach dem was er machen will/muss. Priviligerte Accounts (root, admin, …) dürfen nicht auf beliebige Internetadressen zugreifen, wenn überhaupt welche außer Updaterepositories der jeweiligen Distribution, und sie haben auch keine Emailadresse. Dafür gibts einen normalen unpriviligerten Account.
>>> bei der Suche nach Haaren auf die Eier stets Lücken in Anwendungen zu finden sind. <<<
Ist das eine fremde Redensart? Wie lautet sie im Original? Ich kann nur sagen, dass Anwendungen heutzutage mindestens soviele Lücken aufweisen wie ich Haare auf den Eiern habe.
It's a feature.
Windows ist voller solcher Features. Die nationalen Interessen gehen vor.
Dazu Microsoft (bevor diese Details noch unter den Tisch fallen): "For exploitation to succeed, an attacker must trick or convince an Administrator or a user with delegated permissions into performing a system restore which inadvertently triggers the vulnerability." – soviel zum Thema "als normaler User möglich". Ganz ohne Weiteres also nicht. Quelle: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38202
Dir ist bekannt/bewusst, wie EINFACH ein unprivilegierter Standard-Benutzer an Administrator-Privilegien gelangen und dann "SeRestorePrivilege" aktivieren kann?
"DEFENSE IN DEPTH — the M$FT way"
Zu den Katalog-Dateien mit digitalen Sicknaturen siehe https://skanthak.hier-im-netz.de/quirks.html#quirk13
ok, ich frage Mal für alle: wie einfach ist einfach?
Z.B. durch "Vergiften" des von unter SYSTEM-Konto laufenden Prozessen missbrauchten TEMP-Verzeichnisses %SystemRoot%\Temp\
Oder ein von einem unprivilegierten Standardbenutzer "dank" UAC-Prompt mit Administratorrechten gestartetes (typischerweise Installations-) Programm, das STRUNZDUMMERWEISE DLLs oder Programme aus einem unsicheren Verzeichnis lädt.
ok. Dann sehe ich das nicht als "einfach".
An meinem W11 habe ich im Benutzerkontext nicht mal Lese Rechte am %Temp% Ordner. Es kommt sofort eine Frage zur UAC Elevation und die CMD meldet "Datei nicht gefunden".
Den Ordner und die darin laufenden Prozesse kann ich nicht einfach manipulieren.
Für den UAC Prompt benötige ich ein Konto das Mitglied der Administratoren ist, das dann den Job ausführt. Das hat der "normale" Benutzer im AD nicht.
Heimanwender sind idr in der Gruppe der Administratoren und dann reden wir von "Hacken als Admin" und das geht logischerweise immer.
Im Firmenumfeld mit AD Benutzern, die nur Benutzer sind braucht es schon PrintNightmare oder andere Lücken und das sehe ich nicht als "einfach".
"An meinem W11 habe ich im Benutzerkontext nicht mal Lese Rechte am %Temp% Ordner. Es kommt sofort eine Frage zur UAC Elevation"
AUTSCH: "use the right tool for the job", NICHT den File Explorer!
Unprivilegierte Benutzer dürfen in %SystemRoot%\Temp\ Dateien sowie Unterverzeichnisse (und darin wieder Dateien und Unterverzeichnisse) anlegen; Administratoren plus SYSTEM künnen diese Lesen und Ausführen!
Siehe auch https://skanthak.hier-im-netz.de/tempest.html
"Für den UAC Prompt benötige ich ein Konto das Mitglied der Administratoren ist."
KWATSCH: auch in STANDARD-Benutzerkonten werden UAC-Prompts angezeigt, in denen nach Kontoname und Kennwort eines Administrators gefragt wird.
CMD können Normalsterbliche nicht und dann müssen sie auch noch einen Prozess finden. Das ist nicht "einfach".
UAC Prompts kannst du haben soviel du willst, du kannst den User nicht elevaten, wenn er nicht "Erhöhbar" ist oder er die Kenntnis eines Adminkontos hat.
Es ist WURSCHT, ob Otto Normalmissbraucher es per CMD.exe, PoserShell, VBScript, VBA, CreateFile(), CopyFile() etc. (NICHT)nkann, sondern ob ein ANGREIFER dazu in der Lage ist, und dieser Otto Normalmissbraucher übertölpeln kann, seinen Schädling auszuführen.
Otto Normalmissbraucher wird von M$FT trainiert, UAC-Prompts zu beantworten, insbesondere wenn diese von einem Installationsprogramm stammen, das er dummerweise in seinem "Downloads"-Ordner zur Ausführung bringt.
>> sondern ob ein ANGREIFER dazu in der Lage ist, und dieser Otto Normalmissbraucher übertölpeln kann
ok. der kann es. den nehme ich mit.
den Endkunden habe ich nicht im Fokus. den habe ich nicht. in der Firma wird es unter normalen Umständen für die masse der User nicht passieren. aber auch da ist der "klick ok" auf der UAC Aufforderung manchmal möglich.
Komfort siegt und selbst bei zusätzlichen credentials werden diese meist bedenkenlos eingegeben.
Danke.
Diese Credentials können aber nur eingegeben werden, wenn man welche hat! So ein Konto bekommt nicht jeder. Und den ganzen Krempel wie CMD, Powershell, VBS, … kann man sperren. Ist Arbeit, aber einmal erledigt, ist es erledigt. Nennt man Systemhärtung, sollte auch Hr. Kanthak was sagen.
Hallo Stefan.
Wenn das so einfach ist, wie von dir beschrieben, warum wird von für LPEs auf Windows auf (z.B.) der p2own überhaupt noch $$$ Preisgeld ausgelobt? Dein Beschreibung halte ich zwar für plausibel, aber sie ist für mich nicht nachstellbar.
Ich habe zwei EINFACH nutzbare Angriffsvektoren genannt (die dummerweise noch immer funktionieren); LPE lässt sich auch auf anderen (komplexeren) Wegen erreichen. Bei pwn2own wird Preisgeld für RCE(+LPE) ausgelobt, die OHNE Benutzerinteraktion (wie Bestätigen eines UAC-Prompts) und in endlicher Zeit funktionieren (Letzteres ist bei Wasserloch-Angriffen wie "vergiften" des TEMP-Ordners NICHT gegeben).
Ich habe inzwischen noch etwas weiter recherchiert, um das besser zu verstehen, aber es werden wichtige Infos noch zurück gehalten. Mir ging es vor allem darum, zu wissen, ob es bestimmte Vorraussetzungen gibt, um diesen Downgrade-Angriff zu starten – vielleicht kann man ja was tun, um den Ansatz zu vereiteln oder zu erschweren, in dem man was bestimmtes einfach erstmal verbietet? Irgend einen Programmstart per Applocker abfangen? Was auch immer… Soweit ich das jetzt verstehe, ist Stefan Kanthaks Einstreeuung garnicht mal so schlecht, wo er Windows als Altdatei-Messi kritisiert. Warum hat er da nicht weiter geforscht? Der Ruhm könnte jetzt seiner sein, wenn er darauf Wert legen würde, keine Ahnung. Denn es wird scheinbar nicht das Gesamt-System auf eine ältere Buildnummer gebracht, sondern tatsächlich nur einzelne Systemdateien gegen älterre mit bekannten Sicherheitslücken ausgetauscht. Das ist natürlich übel für jemand (wie mich bis gerade eben) der glaubt diese Art Attacke mit einer Softwareinventarisierung zumindestens erkennen zu können. Darüber gehts nicht, man müsste schon die Versionen aller einzelnen Systemdateien im Blick haben, was enorm viel Speicher in so einer Softwareinventarisierung bräuchte. Denn das System bleibt weiterhin komplett aktuell, bis auf einzelne Dateien… Und eine Erkenntnis, wenn sie zutrifft, ist sie eine gute, jedes kummulative Update würde wahrscheinlich wieder die aktuelle Dateiversion drüberbügeln, die Attack müsste also vielleicht monatlich wiederholt werden… Aber ich habe auch die Erkenntnis gewonnen, und das lässt mich gerade ein bisschen entspannter zurück lehnen, dass es auf dem System schonmal jemanden braucht, der gewisse Privilegien hat, nicht unbedingt lokaler Admin (wenn man der ist, ist es ohnehin zu spät), schon "Backup Operator" Recht reicht scheinbar schon. Denn der wesentliche Angriffspunklt scheint wohl ein Restore einzelner Systemdateien aus dem Müll, den S.K oben anprangert, zu sein. Microsoft hat dazu zwei noch etwas schwammige CVE-Reports erstellt, aus denen sich schon eine erste Anleitung zur Erschwerung des Angriffs hervorgeht.
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21302
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38202
Die Anleitung aus dem 2. Link:
Recommended Actions
The following recommendations do not mitigate the vulnerability but can be used to reduce the risk of exploitation until the security update is available.
o Audit users with permission to perform Backup and Restore operations to ensure only the appropriate users can perform these operations.
oo Audit: Audit the use of Backup and Restore privilege (Windows 10) – Windows 10 | Microsoft Learn -> https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/audit-audit-the-use-of-backup-and-restore-privilege
o Implement an Access Control List or Discretionary Access Control Lists to restrict the access or modification of Backup files and perform Restore operations to appropriate users, for example administrators only.
oo Access Control overview | Microsoft Learn –> https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-sensitive-privilege-use
oo Discretionary Access Control Lists (DACL) — https://learn.microsoft.com/en-us/windows/win32/secbp/creating-a-dacl
o Auditing sensitive privileges used to identify access, modification, or replacement of Backup related files could help indicate attempts to exploit this vulnerability.
oo Audit Sensitive Privilege Use – Windows 10 | Microsoft Learn -> https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-sensitive-privilege-use
Dass in dem Text überall nur Windows 10 erwähnt wird, sollte nicht abschrecken, es geht sicher auch um Win 11 und die Server-Varianten. Hoffnungsvoll macht mich, dass diese Artikel gerade gestern veröffentlicht wurden. Vielleicht gibts ja tasächlich nächste Woche zum Patchday einen passenden Stopfen.
Zusätzlich macht es vielleicht Sinn, wie T.J. oben vorschlägt, die Kisten gelegentlich einen "Dism.exe /online /Cleanup-Image /StartComponentCleanup" durchzuführen, zumindestens um einen Teil dieser gesammelten Alt-Dateien los zuwerden, was nicht da ist, kann auch nicht restored werden (außer der Angreifer liefert es schon mit) … Ich schau jetzt erstmal, ob ich schnell ein Script hinbekomme, dass die lokale "Backup Operators" Gruppe auf allen Kisten ausließt, um mal zu gucken, was sich da alles so tummelt… Den DISM Befehl per Deployment überall mal rennen zu lassen, ist sicher auch nicht verkehrt.
Edit: Die CVEs haben inzwischen auch andere entdeckt.
Zu: "Soweit ich das jetzt verstehe, ist Stefan Kanthaks Einstreuung gar nicht mal so schlecht, wo er Windows als Altdatei-Messi kritisiert. Warum hat er da nicht weiter geforscht? Der Ruhm könnte jetzt seiner sein, wenn er darauf Wert legen würde, keine Ahnung. " kann ich den Zahn ziehen.
Kanthak steht wiederkehrend auf den Top 100-Liste der Leute, die Schwachstellen an Microsoft melden. Er kritisiert ja seit Jahren wiederkehrende und gravierende Verstöße Microsofts gegen deren eigene Sicherheitsvorgaben. Und ich sitze gelegentlich als CC bei E-Mails zwischen Kanthak und MSRC, wo ich fassungslos feststelle, wie verstrahlt die im MSRC teilweise sind.
Polemisch ausgedrückt: Warum sollte Kanthak in einem "Misthaufen wühlen", um herauszufinden oder nachzuweisen, dass da weiter Mist zu finden ist? Soweit ich es richtig interpretiere, ist er nicht auf Ruhm und Ehre angewiesen – und Bug-Bounties für so was (die man auf die Schnelle mitnehmen könnte) werden oft genug mit fadenscheinigen Begründungen verweigert.
Zudem ermüdet es, die Jungs und Mädels wiederkehrend auf bekannte Probleme hinzuweisen, ohne das etwas passiert oder beim nächsten Mal wieder falsch gemacht wird. Da ist bei den Fresh-Man oft kein Verständnis für die Sache. Ist einer der Gründe, warum ich mich vor vielen Jahren (damals noch als MVP) aus den Product Group Interactions zurückgezogen habe. Ja, es gab immer wieder Senior-Entwickler, die ein profundes Wissen über Windows-Features offen legen konnten. Aber mir war persönlich die Zeit zu schade – um mich um 19:00 Uhr hinzusetzen und den Kindergarten zu verfolgen, in der Hoffnung, da die 10 % Klasse an Beiträgen mitzubekommen – zumal vieles da unter NDA segelte.
Das ist alles verständlich und trotzdem schade.
Windows als Altdatei-Messi oder Misthaufen… das sind noch verharmlosende Umschreibungen. Nenn das Kind doch bei Namen!
Ich habe vor ein paar Jahren eine Screenshot-Tour gemacht, was da so an gammligen Leichen und nicht verwahrlosten Baustellen hinter dem ganzen Eye-Candy stecken. Und alle paar Jahre wird der Rotz wieder als "neu" verkauft, mit ein wenig Eye Candy und Glitzer. Am Ende des Tages ist das der gleiche seit Jahrzehnten durchgeschleifte Dreck!
https://blog.jakobs.systems/blog/20210626-windows11/
IMHO sehen wir da eine Trümmerlandschaft, die MS selbst kaum noch im Griff hat weil die Älteren, die noch in den 80er und 90er Jahren aktiv an der Entwicklung beteiligt waren, längst Rentner sind oder irgendwas mit Holz oder Tieren machen.
> Zudem ermüdet es, die Jungs und Mädels wiederkehrend auf bekannte Probleme hinzuweisen…
Es ist nicht nur ermüdend, ich wende mich mittlerweile aktiv ab und diskutiere nicht mehr. Anwender ermuntere ich auch wirklich auf jeden Link, jede Mail und Anlage zu klicken. Denn wenn der sogenannte "falsche Mausklick" ausreicht, die komplette IT-Infrastruktur abzufackeln, dann möge diese bitte auch lichterloh brennen!
früher, bei Unix, gab es so Tools wie chkrootkit.
Das notierte sämtliche "inodes" der Betriebssystem Komponenten. Gab es da Bewegung, gab es Alarm.
Eine Übernahme verhindern konnte es nicht sicher aber es war schon extrem auffällig, wenn in einem System die Lage der Systemdateien geändert wurde, ohne das ein offizielles Update lief.
Vorstellbar dass ein Angreifer so tief in der Materie steckt, Dateien am Filesystem vorbei ändern zu können, aber..
die Inodes sind bei jedem Rechner anders verteilt…und welches der gefühlt 15 Dateisysteme ist im Einsatz?
Natürlich zieht man auch Prüfsummen. Was bei einem Rootkit nix bringt: Es zeigt einfach die alte, unveränderte Datei vor.
BTST.
Wenn das so ist wie es aussieht ist das ein SuperGAU.
Wer hat denn jetzt Schuld an dem Problem?
Microsoft ja offensichtlich weniger.
Wer ist verantwortlich?
Nein, natürlich ist MS dafür verantwortlich, das haben die alleine verbockt. Ich hoffe, sie bekommen das irgendwie wieder hin, denn sonst ist tatsächlich die Windows Landschaft in großer Gefahr, mit allen Konsequenzen, die z.B. eine Migration zu Apple oder Linux mit sich brächte, die da wären, dass all das über Jahre aufgebaute Wissen und Erfahrung im Windows-Adminbereich überflüssig wird, die Leute teils komplett neu lernen müssen, was dann auch dazu führen wird, dass mangels Wissen über das neue OS die Systemhärtung dieser Landschaft nicht optimal sein wird, wenns nicht sogar komplett einfach nur "out of the box verwendet wird), Umlernen der Benutzer auf völlig neue Bedienkonzepte, teils komplett neue Anwendungen welche nicht die gewohnten Leistungen erbringen (vergleiche mal Gimp mit Photoshop oder Affinity, Libreoffice mit Office 365 – ich weiß ich steche da gerade wieder in ein Wespennest – aber es ist so auch wenn mancheiner das nicht wahrhaben will, usw.) und was das alles noch bedeuten würde!
Last famous words:
"Wir können die Software nicht neu schreiben.
Das sind über 200000 Zeilen Fortran/Cobol, das hat Millionen gekostet und jede Menge KnowHow."
Das soll einmal in einer Bank gesagt worden sein.
Klingt leider sehr realistisch.
Es ist so. Ich kenne jemand, der bis vor ein paar Jahren (jetzt Rente) in einer Frankfurter Großbank adminstriert hat, und dort für die Hypervisoren zuständig war, auf denen der ganze Cobol- und Fortran-Krempel läuft. Für die Bank ist/war es billiger, eigene Hypervisoren zu entwickeln, um den Kram laufen lassen zu können, als den Kram selbst umzuschreiben, um nicht mehr von IBM AS/400 usw. abhängig zu sein. Oder sagt Opel "Tech 2" was, der Werkstatt Diagonse Kram von ganz früher, für Opel war es günstiger und schneller, auf der neuen neuen Diagnosesystem ab Insignia einen Emulator zu betreiben, der auf Maschinensprache-Ebene die Tech 2 Diagnosesoftware ausführen kann, als all diese Diagnosesoftware neu zu schreiben. Sowas findet man ständig.
Das Umlernen sollte nicht das Problem sein. Habe ich schonmal mitgemacht, Damals in den 90ern stand der Wechsel von AIX, HP-UX, Ultrix und VMS auf zunächst WinNT und Novell, anschließend noch Novell zu Windows-Server an. Ein weiterer Wechsel steht bevor. Der in die Rente. Dann ist es bei mir vorbei mit M$.
Den Artikel bei SafeBreach haben Sie scheinbar aber auch nur überflogen, sie übersetzen daraus oben:
Nur die Katalogdateien, die die Updates enthalten, sind digital signiert.
Die Dateien für das Manifest und die MUMs sind nicht explizit signiert, sondern werden von den Katalog-Dateien signiert.
Beim Update verwendete Differentialdateien sind ebenfalls nicht signiert.
Das klingt tatsächlich schrecklich, darunter steht:
Targeting Differential Files
I found the last fact interesting, and wondered if there was any chance differential files were left behind in terms of validation. But, I had no luck there, because the expected update file hash is hardcoded in the manifest. And the manifest cannot be changed, since that would break its signature in the catalog.
Also da erstmal Entwarnung, das wäre der Supergau. Der Angriff ist sooo einfach nicht.
Der errfolgreiche Ansatz kommt direkt darunter:
I searched the action list path in the registry and found an interesting key named PoqexecCmdline. It holds the executable that parses the list and the list path.
I then looked at the security attributes of this key and noticed that it is not Trusted Installer enforced! This would allow me to control all the update actions.
Vielleicht reicht es ja, diesem Regkey PoqexecCmdline per ACL dem TrustedInstaller zu übergeben? Das wäre einfach zu beheben!
Das würde imho nicht reichen, denn es gibt so schöne Tools wie powerrun, mit denen man sich die TrustedInstaller Rechte geben kann.
Auch Systemrechte kann man sich damit geben.
Warum nicht einfach auch die Differentialdateien signieren?
Damit wäre eine Manipulation dieser Dateien nicht mehr möglich.
Und veraltete Updatedateien wird man über die Datenträgerbereinigung des Systemlaufwerks los:
Dort "Systemdateien bereinigen" anklicken, dann Haken rein bei "Windows Update Bereinigung"
Ist doch jetzt schon nicht möglich, denn der Hash der Differentialdateien ist doch hardcoded in der Manifest-Datei, die schon signiert ist. Würde man den Hash im Manifest ändern, würde deren Signatur nicht mehr passen. Würde man die Differentialdatei ändern, würde der Hash nicht mehr passen. Ganz so doof sind die bei MS auch wieder nicht. Lies das nochmal genau. Es geht nur über den TrustedInstaller. Tools wie powerrun kann man sperren, entweder per Applocker (funktioniert nur für Standard-user, nicht Admins) oder per Antivirus, könnte man z.B. als PUA markieren, wenn die nicht das schon sind.
>> [Applocker] funktioniert nur für Standard-user, nicht Admins
das ist falsch und nur der Fall, wenn du die Standard Regeln erstellst und sie anschließend nicht editierst.
Tausche Administratoren gg System und dann sind Administratoren ebenfalls unter applocker.
manuelle Installationen müssen dann im systemkontext erfolgen.
Applocker so abdichten, ist in der Tat die ganz große Kunst, das macht kaum jemand. Denn damit sperrt man auch Prozesse wie Winlogon, womit sich dann niemand mehr anelden kann.
Üblich ist, dass wenn man Applocker aktiviert, dass dann auf den Standard-Regeln von MS aufgebaut (%systemroot%, %program files%) wird, und da ist dann der Admin soweit priviligert, dass er alles ausführen kann. Also vergleichbar mit der alten Software-Restriction-Policy.
Mein voriger Vorbehalt über die Ausnutzbarkeit wurde zur Kenntnis genommen? So wild ist es damit nämlich nicht mehr.
Meinen Beitrag oben gelesen?
Ja, du hast das auch angesprochen, etwa 10 Minuten nach meinem Beitrag, wie ich jetzt sehe. Deswegen halte ich wichtige Infos kurz, da behält man mehr Überblick. Beste Grüße
"… rüttelt an den Grundfesten der Betriebssystemarchitektur."
AUTSCH: nein, dass ist NICHT der Fall!
JEDER Benutzer mit Administrator-Privilegien hat (nicht nur unter Windows) IMMER die Möglichkeit, das Betrübssystem zu kompromittieren.
Daher ist STRIKTE Benutzertrennung so wichtig; Zeux wie "Trusted Installer" ist lediglich Sicherheiz-Kasperl-Theater, bzw. ist nur eine leicht überwindbare Hürde.
Powershell:
Ein Script, dass die Dateiversion oder die Signatur der Dateien prüft.
Ist eine Datei älter, schlage Alarm.
Wenn auf der Kiste ein rootkit installiert wurde, gibt es brav die Daten der originalen Datei zurück.
Oder gibt es das unter Windows nicht?l (mehr)?
Vor ein paar Jahren wurde mit rootkit detection geworben..
Jetzt ist da Ruhe.
Das Thema ist nicht schön, aber es sollte durchaus möglich sein dieses Problem zu adressieren. Der Trick besteht ja quasi darin den Registrierungswert "PoqexecCmdline" so zu modifizieren, dass Windows Update eine andere pending.xml mit bösartigen Aktionen untergeschoben wird.
Gemäß des SafeBreach Artikels liegt die Datei pending.xml in einem Verzeichnis, welches der User nicht erreicht. Da der Registrierungswert "PoqexecCmdline" aber TrustedInstaller nicht erzwingt, kann der Pfad zur pending.xml geändert werden. Die Datei kann in einem Verzeichnis liegen, welches der Angreifer kontrolliert.
Maßnahmen wären zum Beispiel:
– Die pending.xml wird immer dann ignoriert, wenn das Quell-Verzeichnis TrustedInstaller nicht erzwingt
– Beteiligte Programme wie poqexec.exe werden digital signiert und müssen gültig signiert sein
– Programme zur Prüfung der Systemintegrität wie sfc werden digital signiert
Die Persistenz und die Unumkehrbarkeit wurde durch patchen dieser Dateien durch den Angreifer erreicht. Möglich, da keine Signatur vorhanden ist, welche gebrochen / geprüft werden könnte.
Auch das "Tool zum entfernen bösartiger Software" könnte jeden Monat einen signierten Scanner mitbringen, welcher die Versionsnummern aller Systemdateien prüft und mit den erforderlichen Werten abgleicht.
Die Stefan Kanthak oben korrekt schreibt, ist jeder Administrator am Ende in der Lage ein System irgendwie zu kompromittieren.
Mal sehen was von Microsoft so kommt. Da die Katze aus dem Sack ist steigt der Druck. Wahrlich kein Ruhmesblatt, aber ich denke das keine gewisse Hartung möglich ist.
Da fällt das Misthaufensystem in sich zusammen und die MS Speichellecker wühlen im Mist, um die goldene Nadel zur Lösung zu suchen.
Gut, dass unsere Macs hier nicht mit so etwas nichts zu tun haben :-D
Du willst doch jetzt nicht wirklich auch noch diese Baustelle aufreißen? ;-)
Schönes Wochenende!
Nicht? :-)
Schönes Wochenende :-)
Übrigens, last final Words zu dem Thema, weder Heise noch Golem haben das Thema bisher aufgegriffen, nur Winfuture sitzt mit im Boot. Das ist das, was diesen Blog immer noch wertvoll macht, auch wenn man sich bisher kaum gegen diesen Fehler wehren kann, wenn man nicht die gängigen Systemhärtungsmaßnahmen durchführt.
Bei Golem kann man statt dessen lesen, dass eine Russische Schachspielerin ihre Gegnerin bei einem Turnir ganz analog vergiftet wurde, so legt man die Prioritäten richtig… *roll*
Microsoft hat seinen Artikel revidiert, jetzt wird nicht mehr wie oben von mir zitiert empfohlen, Benutzer-Berechtigungen zu Backup/Restore zu überweachen und spezielle ACLs zu setzen, sondern es wird empfohlen, das File Access Audit einzuschalten und für bestimmte Ordner, am Besten denke ich wäre gleich C:\Windows\*, per Explorer im Sicherheitstab das Audit für spezifische Nutzer zu aktivieren (muss dann wohl Authenticated Users oder wenigstens Administrators sein…). Das kostet natürlich Performance, und wenn man die Eventlogs nicht sämtlicher Systeme überwacht und keine Alarme bekommt, bringt das natürlich wenig, das Kind ist dann schon in den Brunnen gefallen, die Audits helfen nur noch hinterher bei der Forensik.
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21302
Der Patchday hilft zum Teil zumindetens für 1 von den zwei CVEs gibts jetzt Patch bis runter zu Server 2016.
Da noch nix:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38202
Aber immerhin hier:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21302
Happy patching!