将MSI伪装成JAR绕过数字签名验证(CVE-2020–1464)

阅读量    159500 |

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

前言

Google的VirusTotal发表了一篇博客文章,介绍了一种通过JAR文件绕过Windows代码签名的新方法:

将任何内容附加到由任何软件开发人员签名的Windows Installer(.MSI)文件的末尾之后,Microsoft Windows任然认为Authenticode签名有效。攻击者可以利用此行为来绕过某些依赖Microsoft Windows代码签名来确定文件是否受信任的安全解决方案。当附加的代码是恶意的JAR时,这会非常危险,因为生成的文件具有有效的签名,并且该恶意软件可以由Java直接运行。

简而言之,攻击者可以将恶意JAR附加到由受信任的软件开发者(例如Microsoft Corporation,Google Inc.或任何其他知名开发者)签名的MSI文件中,然后可以将文件重命名为jar文件,这样它的签名依旧是生效的。 例如,通过命令“copy /b signed.msi + malicious.jar signed_malicious.jar”,之后双击该文件即可感染受害者。

 

ZIP和EXE文件如何合并?

首先,Windows和Java都可以执行相同的文件吗?窍门在于Windows可执行文件的工作方式-如Microsoft文档中所述。操作系统从头开始读取文件,先查看“ MZ”头,然后是文件内容。我们将假设文件中存在一个表,该表告诉读者每个段的长度,因此可以将任意数据附加到文件的末尾而不会导致程序崩溃。

但是,JAR文件本质上是一个ZIP文件。 ZIP文件的索引或中央目录位于文件的末尾,并且可以在文件的开头添加数据,还能保证该文件仍然有效。这意味着您可以组合从头开始读取的Windows可执行文件,并依靠其标头和表来告诉读者在哪里停止,并对文件末尾添加ZIP内容,这样将其合并在一起时数据任然有效。同样,虽然VirusTotal提供的示例是一个JAR文件,但同样的技巧也适用于其他基于ZIP的格式,例如Microsoft Office(DOCX / XSLX / etc),OpenOffice(ODT / ODS / etc)等。当然,这些假设是基于这些软件读取的是ZIP的中央目录,并且不检查magic number。

这是Wikipedia的PE文件的修改示例,以及OASIS的ZIP文件示例,显示了读取文件内容的方向:

 

什么是Microsoft代码签名和Authenticode?

Authenticode是代码签名技术,Microsoft将其用于Windows可执行文件,驱动程序和其他文件。目的是确保文件源自受信任的发布者。 Windows中还包含一个称为“ SignTool”的命令行工具,该工具用于签名和验证文件。

此处的Microsoft技术文档中描述了代码签名的工作方式。它实质上是使用PCKS7和特殊X.509证书(由CA颁发的代码签名证书)的数字签名。它与SSL证书连接到相同的PKI基础结构,并且在颁发证书时(不是在签名时)由CA进行了一些附加检查。像所有其他数字签名一样,它本质上是由证书持有者的私钥签名的某种哈希,然后由X.509证书中的公钥进行验证。就像SSL一样,证书本身也已通过公共PKI基础结构进行了验证。

示例如下(来自Microsoft文档):

 

绕过代码签名

在标准的数字签名方案(例如PGP或S / MIME)中,使用SHA之类的函数对消息的整个内容进行哈希处理以生成消息摘要。 然后使用发件人的私钥对该哈希进行数字签名。 请注意,整个消息都是经过哈希计算的,这使接收方可以检查消息是否被修改。

要保证安全性,要注意的事情是“别自己实现加密算法”,在这种情况下,这包括选择要散列的内容。 对于Authenticate,似乎文件哈希不能覆盖整个文件。 如本文档所述,文件末尾(图片“remaining content”之后)的信息不包括在哈希中:

最后一节末尾的信息(由最高偏移量定义)不会被散列。该区域通常包含调试信息。调试信息通常可以认为是调试器的建议。它不会影响可执行程序的实际完整性。在交付产品之后,删除调试信息是完全有可能的,并且不会影响程序的功能。实际上,有时这是节省磁盘的措施。值得注意的是,要保证Authenticode签名有效,则不能删除PE映像指定节中包含的调试信息。

 

总结

这意味着简单地将另一个文件(如JAR)附加到另一个经过数字签名的文件的末尾,然后将其重命名为JAR并使结果文件在Windows中看起来是有效的,因为数字签名检查不会读取到JAR文件处,将其作为校验的一部分。同时,该文件将可由Java执行,因为它将从末尾开始读取,而忽略开头出现的任何已签名内容。同样适用于其他基于ZIP的格式,例如Microsoft Word,这可能使攻击者在伪装合法文件的同时发送恶意文件。此外,从博客文章中可以看出,某些视音频和安全产品使用Authenticode签名作为验证文件的快捷方式,因此无需扫描文件。

此技术的另一种可能用途是误导分析人员,让其而没有意识到是一个恶意软件。

另一个想法是使用此技巧,通过将多余的数据放在文件末尾来从内网向外传输数据。这假设DLP和类似的监视出站流量的工具也依赖于Authenticode签名。

并非只有Microsoft的代码签名方法。 Java,Adobe AIR,Android,MacOS,Debian等也存在类似的方法。还需要进一步研究,以查看其他代码签名方案中是否存在类似的问题。

 

其他信息

这篇文章是19年的文章,但最近又被爆出来,微软给这个漏洞分配为CVE-2020–1464。

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多