Windows PowerShell and the “PowerShell Worm”

Windows PowerShell and the “PowerShell Worm”

  • Comments 13

Updated Aug. 5th, 2006: The Microsoft security folks have finished their full technical analysis of the worm. You can read their analysis in the Malicious Software Encyclopedia.

 

A “PowerShell Worm” has recently been reported by several antivirus companies and some news organizations. There has been some confusion and concern around the classification of this malicious script as a worm as well as questions about the risk.

 

It is important to note that the PowerShell Worm will not work and cannot infect Windows PowerShell in its default configuration.

 

This is a proof-of-concept virus whose “Worm” replication mode is just a simple file copy and could have been implemented in any language which supports copying files. The fact that the worm is written in PowerShell rather than another scripting language or even as an executable has actually made it even harder for this virus to spread since the additional security features around PowerShell scripts result in many additional steps for the user to perform before an infection can take place.

 

Among the various types of malicious code in existence, worms raise a great deal of attention and anxiety among the computing public. This is because the distinguishing characteristic of traditional worms is their ability to self-replicate automatically from host to host with no user interaction. Automated infection gives worms the ability to cause a great deal of damage in a very short period of time.

 

Unlike some worms, the so-called “PowerShell Worm” does not take advantage of any vulnerability within PowerShell to spread automatically. Although classified as a worm the PowerShell Worm depends upon the user performing a series of fairly complex set of steps to circumvent and disable the numerous security features of PowerShell before any infection can take place. I’ve included the full list of steps required for infection below.

 

This is the second purported PowerShell virus. Lee Holmes has written a great article covering that first PowerShell “virus” and common sense steps to prevent infection (Monad and the First Vista Virus). The advice he gives bears repeating:

 

“The guidance on shell script viruses is the same as the guidance on all viruses and malware: protect yourself against the point of entry, and limit the amount of damage that the malicious code can do.”

 

Windows PowerShell has a number of security features designed to protect users from malicious scripts. In order for the PowerShell Worm to execute and infect a machine, all of these must be disabled. To highlight PowerShell’s security features, I’ll walk through the steps required for the PowerShell Worm to infect a machine.

 

The PowerShell Worm is malicious code written in a PowerShell script which spreads through the P2P network Kazaa. On an infected node, it lives in a set of files in Kazaa’s My Shared Files directory with the following names attempting to trick a user to into downloading the worm:

 

AVP - AntiVirus Key Generator.msh

Ad-aware SE Personal Edition 1.06r1.msh

Allround WinZIP Key Generator.msh

Ashampoo Media Player 2.03 install.msh

Daemon Tools Install + Crack.rar.msh

Kaspersky KeyGen working.msh

Microsoft Windows Vista Cd-Key.txt.msh

Nero Burning Rom 6.6.0.13 Crack.msh

Talisman Desktop 2.99 Crack.msh

Windows Vista Update.msh

 

For a client machine to be infected, the user must first have installed both Windows PowerShell and a Kazaa client.

 

1)      The user must download the worm to their local machine.

 

The first step in to becoming infected is to download one of the files listed above off of Kazaa. Once downloaded, the worm now resides in the user’s Kazaa My Shared Files directory. For the sake of this walkthrough, I’ll assume that the file downloaded was “AVP - AntiVirus Key Generator.msh” and was downloaded to the default location of C:\My Shared Files.

 

2)      The user must change the file extension of “AVP - AntiVirus Key Generator.msh” from .msh to .ps1

 

Windows PowerShell only executes scripts if the file extension is .ps1. To make the script executable, the user must change the file extension to .ps1. .msh is a very old file extension used by Windows PowerShell during its very first releases, but is no longer recognized by Windows PowerShell.

 

3)      The user must manually start Windows PowerShell since files with the .ps1 file extension cannot be executed directly from Explorer.

 

Notepad is the default file association for .ps1 files. This means that if the user naively double-clicked on AVP - AntiVirus Key Generator.ps1 the script will not execute.

 

