Windows 7 Benutzerkontensteuerung in Standardeinstellung wirkungslos

Wednesday, February 04, 2009 10:31:21 AM (W. Europe Standard Time, UTC+01:00)

Die Benutzerkontensteuerung in Windows 7 und Windows Vista soll eigentlich verhindern, das Anwendungen ohne Genehmigung durch den Benutzer administrative Änderungen am System vornehmen können. Das hat in Vista zu sehr viel Kritik geführt, da Microsoft bei Vista etwas über das Ziel hinaus geschossen ist und Vista zu oft um Erlaubnis gefragt hat.

In Windows 7 gibt es deshalb nun verschiedene Einstellungen für die Benutzerkontensteuerung. In der neuen Standardeinstellung fragt Windows nur noch nach, wenn Programme Änderungen am System vornehmen wollen, nicht mehr bei Aktionen, die vom Benutzer ausgelöst wurden. Prinzipiell ist das keine schlechte Idee, leider wurde sie aber sehr schlecht umgesetzt – die Änderung der Benutzerkontensteuerungseinstellungen (was für ein Wort…) durch den Benutzer löst auch keine Nachfrage mehr aus, und Anwendungen können durch simulierte Benutzereingaben so nun die Benutzerkontensteuerung vollständig abschalten.

Statt das Problem zu beheben, behauptet Microsoft nun aber das Problem sei by Design und man werde es nicht ändern.

Inzwischen haben Long Zheng und Rafael Rivera jedoch eine weitere, schlimmere Lücke in der Benutzerkontensteuerung entdeckt: Von Microsoft signierte Anwendungen können priviligierte Aktionen ausführen, ohne eine Abfrage durch die Benutzerkontensteuerung auszulösen. Nun gibt es aber auch Microsoft Anwendungen, die ihrerseits wiederrum dazu verwendet werden können, andere Anwendungen zu starten, z.B. rundll32.exe. Somit können nun Malware-Anwendungen die Microsoft Anwendungen nutzen, um Code ohne Nachfrage mit Administratorrechten zu starten. Die neue Standardeinstellung der Benutzerkontensteuerung ist somit vollkommen nutzlos, wenn man diese Einstellung nutzt kann man die Benutzerkontensteuerung auch gleich komplett abschalten. Einen Demo-Exploit gibt es bei Rafael.

Bis Microsoft das Problem behebt – falls sie es überhaupt beheben – sollte man die Benutzerkontensteuerung deshalb unbedingt wieder auf die höchste Sicherheitsstufe einstellen. Ich hatte unter Vista keine Probleme mit dieser Einstelllung, man gewöhnt sich schnell daran und wenn ein System erst fertig eingerichtet ist, führt man sowieso kaum noch Aktionen durch, die eine Nachfrage erfordern.

Technorati Tags: ,,
Kick it on dotnet-kicks.de

SQL Injection – wenn man mal wieder sein Kennwort vergessen hat…

Saturday, July 05, 2008 5:02:24 PM (W. Europe Daylight Time, UTC+02:00)

Gerade wollte ich mich zu einem meiner Produkte auf der Support-Webseite einloggen. Dummerweise ist mir mal wieder mein Kennwort für diese Seite nicht eingefallen (keine Ahnung, ob ich überhaupt schon eins habe). Ohne wirklich mit einem Ergebnis zu rechnen habe ich einfach mal folgendes eingegeben:

Benutzer: %

Passwort: ' OR 1=1 --

Ergebnis: “Welcome to the […] Web Site of the Technical Support”.

Wie lange wird es wohl noch dauern, bis das Thema SQL Injection endlich bei jedem Entwickler angekommen ist? Oder Sicherheit ganz allgemein?

Naja, wenigstens muss ich mir für diese Seite kein Kennwort mehr merken.

Nachtrag:

Gerade habe ich mir mal aktuelle Folien zu einer Datenbankvorlesung bei uns in Paderborn angesehen. Ist leider tatsächlich noch so wie vor Jahren als ich die Vorlesung selbst gehört habe – kein Wort von SQL Injection. Dafür folgendes:

image

Solange selbst an der Uni das Thema “Security” in der Softwareentwicklung überhaupt keine Rolle spielt, darf man sich nicht wundern dass solche grundlegenden Sicherheitslücken immer wieder in Web Seiten auftauchen.

Technorati Tags: ,
Kick it on dotnet-kicks.de

„Month of the browser bug“ und IE7

Tuesday, August 01, 2006 12:57:24 PM (W. Europe Daylight Time, UTC+02:00)

Auf der Seite http://browserfun.blogspot.com/ wurden einen Monat lang jeden Tag Bugs in Browsern vorgestellt, die den Browser entweder zum Absturz bringen sollten oder die sogar zum Einschleusen von Code nutzbar sein sollten. Die meisten davon waren Bugs im IE6.

Ich habe alle IE6 Bugs im Internet Explorer 7+ unter Vista 5472 getestet. Keiner davon hat bei mir funktioniert, d.h. mein Browser ist kein einziges Mal abgestürzt und es wurde auch kein fremder Code eingeschleust. Bei Exploits/Bugs bei denen man eine ActiveX Installation bestätigen musste habe ich diese nicht bestätigt (wenn jemand freiwillig fremden Code installiert ist das schließlich kein Bug, sonst wäre sogar die Möglichkeit Programme mit einem Browser herunterladen zu können genauso ein Bug).

Angenommen einer der Bugs hätte funktioniert, hätte der eingeschleuste Code auch dank UAC keine Administratorrechte bekommen. Er hätte nicht mal mit meinen normalen Benutzerrechten arbeiten können, denn der IE7+ läuft auf Vista im "Protected Mode".

Da keiner der Bugs aus dem "Month of the browser bug"-Test im IE7 funktioniert hat, habe ich als nächstes die Bugs im Heise Browsercheck getestet. Auch von diesen Sicherheitslücken hat keine im IE7 "funktioniert".

Sicher wird es auch für den IE7+ (wie für jede Software) früher oder später Sicherheitslücken geben. Das lässt sich einfach in der Softwareentwicklung nicht vermeiden. Sicher ist aber auch, dass der IE7 bisher deutlich sicherer ist als alle Internet Explorer Versionen davor. Außerdem werden die Möglichkeiten die ein Angreifer hat, wenn er denn eine Sicherheitslücke findet, durch "Protected Mode" und UAC deutlich reduziert. Es mag einige Gründe geben, andere Browser zu verwenden, Sicherheit gehört beim neuen Internet Explorer aber bisher nicht dazu.

Kick it on dotnet-kicks.de
Page 1 of 1 in the Security category