(E)SAE DEEP DIVE SERIE TEIL 5 – Reduce high privileged service accounts - TEAL Technology Consulting GmbH
2619
post-template-default,single,single-post,postid-2619,single-format-standard,bridge-core-2.4.8,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-23.3,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,wpb-js-composer js-comp-ver-6.4.1,vc_responsive

(E)SAE DEEP DIVE SERIE TEIL 5 – Reduce high privileged service accounts

Dass Programm-Code Sicherheitslücken enthält und diese von Angreifern ausgenutzt werden, ist mittlerweile zum Alltag in der IT-Welt geworden. Neben dem regelmäßigen Installieren von Patches für das Beseitigen dieser Sicherheitslücken ist eine weitere wichtige Maßnahme, die Auswirkungen eines Angriffs soweit wie möglich zu reduzieren. Im fünften Teil unserer (E)SAE Deep Dive Serie geht es um die Reduzierung von hochprivilegierten Konten für Windows Services.

Ein Angreifer, dem es gelingt, einen Service zu übernehmen, erhält dadurch in den meisten Fällen weitreichende Berechtigungen. Service-Konten sind häufig auf den Systemen, auf denen der Service installiert ist, lokale Administratoren,  besitzen Sysadmin-Berechtigungen auf Datenbanken der Applikation und damit vollen Zugriff auf alle Daten der Applikation. Eine seit vielen Jahren übliche Best Practice ist daher das Least Privilege-Prinzip. Dieses besagt, dass ein Benutzer eines IT-Systems oder eine Applikation nur die für seine Aufgabe absolut notwendigen Berechtigungen besitzt.

In der Praxis ist das häufig jedoch nicht so einfach umzusetzen, weil Software-Hersteller sich leider allzu häufig nicht die Mühe machen, diese minimal notwendigen Berechtigungen zu dokumentieren. Microsoft ging dabei leider nicht mit gutem Beispiel voran. Als Windows NT 3.1 im Jahr 1993 veröffentlicht wurde, liefen alle Services unter LocalSystem mit unbegrenzten lokalen Berechtigungen. Erst mit Windows XP/Windows Server 2003 führte Microsoft die Konten LocalService und NetworkService ein und wandte das Least Privilege-Prinzip auf die vorinstallierten Services an. Das führte dazu, dass auch Dritthersteller erst langsam die Berechtigungen ihrer Services reduzierten und dies bei weitem noch nicht flächendeckend praktiziert wird. So geben viele Hersteller noch immer häufig lokale Administrationsberechtigungen als Anforderung vor, ohne dass diese hohen Berechtigungen tatsächlich notwendig sind. Im schlimmsten Fall empfiehlt die Hersteller-Dokumentation die Installation von Services als Domänen-Administrator, was niemals der Fall sein darf. Domänen-Administratorenkonten werden ausschließlich für die Administration von Domain Controllern verwendet. Punkt!

Administrative Abhängigkeiten

Warum ist die Reduzierung der Berechtigungen so wichtig? Zum Verständnis ist es dabei hilfreich, kurz das Konzept von Sicherheitsabhängigkeiten zu erklären. Eine Sicherheitsabhängigkeit liegt vor, wenn die Sicherheit eines Computersystems von der Sicherheit eines anderen abhängt. In einer Active Directory-Domäne hängt die Sicherheit aller Domänen-Mitglieder von der aller Domain Controller ab, weil über die Vertrauensstellung eines Domänen-Mitglieds zur Domäne in der Standardkonfiguration ein Domänen-Administrator lokale Administrationsberechtigungen auf jedem Domänen-Mitglied hat oder sich entsprechende Rechte verschaffen kann, z.B. über Gruppenrichtlinien. Diese Sicherheitsabhängigkeit ist nicht vermeidbar und akzeptabel. Die Implikation hieraus ist, dass Domain Controller besonders sicher betrieben werden müssen.

