0day! 0day！Windows 7 和 Windows Office 均被曝 0day

作者：Catalin Cimpanu 和 Tara Seals

编译：360代码卫士团队

谷歌表示，上周修复的 Chrome 0day 漏洞实际上是和影响微软 Windows 7 操作系统的 0day 共同遭利用的。而在 RSA 2019 大会上，Windows Office 也被曝 0day。

Windows 7 被曝 0day

这两个 0day 漏洞是谷歌威胁分析团队 Clement Lecigne 在2月27日发现的网络攻击中的一部分。攻击者结合使用 Chrome 0day 和 Windows 7 0day 漏洞执行恶意代码并接管受影响系统。

谷歌在刚刚发布的博客文章中披露了这些攻击的实际严重程度。谷歌表示微软正在准备修复方案，但并未给出时间轴。

在昨天发布的文章中提到谷歌发布 Chrome 72.0.3626.121 是为了修复存在于 Chrome FileReader 中的 0day 漏洞 (CVE-2019-5786)。该 web API 允许网站和 web  应用读取存储在用户计算机上的文件内容。

不过除此之外，谷歌并未提供更多详情。

Windows 7 被曝 0day，需升级至 Windows 10

谷歌发表博客文章表示，Windows 7 “win32k.sys 内核驱动中存在一个本地权限提升漏洞，可被用于安全沙箱逃逸。该漏洞是 win32k!MNGetpltemFromIndex 中的一个空解指针引用，在一定的条件下被 NtUserMNDragOver() 系统调用所调用。”

谷歌表示，由于 Windows 8 及后续版本的安全性已加固，该 0day 漏洞仅可在 Windows 7中被利用。Lecigne 表示，“截至目前，我们仅观察到 Windows 7的32位系统遭利用。”

Lecigne 表示，谷歌决定公开这个 Windows 0day 的原因是，他们认为 Windows 7 用户应该意识到正在进行的攻击活动并采取防御措施，以防攻击者结合使用该 Windows 7 0day漏洞和其它浏览器上的其它利用代码。

也就是说，即使用户正确应用了最新的 Chrome 版本，Windows 用户仍然受影响。

安装 Chrome 更新的正确方式

谷歌 Chrome 桌面版本的工程负责人Justin Schuh 表示，“最新的这个利用的不同之处在于，起初的链直接攻击 Chrome 代码，因此要求用户在下载更新后重启浏览器。对于多数用户而言，更新是自动下载的，但需要手动操作才能重启。”

简言之，如果是插件组件，那么 Chrome 会分别自动更新；但如果浏览器代码需要刷新，那么在多数情况下手动重启才会奏效。也就是说，如果你的 Chrome 版本如下所示，那么仅仅应用最新的修复方案是不够的，必须重启才奏效。

Windows Office 也被曝 0day，微软不打算立即修复

研究人员在 RSA 2019安全大会上公开了微软 Office 中的一个 0day 漏洞，它可被用于绕过安全解决方案和沙箱。

Mimecast 公司的安全研究人员表示，这个 bug 存在于 OLE 文件格式中以及微软 Word 处理它的方式中。他们注意到，OLE32.dll 库不正确地处理了整数溢出。

微软表示将搁置该漏洞。

研究人员表示，该缺陷允许攻击者将利用代码以不会触发多数杀毒软件解决方案的方式隐藏在武器化的 Word 文档中。他们在最近的一次垃圾邮件活动中发现 Word 附件中隐藏着针对微软Equation 编辑器中的一个老旧漏洞 (CVE-2017-11882) 的利用。在未修复的系统上，该利用能够释放 Java JACKSBOT 的新变体。Java JACKSBOT 是一个远程访问后门，在安装 Java 的前提下能够感染目标。

JACKSBOT 能够完全控制受攻陷系统。它具有完整服务的间谍能力，包括收集按键、窃取缓存密码并从 web 表中抓取数据、截屏、从摄像头中拍照并记录视频、记录麦克风声音、传输文件、收集通用系统以及用户信息、窃取密币钱包的密钥、管理安卓设备的 SMS以及窃取 VPN证书。

研究人员表示，“对于我而言，最引人注目的是，攻击者集中于利用 Equation 利用代码，很可能是因为他们认为它更为可靠，因此创建绕过以避免被检测到。这个进程利用了一个代码执行利用和导致绕过的缺陷，我们在数据格式的利用代码中并未看到太多案例。”

深入分析

OLE Compound File 实际上是出现在 Word 文档中的信息和对象的底层文件系统。它包含的数据流被当做内嵌在 OLE 文件中的单个文件处理。每个流都具有名称（例如，文档中的顶级流直接被命名为“WordDocument”）。流也可包含文件中的宏信息以及文档的元数据（例如主题、作者、创建日期等）。

Mimecast 表示，Compound File Binary File Format 的格式标准规定，OLE 流头部中包含了一个名为 DIFAT 的表，由多个数组组成，其中包括扇区 ID 和某些特殊号码——而这也是问题所在。

研究人员表示，“要访问表中的扇区D，它通过如下公式计算偏移量：扇区大小*（扇区 ID +1）”。当扇区 ID 是 DIFAT[N] 时，似乎存在一个大的扇区ID 时，这个公式会导致整数溢出，从而导致偏移较小。因为结果超过32位（整数溢出），所以当上面的代码执行计算时，只有最低的32位是产品。换句话说，计算的偏移量将是 0×200 =512。”

研究人员表示，系统出现了一个不可能的偏移，导致其崩溃或者该部分遭忽视，其中包括可能隐藏的利用代码。

研究人员表示，微软并未记录这种行为，但它可能会混淆高级解析器，而这些解析器并不会注意到溢出。

在野利用

研究人员表示，几个月来已经发现多起攻击串联使用 CVE-2017-11882 和 OLE 缺陷且均成功放大攻击，从而未被检测到。

研究人员表示，“我们的系统能够检测到一个似乎来自塞尔维亚的攻击者团伙使用特殊构造的Word 文档，导致攻击者绕过很多旨在保护数据免遭感染的安全解决方案。”但该公司并未具体说明这些安全解决方案是什么。

研究人员表示，“结合使用这个老旧利用代码和这个整数溢出漏洞，Word 错误地处理该错误，它忽视了 OLE 扇区 ID 的更高字节，将恶意对象 (CVE-2017-11882) 加载到内存中，而没有遵循正确的指南。”

研究人员表示，尽管该漏洞已遭在野利用，“但利用它并不容易，因为它要求对格式有深入的了解。”微软不打算立即修复可能也是基于此。

微软回应

尽管有证据表明该漏洞正在遭利用，但微软安全响应中心表示，将不会很快修复它，因为问题本身并不会造成内存损坏，因此不符合立即修复的安全界限。

研究员表示，“微软认为这是一种预期之外的行为，但与此同时还不够直接修复的门槛。实际上，微软需要对补丁工作作出优先级排序，因此这样做也合情合理。尽管如此，安全专业人员需要确保系统是最新状态，他们需要利用威胁情报更好地管理不断变换的威胁局势。”

研究人员表示还提供了一种底线评估“分析这类缺陷的所有可能结果并非易事。Mimecast 和微软安全响应中心合作，而且他们并未分析到所有可能的结果，认为不会造成任何内存损坏。因此，虽然这个缺陷并不严重，但成为攻击者绕过安全解决方案的另外一个工具并非好事。”

微软回应称，不在近期修复的原因是该缺陷的严重程度不符合严重性边界标准。