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.

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.

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.

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.

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.

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.

Entwicklung

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.

%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.

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.