2
Application Whitelisting - Umgang mit Systemdateien
Es begab sich Ende letzter Woche, dass einem Sicherheitsspezi auffiel, dass eine Windowssystemkomponente (c:\windows\system32\regsvr32.exe) ihm bislang unbekannte Fähigkeiten hat: sie kann Skriptcode ausführen, und das sogar erstaunlich komfortabel. Auf einem System, wo Ausführung von gängigen Skripten (.bat/.ps1/.vbs...) verboten ist, bietet das ein Schlupfloch für Malware. Dieser Umstand führt nun dazu, dass sich technisch mehr oder minder begabte Online-Journalisten einklinken und ganz aufgeregt darüber hermachen und hinausposaunen, Applocker, eine Form des Application Whitelistings, würde hierbei umgangen.
Ich stelle mal dazu fest: dem ist nicht so. Die Fakten werden zwar nicht großartig verdreht, aber der Kontext wird schlicht nicht erkannt und somit wird unnötig dramatisiert. Es werden keine Skripte gestartet, die nicht erlaubt sind, sondern lediglich ausgenutzt, dass ein bislang in seiner Eigenschaft als Skriptingengine unbekanntes Programm evtl. bei vielen Anwendern gewhitelistet ist.
Wer ist von diesem neu entdeckten Umstand betroffen: Nur die, die regsvr32.exe überhaupt nutzen müssen.
Wer nutzt regsvr32 in der Regel: Administratoren oder Systemdienste. Beide Gruppen werden von Applocker eh nicht beschränkt.
Welcher Anwendungsfall würde es denn vorsehen, dass Nichtadmins diese regsvr32.exe überhaupt brauchen? Lohnt kaum beantwortet zu werden, mit Sicherheit ist dies äußerst selten, und im Falle des Falles könnte ein Admin diese Registrierung systemweit vornehmen, dann wäre die Sache gegessen.
Warum würde man dann neuerdings ein Problem haben, wenn man Applocker einsetzt? Man würde nur dann eins haben, wenn man regsvr32 überhaupt für Nichtadmins zulässt. Da man es normalerweise gar nicht als Nutzer gebraucht, ist dies in der Regel komplett Banane. Nehmt es von der Whitelist, lasst es für Admins zu, für "lokaler Dienst", aber nicht für Nichtadmins - fertig.
--
Dies führt nun zum eigentlichen Kern dieses Tipps: wie geht man als Applocker-Admin mit Systemdateien um? Schaut man in die Grundeinstellung, ist erst einmal gar nichts gewhitelistet. Wie kommt nun ein Sicherheitsforscher dazu, zu glauben, das System wäre umgehbar, wenn man selbst die Mittel um es zu umgehen erst einmal freischalten muss?
Er geht davon aus, dass jeder MS-Dos-Manfred es sich einfach macht und erstmal ohne Sinn und Verstand die Defaultregeln aktiviert, die alles unterhalb von c:\windows zulassen.
Klar, Defaultregeln, warum auch nicht, wenn Microsoft die schon anbietet, kann es so schlimm nicht sein, oder? ODER?
Microsoft schreibt im Applocker Design Guide, wie man es machen soll.
Da steht dann ausdrücklich
Und um noch mal ganz klar die Defaultregeln zu dissen: ladet Euch mal AccessChk runter und macht damit auf einer elevated shell mal
bzw. (für englische Systeme)
Das Ergebnis listet beschreibbare Ordner und dürfte einige Unwissende doch sehr erstaunen... man kann als normaler User in diversen Unterverzeichnissen von c:\windows schreiben... kopiert man also eine Executable dorthin, hat man einen weitaus einfacheren "Bypass" als den anfangs Erwähnten gefunden.
--
Was also konfigurieren, wenn man die Defaultregeln nicht (1:1 über-)nehmen sollte?
Die Antwort lautet logischerweise: so wenig wie möglich, so viel wie nötig zulassen. Wer nicht weiß, wozu Nutzer die einzelnen executables gebrauchen könnten, der wird es wohl lernen müssen - oder er lässt es drauf ankommen, blockiert alles und wartet, bis die User jammern. Oder er gibt eben etwas frei, von dem er nicht 100%ig weiß, was es vermag - that's life, ein Restrisiko bleibt immer.
Man kann natürlich pauschal alle von Microsoft signierten Dinge zulassen. Dann erlebt man zwar evtl. Überraschungen wie gerade unserem Sicherheitsspezi widerfahren, aber zumindest hat man keine Probleme mit dem Betriebssystem. Was aber viel wichtiger ist, als diese Entscheidung, ist den Grundsatz zu befolgen
Gib dem Nutzer auf gar keinen Fall das Recht, Dinge von Orten auszuführen, auf die er Schreibrechte hat
Da die Defaultregeln genau dieses aber tun, müssen sie zwangsläufig geändert werden! Wie man das macht, bleibt herauszufinden:
Alles möglich, alles Wege nach Rom. Mehr dazu siehe Guide, So lange man nicht auf die Idee kommt, auch Admins von den Systemkomponenten auszusperren, ist alles prima. Der Design Guide bietet darüber hinaus noch schematische Vorgehensweisen als Hilfe für die Umsetzung an.
Ich stelle mal dazu fest: dem ist nicht so. Die Fakten werden zwar nicht großartig verdreht, aber der Kontext wird schlicht nicht erkannt und somit wird unnötig dramatisiert. Es werden keine Skripte gestartet, die nicht erlaubt sind, sondern lediglich ausgenutzt, dass ein bislang in seiner Eigenschaft als Skriptingengine unbekanntes Programm evtl. bei vielen Anwendern gewhitelistet ist.
Wer ist von diesem neu entdeckten Umstand betroffen: Nur die, die regsvr32.exe überhaupt nutzen müssen.
Wer nutzt regsvr32 in der Regel: Administratoren oder Systemdienste. Beide Gruppen werden von Applocker eh nicht beschränkt.
Welcher Anwendungsfall würde es denn vorsehen, dass Nichtadmins diese regsvr32.exe überhaupt brauchen? Lohnt kaum beantwortet zu werden, mit Sicherheit ist dies äußerst selten, und im Falle des Falles könnte ein Admin diese Registrierung systemweit vornehmen, dann wäre die Sache gegessen.
Warum würde man dann neuerdings ein Problem haben, wenn man Applocker einsetzt? Man würde nur dann eins haben, wenn man regsvr32 überhaupt für Nichtadmins zulässt. Da man es normalerweise gar nicht als Nutzer gebraucht, ist dies in der Regel komplett Banane. Nehmt es von der Whitelist, lasst es für Admins zu, für "lokaler Dienst", aber nicht für Nichtadmins - fertig.
--
Dies führt nun zum eigentlichen Kern dieses Tipps: wie geht man als Applocker-Admin mit Systemdateien um? Schaut man in die Grundeinstellung, ist erst einmal gar nichts gewhitelistet. Wie kommt nun ein Sicherheitsforscher dazu, zu glauben, das System wäre umgehbar, wenn man selbst die Mittel um es zu umgehen erst einmal freischalten muss?
Er geht davon aus, dass jeder MS-Dos-Manfred es sich einfach macht und erstmal ohne Sinn und Verstand die Defaultregeln aktiviert, die alles unterhalb von c:\windows zulassen.
Klar, Defaultregeln, warum auch nicht, wenn Microsoft die schon anbietet, kann es so schlimm nicht sein, oder? ODER?
Microsoft schreibt im Applocker Design Guide, wie man es machen soll.
Da steht dann ausdrücklich
To avoid scenarios [selbst aussperren] like this, AppLocker allows the administrator to create a set of permissive
default rules that will allow the user to interact with the operating system without
restriction.[...]
While allowing an inexperienced administrator to safely interact with AppLocker, it does not
create a secure environment. The guidance provided in this document recommends that the
default rules not be used. By following the process in this document, an administrator can
safely create a highly tailored set of AppLocker policies without the need for the default
rules.
To reiterate, DO NOT ENABLE THE DEFAULT RULES
Aha, diese Regeln dürfen also als ein Selbstschutz verstanden sein, der tunlichst entfernt werden sollte, sobald man das System fertig konfiguriert hat!default rules that will allow the user to interact with the operating system without
restriction.[...]
While allowing an inexperienced administrator to safely interact with AppLocker, it does not
create a secure environment. The guidance provided in this document recommends that the
default rules not be used. By following the process in this document, an administrator can
safely create a highly tailored set of AppLocker policies without the need for the default
rules.
To reiterate, DO NOT ENABLE THE DEFAULT RULES
Und um noch mal ganz klar die Defaultregeln zu dissen: ladet Euch mal AccessChk runter und macht damit auf einer elevated shell mal
accesschk.exe VORDEFINIERT\Benutzer c:\Windows\ -w -saccesschk.exe BUILTIN\Users c:\Windows\ -w -sDas Ergebnis listet beschreibbare Ordner und dürfte einige Unwissende doch sehr erstaunen... man kann als normaler User in diversen Unterverzeichnissen von c:\windows schreiben... kopiert man also eine Executable dorthin, hat man einen weitaus einfacheren "Bypass" als den anfangs Erwähnten gefunden.
--
Was also konfigurieren, wenn man die Defaultregeln nicht (1:1 über-)nehmen sollte?
Die Antwort lautet logischerweise: so wenig wie möglich, so viel wie nötig zulassen. Wer nicht weiß, wozu Nutzer die einzelnen executables gebrauchen könnten, der wird es wohl lernen müssen - oder er lässt es drauf ankommen, blockiert alles und wartet, bis die User jammern. Oder er gibt eben etwas frei, von dem er nicht 100%ig weiß, was es vermag - that's life, ein Restrisiko bleibt immer.
Man kann natürlich pauschal alle von Microsoft signierten Dinge zulassen. Dann erlebt man zwar evtl. Überraschungen wie gerade unserem Sicherheitsspezi widerfahren, aber zumindest hat man keine Probleme mit dem Betriebssystem. Was aber viel wichtiger ist, als diese Entscheidung, ist den Grundsatz zu befolgen
Gib dem Nutzer auf gar keinen Fall das Recht, Dinge von Orten auszuführen, auf die er Schreibrechte hat
Da die Defaultregeln genau dieses aber tun, müssen sie zwangsläufig geändert werden! Wie man das macht, bleibt herauszufinden:
- Entweder, man setzt deny-Regeln auf die zuvor von accesschk gefundenen, beschreibbaren Orte wie c:\windows\temp, oder
- man macht eine Bestandsaufnahme dessen, was gerade auf dem Rechner ist, gibt genau dieses frei ("automatische Regelerstellung" mit Hashing oder Zertifikaten) und pflegt fortan jedes einzelne neue Executable nach, oder
- man nutzt eben doch die Freigabe für von Microsoft Signiertes und setzt deny-Ausnahmen on-demand wie jetzt für regsvr32.exe
Alles möglich, alles Wege nach Rom. Mehr dazu siehe Guide, So lange man nicht auf die Idee kommt, auch Admins von den Systemkomponenten auszusperren, ist alles prima. Der Design Guide bietet darüber hinaus noch schematische Vorgehensweisen als Hilfe für die Umsetzung an.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 302837
Url: https://administrator.de/contentid/302837
Ausgedruckt am: 21.11.2024 um 18:11 Uhr
2 Kommentare
Neuester Kommentar
Hallo DWW,
nicht regsvr32.exe sondern die scrobj.dll interpretiert das Skript. Der Admin kann nie sicher wissen, ob nicht ein anderes Programm, das er für Nutzer zulässt, ebenso benutzt werden kann, um verfügbare Laufzeit-Bibliotheken mit Skript-Code zu füttern, und welche Interaktion das mit dem System zulässt. Näher an der Wurzel wäre daher, in diesem Fall die WSC-Runtime mit DLL-Regeln zu erfassen (die Deaktivierung des Windows-Script-Host greift dafür nicht).
Laufzeit-Bibliotheken für ganze Gruppen zu blockieren, lässt sich offensichtlich auch nicht beliebig weit treiben, etwa wenn Office zusammen mit VBA-abhängigen Drittanbieterlösungen installiert wird. Casey Smith hat einfach eine generelle Limitation von Application-Whitelisting demonstriert, derer sich der Admin ungeachtet vereinzelter Gegenmaßnahmen bewusst sein muss, um bei Softwarelieferanten auf ein entsprechend sichere Konzeption pochen zu können.
Grüße
Richard
nicht regsvr32.exe sondern die scrobj.dll interpretiert das Skript. Der Admin kann nie sicher wissen, ob nicht ein anderes Programm, das er für Nutzer zulässt, ebenso benutzt werden kann, um verfügbare Laufzeit-Bibliotheken mit Skript-Code zu füttern, und welche Interaktion das mit dem System zulässt. Näher an der Wurzel wäre daher, in diesem Fall die WSC-Runtime mit DLL-Regeln zu erfassen (die Deaktivierung des Windows-Script-Host greift dafür nicht).
Laufzeit-Bibliotheken für ganze Gruppen zu blockieren, lässt sich offensichtlich auch nicht beliebig weit treiben, etwa wenn Office zusammen mit VBA-abhängigen Drittanbieterlösungen installiert wird. Casey Smith hat einfach eine generelle Limitation von Application-Whitelisting demonstriert, derer sich der Admin ungeachtet vereinzelter Gegenmaßnahmen bewusst sein muss, um bei Softwarelieferanten auf ein entsprechend sichere Konzeption pochen zu können.
Grüße
Richard
Hi.
Ich halt's da simpler: Man lässt den Code zu, den man braucht und dem man vertraut. Man wird nie eindämmen können, was der macht, wenn man ihn nicht selbst nachvollziehen kann. Somit bleibt immer nur der bewährte Grundsatz, nur zuzulassen, was man wirklich benutzt. Das noch nachzuschärfen mit dll-Regeln kann man in extrem schützenswürdigen Umgebungen sicherlich rechtfertigen. Ich wollte aber eher den Fokus darauf lenken, was die Defaultregeln bedeuten, da eben auch eingebaute Executables Dinge tun können, die wir nicht wollen und das häufig Executables sein werden, die wir nicht einmal aktiv gebrauchen. Casey Smith testet in einer vom Hersteller abgeratenen, ja als unsicher deklarierten Konfiguration, da braucht man sich nicht großartig zu wundern.
Ich halt's da simpler: Man lässt den Code zu, den man braucht und dem man vertraut. Man wird nie eindämmen können, was der macht, wenn man ihn nicht selbst nachvollziehen kann. Somit bleibt immer nur der bewährte Grundsatz, nur zuzulassen, was man wirklich benutzt. Das noch nachzuschärfen mit dll-Regeln kann man in extrem schützenswürdigen Umgebungen sicherlich rechtfertigen. Ich wollte aber eher den Fokus darauf lenken, was die Defaultregeln bedeuten, da eben auch eingebaute Executables Dinge tun können, die wir nicht wollen und das häufig Executables sein werden, die wir nicht einmal aktiv gebrauchen. Casey Smith testet in einer vom Hersteller abgeratenen, ja als unsicher deklarierten Konfiguration, da braucht man sich nicht großartig zu wundern.
