Sicherheit oder Praxis?

Präsentation zum Thema: "Sicherheit oder Praxis?"—  Präsentation transkript:

1 Sicherheit oder Praxis?
Michael Willers

2 In diesem Abschnitt… Stand der Dinge ACL vs. Privileg
Secure Deployment SQL Server Security Debuggen mit Visual Studio .NET

3 Stand der Dinge Die meisten Anwendungen laufen mit Administratorrechten Eine offene Einladung für Angreifer Nur: Anwender haben keine Wahl  Installation setzt meistens Administatorrechte voraus Anwendungen laufen nicht ohne Administratorrechte Oder schlimmer: Wichtige Funktionen gehen nicht OS bietet keine Hilfestellung Beispielsweise per Wizard

4 Ohne Admin geht‘s auch... Erstellen Sie einen eigenen Account, der lediglich der Gruppe Users angehört Legen Sie Verknüpfungen für administrative Tasks auf dem Desktop an runas.exe Rechtsklick auf die Anwendung fragt automatisch Für das Development mit Visual Studio. NET brauchen Sie zusätzliche Einstellungen Dazu später mehr Ein Wizard wäre schön...

5 ...aber eben nicht immer ;-)
Möglicherweise schreibt die Anwendung in die Registry HKEY_LOCAL_MACHINE anstelle von HKEY_CURRENT_USER Möglicherweise schreibt die Anwendung „wild“ ins Dateisystem Windows- oder Systemverzeichnis (System32) Programmverzeichnis Oder der GAU: Ins Root Interop-Szenarien mit COM-Komponenten Zugriff auf HKEY_CLASSES_ROOT notwendig

6 Wo gehört was in die Registry?
In .NET eigentlich nichts mehr ;-) Bei vorhandenen Anwendungen Code so ändern das er grundsätzlich nur auf HKEY_CURRENT_USER schreibt!

7 Wo gehört was ins Dateisystem?
.config Dateien sind Anwendungsbezogen und by Design Read-Only Werden vom Hersteller mitgeliefert Benutzerbezogene Daten zur Anwendung (Fenstereinstellungen, Fonts, etc) Environment.SpecialFolders.ApplicationData Allgemeine benutzerbezogene Daten gehören in My Documents Environment.SpecialFolders.Personal Weitere Hinweise in der MSDN Dokumentation Environment.SpecialFolders

8 Und was nun? Rausfinden was da los ist Eigener Code Fremde Anwendungen
Wer schreibt wann mit welchen Rechten wohin? Regmon, Filemon, Process Explorer und Konsorten Eigener Code Fix this! Fremde Anwendungen ggf. Installer bauen, der Rechte gezielt freischaltet Testen und dann per Group Policy verteilen Natürlich das alte Problem: Sicherheit ist unbequem Wenn die Rechte da sind aber trotzdem nix geht fehlt vielleicht ein Privileg

9 ACL vs. Privileg Eine Access Control List (ACL) erlaubt oder verbietet den Zugriff auf eine Ressource Datei, Registy, ... Ein Privileg erlaubt oder verweigert die Durchführung einer Aufgabe Backup, Debugging, ...

10 Wie finde ich gute ACLs? Wie sieht der Use Case aus? Ein Beispiel:
Alle User müssen Daten lesen können Interactive Users = Read Administratoren müssen in der Lage sein sämtliche Aktionen auf den Daten ausführen zu können Administrators = Full Control Die Marketing-Abteilung darf keinen Zugriff auf die Daten haben ggf. Benutzergruppe Marketing anlegen Marketing = Deny All Access

11 Wie finde ich gute ACLs? Achtung: Manchmal sind Privilegien die bessere Lösung Beispiel: Ein einzelner User muss immer Zugriff auf sämtliche Dateien haben SeBackupPrivilege Lesezugriff auf sämtliche Dateien SeRestorePrivilege Schreibzugriff auf sämtliche Dateien

12 Security Identifier (SID)
identifiziert Benutzer oder Gruppe eindeutig in Raum und Zeit (vgl. GUID) variable Länge Aufbau: S relative Identifier maschinen-spezifischer Wert eindeutig innerhalb Maschine Revison NT-Trustee 21 für nicht vordefinierte Trustees

13 ACLs und ACEs Die Access-Control List ist ein Container für Access-Control Entries (ACEs) 1 n ACL ACE ACCESS_MASK SID ACCESS_ALLOWED ACCESS_DENIED

14 OS-Systemressourcen Permanent Temporär Dateien, Verzeichnisse
Registry Keys Netzwerkfreigaben, Drucker Active Directory Objekte Temporär Prozesse und Threads Events, Mutexe, Semaphore Pipes, File Mappings

15 Security Descriptor Speichert Informationen für den Zugriff auf OS-Systemressourcen Owner (SID) Primary Group (SID) Discretionary Access-Control List (DACL) System Access-Control-List (SACL, für Auditing) Flags

16 Security Attributes Wird direkt auf eine OS-Ressource angewendet
Hat neben dem Descriptor noch ein Flag ob dieser explizit gesetzt oder vom dazugehörigen Prozess übernommen werden soll Später mehr dazu

17 ACL, Attributes, Descriptor
Ressource wird zugeordnet Security Attributes Security Descriptor Access Control List

18 Prüfen von ACLs

19 Was ist eine NULL-DACL? NULL DACL == Keinerlei Sicherheit
Eine solche DACL erlaubt jedem Benutzer vollen Zugriff auf eine Ressource Niemals den Parameter NULL für eine DACL verwenden! Win32-API-Funktionen SetSecurityDescriptorDacl und Konsorten