Unlike traditional command shells, we purposely don’t associate Windows PowerShell with the .ps1 file extension to ensure that scripts cannot be executed by simple double-clicking. This closes the most common infection vector for scripting viruses.

 

4)      Once Windows PowerShell has started, the user must set their execution policy from the secure default of Restricted to either RemoteSigned or Unrestricted.

 

Windows PowerShell provides a flexible set of policies for Administrators and end users to control script execution in order to protect their environments. In addition, Windows PowerShell also includes script signing to help users run scripts only from publishers they trust while protecting trusted scripts from tampering.

 

In its default configuration, Windows PowerShell will not execute any scripts. This feature is designed to ensure that users who wish to use PowerShell only for its powerful interactive commandline are immune for any scripting attacks. Only an Administrator can change this setting.

 

For the PowerShell Worm to run, the user must change the default execution policy to RemoteSigned or Unrestricted. Windows PowerShell supports four different types of script execution policy:

 

Restricted –Windows PowerShell will refuse to run any scripts. This is the default setting.

 

AllSigned – Windows PowerShell checks all scripts for a digital signature. If the signature is from a trusted publisher, the script is allowed to run. If the signature is from an untrusted publisher, the user is prompted as to whether to execute this script or not. Windows PowerShell will refuse to run any unsigned scripts.

 

RemoteSigned – Windows PowerShell checks all scripts for digital signatures and the rules used in AllSigned are used to determine whether the script is allowed to execute. If no digital signature exists and Windows PowerShell knows the script was downloaded from the internet, the script is not allowed to execute. Scripts created locally or downloaded using applications which do not support internet download marking are allowed to execute unhindered. Many popular applications such as Internet Explorer and Outlook Express support marking of scripts to indicate they originated from the internet.

 

Unrestricted – Windows PowerShell checks all scripts for digital signatures and the rules used in AllSigned are used to determine whether the script is allowed to execute. If the script does not contain a signature, it is allowed to execute unhindered.

 

The PowerShell Worm cannot execute under the default recommended policy of Restricted as its malicious code is in a script. It also cannot execute under the AllSigned policy as it is not signed with a digital signature. It can only execute under the unrecommended policies of Unrestricted as well as RemoteSigned since Kazaa does not mark files to indicate they originated from the internet.

 

5)      The user must explicitly execute the script using its relative or absolute path

 

Windows PowerShell will not run any scripts unless the user explicitly asks it to. This includes the current directory, so even if the user had navigated to C:\My Shared Files within the shell and just typed “AVP - AntiVirus Key Generator.ps1”, the PowerShell Worm will not run. The user must explicitly run the script through either providing the full path (“C:\My Shared Files\AVP - AntiVirus Key Generator.ps1”) or the current relative path (“.\AVP - AntiVirus Key Generator.ps1”).

 

Only after a user completes all five steps to disable or otherwise circumvent Windows Powershell’s security protections will an infection take place. At this point, the script will create copies of itself in the Kazaa My Shared Files directory under the various names listed above for the process to begin anew with a new victim.

 

As seen here, the main security features of PowerShell: No .ps1 file association, default Restricted execution policy, and required explicit execution help to make Windows PowerShell secure by default.

 

Despite the various press articles and the fact that this malicious code calls itself a worm, the risk to normal Windows PowerShell users is very low.

 

A user truly has to go out of his or her way to be infected by the PowerShell Worm.

 

Leonard Chung

Program Manager

Windows PowerShell & Microsoft Management Console

 

