微软发布Windows Defender System Guard运行时认证技术,预期在平台安全方面取得进展 |
来源:聚铭网络 发布时间:2018-04-24 浏览次数: |
信息来源:FreeBuf
上周,微软推出了一项新的 Windows 平台安全技术:Windows Defender System Guard 运行时认证。这项技术主要用于应对软件中的攻击,与 Credential Guard 一样,利用基于虚拟化安全中涉及的源于硬件的安全技术。 微软表示,希望用户能够控制自己的设备,了解设备的安全健康状况。如果重要的安全功能失效,用户可以及时注意到并及时应对。而 Windows Defender System Guard 运行时认证这项新的 Windows 平台安全技术就可以满足这些需求。 在 Windows 10 Fall Creators 更新中,微软工作人员将所有系统完整性功能重新组织到 Windows Defender System Guard 中。内置于核心 Windows 操作系统中的Windows Defender System Guard运行时认证将逐步适用于 Windows 的所有版本。 很多漏洞利用都会针对安全技术发起攻击,以便在相同信任域中运行。例如,特权进程就是用于提供(至少是代码和数据层面的)隔离环境,与普通的用户模式进程隔离开来。NT 内核根据执行进程对象中保存的某些值确定进程是否受到保护,通过内核漏洞或驱动程序(例如 Mimikatz)篡改这些值就能有效地破坏进程保护。因此,将与篡改相关的安全决策移至单独的信任域会增加攻击者的攻击复杂程度。 运行时认证适用于多个场景:
第一阶段的 Windows Defender System Guard 运行时认证将在下一次 Windows 10 更新中推出,为未来的创新奠定基础。这项技术有助于构建新的操作系统功能,以便在系统遭遇完全入侵的情况下(例如通过内核级漏洞利用)检测入侵行为,并有效沟通。 认证与建议信任要在技术层面上引入 Windows Defender System Guard 运行时认证,最好从最明显的层级开始,例如最终可以向依赖方公开的客户端 API。因此,微软也正在开发可使用运行时认证的客户端 API。这个 API 将提供一份运行时报告,详细说明 Windows Defender System Guard 运行时认证时系统的安全状态,具体包括敏感系统属性的运行时间测量。 为了使运行时报告真正实现重要意义,必须以提供合理阻止篡改方案的方式生成运行时报告。这就要求:
运行时认证技术还涉及到 VBS 围圈(enclaves)的概念,VBS 围圈是指基于虚拟化安全的内存中受保护执行区域。在启用虚拟安全模式(VSM)的设备上,采用底层指令集架构(ISA)的虚拟化扩展将会从逻辑上把系统划分为两个(理论上更多)独立的区域:常见的运行 NT 内核的“正常”世界和运行安全内核(SK)的独立’安全’世界。这两个独立区域就称作“虚拟信任级别”(VTL),其中 NT 是 VTL-0,SK 是 VTL-1。 VBS 围圈使得“正常”VTL-0 用户模式过程的孤立部分成为可能。这个孤立部分所有代码和数据都存在于 VTL-1 中。一个围圈内外的事务都通过一个定义良好的、由 VSL 调用(NT 和 SK 用于通信的机制)支持的 API 来完成。结果就是,从 Windows Fall Creators Update(1709)开始,可以在一个区域内执行代码并保存数据,从而导致整个 VTL-0 “正常”模式(包括用户模式和内核模式)在执行过程中和保持在围圈内(在 VTL-1 中)时,不能直接作用于孤立代码和数据。 在 VBS 围圈中,运行时认证组件可以观察并证明报告中包含的一组安全属性。例如,应用程序可以要求 Windows Defender System Guard 从硬件支持的区域测量系统的安全性并返回报告。应用程序可以使用此报告中的详细信息来决定是执行敏感的金融交易还是显示个人信息。 VBS 围圈还可以暴露由特定 VBS 签名密钥签署的围圈认证报告。如果 Windows Defender System Guard 可以获得主机系统在 VSM 处于活动状态下运行的证据,则可以使用此证明和签署的会话报告来确保特定围圈正常运行。 至于运行时报告本身的签名,会在围圈内生成一个不对称的公私密钥对。公钥由 Windows Defender System Guard 证明服务后端签署以创建会话证书。此外,Windows Defender System Guard 证明服务后端会生成一个签名的会话报告,其中包含有关计算机的详细信息。这些详细信息包括启动安全属性,包括启用安全启动的计算机是否启动,以确保核心操作系统未被越狱或篡改。最后,运行时报告由配对的私钥在本地签名,该私钥永远不会离开围圈。依赖方可根据会话证书验证报告签名、确保以 Microsoft CA 为根的证书签名有效,进而轻松验证运行时和会话报告。 因此,建立必要的信任以确保运行时报告的真实性,需要以下信息:
围圈与 Windows Defender System Guard 认证服务之间的网络调用都来自 VLT-0。同时,认证协议能够确保即使在不可信的传输机制下也能够抵御篡改。 在充分建立上述信任链之前,需要许多基础技术。为了让依赖方了解自己可以获取运行时报告中信任级别的任何特定配置,每个 Windows Defender System Guard 证明服务签名的会话报告都会分配到一个安全级别。安全级别反映了平台上启用的底层技术,并根据平台的功能确定信任级别。微软工作人员正在将各种安全技术的实现映射到安全级别中,并在发布 API 供第三方使用时分享这一技术。最高级别的信任至少需要以下功能:
测量会话报告中的安全级别本身就是一个重要而有趣的指标。而 Windows Defender System Guard 可以提供更多功能,对于运行时测量系统安全状态尤其有效。 我们称这个运行时间测量组件为“断言引擎”,是在运行时不断测量(“断言”)系统完整性,证明启动时安全态势的安全级别。 一些注意事项: A. “断言”引擎在设计时考虑了理想的系统配置(即具有最高安全级别的系统配置); 在安全级别最低的情况下,业务需求需要 Windows Defender System Guard 运行时认证才能在系统上运行;在这种情况下,Windows Defender System Guard 运行时认证无法确保效果,并且可以充当非锁定 Windows 版本上其他安全产品的信号; B. 在运行理想配置时,由于虚拟机监控程序代码完整性(HVCI)和强制的内核模式代码完整性(KMCI)限制,非 ROP 内核模式代码执行很困难;在这种情况下:
C. 微软正在努力突破(当前)操作系统设计的限制; 微软的多个团队在合力研究改善 System Guard 运行时认证和核心内核安全功能。在当前版本的操作系统中,主要依靠 NT 内核线程管理和获取到的安全内核原语。 Windows Defender System Guard 运行时认证体系结构的高级概览 在架构上,这个解决方案统称为 Windows Defender System Guard 运行时监视器,由以下客户端组件组成:
为了快速响应威胁,微软选择了一种动态脚本方式,以便经常发布更新。此外,微软还采用了一个满足成熟度、占用空间和性能要求的开源库。此脚本组件构成了在 VTL-1 中执行的断言引擎核心。 如果不能以任何方式与系统进行交互,在此引擎中运行任意逻辑将不会有效。为了让引擎执行有用的工作,可以通过“助手”的形式提供本地帮助。这些协助通过代理服务或内核模式代理在 VTL-0 中执行。 在 Windows 的下一次更新中,断言逻辑通过带内传送的(在签名引擎 DLL 内部)。未来,这些脚本可以实现带外传递,这也是设计的核心部分。这有助于迅速响应安全事件(例如,发现新的攻击不变量),而无需通过服务交付组件更新。应用程序和服务可以利用这种认证技术来确保系统不受篡改,并且让关键流程按照预期运行。这种基于硬件的“健康证明”可用于识别受感染的机器,或识别对关键云服务的访问。运行时认证可用作各种高级安全应用程序的平台。 新技术推动新安全进展微软认为,通过现代硬件和适当的安全策略,可以显著提高锁定平台的安全性。在直接特权代码执行难以实现的当代,将会有越来越多的攻击行为利用数据损坏发起入侵。在当前的模型中,瞬间变化也是一个挑战。但是,未来的创新将导致持久性更难实现,短暂的恶意变化也更加困难。Windows Defender System Guard 运行时认证技术致力于不断提升整个 Windows 10 安全堆栈的防御能力,从而让攻击者更改系统、影响安全状态的行为更容易检测。换句话说,运行时认证更多的是检测可能代表着攻击行为的微小痕迹,而不是寻找明显的信号。 微软对这项新技术充满期待,认为这项技术有可能在平台安全方面取得重大进展。更多细节将会陆续发布。 |