18.20 Detect and Prevent Code Injection Vulnerabilities

Problem

You have a script or function that you are exposing across a security boundary (for example, a JEA endpoint), and want to ensure that it’s not vulnerable to code injection attacks.

Solution

Install and run the InjectionHunter module from the PowerShell Gallery.

Install-Module -Name PSScriptAnalyzer -Scope CurrentUser -Force
Install-Module -Name InjectionHunter -Scope CurrentUser -Force

@'
function Set-PersonalDisplayName($DisplayName)
{
    $c = "Set-AdUser -UserPrincipalName DOMAIN\user -DisplayName $DisplayName"
    Invoke-Expression $c
}
'@ > $env:TEMP\injectable.ps1

Invoke-ScriptAnalyzer -Path $env:TEMP\injectable.ps1 `
    -CustomRulePath (Get-Module InjectionHunter -List).Path

RuleName                       ScriptName     Line Message
--------                       ----------     ---- -------
InjectionRisk.InvokeExpression injectable.ps1    4 Possible script injection risk
                                                   via the Invoke-Expression
                                                   cmdlet. Untrusted input can
                                                   cause arbitrary PowerShell
                                                   expressions to be run.
                                                   (...)

Discussion

One of the incredibly powerful things about JEA and related features is that they let you effectively reduce the number of broadly privileged administrators in your organization. When you have employees that only need to help users reset forgotten passwords, it’s a huge increase of operational risk to make them all domain administrators.

JEA lets you vastly improve this by implementing a trusted subsystem—an endpoint that approved low-privileged users can connect to, but where the actions themselves (exposed as scripts or functions that you write) are performed in a highly privileged context. This transition between low trust and high trust is known as a trust boundary, and any code you expose to the lower-trust side of the equation is called attack surface, and becomes a possible security risk.

There are several examples where PowerShell scripts can become part of an attack surface:

Functions or scripts that you expose in JEA endpoints
Helper scripts that you run as a response to administrative web UIs
Signed scripts that are on a system that has deployed Windows Defender Application Control

The most common cause of security vulnerabilities in PowerShell scripts that are part of a trust boundary is called script injection: where code that you write incorporates user input in an unsafe manner. This then lets the untrusted user code run in the “high trust” side of the attack surface. This class of problem shows up in every technology that involves a trust boundary in one way or another: SQL Injection, Cross-site scripting, and buffer overflows are just a few other examples.

A very simple example of this is given in the Solution, where user input gets unsafely blended into an Invoke-Expression command through the use of variable expansion:

function Set-PersonalDisplayName($DisplayName)
{
    $c = "Set-AdUser -User DOMAIN\user -DisplayName $DisplayName"
    Invoke-Expression $c
}

Invoke-Expression is PowerShell’s cmdlet to take whatever input you give it, treat it like PowerShell code, and run it. Administrators are often lucky that their scripts work at all when they use it in conjunction with user input. Let’s look at a simple example:

Set-PersonalDisplayName -DisplayName "James O'Neil"

This script runs:

Invoke-Expression "Set-AdUser -User DOMAIN\user -DisplayName James O'Neil"

which is like running this at the command line:

Set-AdUser -User DOMAIN\user -DisplayName James O'Neil

and then you start getting help desk calls from users who have the misfortune of being born with a last name that contains only an open quote and not the corresponding closing quote:

Invoke-Expression:
Line |
   4 |      Invoke-Expression $c
     |      ~~~~~~~~~~~~~~~~~~~~
     | The string is missing the terminator: '.

If an attacker is a bit more selective in their placement of special PowerShell characters, they might try something like:

PS > Set-PersonalDisplayName -DisplayName "James'' Revenge; calc"

For more information about the risks of Invoke-Expression and alternative approaches that are both easier and safer to use, see Recipe 1.2.

The Injection Hunter module from the PowerShell Gallery lets you detect this class of problems and also provides suggestions on how to write your code more securely. You can even incorporate it into Visual Studio Code to have it run while you write your scripts, as shown in Figure 18-4.

To do this, open up the PowerShell Script Analyzer settings by typing Ctrl+Comma, and then type analyzer. Under Script Analyzer Settings Path, type a path for these settings—such as alongside your profile: d:\lee\PowerShell\PSScriptAnalyzerSettings.psd1. In it, place the following:

@{
 IncludeDefaultRules = $true
 CustomRulePath =
     "D:\Lee\WindowsPowerShell\Modules\InjectionHunter\1.0.0\InjectionHunter.psd1"
}

For the CustomRulePath setting, you can get the path to Injection Hunter by typing:

Get-Module InjectionHunter -List | ForEach-Object Path

Injection Hunter detects security issues from Invoke Expression, dangerous API usage, command injection, method and property tampering, as well as unsafe input escaping.

To learn how to write analysis rules yourself, see Recipe 10.10 to get started. With that under your belt, Injection Hunter is written as a script module. You can read the contents of InjectionHunter.psm1 to see how it implements its existing rules.

18.20 Detect and Prevent Code Injection Vulnerabilities

Problem

Solution

Discussion

Figure 18-4. Injection Hunter pointing out a script injection vulnerability

See Also