Windows 7 AppLocker can be bypassed

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.

 

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.

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.

 

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.

 

This is what I posted there, under darko:

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*.

 

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.

 

@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)

Code:

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)

Code:

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

I hope this gets a fix as well.

 

Hello safeguy! Long time no talk!!

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

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

 

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.

 

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:

Code:

$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.

Code:

[...]
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.