Benutzerkontensteuerung

Die Benutzerkontensteuerung (englisch User Account Control, kurz UAC) ist ein Sicherheitsmechanismus von Microsoft Windows, welcher mit Windows Vista eingeführt wurde. Die Benutzerkontensteuerung wurde eingeführt, weil viele Windows-Anwender mit Administratorprivilegien arbeiten, welche bis Windows XP direkt auf gestartete Anwendungen übertragen wurden. Dieses Verhalten stellte ein großes Sicherheitsrisiko dar, weil so auch Schadsoftware administrative Rechte erhielt. Mit aktiver Benutzerkontensteuerung erhalten Anwendungen zunächst nur die Rechte eines normalen Nutzers, selbst wenn der Nutzer Administratorprivilegien hat.

Beteilige dich an der Diskussion!

Dieser Artikel wurde wegen inhaltlicher Mängel auf der Qualitätssicherungsseite der Redaktion Informatik eingetragen. Dies geschieht, um die Qualität der Artikel aus dem Themengebiet Informatik auf ein akzeptables Niveau zu bringen. Hilf mit, die inhaltlichen Mängel dieses Artikels zu beseitigen, und beteilige dich an der Diskussion! (+) Begründung: Sehr weit von einem enzyklopädischen Stil entfernt, zudem teilweise Textplagiate.--TheRandomIP (Diskussion) 00:17, 14. Dez. 2015 (CET)

Anmeldepasswort zur Rechteerhöhung

Anwendungen können bei Bedarf administrative Rechte vom Administrator anfordern. Der Administrator muss die Rechteerhöhung ausdrücklich gewähren. Der Mechanismus ist bedingt mit dem unter UNIX-Systemen bekannten sudo Befehl vergleichbar.

Das Verhalten der Benutzerkontensteuerung ist anpassbar. Beispielsweise kann eingestellt werden, dass anstelle eines einfachen Bestätigungsdialoges das Anmeldepasswort zur Rechteerhöhung eingegeben werden muss.

Technisch bildet die Benutzerkontensteuerung die Grundlage für das Sandboxing von Programmen und Verzeichnissen unter Windows. Sie ermöglicht die Vergabe von Privilegien an Prozesse und die Isolierung von Prozessen und Fenstern, die auf demselben System mit unterschiedlichen Rechten ausgeführt werden.

Least-Privilege-Prinzip

Unter aktuellen Versionen von Windows wird bei der Installation ein Benutzerkonto mit Administratorrechten angelegt. Obwohl für den täglichen Gebrauch normale Nutzerrechte ausreichend sind, legen viele Anwender kein zusätzliches Benutzerkonto mit eingeschränkten Rechten an und betreiben ihren PC stattdessen mit dem Benutzerkonto, welches über volle Administratorrechte verfügt.

Da Prozesse grundsätzlich die Rechte des Nutzers "erben", bedeutete dies vor der Einführung der Benutzerkontenkontrolle, dass jede Software, auch Schadsoftware, mit vollen Administratorrechten gestartet wurde und so uneingeschränkten Zugriff auf das System hatten.

Mit Windows Vista, welches erstmals Microsofts Security Development Lifecycle anwendete, wurde mit der Benutzerkontensteuerung ein Sicherheitsmechanismus eingeführt, um das Prinzip des least user access oder least-privileged user account (LUA) umzusetzen. Mitglieder der Gruppe Administratoren erhalten beim Anmelden zwei Token: einen als Administrator und einen als Standardnutzer. Diese Nutzer werden als „Geschützte Administratoren“ (Protected Administrators, PA) bezeichnet. Sie arbeiten meistens mit normalen Nutzerrechten, können diese aber erhöhen, wenn es die Aufgabe erfordert. Um eine Manipulation der Rechteerhöhung durch Schadsoftware zu vermeiden, findet diese standardmäßig auf dem sicheren Desktop statt.

In die Benutzerkontensteuerung wurde auch der Befehl Runas implementiert. Der Befehl ermöglicht, Administrationsaufgaben mit einem normalen Benutzerkonto durchzuführen. Dazu muss das Konto und das Passwort eines Administrators in einem Dialog eingegeben werden. Diese UAC-Abfrage wird als „Eingabeaufforderung für erhöhte Rechte für Standardbenutzer“ (Over-the-shoulder, OTS) bezeichnet, während die Rechteerhöhung von Geschützten Administratoren als „Administratorbestätigungsmodus“ (Admin Approval Mode, AAM) bezeichnet wird.

Sicherheitskonzept

Neben einer Zugriffssteuerungsliste (ACL) und den Privilegien, die zur feineren Rechtevergabe (oder -verbot) auch schon unter XP vorhanden waren, kam ab Windows NT 6.0 (Vista) noch der „Integrity Level“ hinzu. Im Deutschen wurde dies etwas unglücklich mit „Verbindlichkeitsstufe“ übersetzt, aber auch „Integritätsebenen“ ist ein geläufiger Begriff. Die Verbindlichkeitsstufe ist ein Sicherheitsmechanismus der Vorrang vor der Zugriffssteuerungsliste hat, also Zugriffe auch dann verhindert, wenn sie die Zugriffssteuerungsliste erlauben würde. Dazu bekommt jeder Prozess in seinem Access Token einen sogenannten Integrity Level (IL) verpasst, der ausdrücken soll, wie vertrauenswürdig er ist. Die hohe Verbindlichkeitsstufe bildet zusammen mit den administrativen Privilegien die beiden Teile des „administrativen Schlüsselbundes“, neben der Zugriffssteuerungsliste.

Integritätsebenen

Jedes Objekt im System befindet sich auf einer von fünf Stufen, gekennzeichnet durch ein Label in seinem Security Descriptor. Die Grundidee der Integrity Levels (IL) ist es, dass Prozesse, die auf einer niedrigeren Stufe laufen, Objekte mit höherer Stufe nicht beschreiben können (No Write-up). So kann ein Prozess mit niedriger Verbindlichkeitsstufe den auf „Medium“ stehenden Benutzerdaten nichts anhaben und schon gar nicht den noch höher eingestuften Systemkomponenten. Zugriffe von unten nach oben sind also beschränkt, während auf gleicher Ebene oder von oben nach unten alles erlaubt ist – im Rahmen der Zugriffssteuerungsliste. Die fünf Integritätsebenen sind:

Systemverbindlichkeitsstufe

Höchste Stufe, ist nur Systemprozessen wie svchost.exe, csrss.exe, winlogon.exe usw. und dem Benutzer SYSTEM sowie LocalSystem, LocalService und NetworkService vorbehalten.

Hohe Verbindlichkeitsstufe

Ist die Stufe der Benutzergruppen Administratoren, Sicherungs-Operatoren, Netzwerkkonfigurations-Operatoren und Kryptografie-Operatoren. Dies ist nötig, damit deren Prozesse durch User Interface Privilege Isolation (UIPI) nicht von Standardnutzerprozessen beeinflusst werden können.

Mittlere Verbindlichkeitsstufe

Ist die Stufe der Standardbenutzer (authentifizierte Benutzer). Die meisten Ordner und Verzeichnisse auf der Festplatte haben diese Integritätsebene, ebenso die Prozesse dieser Nutzer.

Niedrige Verbindlichkeitsstufe

Entspricht dem „geschützten Modus“ des Internet Explorers, welches das erste Programm war, das dieses Sandboxing nutzte. Auf der Festplatte gibt es unter %userprofile%\Appdata\LocalLow ein Verzeichnis mit niedriger Verbindlichkeitsstufe, in das diese Prozesse schreiben können. In der Registry steht mit HKCU\Software\AppDataLow ein äquivalenter Verzeichnispfad mit IL „low“ zur Verfügung. Die Benutzergruppe „Jeder“ hat ebenfalls diese Verbindlichkeitsstufe.

Nicht vertrauenswürdige Verbindlichkeitsstufe

Entspricht quasi einem Sandkasten im Sandkasten. Diese Integritätsebene wird für Anonymous-Anmeldungen verwendet. Da standardmäßig kein Verzeichnispfad mit diesem IL existiert, können diese Prozesse nur im Arbeitsspeicher existieren. Die Registerkarten des Google Chrome laufen z. B. mit dem Security Descriptor „nicht vertrauenswürdige Verbindlichkeitsstufe“.

Die Hauptziele der Mandatory Integrity Control (MIC) sind die Trennung von Standardnutzerprozessen von Prozessen mit erhöhten Rechten, weswegen auch das Component Object Model die Integritätsebenen beachtet. Ferner wird durch die Verbindlichkeitsstufen ein Schreibschutz im Wurzelverzeichnis des Rechners gewährleistet, während andererseits Anwendungen wie der Internet Explorer nur beschränkte Änderungsmöglichkeiten von Nutzerdaten und -profil haben. Während im Allgemeinen bei Objekten nur „No Write-up“ gilt, setzt das Prozessmanagement im NT-6-Kernel „No Read-up“ und „No Write-up“ bei laufenden Prozessen, um eine Manipulation der höhergestellten Prozesse zu verhindern. Es ist lediglich SYNCHRONIZE, PROCESS_QUERY_LIMITED_INFORMATION und PROCESS_TERMINATE möglich.

Normalerweise bekommt jede Anwendung die Rechte des Prozesses, von dem sie gestartet wurde. Das würde aber bedeuten, dass wenn ein Anwender den Internet Explorer startet, dieser auch mit mittlerer Verbindlichkeitsstufe laufen würde. Um das zu verhindern, gibt es im Access Token eines Accounts den Eintrag TOKEN_MANDATORY_POLICY_NEW_PROCESS_MIN, welcher bei Benutzeraccounts gesetzt und bei administrativen Accounts nicht gesetzt ist. Ist dieser Eintrag gesetzt, bewirkt er, dass Prozesse, welche gestartet werden, keine höheres Integrity Level bekommen können, als der EXE-Datei zugewiesen wurde. Da dem iexplorer.exe nur das IL „Low“ zugewiesen ist, wird diese Datei bei normalen Benutzern auch nur in dieser Stufe gestartet. Wenn der Administrator UAC abschaltet, laufen alle seine Prozesse mit hoher Verbindlichkeitsstufe, da jedem Prozess das administrative Token zugewiesen wird. Alle Dokumente und Dateien, welche dieser Administrator erzeugt, besitzen dann die Integritätsebene „hoch“. Wird nun die Benutzerkontensteuerung wieder aktiviert, bekommt jeder von ihm angeklickte Prozess/Ordner nur das Standardnutzer-Token (IL „mittel“) zu sehen, weswegen er diese Dateien ohne Admin-Rechte nicht mehr öffnen kann.

Die Verbindlichkeitsstufe eines Ordners gilt entweder nur für diesen selbst (object inherit, OI) oder für das ganze Verzeichnis (container inherit, CI). Wird eine Datei z. B. in %userprofile%\Appdata\LocalLow oder ein Unterverzeichnis desselben geschoben, erhält diese die niedrige Verbindlichkeitsstufe, egal welche sie vorher hatte (Abstufung vorausgesetzt).

Privilegien

Die administrativen Privilegien sind der zweite Teil des „Schlüsselbundes“. Unter NT 6.0 wurden die Probleme, die sich bei der Arbeit mit einem Standardnutzeraccount ergaben, entschärft, indem neue Privilegien hinzukamen und manche Aufgaben nicht mehr administrativ sind. Unter XP wurde nicht zwischen Zeitzone und Systemzeit unterschieden, obwohl nur letztere für die Sicherheit relevant ist. Ab Vista gibt es deshalb die Unterscheidung zwischen dem Privileg, die Systemzeit zu ändern (SeSystemTimePrivilege) und dem Privileg die Zeitzone zu ändern (SeTimeZonePrivilege). Ferner können drahtlose Internetverbindungen und Energieoptionen des Rechners ohne Adminrechte konfiguriert werden. Die Installation von kritischen Windows-Updates ist nun ebenfalls als Standardnutzer möglich. In Firmennetzen können auch Treiber und ActiveX-Elemente von bestimmten Seiten installiert werden, wenn dies durch die Administratoren in den Gruppenrichtlinien freigegeben wurde. Die Privilegien der einzelnen Gruppen können unter Start > secpol.msc > Lokale Richtlinien > Zuweisen von Benutzerrechten angesehen oder geändert werden. Die folgende Liste enthält nicht alle Privilegien und Gruppen von NT-6.X-Systemen. Sie dient nur der Veranschauung der Unterschiede zwischen Administratoren und Benutzern.

Privileg	Benutzer	Administratoren	Bezeichnung
SeSystemTimePrivilege			Ändern der Systemzeit
SeTimeZonePrivilege			Ändern der Zeitzone
SeIncreaseBasePriorityPrivilege			Anheben der Zeitplanungspriorität
SeBatchLogonRight			Anmelden als Stapelverarbeitungsauftrag
SeDenyRemoteInteractiveLogonRight			Anmelden über Remotedienste verweigern
SeIncreaseWorkingSetPrivilege			Arbeitseinsatz eines Prozesses vergrößern
SeNetworkLogonRight			Auf diesen Computer vom Netzwerk aus zugreifen
SeChangeNotifyPrivilege			Auslassen der durchsuchenden Überprüfung
SeDebugPrivilege			Debuggen von Programmen
SeManageVolumePrivilege			Durchführen von Volumewartungsaufgaben
SeUndockPrivilege			Entfernen des Computers von der Dockingstation
SeCreatePagefilePrivilege			Erstellen einer Auslagerungsdatei
SeSystemProfilePrivilege			Erstellen eines Profils der Systemleistung
SeProfileSingleProcessPrivilege			Erstellen eines Profils für einen Einzelprozess
SeCreateGlobalPrivilege			Erstellen globaler Objekte
SeCreateSymbolicLinkPrivilege			Erstellen symbolischer Verknüpfungen
SeRemoteShutdownPrivilege			Erzwingen des Herunterfahrens von einem Remotesystem aus
SeShutdownPrivilege			Herunterfahren des Systems
SeLoadDriverPrivilege			Laden und Entfernen von Gerätetreibern
SeInteractiveLogonRight			Lokal anmelden zulassen
SeBackupPrivilege			Sichern von Dateien und Verzeichnissen
SeTakeOwnershipPrivilege			Übernehmen des Besitzes von Dateien und Objekten
SeSystemEnvironmentPrivilege			Verändern von Firmwareumgebungsvariablen
SeSecurityPrivilege			Verwalten von Überwachungs- und Sicherheitsprotokollen
SeRestorePrivilege			Wiederherstellen von Dateien und Verzeichnissen

Technik

Mechanismus

