6
Windows 8.1: Lokale Rechteausweitung öffentlich und ungepatcht
This function has a vulnerability where it doesn't correctly check the impersonation token of the caller to determine if the user is an administrator. It reads the caller's impersonation token using PsReferenceImpersonationToken and then does a comparison between the user SID in the token to LocalSystem's SID. It doesn't check the impersonation level of the token so it's possible to get an identify token on your thread from a local system process and bypass this check.
Warten auf das Update...
(oder die Updates, übliche Fehlschüsse mitgezählt)
https://code.google.com/p/google-security-research/issues/detail?id=118
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: 258899
Url: https://administrator.de/forum/windows-8-1-lokale-rechteausweitung-oeffentlich-und-ungepatcht-258899.html
Ausgedruckt am: 02.01.2025 um 16:01 Uhr
6 Kommentare
Neuester Kommentar
Moin.
POC schon selbst getestet? Auch als Nicht-Admin? Der Autor betitelt das als "elevation of privilege" - aber ist es das auch? Was er beschreibt, sieht eher nach einem UAC-Bypass aus, und das wäre nach Microsofts eigener Definition nicht einmal eine Sicherheitslücke. Zudem muss die UAC offenbar in default-Einstellung (2. höchster) sein, also nicht in recommended-Einstellung (höchster Level).
Werde es demnächst testen.
POC schon selbst getestet? Auch als Nicht-Admin? Der Autor betitelt das als "elevation of privilege" - aber ist es das auch? Was er beschreibt, sieht eher nach einem UAC-Bypass aus, und das wäre nach Microsofts eigener Definition nicht einmal eine Sicherheitslücke. Zudem muss die UAC offenbar in default-Einstellung (2. höchster) sein, also nicht in recommended-Einstellung (höchster Level).
Werde es demnächst testen.
Dieses PoC habe ich nicht getestet, aber mit der Überschrift hier habe ich mich "nicht blind" der Einordnung der fraglichen Vulnerability angeschlossen.
Die Funktion dieser Implementierung wurde von anderen schon bestätigt, und unter den gewählten Rahmenbedingungen ist sie ja nicht weiter spektakulär. Ändert aber nichts am Funktionsprinzip und seinem Potenzial (so gesehen: ein eleganter Ansatz für einen veröffentlichten PoC). Lustig wäre, wenn das ursprünglich als UAC-Bypass bei Microsoft liegen geblieben wäre.
Grüße
Richard
Die Funktion dieser Implementierung wurde von anderen schon bestätigt, und unter den gewählten Rahmenbedingungen ist sie ja nicht weiter spektakulär. Ändert aber nichts am Funktionsprinzip und seinem Potenzial (so gesehen: ein eleganter Ansatz für einen veröffentlichten PoC). Lustig wäre, wenn das ursprünglich als UAC-Bypass bei Microsoft liegen geblieben wäre.
Grüße
Richard
Hab's probiert und der POC ist "nur" ein UAC-Bypass mit den vermuteten Randbedingungen (wenn UAC auf höchster Stufe, wird er gestoppt).
Weitere Kommentare lassen jedoch vermuten, dass der POC absichtlich nicht den volle Umfang hat und in der Tat eine Rechteausweitung von 0 auf 100 vorliegt.
Weitere Kommentare lassen jedoch vermuten, dass der POC absichtlich nicht den volle Umfang hat und in der Tat eine Rechteausweitung von 0 auf 100 vorliegt.
Wenn jemand nun zum Schutz die UAC auf höchsten Level stellen möchte (netzwerkweit und per GPO, meine ich), aber nicht weiß, wie:
Computer Configuration - Policies - Windows Settings - Security Settings - Local Policies
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode: Prompt for consent on the secure desktop
(Das kommt dem höchsten Level gleich, während der Default (2. höchster UAC-Level) in Worten "Prompt for consent for non-Windows binaries" ist)User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode: Prompt for consent on the secure desktop
Das ist empfehlenswert, aber Schutz eben nur gegen den Demo-Code (der auch kein UAC-Bypass ist, sondern lediglich keinen Mehrwert gegenüber einem solchen bietet). Der entsprechende Hinweis von Heise ist irreführend. Da kann ich auch die calc.exe umbenennen.
https://technet.microsoft.com/library/security/MS15-001 will die Lösung sein. Betroffenene Versionen: 7/8.x/2008R2/2012
