Relevant Technologies: Is the Windows PowerShell a Threat to Security?

< Back to Article List

Is the Windows PowerShell a Threat to Security?
By: Brien M. Posey
March 20, 2009

A few years ago, I was attending the MPP global summit, when Microsoft made the announcement to all of the MVPs that future versions of Windows would include the Windows Power Shell (which at that time was known as Monad). When the session finally ended, I remember having a conversation with my friend Bud about what we had just heard. I can't remember all of the details of our conversation, but I do remember that there were two things that we both agreed on. First, we both agreed that the addition of a scripting language would make the Microsoft certification exams a lot more difficult. The other thing that we both agreed on was that the virus writers would have a field day with Windows Power Shell. In this article, I want to talk about whether my prediction came true or not, and about the basic security that is built into Power Shell.

Power Shell and Windows Vista
At the time of the conversation that I mentioned above, Windows Vista was far from being ready to be released, and Windows Server 2008 was probably nothing more than a glimmer in Uncle Bill's eye. A few days after I returned home, I started thinking about one of the things that had been mentioned at the summit. Someone in Redmond had mentioned that Windows Vista and Windows Server 2008 were being built from the same code base. Vista would have a few features that Windows Server 2008 wouldn't have, and vice versa, but at the kernel level the two operating systems were to be identical.

As soon as I thought about this, my mind instantly flashed to the Windows Power Shell. I started thinking about all of the security problems that existed in Windows XP, and how those types of problems could be compounded if Microsoft chose to include its all powerful scripting language in a desktop operating system.

As I'm sure you know, Microsoft ultimately chose not to negatively include Power Shell in Windows Vista. I have never heard any official word as to why Microsoft made this decision, but I can't help wondering if it had something to do with security. After all, Windows XP was nothing short of a PR nightmare for the folks in Redmond because of all its security holes. Windows Vista has been marketed since the very beginning as the operating system that would once again make our workstations secure. As such, it makes sense that Microsoft would omit a feature that could potentially be exploited in such a catastrophic way.

Regardless of how you feel about Power Shell, I think that Microsoft made a very wise decision omitting the Power Shell from Windows Vista. Incidentally though, just because Power Shell was not included natively in Windows Vista, it does not mean that you cannot use Windows Power Shell with Vista. Microsoft allows you to download Windows Power Shell here. The version of Windows Power Shell available at this site is compatible with Windows XP (SP2 and higher), Windows Server 2003 (SP1 and higher), and Windows Vista. You do however, have to install version 2.0 of the .NET Framework prior to installing Windows Power Shell.

Has History Repeated Itself?
Having a scripting language built into Windows is nothing new. Those of you who have been in IT for a while may recall that Windows 3.X was nothing more than a platform that rode on top of the DOS operating system. Windows 95, 98, and ME were technically designed the same way, but they included their own proprietary version of DOS. Although Windows NT, 2000, XP, and Server 2003 did not actually ride on top of DOS, those versions of Windows to include a command interpreter that allowed DOS commands to be executed.

In case you're not familiar with DOS, it was the old Disc Operating System that first became popular somewhere around 1982. Over the years, the DOS interpreter has been extended many times, but all of the original DOS commands still work, even to this day.

Although DOS is nowhere near as powerful as Windows Power Shell, it does provide built-in scripting capabilities. Therefore, in trying to figure out whether or not Windows Power Shell was really going to be a serious threat to security, I did some research to find out if anyone had ever written a DOS batch file virus.

I have to admit that I experimented heavily with creating DOS batch file viruses when I was in high school, back in the late 1980s. At the time, I was able to construct a crude batch file virus, but the virus would only run under ideal conditions, and realistically it did not pose a threat to anyone. Obviously, a lot has changed since the 1980s, so I did some poking around on the Internet to see if anyone had been more successful in creating a DOS -based virus than I was. The only halfway credible reference that I was able to find was a posting on the Berkeley website. The 1998 website article concluded that it is possible to write a DOS batch file virus. Even so, there were much easier methods of writing viruses available at the time.

With that in mind, let's fast forward another eight years to 2006. In August of 2006, Microsoft confirmed that a proof of concept worm had been written using a Windows Power Shell script. You can find a full description of this worm in Microsoft's Malicious Software Encyclopedia.

This particular worm is designed to overwrite files with the .BAT, .CMD, .LOG, .INI, .TXT, .JS, and .HTML extensions. The file can also replicate itself through Kazzaa peer to peer file sharing applications. Although this particular virus sounds pretty nasty, Microsoft designated it a severity level of Low. The reason for this is that the virus simply will not work if Power Shell is running in its default configuration. In fact, even if you wanted to execute the virus, you would have to go through several steps before the virus could run. In order to understand why this is the case though, you need to know a little bit about the security mechanisms that Microsoft has put into place in Windows Power Shell.

Power Shell Security
If you have ever played around with PowerShell, then you probably know that PowerShell can be a pain in the butt to use. Believe it or not though, this is by design. Some of the more frustrating aspects of using PowerShell are actually in place as a way of helping to improve security.

For instance, by default, PowerShell will not allow you to execute any scripts. You can enter individual commands all you want, you just can’t run a script containing PowerShell commands. Obviously, there is a way of disabling this safety feature though. Another mechanism that is in place for your protection is that if you do configure PowerShell to run scripts, then those scripts must be run interactively. You have to run the script from the server console, directly through the PowerShell window in order for the script to execute.