UAC-Architektur: Weiß wurde von XP übernommen, blau wurde modifiziert, gelbe Teile sind eine Neuentwicklung

Die Benutzerkontensteuerung besteht aus dem Application Information Service (AIS), der UAC-Abfrage selbst mit dem sicheren Desktop, der User Interface Privilege Isolation (UIPI), der Installationserkennung und der Anwendungs- /Datenvirtualisierung. Obwohl sich der Login-Prozess von Administratoren äußerlich nicht von dem unter XP unterscheidet, erkennt die Local Security Authority (lsass.exe) bei der Anmeldung eines Mitgliedes der Gruppe Administratoren dies und kreiert zwei Acces Token: Ein User-Token und ein Admin-Token. Der User-Token wird nun zum Starten der Windows-Shell verwendet. Explorer.exe ist wiederum der Vaterprozess, von dem alle anderen Prozesse innerhalb der Shell ihren Access Token vererbt bekommen. Alle Anwendungen laufen so mit Userrechten, wie wenn sich ein Standardnutzer anmelden würde. Wird nun eine Anwendung ausgeführt welche Administratorrechte benötigt, startet der Application Information Service (AIS) eine UAC-Abfrage. Bei Verweigerung wird die Anwendung nicht gestartet, bei Zustimmung wird diese mit dem Admin-Token ausgeführt. Wird diese erhöhte Anwendung beendet, wird auch der Prozess mit erhöhten Rechten beendet.

Eine UAC-Abfrage wird entweder provoziert, wenn ein Programm in seinem XML-Manifest erhöhte Rechte anfordert oder wenn die Installationserkennung zuschlägt. Diese verwendet eine Heuristik die Installationsroutinen erkennt, da die typischen Verzeichnisse (%programfiles%, %systemroot%\System32\config) nur von Administratoren beschrieben werden können. Auf dieselbe Weise werden Updateroutinen und Deinstallationsroutinen erkannt. Die Heuristik arbeitet nur bei 32-Bit-Programmen, wenn diese keine manuelle Rechteerhöhung durch requestedExecutionLevel anfordern, und wenn LUA (Standardnutzer/Geschützter Administrator) aktiv ist. Die Heuristik sucht nach Schlüsselwörtern wie „install“, „setup“, „update“, Schlüsselworte wie Anbieter, Firmenname, Produktname, Dateibeschreibung und Namen. Ferner wird nach Schlüsselwörtern im Side-by-side-Manifest und in den StringTables der ausführbaren Datei gesucht, ebenso bestimmte Bytesequenzen und bestimmte Eigenschaften in RC Data. Fordert eine Anwendung Adminrechte an, läuft folgender Vorgang ab: Der Befehl ShellExecute(BeispielApp.exe) wird an AIS (%SystemRoot%\System32\Appinfo.dll) gesendet. AIS, welche innerhalb von svchost.exe läuft, startet Consent.exe (%SystemRoot%\System32\Consent.exe). Consent.exe macht einen Screenshot und wendet einen Abdunklungseffekt auf die Bitmap an. Anschließend wird auf einen Virtuellen Desktop gewechselt der nur dem Benutzer Lokales System (SYSTEM) gehört, die Bitmap als Bildschirmhintergrund eingefügt und die Abfragebox der Benutzerkontensteuerung eingeblendet. Dieser Vorgang wird als Sicherer Desktop bezeichnet und verhindert, das Schadware Einfluss auf die Entscheidung nehmen kann.

Ablauf der Rechteerhöhung mit dem Application Information Service (AIS)

Wenn das abfragende Programm von Microsoft digital signiert wurde und das Image im Windows-Systemverzeichnis liegt, ist die Kopfzeile der Box blau. Grau bedeutet, dass das Programm digital signiert wurde, aber nicht von Microsoft stammt. Gelb steht für nicht signierte Anwendungen/Programme und rot erscheint bei blockierten Anwendungen. Im Prompt erscheint das Icon, die Beschreibung, der Dateiname und der Publisher, wenn signiert. Dies ist als Hürde für Schadsoftware gedacht, um das Vortäuschen seröser Software zu erschweren. Unter „Details“ kann die Kommandozeile eingeblendet werden, welche zur Rechteerhöhung weitergegeben wird. Bei blauen UAC-Abfragen kann hier auch das Zertifikat angesehen werden. Drückt der Nutzer „Nein“/„Abbrechen“, schickt Windows einen access-denied Fehler an den Prozess, der die Anfrage stellte. Wenn der Benutzer zustimmt, indem er auf „Ja“ drückt oder ein administratives Passwort eingibt, ruft AIS CreateProcessAsUser(BeispielApp.exe) auf, um den Prozess mit Administrator-Identität zu starten. Weil der Prozess technisch gesehen von AIS gestartet wurde, wird ein Feature in der CreateProcessAsUser-API genutzt, welches es erlaubt, die Prozess-ID des Vaters auf die desjenigen zu setzen, welcher das Programm (und damit die Anfrage) ursprünglich startete. Deshalb erscheinen Prozesse, die mit erhöhten Rechten laufen nicht als Kindprozesse von AIS Service Hosting.

In der Praxis könnte Schadware die UAC-Abfrage nachbilden, was im Admin Approval Mode (AAM) aber keine Rolle spielt, da ein Klick auf „Ja“ keine Rechteerhöhung zur Folge hätte. Problematischer sind Passworteingaben, da dies durch Trojaner (Keylogger) abgegriffen werden kann. Microsoft empfahl deshalb bei Over-the-shoulder (OTS) eine Secure Attention Sequence anzufordern, bzw. diese Art der Rechteerhöhungen generell abzublocken. Versucht ein Programm ohne eine Rechteerhöhung anzufordern in administrative Pfade zu schreiben, werden Verzeichnisse und Registry virtualisiert. Dabei wird eine Kopie derselben vom Programm beschrieben, wobei diese im Nutzerprofil unter %userprofile%\AppData\Local\VirtualStore\ sowie HKCU\Software\Classes\VirtualStore\ abgelegt wird, sodass jeder Nutzer eine eigene Kopie erhält. Dies soll vor allem älteren Anwendungen das ungestörte Ausführen ermöglichen. Bei 64-Bit-Anwendungen ist dies nicht möglich, ebenso, wenn eine UAC-Abfrage negativ beantwortet wurde.

Einige Anwendungen laufen mit erhöhten Rechten im selben Desktop wie niedriger gestufte Anwendungen. Wird von einem Nutzer ein Prozess mit erhöhten Rechten ausgeführt (per OTS oder AAM), läuft dieser Prozess in einem anderen Account. Die tiefer laufenden Prozesse können dadurch keinen Code in den höher liegenden Prozess schreiben. Allerdings könnten die tiefer liegenden Anwendungen den höher laufenden Fake-Input senden, um diese zu kompromittieren. Das Sandboxing durch die Integritätsebenen soll dies verhindern, indem tieferliegende Prozesse in ihren Rechten gegenüber höheren beschränkt werden. Dies wird als User Interface Privilege Isolation (UIPI) bezeichnet. Prozesse können nur Prozesse mit gleicher oder niedrigerer Verbindlichkeitsstufe zum Schreiben öffnen. Um den Zugriff auf Geheimnisse im Arbeitsspeicher zu verhindern, haben Prozesse mit niedrigerem IL keinen Lesezugriff auf Prozesse mit höherer Verbindlichkeitsstufe. Tiefergestellte Prozesse können dadurch keine window handle validation auf einen höheren Prozess ausführen. Die Befehle SendMessage oder PostMessage zu höheren Prozessen bekommen von der API Erfolgsmeldungen zurückgeschickt, während die Befehle im stillen verworfen werden. Thread Hooks und Journal Hooks gegen Prozesse mit höherer Verbindlichkeitsstufe sind ebenso wie DLL-Injection nicht möglich.

UAC-Abfrage

Die UAC-Abfrage lässt sich über Start > Systemsteuerung > Benutzerkonten und Jugendschutz > Benutzerkonten > Einstellungen der Benutzerkontensteuerung ändern den persönlichen Vorlieben anpassen. Die Auswahlmöglichkeiten dort beschränken sich aber auf einen Schieberegler, wo zwischen unterster Stufe (Win7: UAC abgeschaltet; ab Win8: UAC erhöht ohne Nachfrage), zwei mittleren Stufen (UAC an, mit Whitelist für Windows-Programme) und der höchsten Stufe (UAC an, ohne Whitelist für Windows-Programme) gewählt werden kann. Die beiden obersten Stufen aktivieren dabei den Sicheren Desktop; standardmäßig ist die zweithöchste Stufe gewählt.

Eingabeaufforderung zur Zustimmung

Den Vollzugriff auf die Einstellungsmöglichkeiten der Benutzerkontensteuerung gibt es nur in den Lokalen Sicherheitsrichtlinien (secpol.msc) unter Start > secpol.msc > Lokale Richtlinien > Sicherheitsoptionen. Käufer einer preisgünstigen Windows-Variante wie Home Basic und Home Premium haben keine grafische Benutzeroberfläche wie gpedit.msc und secpol.msc und müssen die Einstellungen deshalb in der Registrierungsdatenbank (regedit.exe) unter HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System vornehmen. Die Einstellungsmöglichkeiten sind deshalb nachfolgend auch mit Registrierungs-Werten in Klammern angegeben. Die Standardeinstellungen in Windows NT 6.1 und höher sind fett gedruckt.

Interessant ist, dass der Administratorgenehmigungsmodus auch die Möglichkeit hat, Unix-typisch das Anmeldepasswort zur Rechteerhöhung einzugeben, wie dies bei sudo der Fall ist. Dabei kann zwischen dem normalen (ConsentPromptBehaviorAdmin = 3) und dem Sicheren Desktop (ConsentPromptBehaviorAdmin = 1) gewählt werden. Interessant ist auch die Option ValidateAdminCodeSignatures, bei der nur Programme Adminrechte erlangen können, die digital signiert und überprüft sind. Bei Windows 8 und später ist dies nicht mehr nötig, da die Funktion im SmartScreen-Filter aufgeht, der Programme nur starten lässt, die diese Anforderungen erfüllen und/oder Reputation besitzen. Alle Eingabehilfen (UIAccess) müssen bereits ab Vista eine PKI-Signatur aufweisen, sonst werden sie nicht akzeptiert. Die „sicheren Verzeichnisse“ (EnableSecureUIAPaths) können nur von Administratoren beschrieben werden. Die Rechteerhöhung für Standardbenutzer hatte ursprünglich keinen Sicheren Desktop (wird in älterer Literatur nicht aufgeführt), der Zahlensprung von 1 auf 3 mag dies verdeutlichen.

Für Paranoiker gibt es noch die Möglichkeit, zur Rechteerhöhung die Secure Attention Sequence (SAS) anzufordern. Dazu muss unter Start > gpedit.msc > Administrative Vorlagen > Windows-Komponenten > Benutzerschnittstelle für Anmeldeinformationen die Option „Vertrauenswürdiger Pfad für Anmeldeinformationseintrag erforderlich“ aktiviert werden. Die Rechteerhöhung behindert den Arbeitsablauf massiv, soll aber das Abgreifen von Passwörtern verhindern. Wird eine Anwendung gestartet die Adminrechte anfordert, erscheint erst eine Dialogbox „Windows-Sicherheit“, in der man den Vorgang fortsetzten oder abbrechen kann. Wird fortsetzen gewählt, erfolgt die Aufforderung die Secure Attention Sequence (SAS) auszuführen. Erst danach steht die UAC-Abfrage zur Rechteerhöhung bereit.

Richtlinie	Sicherheitseinstellung	Erläuterung
Administratorgenehmigungsmodus für das integrierte Administratorkonto (FilterAdministratorToken)	Deaktiviert (0)	UAC für das integrierte Administratorkonto
	Aktiviert (1)
Alle Administratoren im Administratorbestätigungsmodus ausführen (EnableLUA)	Aktiviert (1)	UAC für die Gruppe der Administratoren
	Deaktiviert (0)
Anwendungsinstallationen erkennen und erhöhte Rechte anfordern (EnableInstallerDetection)	Aktiviert (1)	Installationserkennungsheuristik
	Deaktiviert (0)
Bei Benutzeraufforderung nach erhöhten Rechten zum sicheren Desktop wechseln (PromptOnSecureDesktop)	Aktiviert (1)	Wechsel auf Sicheren Desktop
	Deaktiviert (0)
Datei- und Registrierungsschreibfehler an Einzelbenutzerstandorte virtualisieren (EnableVirtualization)	Aktiviert (1)	Datei- und Registryvirtualisierung
	Deaktiviert (0)
Erhöhte Rechte nur für UIAccess-Anwendungen, die an sicheren Orten installiert sind (EnableSecureUIAPaths)	Aktiviert (1)	Eingabehilfen müssen unter %programfiles% oder %systemroot%\System32 installiert sein
	Deaktiviert (0)
Nur ausführbare Dateien heraufstufen, die signiert und überprüft sind (ValidateAdminCodeSignatures)	Deaktiviert (0)	PKI-Signaturüberprüfung für alle Anwendungen die erhöhte Rechte anfordern
	Aktiviert (1)
UIAccess-Anwendungen können erhöhte Rechte ohne sicheren Desktop anfordern (EnableUIADesktopToggle)	Deaktiviert (0)	Eingabehilfeprogramme können den Sicheren Desktop deaktivieren
	Aktiviert (1)
Verhalten der Eingabeaufforderung für erhöhte Rechte für Administratoren im Administratorgenehmigungsmodus (ConsentPromptBehaviorAdmin)	Erhöhte Rechte ohne Eingabeaufforderung (0)	Alles wird ohne Nachfrage hochgestuft
	Eingabeaufforderung zu Anmeldeinformationen auf dem sicheren Desktop (1)	Anmeldepasswort auf dem Sicheren Desktop
	Eingabeaufforderung zur Zustimmung auf dem sicheren Desktop (2)	Ja/Nein-Abfrage auf dem Sicheren Desktop
	Eingabeaufforderung zu Anmeldeinformationen (3)	Anmeldepasswort zur Rechteerhöhung
	Eingabeaufforderung zur Zustimmung (4)	Ja/Nein-Abfrage zur Rechterhöhung
	Eingabeaufforderung zur Zustimmung für Nicht-Windows-Binärdateien (5)	Ja/Nein-Abfrage mit UAC-Whitelist
Verhalten der Benutzeraufforderung für erhöhte Rechte für Standardbenutzer (ConsentPromptBehaviorUser)	Anforderungen für erhöhte Rechte automatisch ablehnen (0)	Roter UAC-Prompt blockt Rechteerhöhung
	Eingabeaufforderung zu Anmeldeinformationen (1)	Administratives Passwort zur Rechteerhöhung
	Eingabeaufforderung zu Anmeldeinformationen auf dem sicheren Desktop (3)	Dito auf dem Sicheren Desktop

Schwachstellen

Leo Davidson entdeckte während des Beta-Tests von Windows 7, dass etwa 70 Windows-Programme ohne Nachfrage mit vollen Administratorrechten ausgeführt werden, und demonstrierte die damit mögliche Rechteausweitung.

Stefan Kanthak veröffentlichte einen Proof of Concept zur Rechteausweitung mittels der Installationserkennung.

Stefan Kanthak zeigte einen weiteren Proof of Concept, der die Ausführung beliebigen Codes sowie die Rechteausweitung mittels der von Leo Davidson entdeckten automatischen Rechteerhöhung und DLL Hijacking erlaubt.

„Vozzie“ zeigte einen anderen Proof of Concept, der die Rechteausweitung durch Einschleusen eines selbsterstellten Manifests mittels der von Leo Davidson entdeckten automatischen Rechteerhöhung erlaubt.

Integration im Betriebssystem

Entwicklung

„Tagsüber arbeite ich als Security Program Manager bei Microsoft. Ich schreibe zudem recht häufig für das TechNet-Magazin über das Thema Sicherheit. Daher ist es selbstverständlich, dass ich die Sicherheit sehr ernst nehme. Ich habe jedoch auch andere Interessen. In meiner Freizeit spiele ich gern Windows-basierte Spiele. […] Die Sache hat jedoch einen Haken. Wie meine Freunde Jesper Johansson und Aaron Margosis lehne ich es ab, Spiele mit Administratorrechten auszuführen, sofern es nicht unbedingt erforderlich ist. Dies beruht teilweise darauf, dass ich sicherstellen möchte, dass mir bei einem Netzwerkspiel die Meldung „0wn3d“ nur aufgrund meiner mangelnden Geschicklichkeit angezeigt wird und nicht, weil mich jemand mit einem Rootkit bombardiert […]. Ich vertrete diesen Standpunkt so konsequent, dass ich häufig tolle neue Spiele nicht spielen kann. Wenn ich ein Spiel unter meinem Standardbenutzerkonto auf einem zur SBS-Domäne (Small Business Server) gehörenden Client nicht zum Laufen bekomme, nachdem ich es unter einem Administratorkonto installiert und aktualisiert habe, entferne ich es sofort. Es gibt keine Entschuldigung für solche technischen Mängel, und ich habe genug Spiele, aus denen ich wählen kann. Ich gebe zu, dass sich diese Haltung extrem anhören mag, aber in diesem Punkt bin ich unnachgiebig.“

– Matt Clapham über Vista, Februar 2007

Das Problem bei Windowssystemen war in der Vergangenheit immer, dass sie zwar eine Trennung von Nutzer- und Adminkonten für Firmen und Kindersicherung zuließen, die meisten Rechner (75 %) aber Einzelplatzrechner sind. Da jede Maschine einen Administrator braucht und die meisten Nutzer auch die volle Kontrolle über das System haben wollen, um Änderungen vorzunehmen, gab es praktisch nur Administratoren als Nutzer. Dies hatte auch Auswirkungen auf die Software, die stets davon ausgehen konnte, dass der Nutzer über Adminrechte verfügt und systemweit geltende Änderungen vornehmen kann. Software, die für diese Umgebung geschrieben wurde, arbeitet nicht, wenn der Anwender nur ein Standardnutzer ist, was damals nur für Firmen und Kindersicherung relevant war. Eine Software, die Administratorrechte bekommt, kann aber das System beschädigen, entweder mit Absicht (Schadsoftware) oder unabsichtlich (schlecht programmierte Software). Firmen umgingen das Problem teilweise, indem sie diese Anwender zur Powerusergruppe hinzufügten, die es unter Vista eigentlich nicht mehr gibt.

Die Benutzerkontensteuerung sollte zwei Ziele erreichen: die Inkompatibilität der Software beseitigen und dem Nutzer Änderungen am System deutlich machen. Aus diesem Grund wurde der geschützte Administrator (Protected Admin, PA) eingeführt, welcher standardmäßig das erste Konto auf dem System ist. Durch die Erzeugung zweier Access-Tokens – eines als Standardnutzer, eines als Administrator – wurde das Problem der unbemerkten Änderungen gelöst. Der Weg vom Administrator zum Benutzer war bei Drittsoftware aber ein steiniger, da die meisten Anwendungen beim Erscheinen von Vista nicht für Standardnutzer ausgelegt waren (Wes Miller im Microsoft TechNet, Mai 2008: „Meine Herausforderung an Sie: Fühlen Sie den Schmerz“). Durch Telemetriedaten von Kunden konnte Microsoft die Entwicklung von Drittanbietersoftware im Angesicht der Benutzerkontensteuerung gut mitverfolgen.

Die Zahl der Anwendungen, welche mit Adminrechten lief, konnte drastisch gesenkt werden. Dies wurde von Microsoft positiv aufgenommen, da die Verwundbarkeit des Betriebssystems reduziert wurde. Im ersten August (2007) nach dem Release von Vista hatten die Telemetrie-Kunden in 50 % ihrer Sessions (Zeitraum vom Einloggen bis zum Ausloggen, max. 24 Std.) eine UAC-Abfrage. In diesem Zeitraum forderten 775.312 verschiedene Programme Adminrechte an, wobei die Installationen dazugezählt wurden. Hier zeigte sich, dass die meiste Software noch Adminrechte benötigte. Drei Monate später sank die Zahl bereits auf 350.000 pro Monat. Ein Jahr später, im August 2008, waren es nur noch 168.149 UAC-Prompts pro Monat. Der Umstand, dass die Neuinstallation und Einrichtung des Rechners mehr UAC-Abfragen erfordert, wurde ebenfalls erkannt. Die Daten des Customer Experience Improvement Program zeigten auch auf, dass von Mai 2007 bis Juli 2008 die Zahl der Sessions mit einer oder mehreren UAC-Abfragen von 50 % auf etwa 33 % (Vista SP1) fiel.

Damit tat sich aus Sicht von Microsoft das nächste Problem auf: Da Windows selbst ins Betriebssystem eingreifen kann, erzeugte Windows nun etwa 40 % aller UAC-Prompts. Da die Anwendungsprogrammierer ihre Arbeit taten, verschob sich das Verhältnis der UAC-Abfragen. Windows-Komponenten erzeugten 17 der Top 50 UAC-Abfragen in Vista, und 29 der Top 50 in Vista SP1. Mit Vista SP1 wurden kleinere Verbesserungen eingeführt, um die UAC-Abfragen weiter zu reduzieren. Das neue Betriebssystem Windows 7 wurde als Gelegenheit gesehen, tiefergehende Veränderungen durchzuführen, um die Zahl der UAC-Abfragen des Systems weiter zu reduzieren. Es wurde z. B. auch herausgefunden, dass Benutzer die UAC genervt abschalteten, oder die Abfragen einfach nur durchwinkten. Ferner wurde in einer Testumgebung herausgefunden, dass nur 13 % der Teilnehmer sagen konnten, warum der UAC-Dialog erschien. Bei Telemetrienutzern wurde zudem beobachtet, dass 89 % der Prompts in Vista und 91 % der Abfragen in Vista SP1 positiv beantwortet wurden. Es wurde befürchtet, dass die Nutzer den UAC-Dialog aus Gewohnheit abklicken und bei kritischen Abfragen nicht bewusst entscheiden. Ein informativerer UAC-Dialog und eine Reduzierung der UAC-Abfragen von Windows selbst wurden angestrebt, damit die Nutzer besser auf die kritischen UAC-Prompts achten können.

