SAPIEN Technologies

The ILOVEYOU virus in the year 2000 gave Windows Script Host a bad rep because it simply executed every script you double clicked on. Now, mind you, I personally think that was much more the fault of the email clients that indiscriminately executed every attachment without hesitating and the users who where too infatuated with the message to look at the attachment’s extension.

Anyway, the Windows Script Host for VBScript and JScript files has a registry setting that allows scripts to run uninhibited or only if they are signed. The default is to run everything, so you better use group policy to change that.

PowerShell initially does not run any scripts whatsoever, its default for execution policy is “Restricted”. Type Get-ExecutionPolicy in your PowerShell console to see your setting.

If you try to run a script you get an error like this:

File C:\WINDOWS\system32\WindowsPowerShell\v1.0\profile.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see “get-help about_signing” for more details.

So one could conclude from that that PowerShell is more secure. But wait… Regardless of your current execution policy anyone with access to your system can do this:

PowerShell -ExecutionPolicy Bypass -File “Hello world2.ps1”

and run any powershell file they’d like without further prompting.

It helps a little that PS1 files are not associated with PowerShell.exe in a way that allows inadvertent execution, but if someone wants to run a malicious script and has gained access to run powershell.exe, your execution policy setting is no hurdle.

So don’t trust the defaults; keep your systems locked up and execute caution. Don’t rely on any language to give you security. It is your job to create and maintain that.

Additionally, both Windows Script Host and PowerShell use simple text files for their scripts. Obviously that makes creating these scripts and maintaining them very easy and adds much to the appeal of scripting languages over compiled languages for system administrators. However, that presents an inherent security risk as any credentials you have to include in your scripts are open for anyone to see. Whether it is the user ID and password for your SQL server database, the WMI logon for your domain controller or something you just need to include in your script to make it work, anyone can open your script in notepad and see what the credentials are.

So if you have to write scripts that you provide for other users, that leave your workstation and contain even the least bit of sensitive information, use an executable packager to wrap your scripts encrypted in an exe file. There are several options available, but naturally we recommend the script packager found in PrimalScript, PrimalForms 2009 and the upcoming PrimalForms 2011.