1 sicherheit oder praxis? michael willers
TRANSCRIPT
1
Sicherheit oder Praxis?
Michael Willershttp://staff.newtelligence.net/michaelw/
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
– 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-1-5-21-....-....-....-....
Revison
NT-Trustee
maschinen-spezifischer Wert
eindeutig innerhalb Maschine
relative Identifier
21 für nicht vordefinierte Trustees
13
ACLs und ACEsDie Access-Control List ist ein Container für Access-Control Entries (ACEs)
ACL ACEACCESS_MASKSID
1 n
ACCESS_ALLOWED ACCESS_DENIED
17
ACL, Attributes, Descriptor
Security Attributes
Security Descriptor
Access Control List
Ressourcewird zugeordnet
18
Prüfen von ACLs
20
Kein „Happy Coding“• Ohne .NET entweder mit C++
– 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
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 – AuthenticationLogin Request
Integrated Security: SSPIansonsten : Lookup in master.sysxlogin
Kontextwechsel zur Datenbank
Zugriffe auf Datenbankobjekte(Tabellen, Stored Procedures,..)
Authorization innerhalb der Datenbank
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 dasOS-Privileg SeDebugPrivilege besitzt!
• Ausnahme: Admin-Account• Ein generelles CLR-Problem, das so nicht umgangen
werden kann
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
40
http://staff.newtelligence.net/michaelw
Danke für Ihre Aufmerksamkeit