Leave a Comment
  • Please add 3 and 4 and type the answer here:
  • Post
  • A “PowerShell Worm” has recently been reported by several antivirus companies and some...
  • Great post Leonard... I wrote a post in my blog about the same topic, but in Portuguese. I believe that's the only content avaliable in my language...

    Congratulations!

    --
    Vinicius Canto <scripterbratgmaildotcom>
    MVP Visual Developer - Scripting
    Blog: http://viniciuscanto.blogspot.com
  • Cool... can't wait to see how many arms and legs the press is going to break to try to find a way to insinuate that Microsoft's in trouble again :)
  • And bravo for the PSH team - good job of thinking through, in advance, how these "viruses" would work and making sure PSH, by default, wouldn't make it easy for them. This is one case where MS may have done a bad thing (with VBScript, in this regard), but has CERTAINLY learned from those mistakes and done a much better job.
  • Great Response.

    My blood boils when ppl accuse MSFT and my AD based systems as cause of viruses and "holes" - when they download blond16yo.avi.exe and run it!!!

  • On&amp;nbsp;July 29,&amp;nbsp;2006, a new worm&amp;nbsp;MSH/Cibyz.A&amp;nbsp;surfaced which uses Microsoft's new&amp;nbsp;XP...
  • I am SO glad that the default action for .PS1 script files is Edit rather than Execute.  I hope that Microsoft will finally repeat this countermeasure for other dangerous script extensions as well.  
  • Unfortunatelly I cannot totally agree with most of your assumptions:

    #1: "The user must download the worm to their local machine": This is just the way this "worm" is being distributed. But it could be sent by email, linked from the web or whatever. Stating "The user must download ..." strikes me as a little short-sighted.
    #2: "file extension": OK, they used an outdated version of PowerShell. Who expects them to stay outdated?
    #3: ".ps1 file extension cannot be executed directly from Explorer": I can agree with that, Yet if I worked extensively with .ps1 files I would tell the explorer to treat them like .cmd files, i.e. run them on double-click. I somehow don't think I would be the only one.
    #4: "user must set their execution policy": Yes, they must and they will. The most feasible setting would probably be RemoteSigned, yet according to your post this depends on the support of "popular applications" -  in other words not all popular applications and certainly not the unpopular ones implement to that feature.
    #5: "user must explicitly execute the script using its relative or absolute path". This may prevent the user from accidentially executing it but does not help intended (even if imprudent) excution or double-clicks in explorer (see #3)

    All these things help and make it harder for malicous code. I also agree that on the average users machine it will actually be very helpfull and this is a good thing. But for people actively using scripts (i.e administrators, developers, and "power users") only #5 remains valid. This is OK since in the end the user has to decide, but one should be aware the the saftey nets #1 to #4 are probably not in place and the script *will* run and it *will* fullfill its evil intention.

    Anyway, calling this worm a "worm" is simply not correct and if that's all the Microsoft averse community can come up with you've done a pretty good job.

  • >Unfortunatelly I cannot totally agree with most of your assumptions

    To be clear, the goal of this is not to prevent savvy users from shooting themselves in the foot. We cannot protect all users from themselves if they're really determined to execute the script.

    However, most of the folks who are infected by these types of viruses are not the savvy scripters who use the technology day in, day out but rather novice users who don't notice the differences in file extension or even icon.

    Leonard
  • PingBack from http://dmitrysotnikov.wordpress.com/2007/07/27/powershell-security/

  • All I can say is that this FUD is truly some of the most idiotic fear-mongering and ado over nothing that I've ever seen.

    I'm more or less in the middle ground when it comes to M$, but they did a DAMNED good job with PowerShell - and it shows. I just don't see why when Microsoft releases a product, it is AUTOMATICALLY bad - I mean, sure, there's been a few stinkers, but 2000 and XP are actually pretty well-coded pieces of software.

    Leaves a little to be desired in the form of security here and there, but it would appear that Microsoft is doing what it can to change that - who knows?

    All I know is that these tactics, used by bashers, security firms, and anti-virus/firewall vendors, are pretty underhanded, if you ask me. Give things a chance, don't be so quick to shoot when you see the whites of the eyes.

  • 1) write some C code

    2) file extension rename using system calls in a block of C code

    3) change the "security policy" to Unrestricted by writing to the registry

    4) call the code from another system call

    5) name the compiled binary something cool and package it up nicely so it looks and feels like porn

Page 1 of 1 (13 items)