Tags: Sicherheit, Malware, Rechteverwaltung
Das Blockieren von unautorisierten Programmen zählt zu den effektivsten Maßnahmen zur Abwehr von Malware. Windows enthält dafür mittlerweile drei Mechanismen, jeder mit seinen eigenen Stärken und Schwächen. Die größte Hürde für ihren Einsatz ist das Pflegen von Regeln, wobei hier freie Tools helfen.
Die Ausbreitung von Schadprogrammen setzt fast immer voraus, dass sie Code lokal speichern und dann im Kontext des angemeldeten Users ausführen können. Das gilt für Infektionen über Mail-Anhänge und für bösartige Office-Makros genauso wie für Drive-by-Angriffe beim Besuchen von infizierten Websites. Es liegt auf der Hand, dass ein konsequentes Whitelisting zulässiger Anwendungen hier einen Riegel vorschiebt.
Aufwändige Pflege von Regeln
Obwohl mit den Software Restriction Policies (SRP oder auch SAFER) seit XP ein entsprechender Mechanismus zu den Bordmitteln von Windows gehört, ist das App Whitelisting nicht übermäßig weit verbreitet.
Der wichtigste Grund dafür dürfte sein, dass viele Unternehmen den Aufwand scheuen, der für das Erstellen und Pflegen des benötigten Regelwerks notwendig ist. Lässt man hier nicht die erforderliche Sorgfalt walten, dann muss man entweder mit Lücken für Schadcode oder mit dem Blockieren legitimer Anwendungen und Anrufen beim Helpdesk rechnen.
Programmstart aus User-Profil verhindern
Häufig herrscht auch die Vorstellung vor, dass man alle zulässigen Applikationen explizit erfassen und freigeben muss. Für einen soliden Grundschutz reicht es aber schon aus, Anwendungen aus dem Programm- und Windows-Verzeichnis zuzulassen und die Ausführung von Code dort zu verhindern, wo der Benutzer Schreibrechte hat.
Damit blockiert man alle Programme, die der User (unwissentlich) aus dem Internet herunterlädt oder von einem USB-Stick starten möchte. Dagegen läuft alles, was der Administrator installiert hat oder über ein Tool zur Software-Verteilung auf den Rechner gelangt ist. So stellt man sicher, dass der unbedachte Klick auf einen Mail-Anhang nicht gleich böse Folgen hat.
Standardbenutzer als Zielgruppe
Weitergehende Erwartungen können die Funktionen für das Whitelisting teilweise gar nicht erfüllen. So ist es fast unmöglich, lokale Administratoren an der Ausführung von nicht autorisierter Software zu hindern, weil sie die Sperre durch Anhalten von Diensten, das Ändern der Registry oder sonstige Umgehungsstrategien durchbrechen können.
Daher setzt ein wirksames Whitelisting voraus, dass Unternehmen dem Prinzip des Least Privilege folgen und normalen Benutzern keine administrativen Rechte einräumen. Umgekehrt reicht diese Maßnahme alleine als Schutz gegen Malware nicht aus, weil diese auch im Kontext eines Standardbenutzers beträchtlichen Schaden anrichten kann, beispielsweise durch Verschlüsselung seiner Daten.
Windows-Verzeichnis mit Schlupflöchern
Aber auch ein grundlegender Schutz lässt sich nicht ganz einfach erreichen. So greift das Freischalten von C:\windows und aller seiner Unterverzeichnisse zu kurz, weil sich darunter auch solche befinden, in denen Standardbenutzer Schreibrechte besitzen. Außerdem gibt es dort Programme, die normale User nicht brauchen, aber für Angriffe missbraucht werden können, wie etwa cipher.exe.
Andererseits kann es sein, dass legitime Anwendungen aus dem Profil der Benutzer starten müssen, in der Regel eine Folge schlechter Programmierung. Ein Beispiel dafür liefert Microsoft selbst mit Windows Defender Antimalware.
Regeltypen auf Basis verschiedener Kriterien
Wie diese Beispiele zeigen, bedarf es schon einiger Regeln, um Programm- und Systemverzeichnisse für das Ausführen von Code zuzulassen und gleichzeitig die Benutzerprofile dafür zu sperren. Die Mechanismen für das Whitelisting stellen dafür verschiedene Regeltypen zur Verfügung.
So erlauben sie das Starten von Anwendungen abhängig vom Hersteller, dem Pfad der Programmdatei oder vom Hashcode für die ausführbare Datei. In einer idealen Welt würde man einfach nur signierte Applikationen ausgewählter Lieferanten zulassen. Da aber auf absehbare Zeit längst nicht alle Anwendungen signiert sein werden, muss man auch zu anderen Mitteln greifen.
So kann man eine vertrauenswürdige, nicht signierte Anwendung in einem Benutzerverzeichnis freischalten, indem man davon einen Hashcode erzeugt. Sobald sich aber die Datei etwa durch ein Update auch nur geringfügig ändert, dann muss man die dazugehörige Regel ebenfalls aktualisieren.
Testen von Regeln im Audit-Modus
Aufgrund möglicher Komplikationen durch versehentlich blockierte Software bieten die meisten Tools für das App Whitelisting einen Audit-Modus an. Er protokolliert alle Ereignisse, bei denen Anwendungen von Regeln betroffen sind.
Auf diese Weise erhält der Administrator einen Überblick darüber, welche Programme ausgeführt werden und welche das Whitelisting dann im Erzwingungsmodus blockieren würde.
Richtlinien für Software-Einschränkung
Bei den Software Restriction Policies (SRP bzw. SAFER) handelt es sich um den ältesten der in Windows enthaltenen Mechanismen für das Whitelisting von Anwendungen. Es ist der einzige, der in allen Versionen und Editionen des Betriebssystems (inklusive Server) enthalten ist. Seit Windows 7 sehen die SRP nur mehr 2 Sicherheitsstufen vor, nämlich Nicht erlaubt und Nicht eingeschränkt (das Ausführen als Standardbenutzer entfällt seitdem).
Neben Regeln basierend auf Zertifikaten, Hashes und Pfaden unterstützt SAFER auch solche auf Basis von Internet-Zonen. Das Feature umfasst kein Set an Basisregeln, die bereits einen Grundschutz bieten würden. Vielmehr obliegt es dem Admin, das gesamte Regelwerk zu entwickeln. Dabei fehlt aber ein Auditmodus, mit dem man die Wirkung von Richtlinien erst beobachten könnte.
Zu den weiteren Einschränkungen der SRP gehört, dass es die (vergleichsweise sicheren) Store Apps (.appx) nicht blockieren kann. Außerdem lassen sich keine Regeln getrennt nach Dateitypen wie EXE, Batchdateien oder Scripts definieren, sondern sie gelten immer für alle Arten von Code.
Schließlich lassen sich Regeln für SAFER nicht exportieren oder importieren. Vielmehr werden sie standardmäßig im GPO-Editor erstellt und in einer .pol-Datei gespeichert, von wo sie in die Registry gelangen.
Viele der genannten Nachteile der SRP beseitigt Stefan Kanthak mit seinem Regelwerk, das als .inf-Datei für die verschiedenen Versionen von Windows vorliegt. Die ausführlich kommentierten Einträge lassen sich bei Bedarf anpassen, sie schreiben bei Installation die vorgesehenen Werte direkt in die Registrierdatenbank. Insgesamt stellen sie sicher, dass Standardbenutzer nur Programme von dort ausführen können, wo sie diese nicht selbst speichern dürfen.
Als ergänzende Lektüre empfiehlt sich dieses ausführliche Whitepaper der NSA.
AppLocker
Der mit Windows 7 und Server 2008 eingeführte AppLocker ist eine Weiterentwicklung der Richtlinien für Software-Einschränkung. Das Feature ist der Enterprise Edition vorbehalten und somit gerade in kleineren Firmen nicht verfügbar, wenn diese mit der Pro Edition arbeiten.
Wie die SRP wird AppLocker über Gruppenrichtlinien verwaltet. Als Verbesserung gegenüber der älteren Technik bringt es ein Set an Standardregeln mit, die %PROGRAMFILES%\* und alle Verzeichnisse unter %SYSTEMROOT% für nicht-administrative Benutzer zur Ausführung von Programmen freischalten (was angesichts der weiter oben beschriebenen Problematik aber nicht reicht).
Im Unterschied zu den SRP lassen sich jeweils separate Regeln für unterschiedliche Arten von ausführbaren Dateien definieren, und zwar für Scripts, Programmdateien, Appx und Installer. AppLocker kennt mit Ausnahme von Internet-Zonen die gleichen Regeltypen wie SAFER.
Ein weiterer Vorteil von AppLocker gegenüber den SRP ist die Möglichkeit, eine Regel bestimmten Benutzern und Gruppen zuzuordnen. Darüber hinaus bietet das Feature einen Audit Mode, in dem man alle Regeln testen kann, bevor man sie produktiv schaltet.
Schließlich kann man Regeln im XML-Format importieren und exportieren. Das macht sich AaronLocker zunutze, das für AppLocker eine ähnliche Aufgabe erfüllt wie Stefan Kanthaks .inf-Dateien für SRP.
Das Tool verfolgt jedoch mit einer Kombination aus PowerShell-Scripts und XML-Dateien einen anderen Ansatz. Dabei erstellt der Admin einen Regelsatz im XML-Format und importiert diesen in den GPO-Editor. Auch AaronLocker bringt zahlreiche Richtlinien mit, die Lücken der Standardregeln schließen und Umgehungen verhindern.
Windows Defender Application Control
Dabei handelt es sich um den neuesten Mechanismus für das Whitelisting von Anwendungen. Bis Windows 10 1709 und Server 2016 firmierte es zusammen mit der Komponente für Virtualization Based Security (VBS) unter der Bezeichnung Device Guard.
Der VBS-Teil heißt seitdem Exploit Guard, das Whitelisting hört auf Windows Defender Application Control (WDAC). Letzteres lässt es sich aber unabhängig von der VBS nutzen, allerdings um den Preis geringerer Sicherheit. WDAC kann Code nicht nur im User Mode, sondern auch auf Kernel-Ebene (z.B. Treiber) blockieren.
Im Unterschied zu den beiden älteren Technologien orientiert sich Application Control stärker an Microsofts Konzept des Modern Desktop. Die mittels PowerShell generierten Policies lassen sich über Mobile Device Management anwenden, etwa über den Cloud-Service Intune (wobei allerdings eine Verteilung über GPOs ebenso möglich ist). Damit ist es auch unabhängig von den AD Domain Services.
Für das Erstellen von Regeln benötigt man laut Systemanforderungen Windows 10 Pro oder Enterprise bzw. Server ab der Version 2016, anwenden lassen sie sich demnach auf alle Editionen. In der Praxis kann man auf der Pro Edition aber weder Regeln erstellen noch anwenden.
Für die Definition von eigenen Regeln gibt es kein grafisches Werkzeug, sondern nur PowerShell-Cmdlets. Sie erlauben nur ein Whitelisting in engeren Sinn, bei der Anwendungen explizit zugelassen werden. Pfadregeln wie in den beiden anderen Features gibt es beispielsweise nicht.
Limitiert ist auch das Targeting der Regeln, die sich nur auf Computer und nicht auf Benutzer anwenden lassen. Benötigt man User-spezifische Einschränkungen, dann empfiehlt Microsoft eine parallele Nutzung von AppLocker.
Wie AppLocker unterstützt WDAC einen Audit-Modus, der standardmäßig beim Erzeugen einer neuen Richtlinie aktiv ist. Sie wird in einer XML-Datei gespeichert, welche erst in ein binäres Format konvertiert werden muss, bevor sie auf die Zielrechner ausgebracht werden kann.
Einen Einstieg in die Konfiguration und auch einen ersten Eindruck von der Komplexität dieser Aufgabe erhält man durch das Script CIDeployment.ps1 von Matthew Graeber.
Gerade kleinere Unternehmen, die diesen Aufwand nicht leisten können, bietet Microsoft mit der Integration des Intelligent Security Graph eine alternative Option. Damit führt WDAC nur Anwendungen aus, die in dieser Cloud-gestützten Datenbank als vertrauenswürdig aufgeführt sind.
Täglich Know-how für IT-Pros mit unserem Newsletter
Ähnliche Beiträge
- Übersicht: Die wichtigsten Features von Windows Defender
- Überwachter Ordnerzugriff: Ransomware-Schutz mit Gruppenrichtlinien und PowerShell konfigurieren
- Reduktion der Angriffsfläche in Microsoft Defender mit Gruppenrichtlinien oder PowerShell aktivieren
- Schädliche Apps und unsichere Treiber mit Microsofts WDAC-Regeln blockieren
- KrbRelayUp: Domänen-Controller gegen Angriffe auf Resource-based constrained Delegation absichern
Weitere Links