20 Kein „Happy Coding“ Ohne .NET entweder mit C++ Oder per WMI Mit .NET
Win32-API ab VC 7.1 einfacher über ATL-Klassen Oder per WMI Allerdings kein Hinzufügen von Privilegen, die ein Benutzer nicht hat Mit .NET Version 1.1 keine Unterstützung Version 2.0 hat eingebaute Unterstützung, zumindest für ACLs Nur: Viele Klassen, viele Methoden aber kein lösungsgetriebener Ansatz

21 ACLs und Privilegien

22 Service Accounts Local System ist Default-Account
Mögliches Risiko wegen vieler OS-Privilegen Sollte nur vergeben werden, wenn der Service das OS-Privileg SeTcbPrivilege zwingend braucht Win32-API-Funktionen wie LogonUser und Konsorten Unter Windows Server 2003 nicht mehr zwingend notwendig

23 Service Accounts Windows XP ohne SP2
Eigenen Account mit möglichst wenig Rechten und Privilegien anlegen Windows Server 2003, Windows XP SP2 Nach Möglichkeit Local Service oder Network Service als Account benutzen

24 SQL Server – Standardsetup
Standardmäßig läuft der SQL Server mit dem lokalen Systemaccount Eigenen Account anlegen Gastaccount ist oft ausreichend Standardmäßig sind alle lokalen Administratoren in der Serverrolle sysadmin eingetragen Lokale Benutzerguppe anlegen und hinzufügen Lokale Administratoren entfernen Ein Wizard wäre schön...

25 SQL Server – Authentication
Login Request Integrated Security: SSPI ansonsten : Lookup in master.sysxlogin Kontextwechsel zur Datenbank Zugriffe auf Datenbankobjekte (Tabellen, Stored Procedures,..) Authorization innerhalb der Datenbank

26 SQL Server – Login Loginrechte für den Server explizit per eingebauter Stored Procedure vergeben exec sp_grantlogin ['mydomain\myuser'] exec sp_denylogin ['mydomain\myuser'] exec sp_revokelogin ['mydomain\myuser'] Auch global für Windows-Benutzergruppen Bei Problemen in Tabelle sysxlogins nachsehen sp_helplogins ['username']

27 SQL Server – Datenbanklogin
Loginrechte für die Datenbank explizit per eingebauter Stored Procedure vergeben exec sp_grantdbaccess ['mydomain\myusergroup'] exec sp_denydbaccess ['mydomain\myusergroup'] exec sp_revokedbaccess ['mydomain\myusergroup'] Auch global für Windows-Benutzergruppen

28 SQL Server – DBUser dbo Guest
Ist der Datenbankowner und exisitiert grundsätzlich in jeder Datenbank Kann auch nicht entfernt werden Guest Dieser User wird nicht gebraucht In eigenen Datenbanken löschen!

29 SQL Server – Zugriffsrechte
Rechte für Datenbankobjekte sollten explizit vergeben werden, insbesonde Tabellen und Stored Procedures GRANT, DENY,REVOKE Automatisierbar per Script

30 SQL Server – Die Rolle „public“
Vergleichbar mit der Benutzergruppe Everyone unter Windows Ihr gehören automatisch alle Benutzer einer Datenbank an Vermeiden Sie das Vergeben von Rechten für diese Gruppe Insbesondere Deny ist keine gute Idee ;-)

31 SQL Server – Hinweise SQL-Server sollte grundsätzlich nur mit „Integrated Security“ arbeiten sa nur als Notanker mit „strong password“ Beim Erstellen einer Datenbank sollten grundsätzlich Berechtigungen eingerichtet werden Serverseitiges Installationsprogramm wäre schön...

32 SQL Server – DB per MSI aufsetzen

33 VS.NET ohne Adminrechte
Setup legt eigene Gruppen an Debugger Users Nur Mitglieder dieser Gruppe können mit Visual Studio .NET debuggen KEINE Zuordnung von OS-Privilegien! Hängt mit dem Machine Debug Manager zusammen VS Developers User haben Lese- und Schreibzugriff im Root des lokalen IIS-Webserver und können dort WebAnwendungen anlegen Ein Wizard wäre schön...

34 Non-Admin Debugging Benutzer können Prozesse, die Ihnen gehören ohne Einschränkung entwanzen Um fremde Prozesse zu debuggen, wird das OS-Privileg SeDebugPrivilege benötigt

35 Non-Admin Debugging Problem: Unter .NET kann ein Benutzer nur die Prozesse debuggen, die Ihm gehören. ASP.NET Windows Services Enterprise Services Gilt selbst dann, wenn der Benutzer das OS-Privileg SeDebugPrivilege besitzt! Ausnahme: Admin-Account Ein generelles CLR-Problem, das so nicht umgangen werden kann 

36 Security Attributes “[…]Passing NULL as SECURITY_ATTRIBUTES indicates that the OS should select default security setting for the object. The default security settings are set in the process/thread token. If the default settings in the token is not modified by explicit calls to security API functions, only the Administrators group and the user account under which the application is running, have full access to any new kernel object.[…]” Auszug aus der aktuellen MSDN-Dokumentation

37 Non-Admin Debugging

38 Zusammenfassung Standardmäßig keine Administratorrechte für Anwendungen LUA – Limited User Account Least privileged user access Annahme „full trust“ vermeiden wo immer es geht Sorgen Sie für „saubere“ Installer Install, Uninstall, Commit und Rollback implementieren

39 Fragen!? Uff...

40 Danke für Ihre Aufmerksamkeit


41 Über den Referenten Michael Willers ist Senior Architect bei der newtelligence AG. Er berät Projektverantwortliche, Software-Architekten und Entwickler beim Design und der Implementierung von Lösungen für die Microsoft .NET Plattform. Er war zuvor mehrere Jahre technischer Berater bei Microsoft und ist Initiator und Gründer des msdn TechTalk Sie erreichen Ihn per Weblog unter oder über seine Website