自从2006年年底PowerShell发布以来,微软在安全和脚本方面并没有取得很好的名声。毕竟那个时候,**VBScript和Windows Script Host(WSH)**是两个最流行的病毒和恶意软件的载体,它们经常成为臭名昭著的“I Love You“ "Melissa"等其他病毒的攻击点。当PowerShell团队宣布他们创造了一种新的、能提供前所未有强大的功能与可编程能力的命令行Shell语言时,我们认为,警报来临,人们将对这种新的命令行Shell避之不及。但是,没关系。Power Shell时在比尔·盖茨先生在微软发起的一个“可信赖计算计划”之后才进行开发的。
我们需要明确,当谈及安全时,PowerShell会做什么,又不会做什么;最好的办法是列出一些PowerShell的安全目标。首先,PowerShell不会给被处理的对象任何额外的权限。也就是说,PowerShell仅会在你已拥有的权限主体下处理对象。其次,PowerShell无法绕过既有的权限。比如,想为你的用户部署某个脚本,并希望该脚本能完成某些操作——正常情况下这些用户会由于权限不足无法完成的某些操作,那么该脚本同样不能运行。如果希望用户可以完成某些操作,那么必须给他们赋予对应的权限;PowerShell仅能完成这些用户凭借现有权限执行命令或者脚本可以完成的工作。PowerShell的安全并不是针对恶意软件的防护。一旦在你的系统上存在恶意软件,那么恶意软件可以做你权限范围内的任何事情。它可能使用PowerShell去执行一些恶意命令,也有可能非常轻易地使用多种其他技术损坏你的电脑。一旦在你的系统中存在恶意软件,那么你就被”挟持“了。当然,PowerShell也并不是第二道防御系统。此时,首先你需要杀毒软件来阻止恶意软件进入你的系统。对大部分人而言,可能忽略这样的一个重要概念:即使恶意软件可能借助PowerShell去完成一些危害行为,也不应该将恶意软件问题归咎于PowerShell。杀毒软件必须阻止恶意软件运行。再次申明,PowerShell设计出来并不是为了保护一个已经受损的系统。
PowerShell中第一个安全措施是执行策略。执行策略是用来管理PowerShell执行脚本的一种计算机范围的设置选项。该策略主要用作防止用户被注入,从而执行一些非法脚本。
默认设置是Restricted,该策略会阻止正常脚本的运行。也就是说,默认情况下,你可以使用PowerShell进行交互式执行命令,但是你不能使用PowerShell执行脚本。如果你尝试执行脚本,你会得到下面的错误。
无法加载文件 C:\test.ps1,因为在此系统中禁止执行脚本。有关详细信息,请参阅”get -help about_signing"。
所在位置 行:1 字符:11
+ .\test.ps1 <<<
+ CategoryInfo : NotSpecified: (:) [], PSSecurityException
+ FullyQualifiedErrored :RuntimeException
你可以通过Get-ExecutionPolicy命令来查看当前的执行策略。另外,如果你想修改当前的执行策略,可以采用下面3种方式之一。
我们将该策略设置为”启用“的状态。当通过组策略对象来配置时,组策略中的设定会覆盖本地的任何设置值。实际上,如果你试图运行Set-ExecutionPolicy,命令可以正常执行,但是会返回一个警告。该警告会告知由于组策略覆盖的原因,新修改的设定值不会生效。如图所示。
通过手动运行PowerShell.exe,并且给出-ExecutionPolicy的命令行开关参数。如果采用这种方式,那么命令中指定的执行策略会覆盖本地任何设置和组策略中的设置值。你可以将执行策略设置为5种值(请注意:组策略对象中包含下面列表重点3个选项)。
Restricted——这是默认选项,除微软提供的一部分配置PowerShell的默认选项的脚本外,不允许执行其他任何脚本。这些脚本中附带微软的数字签名。如果修改这些数字签名,那么这些脚本就再也无法运行了。
AllSigned——经过受信任的证书颁发机构(CA)设计的数字证书签名后的任意脚本,PowerShell均可执行。
RemoteSigned——PowerShell可以运行本地任何脚本,同时也可以执行受信任的CA签发的数字证书签名之后的原创脚本。”远程脚本“是指存在于远端计算机上的脚本,经常通过通用命名规则(UNC)方式访问这些脚本。我们也会将来自于网络上的脚本称为”远程脚本“。
Unrestricted——可以运行所有脚本。我们并不是很喜欢或不建议使用这个设置选项,因为该设置选项无法提供足够的保护功能。
Bypass——这个特殊的设定主要是针对应用程序开发人员,他们会将PowerShell嵌入到他们的应用程序中。这个设定值会忽略已经设置好的执行策略,应当仅在主机应用程序提供了自身的脚本安全层时才使用该选项。你最终告诉PowerShell的是“别担心,安全问题我已经全部搞定”。
**微软强烈建议在执行脚本时使用RemoteSigned执行策略,并且仅在需要执行脚本的机器上采用该策略。**根据微软的建议,其他计算机应当继续保持Restricted的执行策略。RemoteSigned策略在安全性和功能之间取得了较好的平衡;AllSigned相对更严格,但是它要求所有脚本都需要被数字签名。
**注意:**多个专家,包括微软的一些开发人员,都建议使用Unrestricted作为执行策略。他们觉得该功能并没有提供一个安全层,并且你也不应该相信该设置可以将任何危险的行为隔离开。
数字代码签名,简称为代码签名,是指将一个密码签名应用到一个文本文件的过程。签名会显示在文件末端,并且类似下面的形式。
<!-- SIG # Begin signature block -->
<!-- MiIXXAYJKoZIhvcNAQ.......... -->
<!-- ............................ -->
.....
<!-- SIG # End signature block -->
签名中包含了两部分重要信息:一是列出了对脚本签名的公司或者组织;二是包含了对脚本的加密副本,并且PowerShell可以解密该副本。在创建一个数字签名之前,你需要拥有一个代码签名的证书。这些证书也被称为第三类证书。这些证书均由商业CA签发,比如Cybertrust、GoDaddy、Thawte、VeriSign等公司。当然,如果可能的话,你也可以从公司的公钥基础设施(PKI)中获取到该证书。正常情况下,第三类证书仅会签发给公司或者组织,而不会发给个人。当然,在公司内部可以签发给个人。在签发证书之前,CA需要验证接收方的身份——证书类似一种数字识别卡,该卡上列出了持有者的姓名以及其他详细信息。比如,在签发证书给XYZ公司之前,CA需要验证XYZ公司的授权代表人提交了该请求。在整个安全体系中,验证过程是其中最重要的环节,你应当仅信任能出色完成验证申请证书的公司身份工作的CA。如果你对一个CA的验证流程不熟悉,那么你不应该信任该CA。 应当在Windows的IE属性控制面板(也可以在组策略中配置)中配置信任关系。在该控制面板中,选择Content标签页,然后单击Publishers按钮。在弹出的对话框中,选择“受信任的根证书颁发机构”标签页。如图所示,你可以看到计算机信任的CA列表。
当你信任一个CA之后,你也会信任该CA签发的所有证书。如果有人使用一个证书对恶意脚本进行签名,那么你可以通过该证书去查找该脚本的作者——这也就是为什么已签名的脚本相对于未签名的脚本更加值得“信任”。但是如果你信任一个无法很好验证身份的CA,那么一个恶意脚本的作者可能会获取一个虚假的证书,这样就无法使用该CA的证书去做追踪。这也就是为什么选择一个受信任的CA是如此重要。
一旦你获取了一个三级证书(具体而言,你需要一个包装为带有验证码的证书——通常CA会针对不同的操作系统以及不同的编程语言提供不同的证书),之后将该证书安装到本地计算机。安装之后,你可以使用PowerShell的Set-AuthenticodeSignature Cmdlet将该数字签名应用到一段脚本。如果需要查看更详细的信息,你可以在PowerShell中执行Help About_Signing命令。许多商业的脚本开发环境(PowerShell Studio、PowerShell Plus以及PowerGUI等)都可以进行签名,甚至可以在你保存一段脚本时进行自动签名,这样是的签名过程中更加透明。
签名不仅会提供脚本作者的身份信息,也会确保在作者对脚本签名之后,不会被他人更改。实现原理如下。
(1)脚本作者持有一个数字证书,该密钥包含两个密钥:一个公钥、一个私钥。
(2)当对脚本进行签名时,该签名会被私钥加密。私钥仅能被脚本开发者访问,同时仅有公钥能对该脚本进行解密。在签名中会包含脚本的副本。
(3)当PowerShell运行该脚本时,它会使用作者的公钥(包含在签名中)解密该签名。如果解密失败,则说明签名被篡改,那么该脚本就无法被运行。如果签名中的脚本副本与明文文本不吻合,那么该签名就会被识别为损坏,该脚本也无法被允许。
当执行脚本时,PowerShell处理的整个流程如下图所示。
PowerShell包含另外两种总是一直有效的重要安全设置。一般情况下,它们应该保持默认值。首先,Windows不会将PS1文件扩展名(PowerShell会将PS1识别为PowerShell的脚本)视为可执行文件类型。双击打开PS1文件,默认会使用记事本打开进行编辑,而不会被执行。该配置选项会保证即使PowerShell的执行策略允许执行该脚本,用户也不会在不知晓的情况下运行某段脚本。
其次,在Shell中不能通过键入脚本名称执行该脚本。Shell不会在当前目录中搜索脚本,也就是说,如果有一个test.PS1的脚本,切换到该脚本路径下,键入test或者test.PS1都不会运行该脚本。比如下面的例子。
PS C:\> test
无法将“test"项识别为Cmdlet、函数、脚本文件或可运行程序的名称。请检查名称的拼写,如果包括路径,请确保路径正确,然后重试。
所在位置行:1 字符:5
+ test<<<
+ CategoryInfo : ObjectNotFound: (test:String) [], CommandNotFoundException
+ FullyQualifiedErrorId :CommandNOtFoundException
suggestion [3,General]:未找到命令test,但它确实存在于当前位置。Windows PowerShell默认情况下不从当前位置加载命令。如果信任此命令,请改为键入 ”.\test"。有关更多详细
信息,请参阅“get-help about_Command_Procedence"。
PS C:
如你所见,你可以发现,PowerShell会检测该脚本,但是会给出警告信息:必须通过绝对路径或者相对路径来运行该脚本。因为test.PS1脚本位于C:目录下,所以你可以键入C:\test(绝对路径)或者运行.\test(指向当前路径的相对路径)。
该安全功能的目的是为了防止成为”命令劫持“的攻击类型。在该攻击中,它会将一个脚本文件放入到一个文件夹中,然后将它命名为某些内置的命令名,比如Dir。在PowerShell中,如果你在一个命令前面没有加上路径——比如运行Dir命令,那么你很明确运行的这个命令的功能;但是如果运行的是.\Dir,那么你就会运行一个名为Dir.PS1的脚本。
PowerShell的安全主要是在于防止用户在不知情的情况下运行不受信任的脚本。没有什么安全措施可以阻止用户向Shell手动键入命令或者拷贝一个脚本的全部内容,然后粘贴进Shell中(尽管以该种方式运行脚本,可能不会有相同的作用)。恶意脚本很难让用户去手动执行,以及指导用户如何去做,这也就是为什么微软并没有将该种场景作为一个潜在的攻击因素。但是请记住,PowerShell并不会给与用户额外的权限——用户仅能做权限允许的事情。某些人可能会通过电话联系用户或者发送邮件方式,让用户打开PowerShell程序,然后键入一些命令,最后损坏他们的 计算机。但是这些人也可以不通过PowerShell而是其他方式去攻击某些用户。说服一个用户打开资源管理器,选择Program Files文件夹,然后按键盘上的Delete键是非常容易的(当然, 视你自己的真实情况,也可能比较困难)。在某些方面,比起让用户执行相同功能的PowerShell命令,这会更加容易。指出这一点,是因为人们总是倾向于对命令行以及其看起来具备无限多功能以及功能延伸到焦虑不安,但是事实上,你和你的用户如果通过其他方式无法完成某些工作,那么在PowerShell中你也是无法完成的。
微软建议针对需要运行脚本的计算机,将PowerShell的执行策略设置为RemoteSigned。当然,你也可以考虑设置为AllSigned或者Unrestricted。AllSigned选项相对来说可能比较麻烦,但是如果采用了下面两条建议,那么该选项会变得更加方便。
不太建议去修改.PS1文件名的关联性。曾经有人修改了Windows的一些设置,将.PS1视为一种可执行文件,也就意味着,你可以通过双击一个脚本来执行它。如果采用这样的方式,那么我们就回到使用VBScript时的糟糕日子,所以你需要避免该问题。