Wir hatten im letzten Artikel unserer E(SAE)-Blogserie schon verschiedene Angriffsszenarien beschrieben. Ein weiteres Angriffsszenario ergibt sich in diesem Kontext durch die Art, wie Credentials eines Service-Kontos auf dem System gespeichert werden. Windows startet einen Service mit dem in der Service-Konfiguration hinterlegten Service-Konto. Dabei überprüft Windows das Kennwort des Kontos mit der Funktion LsaLogonUser und gibt im Erfolgsfall ein Access Token zurück. Dazu muss das Kennwort des Service-Kontos jedoch lokal gespeichert sein. Windows legt dieses in der Registry unter HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets ab, auch als LSA Secrets bekannt. Die LSA Secrets sind mit dem System Key verschlüsselt, der beim Start von Windows dazu verwendet wird, die LSA Secrets zu entschlüsseln und in den Hauptspeicher zu laden. Hier findet ihr ein PowerShell-Skript, um die LSA Secrets zu dekodieren. Das Tool Mimikatz ist dazu auch in der Lage. Mit lokalen Administratorenberechtigungen ist es also problemlos möglich, die Credentials eines Service-Kontos auszulesen und falls diese noch hohe Privilegien auf anderen Systemen besitzt, wie das bei einem Domänen-Administrator der Fall ist, bietet das weitreichende Möglichkeiten, weitere Systeme zu kompromittieren.

Da in diesem Beispiel das Kennwort eines Domänen-Administrators von einem Member-Server ausgelesen werden kann, hängt die Sicherheit aller Domain Controller von der Sicherheit dieses einen Servers ab. In diesem Fall handelt es sich in aller Regel um eine nicht akzeptable Sicherheitsabhängigkeit. Denn ein sensitives System darf niemals von der Sicherheit eines weniger sensitiven Systems abhängen. Domain Controller beherbergen alle Benutzerkonten und deren Anmeldeinformationen einer Domäne und dürften in fast jedem Fall sensitiver als ein Member-Server sein, selbst wenn auf diesem auch äußerst sensitive Daten gespeichert sind.

Diese Abhängigkeiten sind natürlich nicht nur auf Domain Controller beschränkt. Ebenso inakzeptabel ist es, dass ein Service-Konto eines Webservers lokale Administratorenrechte auf dem Backend-Datenbankserver besitzt. Die Liste von Beispielen lässt sich beliebig lang fortsetzen. Um die Berechtigungen auf ein Minimum zu reduzieren, müssen wir zunächst verstehen, was Berechtigungen genau sind und wie man herausfinden kann, welche Berechtigungen genau benötigt werden. Das zeigen wir euch in den nächsten Abschnitten.

Service-Konten und Berechtigungen

Eine Applikation im Windows-Umfeld ist üblicherweise als Service installiert, der ähnlich wie ein Daemon in UNIX im Hintergrund ausgeführt wird. Windows Services können unter verschiedenen Konten ausgeführt werden:

Berechtigungen
Privilegien und Benutzerrechte, sowie Berechtigungen auf Objekte zusammen. Objekte, die Zugriffsberechtigungen über Access Control Lists unterstützen, sind unter anderem das NTFS-Dateisystem, die Registry, Services und Active Directory. Applikationen wie Microsoft SQL Server haben zudem ihr eigenes Berechtigungsmodell.

Der Unterschied zwischen Privilegien und Benutzerrechten ist, dass ein Benutzerrecht wie z.B. Allow log on locally (SeInteractiveLogonRight) nur während der Anmeldung überprüft wird, Privilegien werden hingegen auch nach erfolgter Anmeldung bei Ausführung bestimmter Aktionen überprüft, wie z.B. wenn der Benutzer die Uhrzeit ändert, ob er das Privileg Change the system time (SeSystemtimePrivilege) besitzt. Die Tabelle in User Rights Assignment listet Privilegien und Benutzerrechte auf.

Es gibt jedoch einige sogenannte Super-Privilegien, die so mächtig sind, dass ein Konto, das eines dieser Privilegien besitzt, volle Kontrolle über das System besitzt:

  • Debug programs
  • Take ownership
  • Restore files and directories
  • Load and unload device drivers
  • Create a token object
  • Act as part of operating system

Erfordert ein Service-Konto eines dieser Privilegien, sollte dies beim Hersteller der Software hinterfragt werden.

