56

PowerShell Injection Hunter: Security Auditing for PowerShell Scripts

 5 years ago
source link: https://www.tuicool.com/articles/hit/BbIvUv3
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

At the DEFCON security conference last year, we presented the session: “ Get $pwnd: Attacking Battle Hardened Windows Server “.

MjaAVrI.png!web

In this talk, we went through some of the incredibly powerful ways that administrators can secure their high-value systems (for example, Just Enough Administration) and also dove into some of the mistakes that administrators sometimes make when exposing their their PowerShell code to an attacker. The most common form of mistake is script injection, where a script author takes a parameter value (supplied by an attacker) and runs it in a trusted context (such as a function exposed in a Just Enough Administration endpoint). Here’s an example:

vUNrquQ.png!web

There are many coding patterns that can introduce security flaws like this, all of which have secure alternatives. The presentation goes into these in great detail, and what we also promised to release is a tool to help you detect them as you are writing the scripts. We’ve now released this tool, and you can download it from the PowerShell Gallery :

3yE3UrJ.png!web

Using it this way from the command line is an excellent way to automate security analysis during builds, continuous integration processes, deployments, and more.

Wouldn’t it be REALLY cool if you could detect these dangers while writing your scripts? I’m glad you asked!

PowerShell’s Visual Studio Code plugin already does live script analysis to help you discover issues like unassigned variables, and we can customize that rule set to include InjectionHunter capabilities. Here’s what Visual Studio Code looks like with this running:

QfAJFjf.png!web

Here’s how to get this on your system:

First, find out the location of the InjectionHunter module. You can do this by typing:

Get-Module InjectionHunter -List | Foreach-Object Path

On my system, this returns:

D:\Lee\WindowsPowerShell\Modules\InjectionHunter\1.0.0\InjectionHunter.psd1

Next, create a file – ‘PSScriptAnalyzerSettings.psd1’ in a location of your choice. Use the following for the content – replacing the path to InjectionHunter with the one on your system.

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

Finally, update your Visual Studio Code user settings to tell the PowerShell plugin to use your custom settings. You can get to these by typing Control+Comma, or through File | Preferences | Settings.

2eQFbui.png!web

I’ve got some settings that match my personal preferences already, so the critical line to add is:

"powershell.scriptAnalysis.settingsPath": "c:/users/lee/PSScriptAnalyzerSettings.psd1"

Where the path to PSScriptAnalyzerSettings.psd1 is the path that you saved your file earlier. When you open a PowerShell script with possible code injection risks, you should now see Script Analyzer warnings that highlight what they are and how to fix them.

Happy hunting!


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK