​

Letzte Woche ging's um Blacklists, auch bekannt als Anti-Virus. Heute möchte ich mich aber mit Whitelists befassen, genauer gesagt mit Application Whitelisting (AWL).

AWL verhindert, dass nicht autorisierte Software, Scripts, DLLs und Installer ausgeführt werden. Damit reduzierst du deine Angriffsfläche um 90 % und schützt dich vor Ransomware, Malware und anderen Kinkerlitzchen. Stell dir vor, ein User klickt auf eine Vertrag.pdf.exe und nichts passiert. 😎

Leider hat AWL den schlechten Ruf, unglaublich kompliziert zu sein, sodass man es in größeren Umgebungen gar nicht einsetzen kann und deswegen niemand nutzt.

Ist es wirklich so schwierig, wie "niemand" sagt?

TL;DR: NEIN, ist es nicht! Nicht mal wenn du einen Software-Sauhaufen hast.

Vielleicht kennst du die Begriffe Software Restriction Policies (SRP), AppLocker oder Windows Defender Application Control (WDAC) schon. Sie sind fester Bestandteil von Windows seit XP bzw. Server 2003. Ja, das ist schon fast ein Vierteljahrhundert her. 🤯

Was haben die Leute dann all die Jahre falsch gemacht?

• Kein Commitment vom Business: AWL wurde oft als "technisches IT-Ding das Probleme macht" abgestempelt. Wenn du die klaren Vorteile und den positiven Impact kommunizierst, bekommst du auch die Unterstützung, die du brauchst.
• Fehlende Prozesse: Genauso wie du beim Anti-Virus false-positives hast, wirst du sie beim Application Whitelisting ebenfalls bekommen. Du solltest einen Prozess einrichten, um schnell mit diesen Ausnahmen umgehen zu können, und dabei die IT und den Service Desk mit einbinden.
• Keine kontinuierliche Verbesserung: Klingt komisch, ist aber so! Du kannst nicht erwarten, dass du neue Anwendungen veröffentlichen und aktualisieren kannst, ohne deine AWL-Richtlinien anzupassen.
• User haben Admin-Rechte: AWL funktioniert zwar auch mit Admin-Rechten, aber es kann sehr einfach ausgehebelt werden. Schlimmer ist aber der Software-Wildwuchs, der dann auf den Clients herrscht, wenn jeder alles installieren kann.

Problem erkannt, aber können wir das schaffen?

Yo, wir schaffen das!

Schritt 1: Projekt aufsetzen

Ohne die Unterstützung aller Entscheidungsträger wirst du dieses Projekt nicht stemmen können.

Du kannst dich an meiner Anleitung hier orientieren. Hol einfach alle an einen Tisch, erkläre die Vorteile von Application Whitelisting und wie du das Projekt erfolgreich umsetzen wirst. Wenn du in der Windows-Welt lebst und keine externe Lösung einkaufst, dann hast du hier auch keine zusätzlichen Kosten für Lizenzen.

Fang bei den Basics an und arbeite dich langsam vorwärts. Ich orientiere mich bei dieser Anleitung an AppLocker. Andere Lösungen haben ähnliche Funktionen, aber die Methodik ist immer dieselbe.

Wenn wir mal die fancy AI-Sachen weglassen, hast du im Grunde drei Möglichkeiten deine Software freizugeben:

• Datei-Pfad: Das ist der Speicherort, wo deine Software liegt. Gib aber nur Pfade frei, auf denen die User keine Schreibrechte haben.
• Datei-Hash: Hier wird eine Prüfsumme der Datei berechnet. Ändert sich nur ein Bit, ändert sich auch der Hash. Das ist sehr praktisch bei statischer Software, die auch in Ordnern liegen kann, wo die User Schreibrechte haben. Das Problem bei dieser Art von Regeln ist aber, dass sie sehr wartungsintensiv sind. Du musst bei jedem Software-Update den Hash neu berechnen und die Policy updaten.
• Datei-Signatur: Die meisten renommierten Softwarehersteller signieren ihre Software bereits seit vielen Jahren mit Zertifikaten. Du könntest dann zum Beispiel die Software von Adobe, Google und Microsoft generell freigeben. Wenn ein Angreifer die Software verändert, wäre die Signatur ungültig und würde geblockt werden.

Schritt 2: Daten sammeln

Die meisten nehmen sich zu wenig Zeit bei der Analyse der IST-Situation und scheitern dann innerhalb weniger Stunden beim Go-Live.

AppLocker und WDAC haben einen Audit-Modus. Du erstellst deine Whitelist-Policies und kannst sie im Audit-Modus ganz gefahrenlos und ohne Auswirkungen testen. Alle Blocks und Allows werden in den Event-Logs von Windows gesammelt, wo du sie an dein zentrales Monitoring weiterleiten kannst.

Der kleinste gemeinsame Nenner sind in den meisten Fällen die Clients. Die werden oft über Golden-Images installiert und die Anwendungen über die Software-Verteilung ausgerollt. Je ähnlicher die Systeme sind, umso einfacher ist es.

Du möchtest nur die Software erlauben, die ausschließlich von Admins installiert wurden. Normalerweise sind das die "Programme" Ordner und das "Windows" Verzeichnis. Gib aber keine Pfade frei, auf denen User Schreibrechte haben, also zum Beispiel "C:\ProgramData", "C:quot;, oder das Benutzer-Verzeichnis.

Viele Anwendungen, unter anderem auch Anti-Virus-Lösungen, schreiben ihre Daten in das "C:\ProgramData" Verzeichnis, in dem die User zum Teil auch Schreibrechte haben. Um es nicht zu verkomplizieren, füg auch gleich die Zertifikate der Hersteller deiner Standard-Software hinzu.

Teste deine Policy auf einem voll ausgebauten Standard-Client, auf dem du alle Anwendungen einmal startest. Wenn du im Audit-Modus bleibst, siehst du alle blockierten Anwendungen im Eventlog.

Wenn du eine gute Basis hast, kannst du die Richtlinien per GPO oder MDM ausrollen und für 30 Tage alle Meldungen sammeln.

Schritt 3: Policies verbessern

Nun kannst du die Regeln anhand deiner realen Umgebung prüfen und deine Schlüsse daraus ziehen.

Je nachdem, wie viele Hosts es sind, können die Daten ziemlich umfangreich sein. Tools wie AaronLocker helfen dir bei der Auswertung und beim Aufbau der Regeln. Damit findest du Gemeinsamkeiten, nicht freigegebene Software und vielleicht sogar schon die erste Malware.

https://github.com/microsoft/AaronLocker

Du willst nicht als Blockwart auftreten, sondern lieber mit den Leuten und Teams reden, wofür sie die nicht erlaubten Anwendungen brauchen. Oft sind die Gründe dafür sehr simpel und nachvollziehbar. Wenn du weißt, warum sie die Standard-Software nicht benutzen, kannst du sie in den Software-Katalog mit aufnehmen oder ihnen sichere Alternativen anbieten.

Wenn du deine Runden gedreht hast, kannst du die Regeln anpassen und die nächsten 30 Tage weiter Daten sammeln.

Schritt 4: Go-Live

Sobald du deine false-positives auf ein Minimum reduziert hast, kannst du das AWL scharfschalten.

Sprich vorher aber noch mit dem Service Desk und zeig ihnen, wie sie im Worst Case Anwendungen schnell freischalten können. Das sollte im Notfall immer möglich sein. Bei AppLocker kannst du das über lokale Richtlinien machen, da diese mit den Richtlinien, die über GPO kommen, kumuliert werden.

Schritt 5: Continuous Improvement

Du hast eigentlich schon 80 % der Arbeit, mit 20 % des Aufwands erledigt. Hoch lebe Vilfredo Pareto!

Nochmal kurz zur Erinnerung, Application Whitelisting ist keine kugelsichere Lösung. Angreifer können AWL umgehen! Du erhöhst aber deren Aufwand massiv und zugleich auch die Wahrscheinlichkeit, dass sie entdeckt werden.

Oddvar Moe hat übrigens eine Liste mit Methoden erstellt, mit denen Angreifer AppLocker umgehen können. Und weil er ein echt feiner Kerl ist, hat er auch gleich die passenden AppLocker-Regeln dazu gepackt.

​https://github.com/api0cradle/UltimateAppLockerByPassList​

Leider sind Kommandozeilen wie cmd, PowerShell und VBScript ein sehr großes Einfallstor. Wenn du sie für User blockierst, wird die IT dir aber nicht dankbar sein. 😢 Damit blockierst du nämlich alle Startup-Scripts und viele Automatisierungen, die im Namen des Users ausgeführt werden.

Wenn du das aber trotzdem machen möchtest, kann ich dir ans Herz legen, alle Scripts, die von der IT ausgeführt werden, zu signieren. Wenn du das mit einer Source Control Umgebung wie GitHub umsetzt, umso besser. Pass nur auf, dass du dort keine Credentials hinterlegt hast, aber das solltest du sowieso niemals. 😉

Hier noch ein kleines Script, mit dem du deine PowerShell Scripts signieren lassen kannst:

$MyCertPFX = 'F:\Certs\nullzwo_code-signing.pfx'
$MyCertPW = Read-Host "Certificate Password" -AsSecureString
$MyCert = Get-PfxCertificate -FilePath $MyCertPFX -Password $MyCertPW
$MyScripts = 'F:\Scripts#x27;
Get-ChildItem -Path $MyScripts -File -Recurse | Set-AuthenticodeSignature -Certificate $MyCert

Viele Angreifer nutzen Windows-Boardmittel, um AWL zu umgehen oder sich im Netzwerk fortzubewegen, erweiterte Berechtigungen zu erhalten oder Infos abzufangen. Whoami, klist und msbuild sind da die Klassiker. Auch die Microsoft Sysinternals Suite hat viele hilfreiche Tools für Admins. Leider werden die aber auch gern von Angreifern verwendet, wie zum Beispiel "psexec". Das sind Tools, die von Microsoft signiert sind. Würdest du sie für alle freigeben, wäre das für die Sicherheit nicht unbedingt förderlich.

Du kannst AWL auch auf Servern einsetzen und das rate ich dir auch; besonders bei Servern, die in der DMZ stehen. Bei der Shellshock-Schwachstelle konnten Angreifer einen Webserver kompromittieren und dadurch Befehle an das unterliegende Betriebssystem senden. Sie ist zwar schon 10 Jahre alt, aber Remote-Code-Execution-Schwachstellen gibt es immer wieder. Mit AWL wären diese Art von Angriffen sehr schwierig, wenn du dem Service-Account deines Webservers einfach verbietest, cmd, powershell, whoami und echo auszuführen.

Fazit

Application Whitelisting ist super effektiv, viel besser als sein Ruf, bei Windows seit +20 Jahren dabei und mit relativ wenig Aufwand gut zu implementieren. Es ist effektiver als jeder Anti-Virus und Angreifer müssten schon selbst Hand anlegen, um daran vorbeizukommen. Für mich ist es ein unverzichtbares Werkzeug in meinem Verteidigungs-Arsenal geworden.