Windows Tip Sheet
Lock Down Those Scripts!
Take care of this task throughout the company via this Active Directory trick.
"Lock down your scripting environment" is a big refrain with
me. Anyone who's attending my scripting classes has heard me say it, and
certainly anyone who reads anything I've written has seen it. Recently,
though, I got a huge pile of e-mail telling me that it's just too darn
difficult to run around to every machine in the company installing the
registry hacks necessary to properly lock down the Windows Script Host.
Yeah, you're right. Fortunately, there's Active Directory, which is more
than willing to do it for you.
First, some background: The current version of WSH (that'd be 5.6, available
from www.microsoft.com/scripting)
obeys a cool registry key. Normally, WSH doesn't care if your scripts
are digitally signed or not, because this key is set to zero. However,
setting it to 1 or 2 makes WSH care: When WSH sees a script that hasn't
been signed (and the signing certificate must have been issued by a certification
authority that the local machine trusts), WSH either notifies the user
and asks what to do (registry key set to 1) or refuses to run the script
(set to 2). Asking the user is almost always the wrong answer, of course,
because we all know they'll just say "run it anyway," so I prefer
the second option.
As I mentioned, this all takes place in a registry key. Well, actually
a couple of registry keys. On Windows 2000, just one key is involved:
HKCU\Software\Microsoft\Windows Script Host\TrustPolicy, which is a REG_DWORD
value. On Windows XP and Windows 2003, though, things are more complicated.
Under HKLM\Software\Microsoft\Windows Script Host\ you'll find a value
named UseWINSAFER, which is set to 1 by default. This forces WSH to obey
Software Restriction Policy settings instead of the TrustPolicy key. Since
nobody sets up Software Restriction Policies, setting TrustPolicy to 1
or 2 has no effect until you set the UseWINSAFER value to 0. There's another
value on the HKLM side which tells WSH to ignore the HKCU settings and
instead obey HKLM\Software\Microsoft\Windows Script Host\TrustPolicy.
And so on. It's definitely too painful to think about modifying all your
client and server computers but, as I said, "Active Directory to
the rescue!" I've made an ADM template, which you can import into
a Group Policy object and use to push your preferred WSH security settings
out to the world. You can download it from www.scriptinganswers.com/download/adm.zip.
You'll need to modify the GPO editor's Filter options (from the View menu)
to display more than just "managed policies," because these
WSH policies aren't managed (they're referred to as preferences, not policies,
and they remain permanent even if you un-assign the GPO). The template
will let you assign all of the necessary registry keys, and a couple of
other related ones, besides.
With the right WSH TrustPolicy setting in place, scripts will only run
if they're signed. To get your scripts to run, simply sign them using
a digital certificate that's trusted by local computers. This might be
a certificate issued by a commercial CA like VeriSign or Thawte, or one
issued from your internal corporate CA. Until virus authors begin signing
their scripts—thus providing an identity trail back to them—your
scripting environment will be safe and snug.
| Micro
Tip Sheet |
|
Think you can lock down scripting by just deleting
WScript.exe and CScript.exe? Be careful: Those files
are under Windows File Protection (Win2K and newer)
and can be copied back by the operating system during
the next automatic file protection scan.
So maybe you can lock down scripting by disassociating
"VBS," "JS," "WSH," and
other filename extensions from WScript.exe and CScript.exe?
That's a false sense of security: All an attacker has
to do is execute "WScript.exe Anyfile.xxx"
and the script (contained in "Anyfile.xxx")
will happily execute.
Looking for a way to digitally sign scripts? Microsoft
suggests writing a script to do it, which is kind of
cool. You can also use PrimalScript (www.sapien.com),
which has a built-in script-signing tool. In fact, the
latest version can be configured to automatically sign
scripts with a designated certificate every time you
hit "Save," making script signing completely
transparent.
|
|
|
More Resources
Microsoft Scripting Technologies: http://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28001169
Windows Script Host documentation: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/wsoriWindowsScriptHost.asp
My Windows scripting Web site: www.scriptinganswers.com
About the Author
Don Jones is a multiple-year recipient of Microsoft’s MVP Award, and is Curriculum Director for IT Pro Content for video training company Pluralsight. Don is also a co-founder and President of PowerShell.org, a community dedicated to Microsoft’s Windows PowerShell technology. Don has more than two decades of experience in the IT industry, and specializes in the Microsoft business technology platform. He’s the author of more than 50 technology books, an accomplished IT journalist, and a sought-after speaker and instructor at conferences worldwide. Reach Don on Twitter at @concentratedDon, or on Facebook at Facebook.com/ConcentratedDon.