Windows-Sicherheit: So viel bringt ein kluges Rechte-Management

Der wirksamste Schutzmechanismus bei einem PC ist es immer noch, den Nutzern des Systems wirklich nur die Rechte zu geben, die sie für ihre Arbeit benötigen. Das zeigt eine aktuelle Analyse der in den letzten Monaten entdeckten Sicherheitslücken, ... mehr... Sicherheit, Sicherheitslücken, schloss, Abus, Kette Bildquelle: John Dierckx / Flickr Sicherheit, Sicherheitslücken, schloss, Abus, Kette Sicherheit, Sicherheitslücken, schloss, Abus, Kette John Dierckx / Flickr

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Das ganze har nur einen Haken,
wenn ein Angreifer sich erhöhte Rechte durch einen Bug verschaffen kann, sind sämtliche Steuerungen über Benutzerkonten und deren Rechten Makulatur.

Wieder einmal eine "Untersuchung" in der das Ergebnis schon vorher feststand.
 
@Kribs: Jupp, da stehen Selbstverständlichkeiten.

Ich frage mich gerade ob der Internet Explorer erhöhte Rechte hat, wenn man ihn aufruft und als Administrator angemeldet ist, eigentlich sollte er ja in der Sandbox laufen und diese Berechtigungen nicht haben... probiere ich auf jeden Fall bei Zeiten mal aus oder kennt jemand die Antwort.
 
@otzepo: Wenn die UAC aktiv ist, startet kein MS-Browser mit Admin-Rechten, weder der IE noch der Edge.
 
@HeadCrash: Danke. Hat mich total verwirrt diese Inkompetenz bei der Studie. Ab heute starte ich den Browser nur noch über "Als Administrator ausführen", damit diese Studie einen Sinn ergibt. :D
 
@HeadCrash: Das stimmt zwar prinzipiell, der uac prompt bzw der security token ist aber kein schutzmechanismus und wird auch von ms selbst nicht als solcher bezeichnet. Oben geht es darum dass der Account mit dem man arbeitet nicht in der Administratorengruppe ist.
 
@Kribs: Jepp, so wie bei jedem System. Und dennoch sind UAC und andere Schutzmechanismen mehr als sinnvoll.
 
@Kribs: Ändert aber nix an den Aussagen im Artikel.
 
@daaaani: Ähm, irgendwie doch.

Ein Nutzer sollte keine Adminrechte haben, damit er keine Programme ausführen kann, die erhöhte Privilegien verlangen, die NTFS-Berechtigungen gültig sind und er sonst nichts installieren kann.

Wenn der Benutzer nun eine Abfrage bekommt und da die Anmeldung vom Administrator eingibt ist dieser Schutz ausgehebelt. Da ist es quasi egal ob ich jetzt Admin bin oder nicht, wenn ich brain.exe ausschalte und die erhöhten Rechte vergebe sind sie vergeben.
Nun ist es, bei eingeschaltetem brain.exe, quasi das Gleiche, wenn ich als Admin angemeldet bin, ich muss nur keine Anmeldedaten eingeben sondern kann, da ich Superuser bin, mit einem Klick auf JA die Rechte vergeben. - Quasi erst mal kein Unterschied ob ich nun Admin bin oder nicht. Der Schutz ist eigentlich nur gegeben, wenn der Nutzer keine Zugangsdaten für ein Administratorkonto kennt oder weiß was er tut.

Und was mich total verwirrt hatte ist der Blödsinn mit dem Browser, (wurde mir in o1 ja auch bestätigt) es ist kackegal ob ich als Admin oder als Nutzer den Browser starte, der Browser hat dadurch noch lange keine erhöhten Rechte. Diese muss sich die Malware durch einen Exploit erschleichen und aus der Sandbox ausbrechen (oder mich darum bitten und ich muss es abnicken) - und auch hier ist wieder relativ egal ob ich jetzt nur Nutzer oder Admin bin.
Die Hauptsache ist zu wissen was man tut und jemand der es nicht weiß sollte keine Adminrechte haben, damit der eben nicht aus Versehen etwas erlaubt was man nicht hätte erlauben dürfen.

