将MSI伪装成JAR绕过数字签名验证（CVE-2020–1464）-安全客

前言

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等也存在类似的方法。还需要进一步研究，以查看其他代码签名方案中是否存在类似的问题。