AppLocker – Weniger ist mehr

Auch ohne Administratorberechtigung können Benutzer viele Anwendungen und Tools starten, welche nicht für den regulären Aufgabenbereich benötigt werden. Diese können aber nicht nur vom Benutzer, sondern auch von einer eingefangenen Schadsoftware verwendet werden. Die Anwendungen und Tools laufen zwar „NUR“ mit der Berechtigung des angemeldeten Benutzers.

 

Dennoch kann das ausreichen, um weitere Informationen über das System oder die Infrastruktur zu sammeln, um es für einen weiteren Angriff zu verwenden. Daher ist es sinnvoll, den Benutzer so einzuschränken, dass er nur die Anwendungen ausführen kann, welche er tatsächlich benötigt.

Und hier kommt AppLocker zum Einsatz. AppLocker ist nicht neu. Es wurde bereits für Windows 7 und Windows Server 2008 R2 im Jahr 2009 von Microsoft eingeführt. AppLocker ist eine Software, um die Ausführung von unerwünschten und unbekannten Anwendungen zu unterbinden und wurde als Ersatz für Software Restriction Policy (SRP) entwickelt.

Obwohl es schon so lange auf dem Markt ist, ist es bei vielen KMUs noch wenig bekannt und wird kaum eingesetzt.

Regeln

Regelbedingungen

Um die Ausführung von Anwendungen einzuschränken, werden in AppLocker Regeln definiert. Die drei Hauptregelbedingungen sind Herausgeber, Pfade und Datei-Hash.

  • Herausgeber: Identifiziert eine Anwendung anhand ihrer digitalen Signatur und erweiterte Attribute, falls diese vorhanden sind. Eine digitale Signatur enthält Informationen über das Unternehmen, welche die Anwendung erstellt hat. Einige Dateitypen haben weitere Attribute. Bei EXE-Dateien oder DLLs können diese Attribute beispielsweise den Namen des Produkts oder die Versionsnummer enthalten.
    Microsoft empfiehlt, falls möglich, Herausgeber-Regeln zu verwenden, da diese Updates oder Änderungen am Pfad überleben.
  • Pfad: Identifiziert eine Anwendungen anhand des Dateipfades auf einem Computer oder im Netzwerk.
    Diese sollten mit Vorsicht konfiguriert werden, da sie je nach Pfadbedingung viele Unterordner und Dateien enthalten kann. Enthält eine Pfadbedingung einen Ordner, in dem ein Standard-Benutzer (unprivilegiert) Schreibrechte hat, kann dieser jegliche Dateien an diesem Ort kopieren und ausführen.
  • Datei-Hash: Identifiziert die Datei anhand des berechneten Hashes. Der Vorteil liegt darin, dass der Hash nur für diese Datei gilt. Der Nachteil ist, dass sich der Hash beim aktualisieren der Datei, beispielsweise bei einem Update, ändert. Dadurch müssen nach jedem Update die Datei-Hash-Regeln aktualisiert werden.
    Die Datei-Hash-Variante ist die sicherste, aber auch die aufwendigste. Ändert sich etwas an der Datei, hat die Datei einen neuen Hashwert.

AppLocker Standard Regeln

Microsoft liefert mit AppLocker Standardregeln aus, welche die ordnungsgemässe Funktionsweise von Windows gewährleisten. Diese können als Vorlage oder als Starter-Richtlinie verwendet werden. Diese Regeln gewährleisten aber keine vollständige Sicherheit, da beispielsweise alle Benutzer im Windows-Ordner über eine Pfadbedingung für die Ausführung von exe-Dateien freigeschaltet sind. Und es im Windows-Ordner wiederum Unterordner gibt, welche vom Benutzer beschreibbar sind.

Lab-Umgebung

Die Lab-Umgebung besteht aus einem Windows Server 2019 als Domaincontroller und ein Windows 10 Client als Workstation. Die OU-Struktur der Domäne ist wie folgt aufgebaut:

Default-Regeln

Zuerst erstellen wir auf dem Domaincontroller eine neue Gruppenrichtlinie für AppLocker und verbinden diese mit der OU Workstations. Hier sind alle Clients dieser Domäne hinterlegt.

In der Gruppenrichtlinie öffnen wir den folgenden Pfad und erstellen die Default-Rules in dem wir mit der rechten Maustaste auf „Executable Rules“ klicken und „Create Default Rules“ auswählen. Das gleiche wiederholen wir mit den „Packaged app Rules“.

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Application Control Policies -> AppLocker

Damit diese auch auf den Workstations funktionieren, muss in den Optionen unter AppLocker (rechte Maustaste auf AppLocker) die „Executable rules“ und „Packaged app Rules“ als „konfiguriert“ aktiviert werden. Hier kann ausgewählt werden, ob diese aktiviert sind (Enforce rules) oder ob nur protokolliert werden soll, wenn die Regel greift. (Audit only). Mit diesen Einstellungen ist bei Windows 10 gewährleistet, dass die Standardanwendungen, wie beispielsweise das Startmenü oder Edge, funktionieren. Es lässt jedoch, wie wir später sehen können, einige Lücken offen.

Und zum Schluss muss noch der Dienst „Application Identity“ unter folgendem Pfad aktiviert werden.

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> System Services