One more aspect of the way that PowerShell behaves that is a bit of a pain is in the way that it requires paths to be used. Suppose for example that you have a script that resides in a folder named C:\scripts. You can’t just navigate to that folder and run the script. You have to provide the script’s full path as a part of the command, even if you are launching the script from the same folder in which it resides. Microsoft does this as a way of preventing malicious scripts from running automatically. It would be a bit of a trick (though probably not impossible) to construct a script that can calculate itself, and then embed that path into the command that launches the script.

Since script execution is disabled by default, you may be wondering how you can go about enabling the ability to execute scripts. The easiest way to accomplish this is by using a group policy setting. Before you can do that though, you will have to download the Administrative Templates for Windows PowerShell.

The group policy extension comes in the form of an MSI file. When you execute this MSI file, it will launch a simple wizard that will extract the ADM template file from the MSI file. The wizard is really simple to use, but be sure to pay attention to the path that the ADM file is extracted to, because you will need to reference this path in a minute.

The actual method of importing the template will vary depending on which version of Windows you are using. In Windows Vista, you must open the Group Policy Object Editor by entering the GPEDIT.MSC command at the Windows Run prompt.

When the Group Policy Object Editor opens, navigate through the console tree to User Configuration -> Administrative Templates as shown in Figure 1. Next, right-click on the Administrative Templates folder, and select the Add / Remove Templates command from the resulting shortcut menu. When you do, Windows will display a list of the templates that are currently installed on the system. You can add additional templates by clicking the Add button.

Figure 1. Administrative Templates in the Local Group Policy Editor

Once you click the Add button, you will be prompted to select the template file that you want to install. Before you can select a template to install, you must navigate through the directory tree to path to which you extracted the template file earlier (the default path is \Program Files\Microsoft Group Policy). Select the PowerShellExecutionPolicy.adm file, and click the Open button, followed by the Close button.

The PowerShell policy should now be installed. You can access the related policy settings by navigating through the console tree to User Configuration | Administrative Templates Classic Administrative Templates | Windows Components | Windows PowerShell.

As you can see in Figure 2, there is only one group policy setting available for Windows PowerShell. This is the Turn on Script Execution Policy setting.

Figure 2. The PowerShell Template only provides you with one group policy setting

The Turn On Script Execution Policy is not enabled by default, which of course means that PowerShell scripts are not allowed to execute. Disabling the Turn on Script Execution policy setting also has the effect of preventing PowerShell scripts from running.

If you choose to enable the policy setting, there are three different execution policies that you can choose to use. The first option is the Allow only Signed Scripts option. If you choose this option, then you can run scripts, but only if those scripts have a digital signature, and only if the signature is from a signed publisher.

The next option is the Allow Local Scripts and Remote Signed Scripts option. As the name implies, this setting allows any locally installed scripts to run, but it requires any Internet based scripts to be signed by a trusted publisher.

The last available setting is the Allow All Scripts option. This option allows any PowerShell script to run, regardless of whether or not the script is signed. As you can imagine, Microsoft does not recommend using this policy setting, because of potential threats to security.

What About the Virus?
Now that I've talked about the various security mechanisms that are built into PowerShell, I want you to look back at the PowerShell concept virus and show you what it takes to execute it.

Before the virus can be executed, the victim would have to download and install both PowerShell and Kazaa. Naturally, the victim would also have to download the virus from a shared file directory.

The original version of the proof of concept virus used the .MSH file extension. This now defunct extension is not even supported by current versions of Windows Power Shell. Therefore, if the victim is to have any hope whatsoever of executing the virus, they will have to change the infected file’s extension to .PS1.

Windows PowerShell has been specifically designed so that the .PS1 extension is not directly associated with Windows PowerShell. This prevents an administrator from just double clicking on a .PS1 file in Windows explorer and executing a script. Even if the .PS1 file extension were registered to Windows PowerShell though, it wouldn’t matter. PowerShell is designed so that it is not allowed to run scripts by default. It can only run individual commands. An administrator has to specifically configure PowerShell to run scripts. Not only that though, the script execution policy has to be set to unrestricted before an administrator would be able to execute this script. Even at that, the script would have to be initiated manually. As you can see, the chances of this type of virus ever being run automatically, or even accidentally, are pretty slim.

Conclusion: Threat to Security or Not?
Now that I've talked about the various security mechanisms that are built into Power Shell, and I have examined the proof of concept virus for PowerShell, I want to go back to my original question of whether or not the Windows Power Shell is a threat to security.

My personal feelings are that for the time being the Windows Power Shell probably not a huge threat to security. After all, some good security mechanisms have been put in place to prevent malicious scripts from running. Although it is technically possible to create a malicious script for Windows Power Shell, doing so is impractical. If someone wanted to write a virus it would be much easier to construct a virus using some other programming language.

However, I think that it would be naïve to believe that Power Shell will never be a threat to security. I'm sure that someday somebody will probably come up with an exploit that makes it easier to execute Power Shell scripts. When that day comments, we will probably start seeing a bunch of websites that are designed to trick administrators into downloading and running malicious code. For now though, I don't necessarily think that Power Shell’s security mechanisms are foolproof, I just think that there are much easier ways of executing malicious code.