derwowusste
Goto Top

Tipp zur UAC-Nutzung

Ziel des Tipps: Einen Vorschlag zu machen, wie man die UAC sicher benutzt
Hintergrund: das oft zu beobachtende falsche Verständnis davon, was die UAC darstellt
[Nachfolgeartikel, der mit Domänenkonten arbeitet: Tipp zur Nutzung von Zweitaccounts unter Windows ]

Die UAC ist kein Sicherheitsfeature.
Man kann zwar mit Recht sagen, dass ein Rechner mit aktivierter UAC in einigen Belangen sicherer ist, doch geht man dann davon aus, dass der Angreifer schlicht nicht die Fähigkeiten besitzt, die UAC zu umgehen.
Microsoft selbst sagt dazu in https://msdn.microsoft.com/en-us/library/cc751383.aspx

User Access Control (UAC) is a technology introduced with Windows Vista that provides a method of separating standard user privileges and tasks from those that require Administrator access. If a Standard User is using the system and attempts to perform an action for which the user has no authorization, a prompt from Windows appears and asks the Administrator account’s password. If an Administrator is using the system and attempts to do the same task, there is only a warning prompt. That prompt is known as a “Consent Prompt” because the administrator is only asked to agree to the action before proceeding. A weakness that would allow to bypass the “Consent Prompt” is not considered a security vulnerability, since that is not considered a security boundary.

Zu deutsch: Es gibt keine effektive Sicherheitsgrenze zwischen der bloßen Nutzung eines Adminkontos und der (Aus-)nutzung seiner vollen Fähigkeiten, die UAC vermag das lediglich für schwache Userkonten. Wenn man als Admin angemeldet ist und bei aktivierter UAC (Schad-)code ausführt, darf man nicht erwarten, dass dieser daran gehindert wird, auch ohne Zustimmung volle Rechte zu nutzen. Die UAC sollte dies zwar können, aber MS selbst sagt, es wäre keine Sicherheitslücke, wenn eine Designschwäche in Windows dies ermöglichte!

Leider gibt es derzeit diese Designschwäche in Windows 8.1 und 10 und vermutlich auch in 7. MS hat dies bestätigt und eine Lösung für Win10 angekündigt, während für <10 wohl nichts mehr daran getan wird. Siehe https://social.technet.microsoft.com/Forums/windows/en-US/52b9c450-72f1- ...

Konsequenterweise ist also auch bei aktivierter UAC als unsicher zu erachten, dauerhaft ein Adminkonto zu nutzen.
Auch wenn Win10 die Karten neu mischen wird, ändert sich nichts daran, dass MS die UAC nicht als Sicherheitsgrenze einstufen wird.
Wenn man regelmäßig administrative Tasks ausführt, ist es natürlich bequemer, als Admin zu arbeiten. Auch Microsoft-Consultant und Security-Insider Aaron Margosis bezeichnet die UAC als „convenience feature“, siehe https://social.technet.microsoft.com/Forums/windows/en-US/52b9c450-72f1- ... , denn (ohne UAC mit consent-prompt) für jede Admin-Aktion immer den Kontennamen samt langem Adminkennwort einzugeben, stimmt kaum jemanden richtig froh.

Jedoch habe ich mir einen Weg ausgedacht, wie man zumindest lokal angenehm und dennoch sicher arbeiten kann:
für Dinge, die man lokal als Admin tut, legt man sich ein lokales Konto „admin“ an und gibt diesem ein leeres Kennwort. Da per default leere Kennwörter nicht via Netzwerklogon genutzt werden können, kann dies Konto nur für lokale Zwecke genutzt werden (siehe https://technet.microsoft.com/en-us/library/cc737553%28v=ws.10%29.aspx?f ... ). Auch runas-Skripte können dieses Konto dank des fehlenden Kennwortes nicht missbrauchen (http://blogs.msdn.com/b/oldnewthing/archive/2004/11/29/271551.aspx) )
Man stellt ein, dass das Kennwort dieses Kontos nicht abläuft.

Bei Bedarf enabled man noch folgende GPO und schon blendet die UAC dieses Konto auch immer zur Auswahl ein:
Enumerate administrator accounts on elevation ->enabled
Policy path: Computer Config.\administrative templates\Windows Components\Credential User Interface
Supported on: At least Windows Vista
Registry settings: Pfad: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\CredUI, Dword32-Wert: EnumerateAdministrators auf 1 setzen.

Die Kehrseite der Medaille ist schnell gefunden – wir hätten nun ein starkes Konto, mit dem man sich lokal ohne Kennwort anmelden könnte.
Doch auch das ist schnell abgestellt: man setzt 2 Tasks, die das Konto nur dann aktivieren, wenn man selbst angemeldet ist und der Bildschirm entsperrt ist.

Task1:
Name: adminaktiv,
Aktion: cmd /c net user admin /active
Trigger1: on workstation unlock of EuerSchwacherNutzer
Trigger2: on local connection of EuerSchwacherNutzer
Trigger3: at logon of EuerSchwacherNutzer
Ausführendes Konto:System

Task2:
Name: adminlocked
Aktion: cmd /c net user admin /active:no
Trigger1: on workstation lock of any user
Trigger2: on local disconnect from any user session
Trigger3: at system startup
Trigger4 (user logoff): Eventbasiert. Event Log: System, Quelle: winlogon, EventID: 7002
Ausführendes Konto:System

Das ist doch eine runde Sache. Man sollte in jedem Fall zusätzlich die UAC auf höchste Stufe stellen, (die zugehörige GPO ist übrigens https://technet.microsoft.com/en-us/library/dd851609.aspx?f=255&MSPP ... ->“Prompt for consent on the secure desktop”)

Zuletzt ein Tipp an alle Netzwerkadmins, die die Ansicht vertreten
unsere Mitarbeiter arbeiten nur als schwache Benutzer, deshalb schalten wir die UAC aus, sie wird ja nicht benötigt
Diese Sichtweise vernachlässigt die positiven Seiteneffekte der UAC für schwache Nutzer: die UAC umgeht Kompatibilitätsprobleme, indem sie mit Datei- und Registry-Virtualisierung arbeitet. Ohne aktivierte UAC werden für schwache Nutzer wesentlich weniger Programme lauffähig sein, die hohe Rechte voraussetzen.

Edit: ich musste nachbessern: hatte einen Trigger für den Task adminaktiv vergessen!
Edit2: ich hatte vergessen zu betonen, dass das Kennwort dieses Kontos nicht ablaufend sein darf

Content-Key: 264771

Url: https://administrator.de/contentid/264771

Ausgedruckt am: 19.03.2024 um 03:03 Uhr

Mitglied: runasservice
runasservice 27.02.2015 um 18:21:48 Uhr
Goto Top
It's not a bug, it's a feature!

Leider gibt es derzeit diese Designschwäche in Windows 8.1 und 10 und vermutlich auch in 7.

Das Problem besteht bereits seit Windows 7 und ist seit 2009 bekannt. Leo Davidson hat das ausführlich auf seiner Website beschrieben:

http://www.pretentiousname.com/misc/win7_uac_whitelist2.html


Konsequenterweise ist also auch bei aktivierter UAC als unsicher zu erachten, dauerhaft ein Adminkonto zu nutzen.

Eingentlich ist genau das die Schwachstelle. Das Adminkonto besitzt das "Debug Privilege", welches dann unter Umgehung der UAC, dafür benutzt werden kann um Schadsoftware auszuführen.

http://security.stackexchange.com/questions/54324/should-i-worry-about- ...
Mitglied: emeriks
emeriks 11.03.2015 aktualisiert um 12:34:40 Uhr
Goto Top
Hi DWW,
ich widerspreche Dir nur ungern.
Jedoch habe ich mir einen Weg ausgedacht, wie man zumindest lokal angenehm und dennoch sicher arbeiten kann:
für Dinge, die man lokal als Admin tut, legt man sich ein lokales Konto „admin“ an und gibt diesem ein leeres Kennwort. Da per default leere Kennwörter nicht via Netzwerklogon genutzt werden können, kann dies Konto nur für lokale Zwecke genutzt werden (siehe https://technet.microsoft.com/en-us/library/cc737553%28v=ws.10%29.aspx?f ... ). Auch runas-Skripte können dieses Konto dank des fehlenden Kennwortes nicht missbrauchen (http://blogs.msdn.com/b/oldnewthing/archive/2004/11/29/271551.aspx) )
Wenn ich Schädling wäre und auf ein lokales Admin-Konto ohne Passwort spekulieren würde, dann würde ich, wenn ich so ein fände, mir als erstes damit ein weiteres Admin-Konto mit Passwort anlegen und dann dieses benutzen. Und schon greifen die von Dir genannten Einschränkungen nicht mehr.

Unabhängig davon finde ich aber Deine Hinweise, wie man sich das schön anpassen kann, sehr hilfreich. Danke!

E.
Mitglied: DerWoWusste
DerWoWusste 11.03.2015 um 19:30:25 Uhr
Goto Top
Moin.

Was heißt denn "spekulieren auf..."? Du kannst damit nichts anfangen, weder per Skript, noch per Netzwerk. Und interaktiv geht auch nicht unbemerkt.
Mitglied: DerWoWusste
DerWoWusste 08.01.2021 um 15:47:35 Uhr
Goto Top
Edit3: Ich habe zur Sicherheit einen weiteren Tasktrigger empfohlen (Trigger4 für Adminlocked), der in dem Fall greift, wenn man sich (warum auch immer) abmelden möchte, ohne daraufhin direkt im Anschluss den Nutzer zu wechseln oder runterzufahren.