Als Fazit zu sagen, man soll nicht als Admin angemeldet sein ist komplett korrekt - die Begründung ist hier aber ziemlich an den Haaren herbei gezogen.

/edit: es klingt so als ob der Autor denken würde man würde alles mit Rechtsklick "Als Administrator ausführen" starten, wenn man als Admin angemeldet ist. Diese Aussage ist ganz klar falsch und zeigt wie viel diese Studie taugt.
 
@otzepo: Und was hat das jetzt mit krips Aussage zu tun?

Und davon ab verringern die im Artikel beschriebenen Maßnahmen durchaus die Anzahl der möglichen Angriffsvektoren. Auch wenn sie keinen 100% Schutz garantieren, durch Bugs oder z.B. dumme User. Aber dieser Anspruch wird im Artikel auch nicht erhoben.

Übrigens sind alle Maßnahmen fürn Arsch wenn ein Alien persönlich vorbei kommt und die Daten klaut!

Worauf wollt ihr hinaus? Die Tür gar nicht erst abschließen, weil es könnte ja einer mit einem Rammbock oder ne Ladung C4 um die Ecke kommen? Weil es ausschließlich diese gibt?
 
@daaaani: Das Fazit von der Studie ist ja korrekt, aber die Aussagen im Artikel stimmen eben nicht. Wenn ich bei der Abfrage, ob ich erhöhte Rechte vergeben möchte immer auf Nein klicke ist es fast so als ob ich als Standardbenutzer angemeldet wär.

Als Admin kommt man wegen der NTFS-Berechtigungen an andere Orte und ist damit stärker gefährdet (z.B. bei Krypto-Trojanern), bei kritischen Bereichen greift aber auch hier wieder die Benutzerkontensteuerung.

Der Artikel klingt so als ob er für Windows XP verfasst wurde. Wie gesagt, das Fazit unterschreibe ich, aber der Weg wie sie zu dieser Erkenntnis erlangt sind ist nicht wissenschaftlich belegbar und deutet auch mangelndes Fachwissen hin.

"Hier, so das Ergebnis der Analyse, wird es zu hundert Prozent verhindert, dass Malware tief in die kritischen Bereiche des Systems vordringen kann, wenn der Browser selbst in einem Nutzerkonto läuft, das nicht genügend Freiraum bietet."

Der Browser wird IMMER in einem Nutzerkonto geöffnet, dass keine erhöhten Rechte hat, wenn man ihn nicht ganz explizit mit erhöhten Privilegien startet.
somit haben wir hier ein Fazit das ich nicht unterschreiben kann:
"Hier, so das Ergebnis der Analyse, wird es zu hundert Prozent verhindert, dass Malware tief in die kritischen Bereiche des Systems vordringen kann, wenn der Browser läuft."
Diese Aussage ist unhaltbar und Kribs' Eröffnungspost ergibt einen Sinn.

Ohne einen Exploit bekommt niemand erhöhte Rechte, wenn der Nutzer es nicht will, egal ob Admin oder Standardbenutzer. Was jetzt aber nicht heißen soll, dass man die Benutzer mit Adminrechten ausstatten soll. Ich für meinen Teil melde mich immer mit lokalen Adminrechten an und vertraue der Benutzerkontensteuerung. Bei GNU/Linux ist mein Benutzerkonto ja auch in der Gruppe der Superuser, bedeutet aber nicht, dass ich irgendwelche Programme als Superuser ausführe, wenn ich es nicht gerade muss.
Ich kann nur Wiederholen, der Artikel bezieht sich allem Anschein nach auf XP oder ein System mit deaktivierter UAC.
 
@otzepo: "Der Browser wird IMMER in einem Nutzerkonto geöffnet, dass keine erhöhten Rechte hat"
Der security token wird von MS selbst nicht als sicherheitsfeature geführt...startest du den browser mit einem Konto mit Mitgliedschaft in der administratorengruppe hast du verloren, der uac prompt ist für genau gar nichts ein schutz
 
@0711: Wenn ich ein Programm starte benutzt Windows doch den "Standard User Access Token" und nicht den "Full Administrator Access Token". Daher erstellt Windows doch bei der Anmeldung extra zwei Tokens. Für das Öffnen von Programmen ist man auch als Admin nur Standardbenutzer.

https://technet.microsoft.com/en-us/library/9e9c14ac-e256-474d-a5b6-ce3d6ce503b9
 
@otzepo: Das ist richtig, der prompt selbst ist aber keine Sicherheitsbarriere um an den "Full Administrator Access token" zu kommen wenn dieser dem angemeldeten Benutzer "gehört", so zumindest MS eigene offizielle Haltung zum UAC Prompt.

https://msdn.microsoft.com/en-us/library/cc751383.aspx
"A weakness that would allow to bypass the "Consent Prompt" is not considered a security vulnerability, since that is not considered a security boundary. "

So werden z.B. bekannte Lücken zur Umgehung des UAC Prompt von Vista - 8.1 schlicht nicht mehr behoben
https://social.technet.microsoft.com/Forums/windows/en-US/52b9c450-72f1-4dbc-b431-ed3127fc225b/uac-bypass?forum=w8itprosecurity
Wobei das natürlich nicht die einzige schwäche des Prompts ist und es gibt gründe warum MS auch seit jeher empfiehlt getrennte KOnten zu nutzen anstatt einen der durch den UAC Prompt/Token "geschützt" ist.

Dabei bitte nicht verwechseln, UAC IST ein Sicherheitsfeature, der Prompt nicht...wobei es meines wissens die Ausnahme gibt, für die Passworteingabe ist es ein als gesicherter Bereich angesehen Funktion um vor Keyloggern schutz zu bieten.

Auch wenn UAC durchaus einige Schädlinge aus dem tritt bringt, gilt das weitgehend nicht für die geschichte mit der ausnutzung von sicherheitslücken.
 
@0711: Dann ist das Eröffnungspost von Kribs ja wieder richtig.
Habe gerade einen alten Artikel auf heise gelesen und einen ziemlich neuen auf enigma0x3 in dem es um die Schwächen der UAC geht. Vista scheint da weniger betroffen zu sein, da MS seltener Benutzereingriffe haben wollte mit Win7 haben die ihr System geschrottet.
Ich sehe es aber ganz klar als Sicherheitslücke, wenn MS nur halbseiden Bypässe unterbindet und das Ausnutzen dieser Lücken sehe ich als klaren Exploit. MS muss sich da mal echt was besseres ausdenken, man merkt immer wieder, dass Windows überhaupt nicht als Mehrbenutzersystem geplant war und die sich da was zurecht gebastelt haben was nicht so läuft wie es zu laufen hat.

Und okay, die Bypässe kann man nur unterbinden, in dem man sich mit einem Standardbenutzerkonto anmeldet.
 
@otzepo: MS gibt klare Ansagen dass der UAC Prompt eben kein Sicherheitsfeature ist und nur getrennte Accounts eine adequate Sicherheitsbarriere zwischen eingeschränkten und "nicht" eingeschränkten Account bieten. Der UAC Prompt hat auch vor allem einen großen Vorteil, er zeigte welche Software richtig reudig programmiert ist.

Nicht MS wollte, die Nutzerschaft wollte die änderung

"dass Windows überhaupt nicht als Mehrbenutzersystem geplant war und die sich da was zurecht gebastelt haben "
NT war und ist schon immer ein Mehrbenutzersystem und macht auch gerade in diesem Zusammenhang so absolut keinen Sinn als Aussage....gerade die Mehrbenutzerfähigkeit liefert den gewünschten Schutz
 
@0711: ich meinte mit dem Spruch die Flickschusterei, NT hat auf DOS aufgesetzt und musste den Missstand auf einer anderen Ebene kompensieren. Microsoft schleppt den Code seitdem mit und hat "verwöhnte" Kunden, die sich über das Legitimieren ärgern. Bei Unix ist es eleganter gelöst und da kommt niemand auf die Idee den gesamten Window Manager mit Rootrechten auszuführen. Dafür muss man eben ständig das Passwort eingeben oder im laufenden Betrieb eine Shell oder ein Programm mit erhöhten Rechten ausstatten, was aber auf den Rest keinen Einfluss hat.
 
@otzepo: nt hat nie auf dos aufgesetzt und da wurde nichts auf einer anderen ebene kompensiert

Auch bei Windows ist das beschriebene "doing" möglich, abermals dank mehrbenutzerfähigkeit.
 
@0711: Du hast Recht. Mein Fehler. Dachte NT 4 hätte erst die Neuerung gehabt - Habe mir eine Geschichtsstunde verordnet.
 
@Kribs: Wenn ein Angreifer über einen Bug es schafft, sich Admin/Root/System/God-Rechte zu verschaffen, dann kann er alles mit dem System machen. Das gilt für jedes System. Das braucht man nicht untersuchen, denn das ist klar.
 
@Kribs: Wenn ein Angreifer mit Adminrechten Zugriff auf dein System hat, hast du so oder so immer verloren.
Ich vermute mal, dass es mehr Bugs gibt um Code auf einem Zielsystem zur Ausführung zu bringen als es Bugs gibt um das Adminkonto zu kapern. Meine Meinung ist, dass die Implikation sich ein Nicht-Admin-Konto zu erstellen und für den Alltag zu verwenden, ein sehr guter Tipp ist.
 
@Kribs: Oben wird gezeigt dass die Mitgliedschaft in der Administratorengruppe der Fehler ist, der UAC prompt ist kein Security Feature oder gar das "entfernen" von administrativen Rechten von einem Account! Ist man kein Mitglied der Administratorengruppe geht klappt das eben nicht so mit dem ausnutzen
 
@0711: Ich antworte dir Stellvertretend für alle.
Sobald jemand Zugriff auf den Computer hat, gibt es mehrere Wege seine Rechte mit Bordmitteln zu erhöhen, sprich das System ist innerhalb kurzer Zeit offen der Angreifer mit Administratorenrechte ausgestattet.

Ich will keine Anleitung liefern deshalb verkürzt:
cmd/Gruppenmitgliedschaft/Administrator freischalten
oder Manipulation der Registry:
... Microsoft\Windows\CurrentVersion\Policies
oder per Batch-Dateien, etc..
Dazu gib es noch diverse Möglichkeiten über externe Speicher.

Unterm Strich, sobald jemand Zugriff auf den Rechner hat ist dieser nicht mehr geschützt, dabei ist es egal wie eingeschränkt dieser zugriff ist!
 
@Kribs: Ein eingschränkter Nutzer kommt nicht an die Registry, der kann auch nicht über die cmd die Gruppenmitgliedschaft ändern. Auch nicht per Batch Datei oder externen Speicher.

Wenn du als eingeschränkter Nutzer mehr Rechte willst, musst du das Admin-Kennwort kennen. Mit Bordmitteln ist nicht. Vorausgesetzt natürlich es ist auch ein Admin-Kennwort vergeben. Da muss man schon Lücken ausnutzen.
 
@Kribs: Alles was du nennst ist mit einem eingeschränkten Benutzerkonto erst mal nicht erreichbar.

Aber es geht ja gerade darum dass ein Angreifer eben schon gar nicht in den Genuss jedweden Zugriffs kommt, welcher zwar generell eine Gefahr darstellt (auch für das System) aber eine Rechteerweiterung ist nur durch weitere Sicherheitslücken möglich und da gibt es derzeit nicht wirklich viel was offen/bekannt ist.

Wenn du eine pivilege escalation lücke kennst, nur raus damit und nicht schüchtern sein ;)
 
@0711: Die simpelste Methode ist:
Windows Startbildschirm/Erleichterte Bedienung/
*Eingeben*
net user "Konto" "Paswort" /add
*Neue Zeile*
*Eingeben*
net localgroup Administratoren "Konto" /add
*Neustart und mit neuen Admin-Konto und Passwort einloggen.

Zu den andern halte ich mich bedeckt!
 
