MS13-098：增强Authenticode安全性的更新
今天，我们发布了MS13-098安全更新，该更新加强了Authenticode代码签名技术，防止对已签名二进制文件进行修改而不使签名失效。此更新解决了一种特定的恶意二进制修改实例，该修改可能允许篡改后的二进制通过Authenticode签名检查。更重要的是，它还引入了进一步的加固措施，如果二进制文件的特定部分被修改，则将该二进制视为“未签名”。如下所述，这些对Authenticode签名验证的改进需要一小部分但重要的第三方应用程序开发者进行更改，因此新流程今天不会默认启用。从今天起六个月后，即2014年6月10日，不符合新验证流程的二进制将被视为未签名。如果您想立即启用注册表键并测试更改，请参阅安全公告2915720中发布的信息。
我们希望通过这篇博客文章分享更多关于Authenticode及其在增强客户对从互联网下载的可执行文件的信心方面的作用。
Authenticode和签名二进制
Authenticode®是一种数字签名格式，用于确定软件二进制的来源和完整性。Authenticode基于公钥密码标准（PKCS）#7签名数据和X.509证书，将Authenticode签名的二进制绑定到软件发布者的身份。
Authenticode背后的理念是利用软件开发人员或公司的声誉来帮助客户做出信任决策。如果您信任某家公司，您可以从任何来源和媒体执行由该公司发布的二进制文件，只要该二进制文件使用该公司的有效Authenticode签名进行签名。有效的Authenticode签名并不保证软件运行安全，但它确实证明该二进制文件已由特定公司签名，并且此后未被更改。根据Authenticode便携式可执行文件格式规范，Authenticode签名可以“嵌入”在Windows PE文件中，位置由可选头数据目录中的证书表条目指定。当使用Authenticode对Windows PE文件进行签名时，计算文件Authenticode哈希值的算法会排除某些PE字段。在将签名嵌入文件时，签名过程可以修改这些字段而不影响文件的哈希值。这些字段如下：校验和、证书表RVA、证书表大小和属性证书表。证书表包含一个PKCS #7 SignedData结构，其中包含PE文件的哈希值、由软件发布者的私钥创建的签名，以及将软件发布者的签名密钥绑定到法律实体的X.509 v3证书。PKCS #7 SignedData结构可选包含：
- 软件发布者的描述
- 软件发布者的URL
- Authenticode时间戳
以下示意图说明了Authenticode签名如何包含在Windows PE文件中：
[示意图：Authenticode签名在Windows PE文件中的包含方式]
这种设计理念确保没有可执行代码被排除在签名之外。一旦代码经过身份验证并归属于作者，该代码所做的一切都是作者的责任。
安装程序和Authenticode签名
由Authenticode签名的下载器和安装程序需要特别考虑，因为它们下载并执行其他可执行文件。如上所述，Authenticode证明特定程序的代码已由作者签名，并且可执行代码自那时起未更改。如果该特定程序设计为从网络下载并运行第二个可执行文件，则原始程序需要通过Authenticode或其他方式验证第二个可执行文件的完整性。程序开发者应密切关注，确保整个下载链具有相同的信任和完整性级别，以确保其安装程序下载的可执行文件也是可信的，并且不能被恶意程序替换。
微软被告知，一小部分第三方安装程序（使用有效的Authenticode签名）已被修改，以下载与原始设计不同的可执行文件，而不使安装程序的Authenticode签名失效。
我们分析了这些样本中的每一个，以研究执行流程，了解它们的工作原理。首先，从入口点执行由Authenticode覆盖的代码。然后，该代码在文件中查找覆盖层以读取流。最后，代码从流中解密URL，并从该URL下载并执行一个可执行文件。不幸的是，这些程序在执行下载的文件之前省略了完整性检查。
覆盖层是附加到便携式可执行文件物理映像的数据。简单来说，可以取一个PE二进制文件，在末尾附加额外内容而不调整头文件，这样就有一个覆盖层。此数据区域未由PE头定义为映像的一部分，因此不是加载的PE虚拟映像的一部分。Authenticode验证代码验证属性证书表是文件中的最后一项，如果之后附加了任何内容，则报告无效签名。
在报告给微软的样本中，证书目录的大小已增加以覆盖覆盖层。因此，从技术上讲，证书目录是文件中的最后一项，允许测试通过。
从这个样本中可以学到几个教训：
首先，开发者有意将URL流存储在证书目录内，以便他们可以签名一次并创建不同的安装程序。这种特定的次优实践使得报告给微软的恶意二进制修改成为可能。MS13-098加固措施（预计于2014年6月10日生效）将在这种情况下将二进制视为未签名。
其次，在这种情况下，开发者没有通过任何其他方式验证随后下载和执行的文件。
实现开发者所需场景的更好方法是将URL作为资源存储在PE内。这样做，URL将被Authenticode覆盖，任何修改下载URL的尝试都会导致签名验证失败。
今天，通过MS13-098，如上所述，Windows团队增加了额外的加固和缓解措施，以检测这种不良实践并报告无效的Authenticode签名。启用后，这些加固措施将检测PE映像证书目录中PKCS #7 blob之后是否放置了额外的未验证数据。该检查验证PKCS #7结构之后没有非零数据。尽管此更改防止了这种不安全实践的一种形式，但它无法防止所有此类形式；例如，应用程序开发者可以将未验证数据放置在PKCS #7 blob本身内，这在验证Authenticode签名时不会被考虑。然而，正如这篇博客文章所示，强烈不鼓励开发者这样做，因为它可能导致不安全的应用程序行为，并且如果应用程序以不安全的方式使用未验证数据，可能会危及签名公司的声誉。
- Ali Rahbar，MSRC工程团队
我要感谢Jonathan Ness、Elia Florio和Ali Pezeshk
参考：http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx