防止具有无效 Authenticode 签名的可执行文件运行
我们在单个可执行文件中发布了软件包的更新补丁。该文件使用颁发给我们的证书使用 Authenticode 数字签名进行签名。该文件被下载到我们的客户操作的 Windows XP 或 Vista 系统中，他们在其中运行该文件以更新我们的软件。
我们的 PCI 合规审核员要求我们防止出现以下情况：
- 下载我们的可执行文件后，恶意者会更改该文件。细心的人将能够检查文件的属性并确定签名不再有效。
- 恶意者将更改后的可执行文件放置在毫无戒心的用户可以运行它的地方。
- 毫无戒心的用户运行了修改后的文件，引发了不明的破坏。
审计员认为，如果签名无效，有一种方法（或应该有一种方法）可以阻止文件运行。
你知道如何实现这一点吗？
We publish an update patch to our software package in a single executable file. The file is signed with an Authenticode digital signature, using the certificate issued to us. The file is downloaded to Windows XP or Vista systems that our customers operate, where they run it in order to update our software.
Our PCI compliance auditor has asked us to protect against the following situation:
- After downloading our executable file, a malicious person alters the file. An observant person would be able to check the properties for the file and determine that the signature is no longer valid.
- The malicious person places the altered executable somewhere that an unsuspecting user could run it.
- An unsuspecting user runs the altered file, releasing unspecified havoc.
The auditor contends there is a way (or ought to be a way) to prevent the file from running at all if the signature is not valid.
Do you know how this can be accomplished?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
MSDN 有一些关于此主题的有趣文章：
Authenticode 签名的可执行文件
MSDN has some interesting articles about this subject:
Authenticode Signed Executables
组策略中有一个设置。以管理员身份打开“gpedit”，然后在“计算机配置\Windows 设置\安全设置\本地策略\安全选项”下，将“用户帐户控制：仅提升已签名和验证的可执行文件”设置为“启用”。
现在，如果您的受操纵程序尝试获取管理员权限，或者您尝试以管理员身份运行它，它将失败，并显示无用的错误消息“从服务器返回引用”。但是，这也会影响所有未签名的可执行文件。
似乎没有办法以与未签名的可执行文件不同的方式处理损坏的签名。甚至他们的橙色 UAC 弹出窗口看起来都一样，尽管损坏的签名比丢失的签名更令人震惊。 （当然，如果攻击者操纵了您的可执行文件，他也可以完全删除泄露秘密的签名。）
There is a setting in the group policy. Open "gpedit" as administrator, then under "Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options", set "User Account Control: Only elevate executables that are signed and validated" to "Enabled".
Now, if your manipulated program tries to grab admin rights, or you try to run it as admin, it will fail with the unhelpful error message "A referral was returned from the server". However, this also affects all executables which aren't signed at all.
It seems like there is no way to handle broken signatures differently from unsigned executables. Even their orange UAC popups look the same, although a broken signature is much more alarming than a missing signature. (Ok granted, if an attacker manipulates your executable, he could just as well remove the tell-tale signature altogether.)