PowerShell 5.0 and Applocker. When security doesn’t mean security (part 2)

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.

Comments:

Captcha