Tip

Windows PowerShell: A backdoor to malware?

Imagine it: You install Windows PowerShell and are happily using it to automate administrative tasks. Then one day you open the shell and it autonomously starts deleting objects from Active Directory. Is the shell intelligent? Is it simply malicious? Or have you just discovered that Windows PowerShell, as configured by most administrators, is the perfect entry point for malware?

Show me your profile

The problem comes from four scripts that Windows PowerShell is hardcoded to look for and execute. They're called profiles, and they're designed for a good purpose: to pre-configure your shell environment each time you open it -- loading snap-ins, creating functions and so forth. But these profiles are simple text files, and two of them reside in your Documents folder, meaning you and any process you run has full control over them.

So along comes a piece of malware. It executes undetected because it's doing nothing more than writing to a couple of simple text files -- your PowerShell profile scripts. The next time you open the shell, every instruction in your profile executes, including the bad stuff. How could Microsoft possibly have shipped a product that does this?

Four opportunities

The Quick Start Guide that comes with Windows PowerShell details the four scripts that the shell is hardcoded to look for and execute. You won't

    Requires Free Membership to View

find most of these on your system unless you've created them; they are not created by default. That's a potential danger, because all a piece of malware has to do is create the scripts!

More PowerShell resources

Screencast: Getting started with PowerShell

Scripting School archive

The primary ones are located in your Documents folder, in a subfolder called WindowsPowerShell. The first is named profile.ps1 and the second is Microsoft.PowerShell_profile.ps1. Each has a slightly different purpose as discussed in the guide, but they'll both load and execute automatically each time the shell opens. Even better, most PowerShell script editors – PowerGUI, PowerShell Plus and PowerShell Analyzer, AdminScriptEditor and PrimalScript also look for your PowerShell profile, load it and execute it each time the editor opens. There are plenty of opportunities for malware to execute. And get this: It's not Microsoft's fault. It's yours.

Where you went wrong

Out of the box, Windows PowerShell won't execute scripts -- even those profiles. That's because its Execution Policy is set by default to not permit script execution.

Try opening the shell and running Get-ExecutionPolicy. You should see "Restricted" if you're using the out-of-the-box settings. Then try running a script, and marvel at the error message that basically says, "no way, boss."

As shipped, Windows PowerShell is immune from malicious code being inserted into your profile, because it won't execute your profiles. In fact, if a profile script exists, the shell will still try to execute it, but will display the "no way" error. The only way to get the shell to run any script is to modify that Execution Policy, either by running Set-ExecutionPolicy or by deploying a Group Policy Object (you can get the shell's Group Policy extension from Microsoft's Download Center – search for "PowerShell ADM").

Most administrators seem to opt for the RemoteSigned policy or, even worse, the Unrestricted policy. Both will allow any local script to execute without being digitally signed. That means malware can create your profile script or modify it (if it already exists) and not get caught. Most antivirus software won't even detect that activity, because most don't classify it as malicious, unlike modifications to other sensitive files, such as Boot.ini. So what's an honest Windows admin to do?

Signature, please

The answer is to use the AllSigned policy, which requires all scripts to be digitally signed and forces the shell to check the integrity of the signature each time the script is executed. Sign your profile scripts -- create empty ones first if you need to -- and you're protected. Any malware modifications will break the signature; if the malware has some kind of embedded certificate and re-signs the script, then you can use the signature itself to track down the malware's author and apply the appropriate beatings.

Signing a script isn't tough: Just use the Set-AuthenticodeSignature command inside PowerShell itself, or use an editor capable of applying a signature (some will even do so automatically each time you save a script). You'll need to acquire a Class III AuthentiCode code-signing certificate, either from an internal certification authority (CA) or from a commercial one like VeriSign (they run about $400 to $900 for the first year, depending on where you buy it). Be sure to install the certificate on your system to have a password. That way malware can't access it without your knowing. All these steps may seem like a bit of a hassle, but it's the only way to safely enable script execution and keep malware from turning your profile into an attack vector.


OVERLOOKED SECURITY IN WINDOWS 2008
Windows PowerShell
Server Core
Network Access Protection

ABOUT THE AUTHOR
Don Jones is a co-founder of Concentrated Technology LLC, the author of more than 30 IT books and a speaker at technical conferences worldwide. Contact him through his website at www.ConcentratedTech.com.

This was first published in August 2008

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.