8
Windows ALPC Zero-Day-Schwachstelle im Task-Scheduler
Es gibt eine 0-day Schwachstelle im ALPC Interface des Task-Scheduler (Aufgabenplanung), die lokalen Nutzern eine Rechteausweitung bis auf SYSTEM-Privilegien ermöglicht. Glücklicherweise nur lokal ausnutzbar. Was ich bisher weiß, habe ich mal in folgendem Beitrag zusammen getragen.
Neue Windows ALPC Zero-Day-Schwachstelle entdeckt
Neue Windows ALPC Zero-Day-Schwachstelle entdeckt
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 384665
Url: https://administrator.de/contentid/384665
Ausgedruckt am: 22.11.2024 um 03:11 Uhr
8 Kommentare
Neuester Kommentar
Moin.
Ich gehe mal davon aus, dass Sie sich damit befasst haben.
Im write-up.docx des PoC steht, dass man einen Hardlink erstellt, um das auszunutzen. Nicht-Admins können jedoch gar keine Hardlinks erstellen (mklink /h). Hat sich der Autor nur falsch ausgedrückt, oder testet er bereits mit einem Adminuser?
Ich gehe mal davon aus, dass Sie sich damit befasst haben.
Im write-up.docx des PoC steht, dass man einen Hardlink erstellt, um das auszunutzen. Nicht-Admins können jedoch gar keine Hardlinks erstellen (mklink /h). Hat sich der Autor nur falsch ausgedrückt, oder testet er bereits mit einem Adminuser?
Das stimmt, mit Standardbenutzerrechten lässt sich mit dem PoC wenig anfangen (falls ich nichts übersehen habe - zum Testen habe ich aktuell keine 64-Bit-VM). Da aber so einige Leute unter Windows nur mit dem einen, beim Setup angelegten Benutzerkonto arbeiten, sind die Administrator-Berechtigungen gegeben. Und ich bekomme von den Administratoren bei Blog-Beiträgen, wo ich vorschlage, mit Standardbenutzerrechten zu arbeiten, meist die Antwort 'macht kein Mensch, mir passiert schon nichts'. In sauber administrierten Unternehmenumgebungen dürften die Standard-Nutzer nicht gefährdet sein. Aber es soll ja auch schon Administratoren gegeben haben, die die Schleuse für WannaCry & Co. geöffnet haben.
Wenn eh Admin, wäre es aber keine Rechteausweitung mehr, denn Systemrechte kann sich jeder Admin problemlos verschaffen. Ließe sich sofort klären, wenn man den PoC Code als Nichtadmin ausführt.
Scheint nicht so einfach zu sein. Mir ist es zwar nicht gelungen, unter einem Standard-Konto mit der DLL-Injektion eine Rechteausweitung zu erreichen. Ich gehe aber davon aus, dass dies mein Fehler ist und ich etwas übersehen habe. Es scheint wohl so zu sein, dass sich bestimmte Hardlinks mit Standard-Berechtigungen anlegen lassen. Aber das sollen Berufenere verifizieren.
Ich konnte zumindest erreichen, dass eine notepad.exe mit Systemrechten gestartet wurde, was ja auch der Film demonstriert - es geht also. Aber es geht nicht zuverlässig - auf einem zweiten System gelang das mit dem selben Befehl (natürlich geänderte PID) eben nicht.
1
Ich habe noch nicht verstanden, warum es vorhin nicht ging - nun geht es auch auf dem Zweitsystem.
Ich habe nun die ACL auf c:\windows\system32\tasks verändert und dem Nutzer Schreibrechte genommen (nun lediglich "read permissions" übrig gelassen). Resultat: der Exploit funktioniert nicht mehr, aber der Scheduler ist weiterhin nutzbar (Tasks laufen, können von Admins angelegt werden...). Es sieht wie ein gangbarer Workaround aus, bis der Patch da ist.
Ich schätze, der einzige Nebeneffekt ist, dass keine .job Files mehr auf die vom Exploit ausgenutzte Weise verarbeitet werden - aber das stört vermutlich niemanden mehr.
Ich habe nun die ACL auf c:\windows\system32\tasks verändert und dem Nutzer Schreibrechte genommen (nun lediglich "read permissions" übrig gelassen). Resultat: der Exploit funktioniert nicht mehr, aber der Scheduler ist weiterhin nutzbar (Tasks laufen, können von Admins angelegt werden...). Es sieht wie ein gangbarer Workaround aus, bis der Patch da ist.
Ich schätze, der einzige Nebeneffekt ist, dass keine .job Files mehr auf die vom Exploit ausgenutzte Weise verarbeitet werden - aber das stört vermutlich niemanden mehr.
1
Ah danke für die Ergänzung - ich bin genau an diesem Problem mit Notepad auf meinem W7 Testsystem gescheitert.
Also in der Uni Hamburg, in Netzwerk der Herbrich Corporation (ja selbst ich) überall dort wird mit Standart Konten gearbeitet. Ich meine selbst die UAC ist mir nicht gehäuser und nervt nur weswegen ich dann schon lieber ganz auf admin verzichte zum Arbeiten.
Developer Terminal Server sind bei mir z.B. eine Ausnahme aber da dürfen auch nur bestimmte Nutzergruppen ran die endsprechende Kentniss haben und auch nur für die ausführung von Visual Studio und co. Die Systeme werden alle Nachts um 00:00 Uhr Zurückgesetzt (alle Files liegen auf Team Foundation und da geht auch alle 2 Stunden eine AV durch).
Also mein Persönliches Fazit ist, wenn man nicht gerade als privat User Zuhause chillt sollte User eigentlich keine Admin Rechte haben und Admins (sollten) wisssen was man eigentlich nicht anklicken sollte
LG, J Herbrich
Developer Terminal Server sind bei mir z.B. eine Ausnahme aber da dürfen auch nur bestimmte Nutzergruppen ran die endsprechende Kentniss haben und auch nur für die ausführung von Visual Studio und co. Die Systeme werden alle Nachts um 00:00 Uhr Zurückgesetzt (alle Files liegen auf Team Foundation und da geht auch alle 2 Stunden eine AV durch).
Also mein Persönliches Fazit ist, wenn man nicht gerade als privat User Zuhause chillt sollte User eigentlich keine Admin Rechte haben und Admins (sollten) wisssen was man eigentlich nicht anklicken sollte
LG, J Herbrich
1
