PowerShell 2.0 Protects You From Viruses!

Virus protection? PowerShell? Well… sort of.

An old Internet joke from way back involves the so-called Amish Virus. ‘Infection’ by the Amish Virus can be diagnosed when you open an email and see this:

"Thou hast just received the Amish Virus.

As we haveth no technology nor programming experience, this virus worketh on the honour system. Please delete all the files from thy hard drive and manually forward this virus to all on thy mailing list.

We thank thee for thy cooperation.

 — The Amish Computer Engineering Dept."

The subtle humor of this long-standing joke lies in the fact that the author of the ‘virus’ is so technology averse that you have to damage yourself and others with it manually – the virus is not going to automate any of that for you. Of course, few recipients of such an email would go through the effort of doing something so obviously destructive. Common sense quickly argues against deleting valuable files or taking deliberate steps to infect friends with a damaging virus.

What does all this have to do with PowerShell? Interestingly, PowerShell defends against a few kinds of actual security threats using some of the same philosophy that protects us from the ravages of the dreaded Amish Virus.

For contrast, let me remind you about a little virus called ILoveYou. Launched in May of 2000, this simple little piece of code scanned infected computers for graphics and audio files, replaced the contents of those file with a copy of itself, and then propagated itself via email. Unsuspecting targets of the virus found an attachment seemingly named Love-Letter-For-You.txt attached to an email that appeared to be from a trusted source. A text file – what could go wrong? Double-clicking it (you could do that in Outlook back in those days) revealed the truth. The file wasn’t Love-Letter-For-You.txt – it was Love-Letter-For-You.txt.vbs. A VBScript-based application had just been launched in the system, and quite probably, without its user’s awareness.

The impact was immediate and drastic. In a week and a half, 50 million computers had been infected, and upwards of 5 billion dollars of damage had been done. Major corporations, plus the CIA, the Pentagon, and the British Parliament all took their email servers offline in order to clean up the mess. Whoa.

You can imagine that when building PowerShell, Microsoft surely wanted to avoid the disaster produced by the freely-executable nature of VBScript and JavaScript on Windows systems. PowerShell was launched with some significant protections against this kind of mischief.

File Extension Association
Part of what made ILoveYou so nasty was that it didn’t need to ask the user if he wanted to run the VBScript-based executable – that functionality was built right into the operating system. You see, the .VBS extension is already associated with the WScript.exe program in Windows by default, so double-clicking a .vbs file (or a .vbs file masquerading as a .txt) is sufficient to trigger it. By contrast, .PS1 – the PowerShell script file extension, is associated with Notepad.exe. So if some thoughtless user double-clicks an attachment called DamagingVirus.PS1 – no worries – it opens in Notepad, and no harm is done.

Execution Policy
Additionally, PowerShell ships in a default state that prevents script execution. This behavior is called an execution policy, and it’s a reboot-persistent, group policy-configurable setting. It sets a computer-wide configuration for how much trust we need to have in a PowerShell script before we can run it. The default execution policy is called Restricted, and it prevents the execution of any PS1 files. That’s true even for those scripts created locally, or run by the Administrator.

Interestingly, the execution policy does not prevent execution of individual statements at the PowerShell command prompt. So it’s possible that one could attempt to run a PS1 script, fail to do so, and then copy and paste the text of the script into the PowerShell console, one line at a time. But in most cases, that activates our primary defense against the Amish Virus. Common sense should take over in the mind of the user, who realizes he is in danger of doing something foolish. We can imagine that our users would not respond cooperatively to an email that says this:

"You have just received the PowerShell Virus.

Please open the attached PS1 file, and cut and paste the executable code into a running instance of PowerShell.exe. That, or run Set-ExecutionPolicy unrestricted at a PowerShell prompt, and then launch the attached script.

Trust me, it’s totally safe!"

Well, at least we can hope.

(Originally posted on the Global Knowledge blog by Mike Hammond - Link)