Mit Windows 7 wurde deshalb die UAC-Whitelist eingeführt. Die Programme, die auf dieser umfangreichen Liste stehen, erhalten ohne UAC-Abfrage automatisch Adminrechte. Vereinfacht gesagt sind dies fast alle EXE-Dateien, die unter %HOMEDRIVE%\Windows\System32 liegen. Nennenswerte Ausnahmen sind mmc.exe und besonders rundll32.exe, da sich sonst virus.dll mit Adminrechten starten lassen könnte. Das Programm %HOMEDRIVE%\Windows\ehome\Mcx2Prov.exe ist ebenfalls auf der Whitelist. Nachfolgend sind alle Programme aufgeführt, die sich beim Release von Windows 7 auf der Whitelist befanden. Bis auf kleinere Veränderungen wurde die so modifizierte Benutzerkontensteuerung bei allen nachfolgenden Windows-Versionen übernommen. Die Whitelist kann deaktiviert werden, wenn der UAC-Regler auf die höchste Stufe gestellt wird.

Whitelist der Benutzerkontensteuerung

%systemroot%\ehome\Mcx2Prov.exe %systemroot%\system32\AdapterTroubleshooter.exe %systemroot%\system32\BitLockerWizardElev.exe %systemroot%\system32\bthudtask.exe %systemroot%\system32\chkntfs.exe %systemroot%\system32\cleanmgr.exe %systemroot%\system32\cliconfg.exe %systemroot%\system32\CompMgmtLauncher.exe %systemroot%\system32\ComputerDefaults.exe %systemroot%\system32\dccw.exe %systemroot%\system32\dcomcnfg.exe %systemroot%\system32\DeviceEject.exe %systemroot%\system32\DeviceProperties.exe %systemroot%\system32\dfrgui.exe %systemroot%\system32\djoin.exe %systemroot%\system32\eudcedit.exe %systemroot%\system32\eventvwr.exe %systemroot%\system32\FXSUNATD.exe %systemroot%\system32\hdwwiz.exe %systemroot%\system32\ieUnatt.exe %systemroot%\system32\iscsicli.exe %systemroot%\system32\iscsicpl.exe %systemroot%\system32\lpksetup.exe %systemroot%\system32\MdSched.exe %systemroot%\system32\msconfig.exe %systemroot%\system32\msdt.exe %systemroot%\system32\msra.exe %systemroot%\system32\MultiDigiMon.exe %systemroot%\system32\Netplwiz.exe %systemroot%\system32\newdev.exe %systemroot%\system32\ntprint.exe %systemroot%\system32\ocsetup.exe %systemroot%\system32\odbcad32.exe %systemroot%\system32\OptionalFeatures.exe %systemroot%\system32\perfmon.exe %systemroot%\system32\printui.exe %systemroot%\system32\rdpshell.exe %systemroot%\system32\recdisc.exe %systemroot%\system32\rrinstaller.exe %systemroot%\system32\rstrui.exe %systemroot%\system32\sdbinst.exe %systemroot%\system32\sdclt.exe %systemroot%\system32\shrpubw.exe %systemroot%\system32\slui.exe %systemroot%\system32\SndVol.exe %systemroot%\system32\spinstall.exe %systemroot%\system32\SystemPropertiesAdvanced.exe %systemroot%\system32\SystemPropertiesComputerName.exe %systemroot%\system32\SystemPropertiesDataExecutionPrevention.exe %systemroot%\system32\SystemPropertiesHardware.exe %systemroot%\system32\SystemPropertiesPerformance.exe %systemroot%\system32\SystemPropertiesProtection.exe %systemroot%\system32\SystemPropertiesRemote.exe %systemroot%\system32\taskmgr.exe %systemroot%\system32\tcmsetup.exe %systemroot%\system32\TpmInit.exe %systemroot%\system32\verifier.exe %systemroot%\system32\wisptis.exe %systemroot%\system32\wusa.exe %systemroot%\system32\DriverStoreFileRepositorybth.inf_x86_neutral_65c949576945c2a9fsquirt.exe %systemroot%\system32\oobesetupsqm.exe %systemroot%\system32\sysprepsysprep.exe

Auslöser einer UAC-Abfrage

Wie oben erwähnt, konnten 2008 in einer Testumgebung mit Vista nur 13 % der Teilnehmer sagen, warum der UAC-Dialog erschien. Unter Vista lautete der lapidare Kommentar in der UAC-Box: „Zur Fortsetzung des Vorganges ist Ihre Zustimmung erforderlich“. Ab Windows 7 wurde die Formulierung „Möchten Sie zulassen, dass durch das folgende Programm Änderungen an diesem Computer vorgenommen werden?“ gewählt, die für unerfahrene Nutzer besser geeignet ist. Die fachlich korrekte Frage lautet:

„Möchten Sie, dass das folgende Programm Administratorrechte bekommt?“

Konkret sind unter Windows NT 6.0 und höher drei Gründe ausschlaggebend, warum eine UAC-Abfrage eine Rechteerhöhung anfordert: Die Zugriffskontrolle, die Verbindlichkeitsstufen und die Privilegien. Die Zugriffskontrollliste jeder Datei kann angesehen werden, wenn im Windows-Explorer bei einer Datei mit Rechtsklick > Eigenschaften > Sicherheit die Berechtigungen der einzelnen Nutzer und Gruppen angesehen werden. Der Benutzer SYSTEM (Lokales System) und die Gruppe der Administratoren haben praktisch überall den Vollzugriff, der Nutzer Mustermann darf im Stammverzeichnis des Systems C:\Windows (%systemroot%) und den Installationsverzeichnissen C:\Programme bzw. C:\Programme (x86) (%programfiles%) nur lesen und ausführen. Die Integritätsebenen und Privilegien werden in der normalen grafischen Benutzeroberfläche wie dem Taskmanager leider nirgends angezeigt. Der Process Explorer von Microsoft ist dazu praktisch zwingend erforderlich, da hier bei laufenden Prozessen deren Verbindlichkeitsstufe eingeblendet wird, und unter Details auch die Privilegien des Prozesses angezeigt werden können. Folgende Vorgänge benötigen Administratorrechte und lösen eine UAC-Abfrage aus:

