presentation

advertisement
Sicherheit oder Praxis?
Michael Willers
http://staff.newtelligence.net/michaelw/
1
In diesem Abschnitt…
•
•
•
•
•
Stand der Dinge
ACL vs. Privileg
Secure Deployment
SQL Server Security
Debuggen mit Visual Studio .NET
2
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
3
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...
4
...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
5
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!
6
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
7
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
8
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, ...
9
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
10
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
11
Security Identifier (SID)
• identifiziert Benutzer oder Gruppe
• eindeutig in Raum und Zeit (vgl. GUID)
• variable Länge
relative Identifier
Aufbau: S-1-5-21-....-....-....-....
Revison
NT-Trustee
maschinenspezifischer
Wert
eindeutig
innerhalb
Maschine
21 für nicht vordefinierte Trustees
12
ACLs und ACEs
Die Access-Control List ist ein Container für Access-Control
Entries (ACEs)
ACL
1
n
ACE
ACCESS_MASK
SID
ACCESS_ALLOWED
ACCESS_DENIED
13
ACL, Attributes, Descriptor
wird zugeordnet
Security Attributes
Ressource
Security Descriptor
Access Control List
17
Prüfen von ACLs
18
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
20
ACLs und Privilegien
21
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...
24
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
25
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...
31
SQL Server – DB per MSI aufsetzen
32
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...
33
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
34
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 
35
Non-Admin Debugging
37
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
38
Danke für Ihre Aufmerksamkeit

http://staff.newtelligence.net/michaelw
40
Herunterladen