Sicherheit oder Praxis? Michael Willers http://staff.newtelligence.net/michaelw/

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

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

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...

...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

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!

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

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

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, ...

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

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

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

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

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

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

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

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

Prüfen von ACLs

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

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

ACLs und Privilegien

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

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

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...

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

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']

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

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!

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

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 ;-)

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...

SQL Server – DB per MSI aufsetzen

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...

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

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 

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

Non-Admin Debugging

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

Fragen!? Uff...

Danke für Ihre Aufmerksamkeit  http://staff.newtelligence.net/michaelw

Ü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 http://staff.newtelligence.net/michaelw/ oder über seine Website www.devcoach.de.