Vordefinierte Konten
Services können eines der folgenden vordefinierten Konten verwenden. Microsoft empfiehlt, wenn möglich, eines dieser Konten zu verwenden:

  • LocalSystem: Das Access Token enthält die Security Identifier (SIDs) von BUILTIN\Administrators und besitzt damit unlimitierte Rechte auf dem lokalen System. Verwendet beim Zugriff auf Netzwerk-Ressourcen das Computerkonto des lokalen Systems. (Das Computerkonto verwendet den Namen des Systems mit einem $-Zeichen als Suffix.)
  • LocalService: Dieses Konto hat die Berechtigungen von BUILTIN\Users und einige zusätzliche Privilegien. Greift auf Netzwerk-Ressourcen als Anonymous Logon
  • NetworkService: Besitzt lokal dieselben Berechtigungen wie LocalService und greift wie LocalSystem auf Netzwerk-Ressourcen mit dem Computerkonto des lokalen Systems zu.

Der Nachteil der vordefinierten Konten ist jedoch, dass diese von vielen Windows Services verwendet werden und damit eine detaillierte Protokollierung nur noch eingeschränkt möglich ist. Das ist häufig ein Grund, ein Benutzerkonto im Active Directory als Service-Konto zu verwenden.

Lokale Benutzerkonten
Benutzerkonten in der lokalen SAM können auch als Service-Konto verwendet werden. In der Praxis sollten jedoch lokale Benutzerkonten in aller Regel vermieden werden. Eine Ausnahme können Systeme im Kiosk-Modus, die nicht Mitglied einer Domäne sind, darstellen.

Active Directory Benutzerkonten
Ein Active Directory Benutzerkonto als Service-Konto kann zentral verwaltet werden und dem Konto können auf den betreffenden Systemen, auf denen der Service installiert ist, die minimal notwendigen Berechtigungen zugewiesen werden.

Feststellen der minimal notwendigen Berechtigungen

Doch was macht man, wenn die Berechtigungen des Service-Kontos seitens des Herstellers nicht dokumentiert sind? Zunächst sollte man auf den Hersteller zugehen und um die technischen Informationen bitten. Bleibt das ergebnislos, sollte man noch nicht die Flinte ins Korn werfen. Möglicherweise führt eine Eskalation ggf. auch mit anderen Kunden z.B. über eine Anwendergruppe zu einem Ergebnis. Falls das nicht der Fall ist oder es um eigengeschriebene Software geht, bleibt die Möglichkeit, auf technischem Weg herauszufinden, welche Berechtigungen das Service-Konto benötigt.

Die beiden verbreitetsten Möglichkeiten sind Windows Auditing und das Tool Procmon als Teil der Sysinternals Suite. Das Windows Auditing erfordert keine Zusatzsoftware und kann sowohl Windows OS als auch Active Directory überwachen. Procmon bietet für Windows OS noch weitere und flexiblere Möglichkeiten.

Windows Auditing
Es gibt zunächst das Windows Auditing, mit dem man den Zugriff auf Ressourcen wie Dateien überwachen kann. Auditing ist Bestandteil von Windows und erfordert keine Zusatzsoftware. In der Audit Policy muss zunächst die Kategorie Audit object access aktiviert werden. Dabei ist es ausreichend, nur fehgeschlagene Zugriffe zu protokollieren.

Mit dem Aktivieren des Object Access werden eine ganze Reihe von Einzelkategorien, wie z.B. File System und Registry aktiviert, wie in der Ausgabe von audipol.exe zu sehen ist.

Damit werden jedoch nicht automatisch fehlgeschlagene Zugriffe auf alle Dateien protokolliert. Dazu muss für die entsprechenden Verzeichnisse und Dateien eine System Access Control List (SACL) definiert werden.

Damit wird der fehlgeschlagene Zugriff im Security Event Log mit der Event ID 4656 vermerkt:

Auditing in der Domäne
Auditing funktioniert auch für Active Directory. Dazu muss in der Default Domain Controllers Policy die Kategorie Audit directory services access aktiviert werden.

Auch hier werden wieder einige Einzelkategorien in der Audit Policy aktiviert.

Auch für die zu überwachenden Active Directory-Objekte müssen wieder SACLs definiert werden.

Damit wird der fehlgeschlagene Zugriff im Security Event Log mit der Event ID 4662 vermerkt:

In der Dokumentation zum Active Directory Auditing findet sich eine Liste der Auditing Event IDs.

