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