• Wenn Programme installiert werden, da %programfiles% nur mit Adminrechten beschrieben werden kann. Gleiches gilt für Entfernen, da Löschen auch nur eine Art des Schreibens ist.
• Wenn Treiber (de)installiert werden, da c:\windows\system32\drivers unter %systemroot% liegt und nur mit Adminrechten beschrieben werden kann. Ferner wird das Privileg SeLoadDriverPrivilege benötigt.
• Wenn ActiveX-Elemente (de)installiert werden, da C:\Windows\Downloaded Program Files unter %systemroot% liegt.
• Wenn in administrative Teile der Registry geschrieben werden soll. Diese Dateien (SYSTEM.DAT, SOFTWARE.DAT, SAM.DAT, SECURITY.DAT, BCD-Template.DAT uvm.) liegen unter C:\Windows\System32\config und damit unter %systemroot%. Dies ist z. B. bei Änderungen an der Benutzerkontensteuerung und Windows Update der Fall, da diese in SOFTWARE.DAT, und damit unter %systemroot% gespeichert werden.
• Wenn Änderungen in der Systemsteuerung vorgenommen werden, da hierfür praktisch immer administrative Privilegien erforderlich sind, z. B. SeSystemTimePrivilege (Ändern der Systemzeit), SeBackupPrivilege und SeRestorePrivilege (Systemwiederherstellung etc.) uvm. Meist wird dabei auch in administrative Teile der Registry geschrieben.
• Wenn Änderungen an der Windows-Firewall vorgenommen werden, da diese irgendwo unter %systemroot% abgelegt werden. Ferner werden Privilegien wie SeCreateGlobalPrivilege u. a. benötigt.
• Wenn Einblick in Order und Verzeichnisse genommen werden soll, die für Standardnutzer nicht einsehbar sind, und/oder Daten zwischen Benutzerverzeichnissen kopiert werden.

Eine besondere Rolle nimmt das Verzeichnis %programdata% ein, das standardmäßig unsichtbar geschaltet ist. Hier haben Benutzer Vollzugriff, %programdata%\Microsoft und seine Unterverzeichnisse können aber nur von Administratoren beschrieben werden. Die Unterordner Microsoft Antimalware und Windows Defender können aus Gründen des Selbstschutzes nur von Administratoren, SYSTEM und TrustedInstaller gelesen und beschrieben werden. Änderungen an MSE bzw. Defender erfordern deshalb Adminrechte.

Geschützter Modus und AppContainer

Mit dem Aufkommen der Benutzerkontensteuerung war klar, dass Schadware versuchen würde, allein mit Standardnutzerrechten auszukommen. Hier kommen die Verbindlichkeitsstufen ins Bild: Alle administrativen Pfade werden de facto durch Zugriffssteuerungslisten und Privilegen vor dem Zugriff tieferstehender Anwendungen und Nutzer geschützt. Die Verbindlichkeitsstufen betreffen hier nur die laufenden Prozesse, welche durch UIPI (No Read-up, No Write-up) durch Zugriff von unten geschützt sind. Verzeichnisse, welche mit Integrity Level (IL) „high“ geschützt sind, gibt es standardmäßig nicht. Bei der Entwicklung von Vista war sich Microsoft schon damals des Problems bewusst, dass ein Webbrowser im gleichen Rechtekontext läuft, wie die Gehaltsabrechnung einer Firma. Die Integritätsstufen „low“ und „untrusted“ werden deshalb zum Sandboxing von Anwendungen und ihren Verzeichnissen eingesetzt.

Dialogbox zur Rechteerhöhung „low“ auf „medium“.

Mit dem Internet Explorer 7 in Vista wurde die erste Anwendung geschaffen, die mit niedriger Verbindlichkeitsstufe läuft. Wie bereits oben erwähnt, gibt es auf der Festplatte unter %userprofile%\Appdata\LocalLow ein Verzeichnis mit niedriger Verbindlichkeitsstufe, in das diese Prozesse schreiben können. In der Registry steht mit HKCU\Software\AppDataLow ein äquivalenter Verzeichnispfad zur Verfügung. Damit Daten aus der Sandbox iexplorer.exe in das Benutzerprofil gelangen können, ist ein Broker-Prozess ieuser.exe mit IL „medium“ nötig. Inzwischen wurde das Sandboxing auch von anderer Software übernommen: Beim Chrome läuft der Broker-Prozess chrome.exe mit Integrity Level (IL) „medium“, die Registerkarten chrome.exe mit „nicht vertrauenswürdiger Verbindlichkeitsstufe“, d. h. ohne Schreibzugriff auf die Festplatte. Der Adobe Reader hat inzwischen einen „Protected Mode“, Microsoft Office 2010 „Protected View“ usw.

Wird aus diesen Sandkästen eine Datei mit IL „low“ in ein Verzeichnis mit IL „medium“ per Drag and Drop verschoben, erscheint die „UAC-Abfrage für Arme“ im Bild rechts, da eine Rechteerhöhung von niedriger auf mittlere Verbindlichkeitsstufe stattfinden würde. Dies hat mit der Benutzerkontensteuerung direkt nichts zu tun, da der Standardnutzer selbst IL „mittel“ besitzt, also keine Adminrechte benötigt, um Dateien „auf sein Niveau“ zu erhöhen. Die Benutzerkontensteuerung unter Windows Vista und 7 ist insofern relevant, da das Abschalten derselben (oder das Arbeiten mit dem eingebauten Administratorkonto, was denselben Effekt hat) dieses Sandboxing zerstört. TOKEN_MANDATORY_POLICY_NEW_PROCESS_MIN wird nur bei Benutzeraccounts gesetzt und bewirkt, dass Prozesse keinen höheren Integrity Level bekommen können, als wie der Anwendung zugewiesen wurde. Wenn die Benutzerkontensteuerung abgeschaltet wird, bekommen alle Prozesse Adminrechte zugewiesen. Aus diesem Grund ist der Protected Mode des IE abgeschaltet, wenn UAC deaktiviert ist.

Unter Windows 8 ist die Benutzerkontensteuerung nicht abgeschaltet, wenn der UAC-Regler auf unterster Stufe steht. Die Rechteerhöhung auf Wunsch einer Anwendung findet dann geräuschlos statt. Dies ist notwendig, da für die Windows-Apps Sandboxing erzwungen wird. Da immer mehr Windows-Anwendungen auf niedriger Verbindlichkeitsstufe laufen, wurde zudem ein Weg gesucht, damit diese nicht in die „Low“-Verzeichnisse einer anderen Anwendung schreiben können. Deshalb bekommt jede Windows-App (bzw. ihre Dateien und Anwendungen) einen individuellen Security Identifier (S-1-15-2-...) zugewiesen. Diese Kapselung wird als AppContainer bezeichnet. Diese AppContainer werden unter %programfiles%\WindowsApps abgelegt, das Verzeichnis besitzt niedrige Verbindlichkeitsstufe. Der Internet Explorer ist unter Windows 8 die einzige Anwendung, die auch als Desktop-Programm in einem AppContainer laufen kann („Erweiterter geschützter Modus“). Mit Windows 10 sollen die AppContainer auch auf dem Desktop Einzug halten. In beiden Betriebssystemen kann die Benutzerkontensteuerung nur abgeschaltet werden, wenn in den Lokalen Sicherheitsrichtlinien (secpol.msc) „Alle Administratoren im Administratorbestätigungsmodus ausführen“ auf „Deaktiviert“ gesetzt wird. Wenig überraschend kommt dann, wenn eine Windows-App gestartet werden soll, eine Fehlermeldung mit der Aufforderung, UAC wieder zu aktivieren.

Hürde oder Bürde?

Wenn ein Angreifer bei einem Unix-System Zugang zu einem Account bekommt, der sudo ohne Einschränkungen und weitere Authentifizierung ausführen kann, hat er praktisch schon gewonnen, da ihm damit Vollzugriffsrechte gewährt werden. Bei Windows Vista und höher ist dies nicht anders. Bereits beim Erscheinen von Vista 2007 stellten Russinovich und Johansson klar, dass die Benutzerkontensteuerung weder zum Nerven, noch als Schutz gegen ausgeklügelte Angriffe zur Rechteausweitung gedacht ist. Damit hatte man nun dasselbe Problem, an dem UNIX seit 20 Jahren arbeitet. Ferner schützt die UAC nicht vollständig höhere Prozesse gegen Manipulation durch niedere Prozesse, da eben kein vollständiges Sandboxing stattfindet, was auch nicht geplant war. Malware mit Nutzerrechten läuft bei Geschützten Administratoren im selben Account wie erhöhte Prozesse. Da viele Anwendungen in das Nutzerprofil schreiben und lesen, kann sich hier eine Lücke ergeben, die zu einer Rechteausweitung führt. Russinovich nannte z. B. das Anhängen von Schadprogrammen an Shell-Extensions in der Registry, um sich früher oder später Adminrechte zu erschleichen. Ferner teilen sich privilegierte Prozesse denselben Namensraum mit Standardnutzerprozessen. Wenn Schadware weiß, wann ein privilegierter Prozess (IL: high/system) auf einen bestimmten Speicherbereich zugreift, könnte sie durch einen Pufferüberlauf Schadcode in den Prozess injizieren. Die einfachste Möglichkeit ist, unter einem wohlklingenden Namen einen UAC-Prompt auszulösen, in der Hoffnung, dass unerfahrene Nutzer auf „Ja“ klicken. Wie Jesper M. Johansson im Microsoft TechNet schon 2007 treffend formulierte:

“If the bad guys can't think of any other way to defeat UAC, they will almost certainly resort to asking the user to do it for them. Given the choice of dancing pigs and security, we know from experience that the dancing pigs win every time.”

„Wenn den bösen Jungs kein anderer Weg einfällt, UAC zu besiegen, werden sie sicher darin Zuflucht nehmen, den User zu bitten, es zu tun. Wenn es die Wahl zwischen tanzenden Schweinen und Sicherheit gibt, wissen wir aus Erfahrung, dass die tanzenden Schweine immer gewinnen.“

– Jesper M. Johansson

Aufgrund dieser Möglichkeiten wurde die Benutzerkontensteuerung von Microsoft auch nicht als Sicherheitsbarriere gesehen. Als Sicherheitsbarriere wird von Microsoft eine Schranke bezeichnet, durch die Code oder Daten nur passieren können, wenn die Sicherheitsrichtlinien es erlauben. Beispielsweise kann ein Standardnutzer die Daten eines anderen Nutzers nicht manipulieren oder diesen zwingen, bestimmten Code auszuführen. Wenn es doch möglich wäre, wäre dies eine Sicherheitslücke in Windows (oder einem Drittprogramm). Diese strikte Art der Trennung findet bei der Benutzerkontensteuerung nicht statt, als Kompromiss aus Bequemlichkeit und Sicherheit. Deshalb stellen die Integritätsebenen auch keine Sicherheitsbarriere dar, da standardmäßig eben nur No Write-up gilt. Die Benutzerkontensteuerung war in erster Linie eine Bequemlichkeit, die das Wechseln zwischen den Benutzerkonten zur Rechteerhöhung erleichtern sollte. Ihr Kernanliegen ist es, dass alle User nur mit Standardnutzerrechten arbeiten, um das Prinzip des least-privileged user account (LUA) durchzusetzen.

Eine Zahlenkolonne möchte Administratorrechte

Im Jahr 2011, also vier Jahre und eine Version der UAC später (Windows 7), sah Microsoft auch einen Nutzen gegen Malware. Die Schadwareschreiber begannen, ihre Software auf Standardnutzerrechte anzupassen. Für die meisten Schadprogramme stellte dies kein Problem dar. Die Umgehung der UAC stellte sich für Malware aber als sehr schwierig heraus. Ein Teil der Schadware ging deshalb dazu über, die Benutzerkontensteuerung zu deaktivieren, um böse UAC-Prompts der Schadware direkt nach dem Neustart zu vermeiden. Genannt wurden Sality-Viren, Alureon-Rootkits, FakePAV, Autostart-Würmer, Banking-Trojaner usw. Für die Änderung der UAC-Einstellungen benötigt die Malware bereits Adminrechte, was durch Exploits, eine Abschaltung der UAC oder einen „Ja“-Klick zur falschen Zeit möglich ist. Microsoft reagierte darauf, indem Microsoft Security Essentials nun darauf achtet, ob Software die UAC-Einstellungen ändert, und nutzt dies als Verhaltenserkennung. Da normale Software immer weniger UAC-Abfragen stellt, wurde die Verhaltenserkennung einfacher. Da 23 % aller infizierten Rechner die Benutzerkontensteuerung deaktiviert hatten, wurden die Nutzer gebeten, diese aktiviert zu lassen. Es wurde nochmals darauf hingewiesen, dass UAC nicht als Virenschutz gedacht ist, aber die Sicherheit des Betriebssystems verbessert.

Die Benutzerkontensteuerung schützt nicht per se vor Malware, sie sorgt nur für eine strikte Trennung zwischen Benutzer- und Administratorrechten. Jedes Mal, wenn die Grenze von unten nach oben durchschritten werden soll, erfolgt eine UAC-Abfrage. Der „Schutz“ besteht also darin, dass man bestimmen kann, welches Programm Adminrechte bekommt und welches nicht. Alle administrativen Einstellungen, die man von Hand am Rechner vornimmt, können auch von einer Software durchgeführt werden; die Frage ist eben bloß, ob man das will. Bei tanzenden Schweinen, Zahlenkolonnen und chinesischen Schriftzeichen, die Administratorrechte möchten, sollte man besser vorsichtig sein. Der UAC-Prompt im Bild rechts stammt z. B. von einer Schadware, die am 30. Dezember 2014 von der Malc0de Database zu Testzwecken in ein Windows 10 TP heruntergeladen wurde. Die Malware wird ausgeführt, wenn der Benutzer entweder auf „Ja“ klickt oder die Benutzerkontensteuerung abgeschaltet hat. Knapp zwei Tage später, zu Silvester, erkannte der Windows Defender die Zahlenkolonne als Win32/Sality. Der SmartScreen-Filter war dabei zu Testzwecken deaktiviert, da er die Schadware mangels PKI-Zertifikat geblockt hätte.

Wie oben erwähnt, ist die Benutzerkontensteuerung nicht zum Schutz gegen ausgeklügelte Angriffe zur Rechteausweitung gedacht. Das Metasploit-Framework bietet verschiedene Möglichkeiten, die UAC zu umgehen, sowie die Möglichkeit, unter wohlklingendem Namen einen UAC-Prompt auszulösen und dreist um Adminrechte zu bitten. Die Varianten ohne UAC-Pop-up arbeiten alle mit DLL-Hijacking und DLL-Injection und nutzen unter Windows 7/8/8.1 die automatische Rechteerhöhung durch die UAC-Whitelist (autoElevate) aus. Vista ist dagegen immun. Aus diesem Grund ist es sinnvoll, den UAC-Regler auf die höchste Stufe zu stellen, bzw. mit getrennten Konten zu arbeiten. Jesper M. Johansson stellte 2007 folgende Liste der Best practices auf:

Wertung	Einstellung
Am Schlimmsten	Benutzerkontensteuerung abschalten
Schlecht	Automatische Rechteerhöhung ohne Nachfrage
Gut	Arbeiten im Administratorbestätigungsmodus
Besser	Getrennte Konten, Rechteerhöhung durch OTS
Am Besten	Getrennte Konten, Kontowechsel für Admin-Aufgaben