Beim nächsten Start der Workstation sind für alle User-Accounts, ausser Administratoren, nur noch Anwendungen aus den Verzeichnissen %PROGRAMFILES%\* (C:\Program Files\*) und %WINDIR%\* (C:\Windows\*) aufrufbar.

Wird jetzt eine EXE-Datei, wie beispielsweise putty.exe, heruntergeladen und im Download-Ordner ausgeführt, wird diese Anwendung blockiert.

Dadurch haben Sie einen kleinen Grundschutz erreicht und es macht es schwieriger für einen User fremde Software zu starten. Wird die Datei beispielsweise in das Verzeichnis C:\Windows\Tasks kopiert, kann putty.exe wieder ausgeführt werden.

Hier zeigt es sich schnell, dass die Default-Regeln alleine nicht ausreichen. Um bessere Sicherheit zu gewährleisten, müssen zum einen die Regeln besser eingeschränkt werden und zum anderen die Verzeichnisberechtigungen richtig gesetzt sein. Alle Verzeichnisse, welche mit AppLocker freigeschaltet werden, müssen zwingend für den Benutzer schreibgeschützt sein. Sonst hat dieser die Möglichkeit, jede beliebige Anwendung auszuführen.

Default-Regeln erweitern

Bei Windows 10 sollten mindestens die nachfolgenden Verzeichnisse in der Default-Regel „All files located in the Windows folder“ ausgeschlossen werden. Es hängt aber immer noch zusätzlich von der Installation und Konfiguration des Systems ab. Es ist keine vollständige Liste.

%SYSTEM32%\catroot2\*
%SYSTEM32%\com\dmp\*
%SYSTEM32%\FxsTmp\*
%SYSTEM32%\spool\drivers\color\*
%SYSTEM32%\spool\PRINTERS\*
%SYSTEM32%\spool\SERVERS\*
%SYSTEM32%\Tasks\*
%WINDIR%\Debug\*
%WINDIR%\PCHEALTH\ERRORREP\*
%WINDIR%\Registration\*
%WINDIR%\SysWOW64\com\dmp\*
%WINDIR%\SysWOW64\FxsTmp\*
%WINDIR%\SysWOW64\Tasks\*
%WINDIR%\Tasks\*
%WINDIR%\Temp\*
%WINDIR%\tracing\*

Diese können einfach als „Exceptions“ in der Regel hinzugefügt werden.

Sollen Windows PowerShell und die Windows Eingabeaufforderung (cmd.exe) ebenfalls blockiert werden, können diese als eigene Deny-Regeln oder als Ausnahmen in der Default-Regel erfasst werden.

%SYSTEM32%\WindowsPowerShell\*
%SYSTEM32%\cmd.exe

Jetzt funktioniert putty.exe auch nicht mehr aus dem Verzeichnis C:\Windows\Tasks.

Fazit

Mit AppLocker kann mit den Default-Regeln und ein paar Modifikationen relativ einfach eine Grundsicherung hergestellt werden. Um eine hohe Sicherheit zu erreichen, muss jedoch noch tiefer in die Trickkiste gegriffen werden. Pfad-Regeln reichen hier nicht aus. Die Beispiele in der Lab-Umgebung haben gezeigt, dass der Windows AppLocker alleine nicht ausreichend ist. Nur eine Kombination aus durchdachter Workstation-Konfiguration, AppLocker-Konfiguration und die strenge Vergabe der Verzeichnisberechtigungen führen zum Ziel.

Für den Start empfehle ich die Microsoft Dokumentation zu studieren und die Anforderungen in einem Konzept zu definieren. Darunter definieren Sie beispielsweise, was der Anwender alles ausführen darf, was und wie protokolliert werden soll. Eine gute Ergänzung zu den Default-Regeln von Microsoft bietet beispielsweise die NSA mit der AppLocker Guidance. Hier werden schon einzelne Schwächen der Default-Regeln von Microsoft behoben. Weiter finden Sie bei Microsoft eine Liste mit Anwendungen, welche von einem Angreifer möglicherweise verwendet werden können. Diese sollten ebenfalls geblockt werden.

Informationen zum Autor: Marius Hamborgstrøm

Im Jahre 2014 ist es mir gelungen goSecurity von meinem Talent zu überzeugen. Als Experte für Penetration Tests konnte ich schon viele Schwachstellen aufdecken, bevor dies einem Hacker gelungen ist. Zudem bin ich für die Gestaltung und die Durchführung unserer goTraining-Kurse Hack to PROTECT (H2P), Hack to PROTECT [ADVANCED] (H2PA) und Windows Server Hardening (WSH) verantwortlich. Durch meine jahrelange Erfahrung als IT-Leiter einer mittelständischen Bank, kenne ich auch die Seite des Administrators und des IT-Managers in einer Umgebung mit hohen Sicherheitsanforderungen. Aus dieser Erfahrungskiste kann ich die Anforderungen unserer Kunden auch bei Audits und umfassenden Beratungen schnell verstehen und Sie zielgerichtet und praxisnah beraten. Jede Sicherheitslücke bei Ihnen zu finden, bevor dies jemand anderem gelingt, ist leider nicht immer realistisch. Und dennoch ist es mein Antrieb und mein Anspruch.