4
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
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
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
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 264771
Url: https://administrator.de/contentid/264771
Ausgedruckt am: 13.11.2024 um 07:11 Uhr
4 Kommentare
Neuester Kommentar
It's not a bug, it's a feature!
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
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- ...
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- ...
Hi DWW,
ich widerspreche Dir nur ungern.
Unabhängig davon finde ich aber Deine Hinweise, wie man sich das schön anpassen kann, sehr hilfreich. Danke!
E.
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.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) )
Unabhängig davon finde ich aber Deine Hinweise, wie man sich das schön anpassen kann, sehr hilfreich. Danke!
E.
Moin.
Was heißt denn "spekulieren auf..."? Du kannst damit nichts anfangen, weder per Skript, noch per Netzwerk. Und interaktiv geht auch nicht unbemerkt.
Was heißt denn "spekulieren auf..."? Du kannst damit nichts anfangen, weder per Skript, noch per Netzwerk. Und interaktiv geht auch nicht unbemerkt.
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.
