In the previous post, I tried to explain some inconsistences in the current implementation of Constrained PowerShell feature that is introduced in PowerShell 5.0: PowerShell 5.0 and Applocker. When security doesn’t mean security. After having a long email and twitter conversations I realized that many of readers blame me for being against Constrained PowerShell feature. It is not true. In this post, I would like to summarize what is going wrong now and how it should work in my opinion.

  1. The whole idea to protect PowerShell from being used by attackers is good.

    I clearly understand that an attacker could run arbitrary in-memory code without having to touch filesystem by calling powershell.exe -command <evil code> and this ultimately makes AWL (Application Whitelisting) weaker.

  2. First fault: PowerShell team made new security feature dependent on a non-security feature.

    Although many of AWL users and PS team consider AWL as a security feature, not all in Microsoft thinks the same. Especially, Microsoft Security Response Center (MSRC). Proof: https://github.com/kasif-dekel/Microsoft-Applocker-Bypass (image at the bottom).

    1. Instead of relying on AWL status, I would propose to make an entry in group policies that would configure interactive language mode. Administrators would be able to control Constrained PowerShell separately from AWL status.

    2. It should be possible for PowerShell.exe to differentiate the code called from interactive shell and from PowerShell.exe parameters (i.e. -command parameter).

      In my opinion, interactive shell is not that insecure like direct powershell.exe calls. So, PS itself should be able to differentiate input sources.

    3. In addition, there should be a GPO entry that would configure language mode for admins (elevated shell) and non-admins (standard users and non-elevated shells).

    By having all three, we would propose a new PS security baseline like this:

    • standard user interactive shells and powershell.exe -command will always run in constrained language mode.
    • admin user (non-elevated) interactive shells and powershell.exe -command will always run in constrained language mode.
    • Admin interactive shell will run in full language mode (because we obviously need to perform administrative tasks that are impossible in constrained language), but powershell.exe -command will run in constrained mode even in admin mode.

    Such baseline would improve PS security, while administrators will be able to perform their usual (or unusual when something is failed) tasks without worrying that something calls powershell.exe -command <evil> in background.

  3. AWL is not security boundary, consider it bypassable.

    There are number of issues with Microsoft implementations of AWL that potentially allow to bypass it and run arbitrary executable/dll. Link to GitHub is just *another* example. The things goes worse, because new similar issues with Applocker won’t be patched (see response from MSRC). As the result, PowerShell is still the target and attacker is potentially capable to utilize PowerShell class in System.Management.Automation.dll assembly. At this point, an attacker is able to call PowerShell.Create().AddScript(<evil>) that will execute the code in Full Language mode. As the result, PS team should enforce constrained language mode (if it is selected by an administrator) to PS .NET calls too. This would be more complete solution from security perspective.

  4. Considering, the company is using AWL. As the result, all interactive sessions will be run in constrained language mode. Including ISE.

    How Microsoft would support script authoring/debugging and various administration operations from interactive shell when AWL is enforced? In the current implementation it is impossible and we are forced to disable new feature by creating appropriate rules in AWL, because it is unreliable and unusable at this point. This question is still open.

Hope, this adds some clarity to my position in this question.


Share this article:

Comments:

Thilo
Thilo 01.12.2017 16:01 (GMT+2) PowerShell 5.0 and Applocker. When security doesn’t mean security (part 2)

Are there updates in the meantime, how I should organize this stuff for my powershell developers?

nigel brown
nigel brown 06.04.2018 02:01 (GMT+2) PowerShell 5.0 and Applocker. When security doesn’t mean security (part 2)

So if we run an environment with AppLocker how can we run scripts in full language mode without launching in Admin mode? 

Vadims Podāns
Vadims Podāns 06.04.2018 12:03 (GMT+2) PowerShell 5.0 and Applocker. When security doesn’t mean security (part 2)

> So if we run an environment with AppLocker how can we run scripts in full language mode without launching in Admin mode?

if you have scripts ready for execution, just digitally sign them and execute. They should run in full language mode. If not -- you are out of luck, you are always limited to constrained language in interactive sessions.

Nick
Nick 15.08.2018 17:47 (GMT+2) PowerShell 5.0 and Applocker. When security doesn’t mean security (part 2)

https://community.spiceworks.com/topic/1451109-srp-whitelist-causing-odd-behavior-in-powershell-v5?page=2

This post covers how to add an Applocker rule to allow PS to run in full language mode.

This rule can then be targerted at AD groups / individual users etc as required.

You are NOT always limited to constrained mode when using Applocker!

Vadims Podāns
Vadims Podāns 15.08.2018 18:40 (GMT+2) PowerShell 5.0 and Applocker. When security doesn’t mean security (part 2)

> This post covers how to add an Applocker rule to allow PS to run in full language mode.

The only way to allow PS in full language mode is to disable PS1 file screening through SRP/Applocker. There is no need in so complex rules, you can simplify it to "*.ps1" and that's all. The point here is that PS1 files are no longer screened by AWL.

Nick
Nick 20.08.2018 20:10 (GMT+2) PowerShell 5.0 and Applocker. When security doesn’t mean security (part 2)

That's not the only way becasue I'm running it in my environment

allowing *.ps1 will open you up to any PS script running.

The process outlined in that spiceworks post will allow you to get PS out of constrained mode but still allow to granularly control which scrips can execute or indeed who can execute them

In my environment one AD group can run powersehll outside of contrained mode. No one else.

 

Nick
Nick 20.08.2018 20:14 (GMT+2) PowerShell 5.0 and Applocker. When security doesn’t mean security (part 2)

I should point out that I'm on Win 10 1803 and the path has changed that you need to allow via Applocker.

If you are interested in seeing what is and isn't being blocked and thus what needs to be allowed (or indeed not!) you look here:

Eventvwr -> Apps & Services -> MS -> Widows -> Applocker -> MSI & Scripts

Enjoy!

Nick Brennan
Nick Brennan 20.08.2018 22:19 (GMT+2) PowerShell 5.0 and Applocker. When security doesn’t mean security (part 2)

Sorry 3rd follow up haha.

 

You are correct. However you can use a targeted rule to constrain this to groups of approved users whilst still keeping applockers 'protection' for others. That's an important distinction.

 

 

Vadims Podāns
Vadims Podāns 21.08.2018 14:11 (GMT+2) PowerShell 5.0 and Applocker. When security doesn’t mean security (part 2)

> allowing *.ps1 will open you up to any PS script running.

this is the problem. If PowerShell started in full lnaguage mode, PS script execution is no longer screened by Applocker. So, whether you enable ps1 files in %temp% folder or completely enable ps1 files (*.ps1), the effect is identical. This is why I'm using simplest solution to remove ps1 files from SRP/Applocker.

Nick
Nick 21.08.2018 19:17 (GMT+2) PowerShell 5.0 and Applocker. When security doesn’t mean security (part 2)

Not quite.

Modules won't load with or without custom XML definitions (I can't remember what the proper term is). The 365 2FA module won't run without a *.ps1 rule, you need to import into an open session using a more specific rule.

So you're not giving up complete control and I still say that the ability to target a group and retain protection for anyone outside that group is useful.

Code signing won't be implemented everywhere and this at least means you can restrict PS access to certain users and still use Applocker to protect the majority.


Post your comment:

Please, solve this little equation and enter result below. Captcha