Benutzerkontensteuerung
Die Benutzerkontensteuerung (auch englisch User Account Control, UAC) ist ein im Betriebssystem Windows von Microsoft integrierter Sicherheitsmechanismus, welcher mit Windows Vista eingeführt wurde. Ziel der Benutzerkontensteuerung ist es, die Sicherheit des Systems zu verbessern, indem Software zunächst nur mit einfachen Nutzerrechten ausgeführt wird anstatt mit Administratorrechten. Administratoren können eine Erhöhung der Rechte veranlassen, sollte die Anwendung diese benötigen. Die Benutzerkontensteuerung wurde eingeführt, da viele Anwender mit Administratorprivilegien arbeiten, welche bis inklusive Windows XP direkt auf gestartete Anwendungen übertragen wurden. Dieses Verhalten stellte ein großes Sicherheitsrisiko dar, weil auch etwaige Schadsoftware administrative Rechte erhielt.
Wenn sich mit aktiver UAC ein Administrator am System anmeldet, so arbeiten von ihm gestartete Programme dennoch zunächst nur mit den Rechten eines normalen Benutzers. Sobald eine Anwendung administrative Berechtigungen für ihre Ausführung anfordert, wird ein Dialogfeld angezeigt, welches explizit zu bestätigen ist, um die Rechte zu gewähren.
Unter UNIX-Systemen existiert mit dem Kommandozeilenbefehl sudo ein Mechanismus, der bedingt mit der Benutzerkontensteuerung zu vergleichen ist.[1] Das Verhalten der UAC kann in den lokalen Sicherheitsrichtlinien angepasst werden. Es besteht so beispielsweise auch die Möglichkeit, das Anmeldepasswort zur Rechteerhöhung erforderlich zu machen.[2]
Ferner ist die UAC die Grundlage und Voraussetzung 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.
Risiko und Bedeutung voller Zugriffsrechte
Versionen von Windows, die älter als Windows NT sind, beziehungsweise nicht davon abstammen (beispielsweise Windows 3.1, Windows 95, 98 und ME), waren Einzelbenutzersysteme, in denen jeder Benutzer die volle Systemkontrolle besaß. Windowssysteme der NT-Linie sind dagegen Mehrbenutzersysteme, so dass verschiedene Benutzerrollen und -rechte vergeben werden können.
Unter Windows XP erhalten die bei der Installation angelegten Benutzerkonten Administratorrechte. Dies führte dazu, dass viele mit Windows XP ausgestattete Einzel-PCs standardmäßig mit einem Benutzer betrieben wurden, der über volle Administratorrechte verfügten. Dadurch wird jede Software, auch Schadsoftware, mit Administratorrechten gestartet, so dass diese vollständigen Zugriff auf das System besitzt. In vielen älteren Anwendungen wurden eingeschränkte Benutzerrechte nicht berücksichtigt, obwohl Microsoft dies in den mit Windows 95 erstmals veröffentlichten „Designed for Windows“-Richtlinien als Minimalanforderung festlegte. Installiert oder startet man solche Software mit eingeschränkten Rechten, treten Fehler auf oder die Software arbeitet nicht ordnungsgemäß. Dazu kam die eingeschränkte Benutzerfreundlichkeit: Um in Windows XP den Kalender durch klicken auf die Uhrzeit abrufen zu können, sind Administratorrechte erforderlich. Diese Probleme wurden früher oft dadurch umgangen, dass an Einbenutzerrechnern stets mit Administratorrechten gearbeitet wurde.
Unix- und Unix-artige Systeme (wie macOS ab Version 10 oder z. B. Ubuntu) wurden von Anbeginn als Mehrbenutzersysteme konzipiert. Jeder angemeldete Benutzer hat ein Heimatverzeichnis für seine persönlichen Daten, wo er nach Belieben editieren kann. Änderungen außerhalb des Benutzerkontos können im Allgemeinen nur vom Root-Konto durchgeführt werden. Dieses ist bei manchen Unix-artigen Systemen wie Ubuntu standardmäßig nicht freigeschaltet. Die Mitglieder der Gruppe „Sudoers“ können aber administrative Aufgaben mit dem Befehl sudo ausführen, was dann im Rechtekontext des Benutzers root geschieht. Um zu verhindern, dass Schadsoftware sudo anwendet, muss zur Ausführung des Befehls das Anmeldepasswort zur Authentifizierung eingegeben werden. Sonderfall bzgl. unixoider Systeme ist Android; hier wird das Benutzersystem nicht für die Benutzerverwaltung verwendet, sondern für die Abschottung der Apps gegeneinander: Für jede App wird bei ihrer Installation ein eigenes „Nutzerkonto“ eingerichtet, anschließend wird die App (als einzige) in dessen 'home-Verzeichnis’ installiert. Die eigentliche Verwaltung des (einen) echten Benutzers geschieht gesondert; dadurch ist Android im Grunde ein Einbenutzer-System. Dieser eine (echte) Benutzer hat im Allgemeinen keine Rechte, die einem Admin-User entsprechen würden – dazu muss Android „gerootet“ werden.
Mit Windows Vista, welches erstmals Microsofts Security Development Lifecycle anwendete, wurde mit der Benutzerkontensteuerung ein vergleichbarer Mechanismus 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, dem alle administrativen Rechte und Privilegien entzogen sind. Diese Nutzer werden als „Geschützte Administratoren“ (Protected Administrators, PA) bezeichnet. Während die Sudoers unter Unix den „großen Bruder“ mit sudo anrufen, haben die Geschützten Administratoren eine „gespaltene Persönlichkeit“, welche sie je nach Aufgabe wechseln. Um eine Manipulation der Rechteerhöhung durch Schadsoftware zu vermeiden, findet diese standardmäßig auf dem sicheren Desktop statt.[3][4]
Das Endszenario ist in beiden Fällen das Gleiche: Die meisten Benutzer sind nur mit Standardnutzerrechten unterwegs und können nur in bestimmten Bereichen des Rechners editieren. Die Verwalter des Systems, also die Mitglieder der Gruppe Sudoers oder Administratoren arbeiten ebenfalls mit eingeschränkten Rechten, können diese aber bei Bedarf erhöhen. In beiden Fällen ist das Prinzip des Least-privileged User Account (LUA) umgesetzt: Alle arbeiten nur mit den Rechten, die sie für diese Aufgabe auch wirklich benötigen. Interessant ist dazu das Buch Windows Vista Security: Securing Vista Against Malicious Attacks von Roger A. Grimes (u. a. CISSP, MCSE: Security, MVP) und Jesper M. Johansson (Senior Security Strategist bei der Security Technology Unit von Microsoft). Auf drei Seiten beschreiben sie detailliert die Unterschiede und Gemeinsamkeiten von sudo und UAC, deren spezifischen Vor- und Nachteile, und warum sich Microsoft gegen die Einführung eines sudo-Befehls entschieden hat.[1]
In die Benutzerkontensteuerung wurde auch der Befehl Runas implementiert. Der Befehl kann dazu genutzt werden, Verwaltungs- bzw. Administrationsaufgaben durchzuführen, ohne dass sich ein Benutzer mit Administrationsrechten komplett neu anmeldet. Dazu muss das Konto und das Passwort eines Mitgliedes der Gruppe Administratoren 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:[5]
- 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\LocalLowein Verzeichnis mit niedriger Verbindlichkeitsstufe, in das diese Prozesse schreiben können. In der Registry steht mitHKCU\Software\AppDataLowein ä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“.[6]
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.[5]
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.[7] 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.[8]
Die Verbindlichkeitsstufe eines Ordners gilt entweder nur für diesen selbst (object inherit, OI) oder für das ganze Verzeichnis (container inherit, CI).[8] 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).[9]
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.[10] 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.[11]
| 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[Anm. 1] |
| 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
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.[12]
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.[12] 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.[13][Anm. 2]
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.[13]
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.[13] 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.[14] 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.[12]
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.[15] 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.[14]
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.[16]
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.[17]
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.[18]
| 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.[19]
Stefan Kanthak veröffentlichte einen Proof of Concept zur Rechteausweitung mittels der Installationserkennung.[20]
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.[21]
„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.[22]
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.“
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).[24] Firmen umgingen das Problem teilweise, indem sie diese Anwender zur Powerusergruppe hinzufügten, die es unter Vista eigentlich nicht mehr gibt.[25]
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.[24] 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“).[25] 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.[24]
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.[24]
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.[26] 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\driversunter %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 Filesunter %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\configund 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.[6]
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.[1] 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.[6]
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.[Anm. 3] 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“).[27] 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.[6] 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.[1] 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.[28] 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.[13] Die einfachste Möglichkeit ist, unter einem wohlklingenden Namen einen UAC-Prompt auszulösen, in der Hoffnung, dass unerfahrene Nutzer auf „Ja“ klicken.[13] 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.“
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.[13][15]
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.[29]
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.[30] 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:[28]
| 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[Anm. 4] |
Anmerkungen
- Alle Admins sind auch Benutzer, d. h., sie besitzen auch SeIncreaseWorkingSetPrivilege. Ist aber nicht Teil der Privilegien der Gruppe Administratoren
- Ist auch der Grund, warum bei Bildschirm-Recordern oder Remotedesktop-Anwendungen die UAC-Abfrage nicht erscheint. Sie findet auf einem anderen Desktop statt als dem, wo aufgezeichnet wird.
- Die Details haben nicht direkt mit der Benutzerkontensteuerung zu tun, weswegen hier nur oberflächlich darauf eingegangen wird. Dass nicht alles, was wie eine Windows-App aussieht, auch eine ist, d. h. ein AppContainer, bleibt hier auch unerwähnt. „PC-Einstellungen“ z. B. hat App-Design, ist aber kein AppContainer. Details dazu sollten im Artikel Windows-App stehen.
- Sinnvollerweise sollte dann bei „Verhalten der Benutzeraufforderung für erhöhte Rechte für Standardbenutzer“ die Option „Anforderungen für erhöhte Rechte automatisch ablehnen“ gewählt werden.
Einzelnachweise
- Roger A. Grimes, Jesper M. Johansson: Windows Vista Security: Securing Vista Against Malicious Attacks. Wiley, 2007, ISBN 0-470-10155-5.
- DaniHalfin: User Account Control security policy settings (Windows 10). Abgerufen am 30. Mai 2019 (amerikanisches Englisch).
- Benutzer in Windows 7. (PDF) com!, August 2010, abgerufen am 1. Januar 2015.
- Russell Smith: Least Privilege Security for Windows 7, Vista and XP. Packt Publishing, 2010, ISBN 1-84968-004-3.
- How the Integrity Mechanism Is Implemented in Windows Vista. Microsoft, abgerufen am 1. Januar 2015 (englisch).
- Windows 8.1 Security Internals. Chris Jackson, 11. November 2014, abgerufen am 1. Januar 2015 (englisch).
- Sicherheitsmechanismus "Integrity Level" (IL). WinFAQ, abgerufen am 1. Januar 2015.
- Windows Integrity Mechanism Design. Microsoft, abgerufen am 1. Januar 2015 (englisch).
- Rechte und Rechtschaffenheit - Die Sicherheitsarchitektur von Windows Vista, Teil 1. c't, Oktober 2007, abgerufen am 1. Januar 2015.
- Windows Vista. TechNet Magazine, Juni 2008, abgerufen am 1. Januar 2015 (englisch).
- Martin Grotegut: Windows Vista. Springer, 2007, ISBN 3-540-38882-6.
- Understanding and Configuring User Account Control in Windows Vista. Microsoft TechNet, abgerufen am 1. Januar 2015 (englisch).
- Inside Windows Vista User Account Control. Microsoft TechNet, Juni 2007, abgerufen am 1. Januar 2015 (englisch).
- Windows Vista Application Development Requirements for User Account Control Compatibility. Microsoft, Juni 2007, abgerufen am 1. Januar 2015 (englisch).
- PsExec, User Account Control and Security Boundaries. Microsoft TechNet, Februar 2007, abgerufen am 1. Januar 2015 (englisch).
- Benutzerkontensteuerung (UAC – User Account Control). WinFAQ, abgerufen am 1. Januar 2015.
- UAC-Gruppenrichtlinien- und Registrierungsschlüsseleinstellungen. Microsoft TechNet, abgerufen am 1. Januar 2015.
- Windows 7: CTRL+ALT+DEL - Require to Press to Approve UAC Elevation. Windows SevenForums, September 2013, abgerufen am 1. Januar 2015 (englisch).
- Leo Davidson: Windows 7 UAC whitelist: - Code-injection Issue - Anti-Competitive API - Security Theatre. Abgerufen am 25. August 2015.
- Stefan Kanthak: Defense in depth -- the Microsoft way (part 11): privilege escalation for dummies. In: Full disclosure (mailing list). Abgerufen am 17. August 2015.
- Stefan Kanthak: Defense in depth -- the Microsoft way (part 31): UAC is for binary planting. In: Full disclosure (mailing list). Abgerufen am 25. August 2015.
- UAC Bypass Vulnerability on "Windows 7" in Windows Script Host. In: Bugtraq (mailing list). Abgerufen am 31. August 2015.
- Spielen in einer sicheren Umgebung. Microsoft TechNet, Februar 2007, abgerufen am 1. Januar 2015.
- Engineering Windows 7. Microsoft, Oktober 2008, abgerufen am 1. Januar 2015 (englisch).
- Die Desktopdateien. Microsoft TechNet, Mai 2008, abgerufen am 1. Januar 2015.
- Paul Thurrott, Rafael Rivera: Windows 7 Secrets. Wiley, 2009, ISBN 0-470-50841-8.
- Erweiterter geschützter Modus auf Desktop IE. Microsoft, abgerufen am 1. Januar 2015.
- Security Watch - The Long-Term Impact of User Account Control. Microsoft TechNet, September 2007, abgerufen am 1. Januar 2015 (englisch).
- UAC plays defense against Malware. Microsoft TechNet, August 2011, abgerufen am 1. Januar 2015 (englisch).
- User Account Control – What Penetration Testers Should Know. Raphael Mudge, März 2014, abgerufen am 1. Januar 2015 (englisch).