已遭利用的微软0day CVE-2020-1464,原来是两年前的老相识

 聚焦源代码安全,网罗国内外最新资讯!

编译:奇安信代码卫士团队

在本月补丁星期二中,微软修复了一个已遭利用的 0day 漏洞 CVE-2020-1464。它可导致MSI 文件被转换为恶意的 Java 可执行文件,同时保留公司的合法数字签名。

代码签名是指使用基于证书的数字签名来签名可执行文件和脚本,验证作者的身份并确保该代码自作者签名起并未遭修改或损坏。

微软将该漏洞称为欺骗漏洞,是由 Windows 不正确地验证签名文件导致的,“攻击者如成功利用该漏洞,可绕过安全特征,不正确地加载已签名文件。在攻击场景中,攻击者能够绕过旨在阻止加载不正确签名文件的安全特征”。微软证实称该漏洞已遭利用。

随后,Zengo 公司的安全研究员 Tal Beery SafeBreach 实验室的研究员 Peleg Hadar 发布博客文章指出,实际上微软早在2018818日就获悉该漏洞(他们将该漏洞称为 GlueBall),当时的决定是不修复。最近,又有研究员在20206月发布 Security-in-bits 博客文章指出,有恶意软件滥用了该弱点。

已遭利用的微软0day CVE-2020-1464,原来是两年前的老相识_第1张图片

已遭利用的微软0day CVE-2020-1464,原来是两年前的老相识_第2张图片

已遭利用的微软0day CVE-2020-1464,原来是两年前的老相识_第3张图片

早在2018年就已检测出

20191月,谷歌旗下VirusTotal 公司的研究员 Bernardo Quintero披露称2018年,恶意签名的 Java 可执行文件如何被上传到 VirusTotal Monitor 服务且被检测到(59个引擎中的28个检测到)、他分析后发现该 .jar 文件是一个 MSI 文件,且其尾部附加了一个 Java JAR 文件。尽管该 MSI 文件遭篡改并被更名为一个 JAR 文件,但问题在于,Windows 仍然认为该文件是由源自谷歌的一个合法证书签名的。

已遭利用的微软0day CVE-2020-1464,原来是两年前的老相识_第4张图片

已遭利用的微软0day CVE-2020-1464,原来是两年前的老相识_第5张图片

由于某些安全解决方案使用数字签名来判断未知文件是否应运行,因此威胁者可以使用这种技术创建 Java 恶意软件,绕过安全软件。发现这个缺陷后,Quintero 负责任地在2018818日将其告知微软,但微软表示不会修复。

Quintero 指出,“这个攻击向量已在 Windows 10 的最新更新版本以及可用 Java 版本中得到验证(Windows 10 版本1809 Java SE RuntimeEnvironment 8 Update 191)。微软虽然已证实问题存在,但表示将不在当前的 Windows 版本中修复该问题,并同意我们公开这个案例和研究成果。”

为了检测到这种类型的恶意 JAR 文件,VirusTotal 在分析中增加了对这些已遭篡改文件的检测,SysInternal 的签名检查工具也被上传到引擎。

发布补丁后,如果 MSI 文件已遭附加的 JAR 文件篡改,则微软不再认为MSI 文件已签名。我们查看 Windows 1909(图左)和 Windows 10 2004(图右)中使用该技术的恶意 JAR 文件属性时,就会看到微软的修复方案。BleepingComputer 测试认为该安全更新仅仅是删除了由 JAR 文件修改的 MSI 文件上的数字签名。

 

已遭利用的微软0day CVE-2020-1464,原来是两年前的老相识_第6张图片

如果在 MSI 文件后面附加一个 .exe 可执行文件,MSI 的签名仍然是有效的,则表明签名并未被修改。2019年,Chronicle 公司曾表示由于只有 JAR 文件能利用这个问题,因此它并不算缺陷,“截至目前来看,这种技术极其少见。当你在 MSI 末尾附加任何东西时,在这个案例中,只有 JAR 将以原博客文章所述方式执行。”

至于微软为何花了两年的时间才修复这个已遭利用的问题,微软并未正面回应,只是表示应用了最新安全更新的用户免受该攻击。目前也不清楚为何微软未将Quintero 列为漏洞发现者。

MSI 文件为何会遭篡改

鉴于 MSI 文件的读取方式,我们可以在不对签名进行验证的情况下篡改 MSI 文件。

Tal Beery 表示,当 Windows 读取 MSI 文件时,它会从文件开头开始读取,一直到有效的 MSI 签名末尾结束并舍弃其它部分。因此在检测到合法的 MSI 文件结构后,它会忽略被附加的数据,而不管它是什么。

2019年报道的那样,JAR 文件只不过是 ZIP 文件,并且在执行时由 Java 运行时从文件末尾开始读取,直到检测到有效 ZIP 文件结构的开头为止,然后它将丢弃文件的其余部分。

已遭利用的微软0day CVE-2020-1464,原来是两年前的老相识_第7张图片

Windows 开始从开头读取而 JAVA 从末尾读取时,它允许 Windows 操作系统将 JAR 文件看作是合法签名的文件。

同时,JAVA 从末尾开始读取 JAR 文件并丢弃其余部分。

如此,我们就知道恶意行动者如何创建恶意 JAR 文件同时欺骗公司的合法数字证书。

相关博客文章请见:

https://www.securityinbits.com/malware-analysis/interesting-tactic-by-ratty-adwind-distribution-of-jar-appended-to-signed-msi/

https://medium.com/@TalBeerySec/glueball-the-story-of-cve-2020-1464-50091a1f98bd

推荐阅读

微软补丁星期二修复120个漏洞,含2个已遭利用的 0day

已遭利用的Windows 0day漏洞 CVE-2020-1380分析

原文链接

https://www.bleepingcomputer.com/news/security/microsoft-fixes-actively-exploited-windows-bug-reported-2-years-ago/

https://krebsonsecurity.com/2020/08/microsoft-put-off-fixing-zero-day-for-2-years/comment-page-1/

题图:Pixabay License

本文由奇安信代码卫士编译,不代表奇安信观点。转载请注明“转自奇安信代码卫士 www.codesafe.cn”。

奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的

产品线。

    觉得不错,就点个 “在看” 吧~

你可能感兴趣的:(安全,微软,信息安全,jvm,xss)