欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

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

来源:本站整理 作者:佚名 时间:2019-01-24 TAG: 我要投稿

一、概述
长期以来,我非常热衷于探讨应用程序控制/应用程序白名单(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配置/实施方案,以及此前公开的绕过技术。

[1] [2] [3] [4] [5]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载