Windows PowerShell and the “PowerShell Worm”
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
Light
Dark
0 comments