@Kribs: Was kein weg für eine malware ist da diese aus dem userkontext auf diesen Bereich nicht kommt und du hast bei dieser "simplen" Methode einen entscheidenden punkt vergessen...erst mal muss man die erleichterte Bedienung (als systembestandteil) durch die cmd ersetzen.

Schon das ist alles andere als trivial für eine schadsoftware, erst mal werden systemdateien im normalen betrieb gesondert geschützt (auch vor dem "admin"), für das austauschen bedient man sich also üblicherweise des abgesicherten Modus (oder aus einem anderen os heraus ala Linux/winpe o.ä.) um diesen schutz zu umgehen.
das zweite ist natürlich, ein normaler user kann diesen schritt nicht durchführen...

Schwach was du da lieferst und macht wirklich nicht neugierig was für streng geheime dinge du noch "bedeckt" hälst, eher was zum schmunzeln.

Schlussendlich bleibts wie zuvor, du kannst nichts aufgezeigt was aus dem userkontext heraus möglich ist (wie eben zuvor auch)
 
@0711: Minus

Das Szenario war, wie ein Angreifer sich erhöhte Rechte einräummen kann, somit die Benutzersteuerung kompromittiert, nichts anderes habe ich geschrieben.
Das Szenario geht wie der Artikel von einen Physischen Zugriff auf den Rechner aus, keinen Onlinezugriff.

Das du das von mir vertretenen Szenario, nachträglich durch ein anderes ersetzt, ist ein ganz mieser Stil!
 
@Kribs: In dem Artikel wird ein zugriff von "außen" bzw Anfälligkeit durch Sicherheitslücken konstruiert...mitnichten ein (schutz vor) physischer zugriff. Es gibt in dieser branche durchaus einen unterschied zwischen Access und physical Access. Warum sollte ich bei einem physischen Zugriff überhaupt irgendwas am "Zielsystem" tun? Ich bau die platte aus und hab alles...sofern dagegen keine Maßnahmen ergriffen wurden, wenn dies das Szenario wäre.

Von einem Rechtemanagement und/oder Softwareschutzmechanismen physikalischen Schutz einzufordern ist absurd und ist weder im Artikel noch im Paper das Szenario gewesen.

Das Szenario ist sehr klar, es geht um das ausnutzen von Sicherheitslücken in der Software...die konntest du nicht aufzeigen, viel mehr konstruierst du dir die Problematik rund um den physischen Schutz.

Edit3
Ich habe z.B. auch explizit nach privilege escalation lücken gefragt...geliefert hast du die Manipulation des Systems über ein drittsystem und versuchst dann auch noch das große Geheimnis zu machen. Das ist mehr als lächerlich und keinesfalls ein von mir "geändertes" szenario
 
Dies sollen ja die 6% sein. in wie fern dieser Wert stimmig ist, steht auf einem anderen Blatt.
 
Warum wird dann bei der Ersteinrichtung nicht gleich der Standardbenutzer als eingeschränkter Nutzer angelegt und zusätzlich eben ein Adminkonto mit entsprechendem Passwort, dass sich vom Standardnutzerpasswort unterscheiden muss ?
Die UAC sollte dann standardmässig so eingestellt sein, dass sie auch das Passwort abfragt (egal mit welchem Konto man nun unterwegs ist)
 
@chrislog: Tja warum...der UAC prompt ist z.B. in der höchsten Stufe (Vista Standard) am effektivsten, alles hat geheult über Bevormundung usw usf

Was glaubst du würde passieren wenn MS den weg mit 2 account gegangen wäre? Viele die über UAC geschumpfen haben hätten eh gleich mit dem Adminaccount gearbeitet und so hat man eben einen Mittelweg gesucht, erst mit der Variante unter Vista, dann entschärft unter Windows 7. So hat man vermutlich auch die größte Reichweite mit der Maßnahme aber bei weitem nicht die höchste Effektivität.

In seinen Empfehlungen hat MS seit jeher stehen man solle 2 getrennte Accounts nutzen.
Kommentar abgeben Netiquette beachten!
Einloggen

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles