Storage Daily
Security Daily
Networking Daily
FREE NEWSLETTERS
search
 

follow us on Twitter


internet.commerce
Be a Commerce Partner















internet.com
IT
Developer
Internet News
Small Business
Personal Technology

Search internet.com
Advertise
Corporate Info
Newsletters
Tech Jobs
E-mail Offers


Related Articles
PowerShell: Active Directory and .NET Group Creation and Membership
Windows 7 IT Pro Feature Watch List

Security Products
 WebAllow (Ashkon Technology LLC)
 USB Port Protection Software (Keylogger)
 Google Chrome Password Recovery (XaviWare Software Ltda.)
 Access Password Recovery (Barcode Design Software)
 Lock Folder Lock File! (Lock Folder Lock File! Software)
 Recover Thumb Drive Files (Data Recovery Software Downloads)
» Enterprise IT Planet » Security » Security Features

Securing PowerShell: Code Signing Made Simple

December 17, 2008

Email Print Digg This Add to del.icio.us

By Richard Siddaway

PowerShell in PracticeThis article is based on PowerShell in Practice, to be published May 2009. It is being reproduced here by permission from Manning Publications. Manning early access books and ebooks are sold exclusively through Manning. Visit the book's page for more information.

Security must be at the top of every administrator’s list. Security and usability can pull you in opposite directions. Automation by PowerShell, or any other scripting tool, is a definite move to the ease-of-use side of the balance. How can we keep our automation and make sure that we are secure?

PowerShell has a number of designed-in security features including:

  • Cannot run a script by double clicking
  • Execution policies
  • Current folder not on the path.

We will look at some other techniques for keeping our scripts secure and finish off by looking at script signing.

Script Security

We need to keep our scripts secure for two reasons. One, we don't want anyone running them that shouldn't. No telling what damage could be done by someone running your admin scripts "just to see what happened." Secondly we don't want anyone getting access to the scripts and altering them. That could be even nastier!

So how do we keep our scripts secure?

How many people need access to the scripts? Restrict access to only the administrators that need them. Use NTFS permissions to secure the scripts. Put the scripts on an administration machine rather than a file server to which everyone has access.

Severely restrict the number of people who can modify scripts. In many organizations there is often only one person creating or modifying scripts. This is usually because they are the only one interested or the only one with the skills.

Consider using PowerGUI for running scripts. It can provide a friendly front end enabling administrators to run scripts that cannot necessarily develop scripts.

The maximum security for scripts is created by using the AllSigned execution policy and digitally signing your scripts. At this point in talks when I mention this a lot of people go pale at the thought. Script signing is not a scary subject as we will see.

Script Signing

PowerShell is most secure when used with the AllSigned execution policy. This requires that all scripts are digitally signed using a code signing certificate from a trusted Certificate Authority. Digitally signing a script identifies the source of the script or at least who signed it. If your execution policy is set to Allsigned and a signed script is changed it will not be allowed to be executed until it is resigned.

Code signing certificates can be supplied by one of the commercial Certificate Authorities for a fee or a "self-signed" certificate for which your computer is the Certificate Authority. At this point you may think that this is too hard. Believe me, it's not.

NOTE

If scripts are going to be distributed to other machines either internally or externally to the organization a commercial code signing certificate must be used. The "self signed" certificate is only recognized on the machine on which it was created.

For the rest of this section we will use a "self-signed" certificate for the examples. If you obtain, or already have, a commercial code signing certificate you can skip this next section where we look at creating a certificate.

Create certificate

We can create a "self-signed" certificate using the makecert.exe utility. The bad news is that it is not part of Windows or PowerShell. You need to download and install the Windows SDK from the Microsoft web site. Alternatively, makecert is available if you have Visual Studio installed.

Once makecert is installed we can create a certificate root and then make the code signing certificate. We create the root using this syntax.

./makecert -n "CN=PowerShell Local CertificateRoot" -a sha1
-eku 1.3.6.1.5.5.7.3.3 -r -sv root.pvk root.cer
-ss Root -sr localMachine

It is not quite as bad as it looks, as the following table explains.

Table 1 - Syntax explanation for creating a certificate root

Parameter Meaning Value
-n Certificate subject name "CN=PowerShell Local CertificateRoot"
-a Signature algorithm. Sha1 (md5 is alternative)
-eku Object Identifier (OID) 1.3.6.1.5.5.7.3.3
-r Switch to create a self signed certificate
-sv Pvk file (to be created if not present) root.pvk root.cer
-ss Certificate store Root
-sr Certificate store location localMachine

Our syntax can be read as make a "self-signed" certificate root called "PowerShell Local CertificateRoot" using the Sha1 algorithm and an Object Identifier of 1.3.6.1.5.5.7.3.3. The pvk file is called root and is stored in the Root certificate store on the local machine. Easy.

Full syntax details of makecert can be found by using makecert /? for the basic options and makecert /? for the advanced options.

The next stage is to run this code

./makecert -pe -n "CN=PowerShell User" -ss MY -a sha1
-eku 1.3.6.1.5.5.7.3.3 -iv root.pvk -ic root.cer

This is explained in table 2.

Table 2 - Syntax explanation for creating a certificate

Parameter Meaning Value
-n Certificate subject name "CN=PowerShell User"
-pe Private key is exportable
-a Signature algorithm. Sha1 (md5 is alternative)
-eku Object Identifier (OID) 1.3.6.1.5.5.7.3.3
-ss Certificate store MY
-iv Issuers pvk file root.pvk
-ic Issuers Certificate file

Working with PowerShell we have an advantage. We can look directly into the certificate store. The following code will show us the relevant information about the certificate.

Listing 1 - Viewing code signing certificate

PS> Get-ChildItem cert:\CurrentUser\My -codesigning | Format-List

Subject : CN=PowerShell User
Issuer : CN=PowerShell Local CertificateRoot
Thumbprint : FC5A497BB74AC542876D4E84B6921B457E04CB10
FriendlyName :
NotBefore : 16/08/2008 13:08:08
NotAfter : 31/12/2039 23:59:59
Extensions : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid}

Having created our certificate we should secure it. We don't want the bad guys getting access to it, automatically signing scripts and doing nasty things to your machine now do we?

Page 2: Secure Certificate

Go to page: 1  2  Next  

Email Print Digg This Add to del.icio.us

Security Features Archives










The Network for Technology Professionals

Search:

About Internet.com

Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers