本页内容二维码：
本页内容二维码：
这个被微软定性为“让用户自选是否修复”的漏洞被利用在最近黑客组织对3CX的攻击中。
先长话短说。修复方法是修改注册表，添加以下注册表项：
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config]
"EnableCertPaddingCheck"="1"
[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config]
"EnableCertPaddingCheck"="1"
懂修改注册表的朋友应该不用多说。如果不懂但也想加固自己的Windows，可以把上面的内容复制粘贴到记事本，然后保存时编码选择ANSI，保存类型选择“所有文件（*.*）”，文件名连同扩展名一起设置命名为比如“CVE-2013-3900.reg”。保存后再双击导入该注册表文件，按提示确认导入。
完成导入后要重启电脑生效。
需要注意的是，如果从Windows 10升级为Windows 11，这个注册表项会被删除，所以必须重新设置一次。
下面详细说说这个漏洞：CVE-2013-3900，WinVerifyTrust 签名验证漏洞，当年是金山安全报告给微软的。
正常情况下，经过正常数字证书签名以保护其不会被篡改的可执行文件，查看文件属性时，Windows会显示数字签名页面让用户可以了解签名的详细情况：
在2013年12月10日，微软对外发布了关于这个漏洞的信息，指出如果对可执行文件的验证签名部分（WIN_CERTIFICATE结构体）添加信息，是有可能不会破坏该文件的签名验证状态的。
这个漏洞的典型无害利用是Google Chrome浏览器的安装包。如果在下载安装包时勾选了向Google发送使用统计和崩溃报告信息的话，Chrome的安装包就会利用这个漏洞添加标记信息，以便在执行安装时能判断用户勾选了发送信息并进行内部设置。
最终，微软把这个漏洞定义为“可选修复项”，虽然释出了补丁，但需要用户手工启用，也就是上面那段修改注册表的做法。
当启用了修补后，Windows就不会再允许通过WIN_CERTIFICATE结构体存储额外的信息，并不再认为此类可执行文件的签名有效。
只是这个“可选修复项”基本上就等于无人修复，除非个别足够细心的网管员，知道了这个漏洞的状态，并且通过某些方法进行全内网终端部署......不用看我，我也是最近才知道。
在安全专家将这个问题曝光后，微软只给出了一些典型的外交辞令式的说明。这些说明内容在笔者看来，基于数字签名去认可文件是否合法没有恶意的做法，随着专门盗取代码证书用于签发恶意软件的供应链攻击模式大行其道之后，已经变得不具备实际意义，连微软自己都不再完全依赖于数字签名防篡改。
虽然，组策略里面的AppLocker还在，笔者也曾经尝试过在内网全面启用它：
但如果没有域控制器配合，或者自己写个小软件对全部终端强制设置（像下面这样），要在几百台电脑上折腾组策略是不现实的。
记得在多年前第一次采购某企业版终端安全软件时，笔者就和厂家探讨过，是否可以在该软件的管理中控端的白名单功能加入基于签名认证功能，而不是只认文件的校验值。厂家那边就反馈说，这个做法不可靠。
所以，时至今日，可靠的端点防御措施除了打补丁之外，还是得靠一些靠谱的防御软件，基于可信文件CHECKSUM检查、系统底层实时行为监控、可疑文件虚拟化沙箱分析等等技术才可能防得住。
相关安全分析：
关于CVE-2013-3900：
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900
https://learn.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-098
关于AppLocker：
