背景
2020年10月13日，微软发布了10月份的漏洞风险通告。其中包含一个奇安信红雨滴团队独立提交的数字证书欺骗漏洞，该漏洞编号为CVE-2020-16922。攻击者若成功利用此漏洞可以绕过Windows数字签名安全验证并加载执行未正确签名的恶意文件。而在真实攻击情形中，攻击者利用该漏洞可能会绕过防止加载未正确签名文件的安全软件（如杀毒软件等）。
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-16922
随后奇安信威胁情报中心也第一时间在安全社区公开了该漏洞的相关信息。
https://twitter.com/RedDrip7/status/1316592876881502208
漏洞原理
该漏洞成因和CVE-2020-1464[2]类似，均是未对已签名文件末尾的数据进行额外的检查，稍有不同的是，CVE-2020-1464是针对.MSI文件附加数据，而此次的CVE-2020-16922是针对.CAT文件附加数据（注：.CAT文件是微软的一种分离式签名的文件，单独一个.CAT文件可保证多个原始文件的真实性）。由于微软未考虑已签名文件附加数据的情况，导致在拥有合法数字签名的CAT文件末尾增加其它数据后，该文件也能通过Windows签名验证：显示数据签名正常。
而如果在拥有合法数字签名的CAT文件尾部附加比如一个恶意的.jar（JAVA可执行文件）文件后，再将该文件重命名为.jar后缀。由于JAVA运行时环境对.jar文件的宽松解析特性，此时双击执行该文件将会执行文件末尾附加的恶意.jar文件，从而可能绕过安全软件的检测进而分发恶意软件。当然如果有其它类型文件也拥有这种宽松解析特性，那也可以用于利用该漏洞进行类似攻击。
漏洞分析
通过跟踪Windows对CAT文件签名验证的过程，发现它使用的也是微软的Subject Interface Package技术（注：SIP技术为Windows签名验证提供了可扩展性，通过注册表的一组GUID和动态库能够给特定类型的文件提供签名验证）。所以此验签过程首先调用了crypt32!CryptSIPLoad函数，来确定哪个动态库有能力为CAT文件提供签名验证。
从注册表中得知，验证CAT签名（CAT文件对应的GUID为DE351A43-8E59-11D0-8C47-00C04FC295EE）的动态库为WINTRUST.DLL。
然后由crypt32! CryptSIPGetSignedDataMsg调用wintrust! InboxCryptSIPGetSignedDataMsg获取CAT文件的数据并解析。
最后由crypt32! CryptSIPVerifyIndirectData调用wintrust! InboxCryptSIPVerifyIndirectData验证CAT文件的签名是否有效。
CAT文件签名验证的整体逻辑是通过GetSignedDataMsg函数将整个CAT文件作为一个PKCS#7签名格式的文件进行读取解析，若能正确解析则说明此文件格式有效。之后的CryptSIPGetSignedDataMsg函数只是对证书所有者信息作了简单判断，并回调另外的一个函数SIPObjectCatalog_::VerifyIndirectData作进一步判断，然而有意思的是VerifyIndirectData函数始终返回1，猜测这可能是微软为之后打补丁占的一个坑。
补丁分析
对2020年10月13日的补丁进行分析，证实了微软采纳了红雨滴团队给出的修复建议，在函数SIPObjectCatalog_::VerifyIndirectData内增加了额外的检查。
增加的函数名为CheckFileExtensions，其思路是维护了一个黑名单，如果当前文件的后缀名在黑名单列表里，则签名验证不通过；倘若文件后缀名不在黑名单（.hta .jar）列表里，则对整块CAT数据再进行额外的检查，判断是否有附加数据。
参考链接
[1].https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-16922
[2].https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1464
[3].https://twitter.com/RedDrip7/status/1316592876881502208
声明：本文来自奇安信威胁情报中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
