Introduction to PowerShell - part 4 - Security

by Dmitry Kirsanov 23. March 2012 01:42

One of the qualities of the PowerShell, one of the scales to mark it’s success was the Security. It is also the first question asked when someone new to PowerShell is trying to run the PowerShell script.

The previous generations of scripting environments, like the Windows Scripting Host with it’s notorious VBS files sent automatically over e-mail by all sorts of worms and trojans – they cried for better security, and not only in terms of getting over the problems, but also in terms of applying newest standards and technologies.

So this video training article is about the security in Windows PowerShell.

Windows PowerShell is not installed by default in any version of Microsoft Windows. Although it’s part of the operating system, shipped as a feature since Windows Server 2008. However, even after you install the Windows PowerShell, you can’t run the PowerShell scripts unless they are signed. In order to execute the .ps1 (the extension for PowerShell scripts) files, you need to either have them signed by trusted certificate, or disable the default Execution Policy.

Currently there are seven different execution policies available for Windows PowerShell – Unrestricted, RemoteSigned, AllSigned, Restricted, Default and Bypass. If you long for good old days, you can set the Unrestricted execution policy by executing the Set-ExecutionPolicy Unrestricted command. This would allow executing any PowerShell script despite of it’s origin.

The RemoteSigned execution policy basically means that PowerShell will look at the origin of the file, and will request digital signature if the file is considered to be originated from remote location.

Remote location is not a constant term. There are six zones defined:

NoZone = -1
MyComputer = 0
Intranet = 1
Trusted = 2
Internet = 3
Untrusted = 4

With all zones with ID higher than 2 considered to be remote. Moreover, if the Enhanced Security Configuration of your Microsoft Internet Explorer browser is switched on, which is the default state on all Windows server platforms since Windows Server 2008, then Intranet is considered remote as well.

The problem I see with RemoteSigned execution policy is that rogue scripts may be originated from the local computer, generated by rogue program. Pieces of malicious PowerShell code could be injected into the existing scripts and it wouldn’t make them look foreign either.

The only solution to make injection impossible is to digitally sign all scripts. In that case, if file is modified without re-signing it, PowerShell will consider it damaged and will not execute it.

In this video I am showing you how to generate the self-signed certificate using the default tool from Microsoft, the makecert.exe utility, which may be found in Windows Platform SDK and Microsoft .NET SDK. It is also possible to generate the certificate using the free open source OpenSSL utility, which is also available for Windows.

In the second part of the video we’re looking at another side of security – the authentication in Windows PowerShell. We are executing the WMI query to retrieve records from System Event Log of remote machine. We could as well request Windows Registry entries or file system information – either way it would require us to authenticate. In a very elegant way we are avoiding using the user credentials to be explicitly set in the script, as well as making it impossible to use by unauthorized people.

Interesting, that the Graphical User Interface (GUI) you see as the PowerShell dialog for credentials, is not based on Windows GUI, which is not present in Windows Server Core. Instead, PowerShell is able to create it’s own, very basic but functional, graphical user interface. That way, for example, you may have a perfect administrative console in Windows Server 2008 Core, which doesn’t support the standard Windows GUI.

Introduction to PowerShell - part 4 - Security
blog comments powered by Disqus

Month List