Sysinternals Procmon
Das Tool Procmon ist Teil der Sysinternals Suite und ist in der Lage, Aktivitäten im Dateisystem, in der Registry, von Prozessen und Threads, sowie übertragende Netzwerkpakete zu überwachen. Damit lassen sich alle fehlgeschlagenen Zugriffe eines Prozesses protokollieren.

Die Überwachung von Procmon ist sofort nach dem Programmstart aktiv und erzeugt hunderte von Einträgen. Daher ist es sinnvoll, für dieses Szenario eine Filterregel zu erstellen, die nur fehlgeschlagene Einträge überwacht.

Ein fehlgeschlagener Zugriff wird dann beim Auftreten angezeigt. Nachfolgend ein Beispiel für einen fehlgeschlagenen Schreibversuch auf eine Datei:

Die überwachten Einträge lassen sich dann auch abspeichern und bei Bedarf nach XML oder CSV exportieren.

Umsetzung

Wenn man mit den vorhergehend beschriebenen Methoden die minimal notwendigen Berechtigungen ermittelt hat und es sich um kommerzielle Software handelt, ist es dennoch ratsam, die Auswirkungen bezüglich Support mit dem Hersteller abzuklären bevor man die Berechtigungen des Service-Kontos verändert.

Insgesamt wird ein größeres Unternehmen auf tausende installierte Services auf Windows-Systemen kommen. Daher ist zunächst einmal eine Priorisierung notwendig. Bei Services, die Bestandteil von Windows sind, wird die Berechtigung ohnehin nicht verändert. Es werden je nach Einsatzszenario nicht benötigte Services deaktiviert. Dies geschieht normalerweise über die Implementierung von Security Baselines, die Microsoft oder andere Organisationen wie das Center for Internet Security (CIS) oder das US-Verteidigungsministerium (Dod für Department of Defense) für verschiedene Windows-Versionen zur Verfügung stellt.

Für die Inventarisierung der Services sind Client Management Suiten wie Microsoft Endpoint Manager hilfreich. Wenn ein derartiges Tool nicht vorhanden ist, kann auch über Werkzeuge wie PowerShell eine Inventarisierung mit Scripts durchgeführt werden. So können die Services nach Hersteller klassifiziert werden.

Eine Priorisierung sollte zunächst auf Services liegen, die über das Netzwerk erreichbar sind und über hohe Privilegien verfügen. Ob ein Service auf Netzwerk-Ports hört, kann lokal über Tools wie netstat oder Get-NetTCPConnection festgestellt werden. Für einen Remote-Scan kann z.B. nmap verwendet werden.

Die Umsetzung der Berechtigungen hängen dann von den konkreten Anforderungen der Applikation ab. In aller Regel sind dort ACLs auf Dateisystem oder Registry involviert oder die Konfiguration von bestimmten Rechten über lokale Security Policies. Vor allem, wenn Service-Konten auf mehreren Systemen zu berechtigen sind, ist eine Automatisierung mit PowerShell zu empfehlen. Hier können Tools wie icacls und Set-Acl verwendet werden. Einige Applikationen wie Microsoft SQL Server bieten dazu auch eigene Werkzeuge wie den SQL Server Configuration Manager an, der alle notwendigen Berechtigungen für das Service-Konto konfiguriert.

Bei der Vergabe von Berechtigungen innerhalb des Active Directory sollten Gruppen (nach dem IGDLA-Prinzip) verwendet werden und die Berechtigungen über den Delegation Wizard konfiguriert werden.

Ausblick

Dieser Artikel gab einen Überblick über die Risiken, die mit hochpriviligierten Service-Konten verbunden sind und hat einige Wege aufgezeigt, wie diese hohen Berechtigungen reduziert werden können. Im nächsten Artikel werden wir das Thema lokale Administratorkennwörter und wie man mit der Local Administrator Password Solution (LAPS) auf jedem System individuelle Administratorkennwörter vergibt und diese regelmäßig ändert, behandeln.

AUS UNSEREN SOCIAL MEDIA KANÄLEN

 

Sieh dir diesen Beitrag auf Instagram an

 

Ein Beitrag geteilt von TEAL Technology Consulting (@tealconsulting) am

 

Sieh dir diesen Beitrag auf Instagram an

 

Ein Beitrag geteilt von TEAL Technology Consulting (@tealconsulting) am

LATEST POSTS