Es gibt eine weitere Methode, um die Windows Benutzerkontensteuerung (UAC) schlicht auszuhebeln. Dabei ist nicht mal ein UAC-Bypassing erforderlich. Das Ganze läuft über die Aufgabe SilentCleanup der Aufgabenplanung.
Anzeige
Blog-Leser Leon hat mich vor einigen Tagen bereits per Mail auf den Beitrag Windows Escalate UAC Protection Bypass Via SilentCleanup von Packet Storm-Security aufmerksam gemacht.
UAC über SilentCleanup ausgehebelt
Es gibt eine Aufgabe im Windows Taskplaner namens "SilentCleanup", die, obwohl sie als Benutzer ausgeführt wird, automatisch mit erhöhten Berechtigungen läuft. Wenn dieser Task läuft, wird die Datei %windir%\system32\cleanmgr.exe zur Datenträgerbereinigung ausgeführt. Das ist nicht so der Brüller. Aber es gibt einen speziellen Aspekt.
Der Task SilentCleanup wird zwar unter dem Konto des Benutzers ausgeführt, läuft aber mit erhöhten Berechtigungen. Wenn der Benutzer die Umgebungsvariablen ändern darf, ließe sich die Umgebungsvariable %windir% (die normalerweise auf C:\Windows verweist) so anpassen, dass der Verweis auf beliebige Ordner zeigt. Ändert man den Wert der Umgebungsvariablen %windir% auf test, wird alles, was in diesem Ordner liegt, als Administrator ausgeführt.
Allerdings erfordert die Änderung einer Systemumgebungsvariable administrative Berechtigungen. Dabei wird unter Standardkonten eine UAC-Abfrage gezeigt. Das ließe sich aber unter Administratorkonten per UAC-Bypassing austricksen.
Ist die Umgebungsvariable geändert, wer hindert mich daran, einen Unterordner system32 in dem per Umgebungsvariable %windir% referenzierten Ordner anzulegen und ein Malware unter dem Namen cleanmgr.exe in den Zielordner zu kopieren? Schon habe ich den perfekten UAC-Bypassing-Mechanimus gefunden.
Ergänzender Hinweis: Der Entdecker der Schwachstelle hat ein C#-Programm auf der Seite veröffentlicht, das prüft, ob das Benutzerkonto Mitglieder der Gruppe der Administratoren ist. Trifft dies zu, werden Befehle ausgeführt, die einen Exploit simulieren.
Die Alternative wäre UAC-Bypassing
Der obige Ansatz ist ohne Tricks möglich (solange die Systemumgebungsvariable geändert werden kann). Es gibt aber auch das sogenannte UAC-Bypassing, bei dem Schadsoftware an administrative Berechtigungen heranzukommen versucht, ohne die Benutzerkontensteuerung auszulösen. Der Hintergrund: Sowohl Standard-Benutzerkonten als auch Administratorkonten bekommen bei der Anmeldung nur ein Standard-Sicherheitstoken (filtered Token), welches keine administrativen Berechtigungen verleiht. Für administrative Aufgaben fordert der Prozess administrative Berechtigungen von Windows an. Das betreffende Sicherheitstoken bekommt der Prozess (seit Windows Vista) beim Aufruf über die Benutzerkontensteuerung (User Account Control, UAC) zugeteilt.
Viele Windows-Funktionen, die administrative Berechtigungen erfordern, sind mit einem stilisierten Schild (siehe folgender Screenshot) gekennzeichnet und bei Anwahl erscheint dann die Abfrage der Benutzerkontensteuerung (UAC) zur Zuteilung des administrativen Sicherheitstokens. Das soll die ungewollte Ausführung administrativer Aufgaben verhindern, der Nutzer muss mit Administratorberechtigungen explizit der Ausführung zustimmen.
Anzeige
Beim UAC-Bypassing sucht man sich Methoden, um die Sicherheitsabfrage der Benutzerkontensteuerung zu umgehen. Und diese Ansätze gibt es, wie ich in den nachfolgend verlinkten Blog-Beiträgen gezeigt habe. Das Ganze ist auch nichts theoretisches, genau solche Ansätze wurden von der Ransomware Erebus ausgenutzt.
Ähnliche Artikel:
Windows 10: Neue UAC-Bypassing-Methode (fodhelper.exe)
Erebus Ransomware und die ausgetrickste UAC
2015
Die UAC ist zwar manchmal nervig, aber sie verhindert meistens das Schlimmste.
Denn nicht jede Schadsoftware geht den Weg, wie im beschriebenen Beispiel.
Dafür müsste das System aber erst mal mit Malware infiziert sein, womit das Unheil ja schon geschehen wäre.
Dieser Task ist zudem auch ziemlich nutzlos, man kann ihn deaktivieren oder die automatische Erhöhung daraus entfernen, womit er dann nur mit Userrechten ausgeführt würde. Üblicherweise läuft er mit Adminrechten, nicht mit Systemrechten. MS will angeblich deswegen nichts unternehmen, weil UAC keine Sicherheitsgrenze sei und man dies somit nicht als Sicherheits-Schwachstelle sehe. Das widerspricht allerdings anderen MS-Artikeln, in denen UAC sehr wohl als Sicherheitsfeature bezeichnet wird.
Du hattest doch heute die Ankuendigung zum TaskExplorer im Blog. Zumindest mit erhöhten Berechtigungen lassen sich auch die Umgebungsvariablen eines laufenden Programms bearbeiten lassen. Bietet das moeglicherweise eine Angriffsflaeche?
Der Artikel könnte präziser sein.
Und zwar: "obwohl sie als Benutzer ausgeführt wird, automatisch mit erhöhten Berechtigungen läuft" – nicht für schwache User. Sie läuft automatisch elevated. Erhöhte Berechtigungen ergeben sich nur aus der Kombi "User ist eh Admin + Elevation".
"Ändert man den Wert der Umgebungsvariablen %windir% auf test, wird alles, was in diesem Ordner liegt, als Administrator ausgeführt. " – nein, es wird elevated ausgeführt. Also nur dann als Admin, wenn… (hatten wir schon).
"Allerdings erfordert die Änderung einer Systemumgebungsvariable administrative Berechtigungen" – richtig, aber beim Exploit wird keine Systemvariable geändert! Diese Systemvariable %windir% bleibt dabei unangetastet. Was der Exploit macht, braucht keine Adminrechte zum Ausnutzen der Umleitung von %windir% zu einem anderen Ordner.
Was ist also das Einsatzszenario für diesen Exploit und wie schützt man sich?
Einsatz: um Leute, die als Admin arbeiten, zu überlisten.
Schutz: Wie eh und je: man arbeitet schlich nicht als Admin. Als User birgt dieser Exploit keine Gefahr. Zudem ist dieser UAC-Bypass ja auch nicht wirklich etwas Sicherheitskritisches, denn Microsoft sagt selbst, dass die UAC gar keine Sicherheitsbarriere darstellt und Ihre Umgehung somit gar kein Sicherheitsproblem wäre, welches sie beheben müssten.
Ich antworte mal nur auf 'Schutz: Wie eh und je: man arbeitet schlich nicht als Admin.' und sage: Willkommen bei Windows 10! Ich hatte es hier schon mal im Blog und hab dafür auf die Mütze bekommen. Wer in Windows 10 administrative Aufgaben über die Einstellungen-App erledigen muss, wird schlicht gezwungen, sich unter einem Administrator-Konto anzumelden. Andernfalls sind nämlich alle Optionen, die administrative Rechte benötigen, ausgeblendet. Und in welcher Gruppe ist das Benutzerkonto, was beim Setup von Windows 10 angelegt wird?
Ich würde eher sagen: willkommen bei Windows ab Vista aufwärts. Just seit diesem Zeitpunkt arbeite ich natürlich in einem Adminkonto – und wenn man die dämliche Autoelevation abstellt, ist das eine brauchbare und hinreichend sichere Sache. Man kann seit Vista nicht mehr "als Admin arbeiten", es sei denn, man nähme das Konto "Administrator". In allen sonstigen Adminkonten hat man nur eingeschränkte Userrechte. Nicht-Admins werden natürlich in Standardkonten gepackt und sie haben nie Zugang zu erhöhten Rechten. Und ganz sicher hat dieser Angriff hier nicht die geringste Chance auf Erfolg. Zudem muss jeder User, der auf seinem System selbst Admin ist, oft genug mit erhöhten Rechten arbeiten, für Installationen und alle möglichen Verwaltungsarbeiten. Der Schutz ist also nicht, nie mit erhöhten Rechten zu arbeiten, weil gar nicht machbar, sondern sein System sinnvoll und effektiv vor Malware zu schützen: also KEINE Virenscanner, sondern
https://skanthak.homepage.t-online.de/SAFER.html
usw… Sogenannte "Sicherheitssoftware" macht das System unsicherer als es vorher ohne sie war.
Safer ist eine tolle Sache, bedeutet aber, wenn man das einem Familienmitglied einrichttet, wieder zusätzlichen Support. Installier mal hier, installier mal da…
Wenn deine User keine Adminrechte haben, musst du doch auch ohne SRP ständig für sie installieren und sonstige Adminarbeiten erledigen. Haben sie aber Adminrechte, dass können sie das auch mit SRP selbst machen.
"Wer in Windows 10 administrative Aufgaben über die Einstellungen-App erledigen muss, wird schlicht gezwungen, sich unter einem Administrator-Konto anzumelden." – sagtest Du bereits oft. Das habe ich widerlegt, siehe Kommentare unter
https://www.borncity.com/blog/2019/01/12/fix-fr-das-windows-7-netzwerkproblem-mit-update-kb4480970-kb4480960/
"Allerdings erfordert die Änderung einer Systemumgebungsvariable administrative Berechtigungen"
Nicht ganz richtig. Wenn ich z. B. eine Eingabeaufforderung öffne und mit "set windir=c:\xy" die Umgebungsvariable ändere, so bleibt das bis zum Ende des Prozesses (und weiterer darin gestarteter Prozesse) erhalten. -> Das kann z. B. der heute vorgestellte TaskExplorer – auch für andere Prozesse.
Interessanter wäre nun, wie die Elevation ausgenutzt wird und wie die Änderung der Umgebungsvariablen in einem mit erhöhten Rechten ausgeführten Prozess ohne erhöhte Rechte bewerkstelligt werden kann.
Es wäre noch einmal wirklich schlimm, dass die Einstellungen nicht vollständig verfügbar sind. Wenn es um systemweite Einstellungen geht, gilt noch immer, dass man neben dem administrativen Konto ein reines Benutzerkonto auf dem Rechner anlegt und genau das immer nutzt.
Viel schlimmer finde ich den Haufen an Programmen und vor allem Spielen, die grundsätzlich administrative Berechtigungen benötigen, um überhaupt zu funktionieren. Da ist es vorprogrammiert, dass der faule – Verzeihung, bewueme – Mensch auf das reine Benutzerkonto verzichtet, weil die UAC sich gar zu oft meldet und das Kennwort des administrativen Kontos anfordert.
Broken by design, das Ganze.
"Wenn es um systemweite Einstellungen geht, gilt noch immer, dass man neben dem administrativen Konto ein reines Benutzerkonto auf dem Rechner anlegt und genau das immer nutzt."
Das wäre Arbeiten wie im letzten Jahrtausend. Ob man nun im Userkonto umständlich das Adminpasswort eingibt oder im Adminkonto auf "OK" klickt, macht letztlich keinen Unterschied. Wer sich selbst nicht traut, kann auch das Adminkonto auf Passworteingabe für erhöhte Rechte umstellen. Die meisten User leisten sich keinen Admin, sondern sind es selbst. Programme haben grundsätzlich mit Userrechten zu laufen, mit wenigen Ausnahmen, die nun mal wirklich erhöhte Rechte brauchen, der Imager z.B… Allen anderen Schrott sollte man meiden.
UAC nervt auch nie, man kann Prozesse, die immer erhöhte Rechte brauchen, so einstellen, dass sie diese automatisch erhalten. "Broken bei Design" war Windows bis einschließlich XP, wo User tatsächlich in einem echten Adminkonto (sämtliche Prozesse erhöht) arbeiten konnten. Die Masse der XP-User war so gemeingefährlich unterwegs, das Paradies für Hacker. Es gibt einen alten Artikel von André Ziegler zu UAC, dem ich voll zustimme:
http://web.archive.org/web/20141129124212/http://www.winvistaside.de/forum/index.php?showtopic=3030
"No Shit, Sherlock" – SCNR
Von UAC-Bypass hast du auch schon mal gehört? Oder Zugriff auf andere Systeme mit identischen Zugangsdaten?
Hatte letztens auch die Diskussion mit Benutzern, die sich beschwerten, nach spätestens zehn Minuten Inaktivität ihr persönliches Passwort eingeben zu müssen (Bildschirmsperre; vom Nutzerwechsel mal abgsehen). (PS: Bei jedem Supermarkt müssen die Kassenkräfte ihre Geldkassette mitnehmen, wenn sie nur aufs Klo gehen).
Für Windows XP gab es übrigens SuRun, was die UAC auch für XP nachbildete (ob das technisch nun genauso gut war oder dem erhöhten Benutzer sogar zu viele Rechte gab, kann ich nicht beurteilen).
> Von UAC-Bypass hast du auch schon mal gehört?
Und das geht wie, wenn Malware keinen Zugriff aufs System hat, na? Von Autoelevation hast du schon mal etwas gehört und wie man sie abstellt?
> Oder Zugriff auf andere Systeme mit identischen Zugangsdaten?
Versuch das mal mit meinen Systemen. Zudem kann man auch User in Standardkonten recht leicht dazu bringen, erhöhte Rechte zu verwenden, wenn sie das Adminpasswort kennen. Absolute Sicherheit gibt es nie. Lies noch mal meinen Link – und bitte Sinn entnehmend.
Es macht einen gewaltigen Unterschied, ob man nur die UAC mit Ok wegklickt, oder ob man Admin-User und Passwort eingeben muss. Bei letzterem sollte bei jedem die Alarmglocke angehen, wenn das passiert, ohne dass man das bewusst ausgelöst hat.
Nein, schon bei OK muss bei jedem User die Alarmglocke läuten, sofern er nicht ein völlig schwachsinniger DAU ist. Bei solchen Leuten nützt das Arbeiten in Standardkonten auch rein gar nichts, sofern sie das Adminpasswort kennen.