Kompromisse zwischen Sicherheit und Bequemlichkeit? Das Beispiel UAC

Wer sich mit IT-Sicherheit beschäftigt, kennt die Einsicht, dass Maßnahmen, die das Sicherheitsniveau eines Systems erhöhen, zumeist die Bequemlichkeit reduzieren. Viele Berater gehen sogar soweit, dass sie “Bequemlichkeit” und “Sicherheit” als zwei Pole betrachten, die einander gegenüberstehen. Verschiebt man den Regler in Richtung eines Pols, so entfernt er sich stets vom anderen Pol. Leider gibt das kurz vor dem Release stehende Windows 7 Anlass, diese Betrachtung erneut zu betonen und einige Entscheidungen des Herstellers Microsoft zu kritisieren.

UAC – wie sie gemeint war

Mit Windows Vista hatte Microsoft mit der “User Account Control” (UAC, deutsch:  Benutzerkontensteuerung) eine Technik eingeführt, die dazu beitragen sollte, das allgemeine Sicherheitsniveau von Windows-Systemen anzuheben, die auf typische Weise genutzt werden. Denn leider ist es in der Windows-Welt allzu oft üblich, jede Arbeit mit Administratorrechten zu erledigen. Hier haben wir auch einen typischen Fall für die beiden Pole: Es ist recht bequem, als Admin zu arbeiten, weil einem das System so offen steht und keine (oder kaum) Hürden in den Weg stellt. Dafür ist es auch hochgradig unsicher, denn eben diese fehlenden Hürden bedeuten auch, dass kein Schutz vor versehentlichen Änderungen besteht und dass Angreifer z.B. mit Schadsoftware leichtes Spiel haben und an “alles” im System herankommen.

UAC trug dazu bei, den Regler in solchen Situationen etwas weiter in Richtung “Sicherheit” zu verstellen. Der UAC-Trick: Auch wenn ein Admin sich anmeldet, erhält dieser nur “normale” Benutzerrechte (über das sog. Anmeldetoken oder Access Token) und wird so von den Sicherheitsmechanismen des Betriebssystems geschützt wie – ja, eben wie ein normaler Anwender. UAC sorgt dafür, dass der betreffende Benutzer seine administrativen Aufgaben trotzdem erledigen kann, indem es bei Änderungen, die höhere Rechte erfordern, nachfragt. Bei Bestätigung führt Windows diese Änderung mit vollen Adminrechten aus.

Näheres dazu siehe:

[faq-o-matic.net » Benutzerkontensteuerung (UAC) richtig einsetzen]
http://www.faq-o-matic.net/2008/02/22/benutzerkontensteuerung-uac-richtig-einsetzen/

UAC-Renovierung in Windows 7

UAC wurde heftig kritisiert – nicht immer zu Unrecht. Trotzdem handelt es sich aus Sicht der meisten Experten um ein sinnvolles Feature, das zur Gesamtsicherheit beitragen kann. Um der massiven Kritik zu begegnen, hat Microsoft in Windows 7 einige Änderungen an der User Account Control durchgeführt. Kurz gesagt, sollen diese Änderungen bewirken, dass UAC bei angemeldeten Administratoren seltener nachfragt und viele Aktionen “einfach so” mit Adminrechten ausführt.

Schon diese Ankündigung sorgte bei Kennern der Sicherheitsmaterie für Stirnrunzeln. Schaut man sich die Hintergründe an, so wird dies auch verständlich. Denn UAC funktioniert im Kern wie vorher auch – der angemeldete Administrator hat ein reduziertes Anmeldetoken, das ihm keine Adminrechte gewährt. Muss er nun etwas tun, was administrative Privilegien erfordert, so ist auch weiterhin eine Anhebung der Benutzerrechte (Elevation) nötig, d.h. Windows muss dem jeweiligen Prozess das volle Administrator-Anmeldetoken zuordnen. Bislang erforderte dies immer die Bestätigung des Anwenders, die auch manuell erfolgen musste (die Steuerung durch Programme verhindern einige Mechanismen, die bislang auch noch niemand überwunden hat).

In Windows 7 allerdings kann UAC so konfiguriert werden, dass es bestimmte Änderungen automatisch mit dem Admintoken ausführt, ohne dass es einer Bestätigung bedarf (Auto-Elevation). Im Installationszustand ist dies bereits eingestellt – damit darf man davon ausgehen, dass die breite Masse der Anwender dies auch so belässt. Wichtig dabei aber: Die Auto-Elevation funktioniert nur, wenn der angemeldete User prinzipiell Administrator ist. Meldet sich ein “normaler” Benutzer an, so gibt es ja im Hintergrund für diesen kein Admin-Token.

Hinter den Kulissen: Billige Tricks

Wie vollzieht Windows diese Auto-Elevation? Um die Methode handhabbar zu machen, gibt es dafür ein paar vergleichsweise simple Mechanismen. Dazu gehört eine Art Positivliste (Whitelist) von betriebssystemeigenen Komponenten, denen die Auto-Elevation gestattet ist. Ruft ein Administrator unter dem Schutz von UAC in der Standardeinstellung eine dieser Komponenten auf, um eine administrative Änderung auszuführen, so winkt Windows 7 dies durch – ohne zusätzliche Bestätigung. Sehr bequem.

Das Problem dabei: Auf diese Weise entfällt in vielen Situationen der Effekt von UAC, auf mögliche gefährliche Änderungen aufmerksam zu machen. Anders als in der strikten Handhabung von Windows Vista ist es auf diese Weise auch möglich, dass Applikationen gezielt die neuen Mechanismen ausnutzen, um unbemerkt an administrative Rechte zu gelangen. In der Betaversion von Windows 7 war dies sogar auf triviale Weise möglich: Die Systemdatei rundll32.exe, mit der man beliebige DLLs ausführen kann, war zur Auto-Elevation berechtigt. Schon wenige Tage nach Erscheinen der Betaversion wiesen Experten nach, wie einfach es war, diese Methode auszunutzen und Unfug im System zu treiben, ohne dass der Anwender dies überhaupt bemerkt – obwohl er sich vielleicht sogar auf den von Vista gewohnten Schutz verlässt (siehe unseren Artikel über UAC-Probleme in der Beta).

“Wir haben verstanden” – habt ihr?

Nach etwas Hin und Her reagierte Microsoft und versprach, das Problem bis zur nächsten Vorabversion von Windows 7 zu beheben (Engineering-Blog). Tatsächlich waren die simplen Angriffe der Betaphase mit dem Release Candidate nicht mehr möglich.

Tatsächlich behoben ist das Problem aber nicht. Neben einigen weiteren Kleinigkeiten hat Mirosoft im Wesentlichen nämlich nur die interne Whitelist angepasst und einigen Komponenten die Fähigkeit zur Auto-Elevation genommen, darunter rundll32.exe. Der eigentliche Mechanismus bleibt aber, denn diesen grundlegend zu ändern hätte erhebliche Design-Änderungen oder sogar die Abkehr von der “renovierten” UAC bedeutet.

So ist es auch weiterhin möglich, den bevorrechtigten Windows-Komponenten nahezu beliebigen Code unterzuschieben, der dann durch Auto-Elevation mit vollen Adminrechten läuft. Das Problem ist mittlerweile gut dokumentiert, und Code zur Ausnützung dieser Mechanismen steht frei zur Verfügung. Ein Video zeigt schon seit einigen Wochen, wie sich die Lücke ausnutzen lässt.

[Windows 7 UAC code-injection vulnerability: video demonstration, source code released – istartedsomething]
http://www.istartedsomething.com/20090613/windows-7-uac-code-injection-vulnerability-video-demonstration-source-code-released/

Dabei interessieren sich nicht nur Angreifer für dieses Problem. Auch so mancher “ehrliche” Software-Entwickler dürfte erfreut sein über einen einfachen Weg, seine Applikation mit vollen Adminrechten auszustatten und den Aufwand zu umgehen, der evtl. nötig wäre, um “sauberen” Code zu schreiben, der dem Sicherheitsmodell von Windows 7 tatsächlich entspricht.

UAC – kaputtbequemt

In der Konsequenz lässt sich nur sagen: Microsoft ist der Versuchung zum Opfer gefallen, das UAC-Feature der Bequemlichkeit der Anwender zu opfern. In der Standardeinstellung ist es für Programmierer, die nicht ganz auf den Kopf gefallen, sehr einfach, die Benutzerkontensteuerung auszuhebeln. Die Beteuerung der Redmonder, UAC sei ja nie ein Sicherheitsfeature gewesen, sondern eine Art Zwangsaufforderung an Entwickler, ihre Software konform zu den Windows-Sicherheitsanforderungen zu entwickeln, verfängt nicht. Auch wenn UAC keine unüberwindliche Sicherheitsgrenze darstellt, ist bzw. war es selbstverständlich ein Sicherheitsfeature. In der nun vorliegenden “Überarbeitung” aber wird auch der angestrebte Effekt verfehlt, denn Malware-Entwickler haben es in Standardsituationen (besonders Heimanwender, die im Installationszustand arbeiten und daher als faktisch ungeschützter Administrator angemeldet sind) wieder so leicht wie unter Windows XP, das System zu kompromittieren. “Faule” Softwareentwickler finden einen bequemen Weg, sich wie bisher auf vorhandene Administratorrechte verlassen zu können.

Damit stellt sich endgültig die Sinnfrage: Ein Sicherheitsgurt, der nur manchmal greift, bietet keine Verlässlichkeit. Dass viele Unfälle trotz Gurt tragisch ausgehen, kann da nicht ernsthaft beruhigen – Microsoft argumentiert aber leider genau so (Mark Russinovich im TechNet Magazine vom Juli 2009).

Was tun?

Aller Voraussicht nach wird Microsoft an diesem Problem nichts ändern. UAC so umzubauen, dass es so “bequem” ist wie in der Standardeinstellung von Windows 7, gleichzeitig aber einen Schutzeffekt hat, der dem von Windows Vista nahekommt, dürfte kaum möglich sein. Selbst wenn Redmond es angehen wollte, müsste man dort so gravierende Änderungen am System vornehmen, dass dies kurz vor dem Release oder auch später im Rahmen etwa von Patches kaum zu leisten ist.

Bleibt als einziger Ausweg für den Anwender: So arbeiten, wie man es schon immer hätte tun sollen. Denn UAC ist für Normalanwender, die nicht den lokalen Administratoren angehören, so sicher und komfortabel wie schon unter Windows Vista – eine dauerhafte Anmeldung als Administrator ist praktisch nie nötig, so gut wie alles lässt sich über UAC im “Over the Shoulder”-Modus durchaus bequem ausführen, wenn ein Administratorkennwort bekannt oder ein Administrator “in der Nähe” ist (siehe den oben zitierten Artikel “Benutzerkontensteuerung richtig einsetzen”).

Wer sich als Administrator anmelden muss, aber auf den wirksamen Schutz der UAC nicht verzichten will, kann UAC auch einfach in den Vista-Modus bringen: Einfach den Schieberegler unter “Benutzerkontensteuerung” in der Systemsteuerung ganz nach oben stellen. Domänen-Admins können dies auch per Gruppenrichtlinie tun.