Bypass the Windows AppLocker bouncer with a tweet-size command The Register
Sers,
damit ist AppLocker dann ein deutlich geringerer Schutz vor Malware.
Eine bittere Pille, die den Implementierungsaufwand von AppLocker in kleineren Umgebungen noch stärker in Frage stellt.
Grüße,
Philip
http://www.theregister.co.uk/2016/04/22/applocker_bypass/
damit ist AppLocker dann ein deutlich geringerer Schutz vor Malware.
Eine bittere Pille, die den Implementierungsaufwand von AppLocker in kleineren Umgebungen noch stärker in Frage stellt.
Grüße,
Philip
http://www.theregister.co.uk/2016/04/22/applocker_bypass/
Please also mark the comments that contributed to the solution of the article
Content-ID: 302575
Url: https://administrator.de/contentid/302575
Printed on: October 7, 2024 at 23:10 o'clock
13 Comments
Latest comment
Schon getestet?
Dann sag mir bitte, ob es Dir gelingt, eine Datei außerhalb der erlaubten Orte zu starten. cmd.exe ist eh zugelassen per Defaultregel.
Wenn ich etwas Unerlaubtes damit starten will, gelingt es mir nicht.
Edit: Oder noch einfacher: modifiziere mal die Applocker-Defaultregel, so dass alles unterhalb von c:\windows nur noch für Admins erlaubt ist. Und, geht der "Exploit" noch? Natürlich nicht. Habe ich gerade auch bei theregister so kommentiert.
Dann sag mir bitte, ob es Dir gelingt, eine Datei außerhalb der erlaubten Orte zu starten. cmd.exe ist eh zugelassen per Defaultregel.
Wenn ich etwas Unerlaubtes damit starten will, gelingt es mir nicht.
Edit: Oder noch einfacher: modifiziere mal die Applocker-Defaultregel, so dass alles unterhalb von c:\windows nur noch für Admins erlaubt ist. Und, geht der "Exploit" noch? Natürlich nicht. Habe ich gerade auch bei theregister so kommentiert.
Moin,
@DerWoWusste ich glaube du hast die Idee des Exploits missverstanden. Es ging nicht darum die cmd.exe auszuführen, das war nur ein Beispiel.
Es geht darum, dass ein fetchen der URL automatisch JavaScript ausführt. (Wie eine JavaScript-Anwendung die eval() aufruft nur dass es hier nicht im Webseiten- sondern im Userkontext ausgeführt wird)
Das Problem ist also, dass hierdurch code auf dem System ausgeführt werden kann, den du nicht per AppLocker blocken kannst, da er einfach über eine Datei heruntergeladen wird und innerhalb des Speichers gehalten wird.
Das stellt ein echtes Problem dar :D wird in jedem Fall spannend ;)
Gruß
Chris
@DerWoWusste ich glaube du hast die Idee des Exploits missverstanden. Es ging nicht darum die cmd.exe auszuführen, das war nur ein Beispiel.
Es geht darum, dass ein fetchen der URL automatisch JavaScript ausführt. (Wie eine JavaScript-Anwendung die eval() aufruft nur dass es hier nicht im Webseiten- sondern im Userkontext ausgeführt wird)
Das Problem ist also, dass hierdurch code auf dem System ausgeführt werden kann, den du nicht per AppLocker blocken kannst, da er einfach über eine Datei heruntergeladen wird und innerhalb des Speichers gehalten wird.
Das stellt ein echtes Problem dar :D wird in jedem Fall spannend ;)
Gruß
Chris
@psannz: was ist denn Deine Testumgebung für eine?
Hier auf win10 enterprise geht es nicht, auf Server 2012R2 auch nicht.
Beschreib mal Deine Schritte (nein, nicht das Beispiel wiederholen bitte, das geht ja aus genannten Gründen ).
Hier auf win10 enterprise geht es nicht, auf Server 2012R2 auch nicht.
Beschreib mal Deine Schritte (nein, nicht das Beispiel wiederholen bitte, das geht ja aus genannten Gründen ).
Dann solltest du ja wissen welchen Schaden man mit ein bisschen JavaScript anrichten kann ;)
Das weiß ich wohl. Nur ist das kein Bypassing von Applocker. Wenn regsvr32 erlaubt ist (muss man ja nicht erlauben, braucht kein Schwein von den Nutzern), dann darf der schon immer (wie jede andere erlaubte exe auch) Scriptcode ausführen. Wäre es jedoch wirklich ein Bypassing von applocker, so dürftest Du entgegen der Applocker-Regeln executables ausführen. Und das trifft nicht zu.
Ich habe dort nun noch weiter kommentiert:
"A little more": Surely, the researcher has "found" something. He found a relatively unknown way to execute script code by means of regsvr32.exe. So if we assume that applocker users don't care for locking down their systems (?) AND use default rules AND DO NOT revise the executables these default rules do whitelist, well, then yes, this IS dangerous.
In secured environments, in addition to the default rules (if those are used at all), you would at least use NTFS ACLs to restrict usage of executables in c:\windows that are not needed to administrators. So tell me: what non-admin would ever need regsvr32? No answer expected.
"A little more": Surely, the researcher has "found" something. He found a relatively unknown way to execute script code by means of regsvr32.exe. So if we assume that applocker users don't care for locking down their systems (?) AND use default rules AND DO NOT revise the executables these default rules do whitelist, well, then yes, this IS dangerous.
In secured environments, in addition to the default rules (if those are used at all), you would at least use NTFS ACLs to restrict usage of executables in c:\windows that are not needed to administrators. So tell me: what non-admin would ever need regsvr32? No answer expected.
*Schädel senk, kein Freitags-Steak heute*
Freitagssteak? Nehm ich!Nach Scharfschaltung von AppLocker und samt definition der Skriptregeln dass Standardnutzer keine Skripte außerhalb %WinDir% und %ProgramFiles% ausführen dürfen konnte ich mit einem einfachen Standardnutzer über den obigen Weg ein VB Skript, abgelegt im Usertemp, starten.
Dann gib mir bitte Dein xml-File. Ich bezweifle das mal ganz hart.Edit:
PS: ich habe den Researcher auch angetweetet. Er hat seinen Antworttweet an mich, der mein Kommentar teils bestätigte, teils versuchte zu widerlegen, bereits wieder gelöscht. Nanu
Der Redakteur hat es missverstanden:
Eben nicht. Es wird nur demonstriert, dass AppLocker keinen Skript-Code zwischen einem In-process-Server (scrobj.dll) und dessen Container (regsvr32.exe) abfängt. Works as designed...
The magic here is that if you change cmd.exe for any program outside the AppLocker whitelist, bingo: it will start, in theory.
Eben nicht. Es wird nur demonstriert, dass AppLocker keinen Skript-Code zwischen einem In-process-Server (scrobj.dll) und dessen Container (regsvr32.exe) abfängt. Works as designed...
Ich hätte an dieser Stelle noch etwas Schönes zu Applocker beizutragen: den Applocker Design Guide. Achtung - Link veraltet. Neuer Link hier
Aus dem Guide geht klar hervor, dass die Defaultregeln keinesfalls anzuwenden sind, wenn man es mit der Sicherheit genau nimmt (und wer, der Applocker nutzt, würde von sich behaupten, es nicht genau zu nehmen?):
Das Ergebnis 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 hier verlinkten.
Aus dem Guide geht klar hervor, dass die Defaultregeln keinesfalls anzuwenden sind, wenn man es mit der Sicherheit genau nimmt (und wer, der Applocker nutzt, würde von sich behaupten, es nicht genau zu nehmen?):
To avoid scenarios 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
Und um noch mal ganz klar die Defaultregeln zu dissen: ladet Euch mal AccessChk runter und macht damit auf einer elevated shell maldefault 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
accesschk.exe BUILTIN\Users c:\Windows\ -w -s