5 Real-World Software Nightmares That Code Integrity Verification Could Have Prevented

2025年7月29日于 代码签名，网络安全

（27票，平均分：5.00 / 5）正在加载… 通过这5起臭名昭著的网络攻击（及其灾难性后果）学习过去，为未来做准备，这些攻击本可通过代码完整性检查得以预防。

根据Palo Alto Networks的Unit 42团队在2024年分析的数据，运营中断、声誉损害和经济损失是86%成功网络攻击带来的三大主要后果。到2025年第一季度，每个组织遭受的网络攻击数量呈上升趋势，同比增长了47%。

代码完整性验证（例如，作为代码签名中数字签名过程一部分的哈希计算）是您可以最小化此类攻击风险的一种方法。这种方法使您的客户和员工能够验证他们刚刚下载的软件与您的开发人员创建时完全一致——即自被加密签名以来未被修改或感染恶意软件。

在本文中，我将成为您的“过去之魂”。我将带您回到过去，探索五个真实世界的网络安全事件，并分享代码完整性验证如何能减轻其影响，或者可能完全预防它们。那么，请随我一同倒转时钟。

代码完整性检查本可预防的5个真实案例

代码完整性验证就像是私人俱乐部入口处的保镖。它确保您的用户和客户只在其机器上运行受信任且未被篡改的软件。这是通过利用代码签名及其内部层次的力量来实现的：

• 代码签名证书：用于对软件、应用程序、可执行文件和脚本进行签名的数字证书。它们向用户确认，他们正在下载或安装的代码是真实的，并且未经授权未被修改。
• 加密密钥：私钥和公钥是一串随机字符，与用于加密和解密数据的强大加密算法配对。它们是代码完整性验证的核心。在代码签名中，开发者使用与代码签名证书关联的私钥来加密和签署代码哈希值（即摘要）。当用户下载或安装软件时，他们的客户端使用相应的公钥解密摘要并验证签名的真实性。
• 哈希计算：这是代码签名过程的第一步。开发者对代码运行加密哈希函数，将其转换为固定长度的字符串（即哈希值或代码摘要）。开发者在将此结果哈希值发送给接收者之前，使用他们的加密密钥对其进行签名。如果哈希值在接收端保持不变，则向用户确认已签名的软件未被篡改。
• 数字签名：这些签名嵌入在软件内部。它们包括已签名的哈希值、时间戳（可选）以及用于签署代码的数字证书。用户的操作系统利用这些信息来执行代码完整性验证过程。此操作确认您作为开发者或发布者的身份，以及软件自签名以来未被更改。

图片说明：截图显示了代码签名的四个关键内部层次。

当您的私人软件俱乐部的门无人看管时会发生什么？我向您保证，不会有什么好事。同样的概念也适用于软件安全。

那么，如何防止Palo Alto所识别的同类问题发生在您或您的组织身上？让我们通过回顾过去的五次网络攻击来寻找答案并从中学习。

1. 感染230万台设备的CCleaner攻击（2017年）

攻击者将恶意负载注入到CCleaner（v.5.33）的合法版本中，这是一款流行的系统优化工具。该恶意软件感染了超过230万台计算机，包括主要科技公司的电脑。

Talos对攻击的分析显示，软件发布者使用有效的代码签名证书对可执行文件进行了数字签名。然而，Talos注意到签名的时间戳是在第一次签名后大约15分钟应用的，这表明开发过程可能已遭破坏。

图片说明：图形显示了攻击可能发生的时间点。

尽管如此，如果用户检查了数字签名和时间戳，他们可能会发现时间差异，从而避免安装恶意软件。

更重要的是，收购了Piriform（CCleaner原始作者于2017年7月被收购）的软件发布者Avast，本应在将软件发布到其网站之前检查软件是否含有恶意软件。如果他们这样做了，公司本可以在整个软件开发过程中实施必要的安全检查，从而发现问题并更快地减轻进一步的损害。

2. SolarWinds “SUNBURST” 攻击（2020年）

三年后，网络犯罪分子侵入了SolarWinds的网络并访问了其构建服务器。一旦进入内部，他们识别并利用了公司软件构建和审查流程中的几个漏洞。这使他们能够在Orion平台的更新包中插入恶意代码。

这些恶意分子甚至在软件签名过程开始之前就将他们的“毒药”混入了软件中。但更糟的是，他们能够在不被任何人察觉的情况下做到这一点，使用SUNBURST后门来部署TEARDROP和RAINDROP恶意软件加载器。

简而言之，恶意软件像野火一样蔓延。在几天之内，攻击者发送的更新就触及了成千上万的SolarWinds客户——从政府机构到各种私营组织（包括其他几家网络安全公司）。

图片说明：图形提供了SolarWinds攻击如何开始的示例。

因此，SolarWinds的开发人员确实签署了软件。然而，他们被公司软件开发生命周期（SDLC）中的构建和审查流程及政策所拖累。（公司没有强制要求在整个SDLC或其CI/CD实践中进行代码签名。不幸的是，对于SolarWinds的客户，公司只在开发过程的最后阶段使用了代码签名。）

这证实了一个事实：虽然代码签名是保护软件免受篡改的绝佳工具，但它无法独自赢得安全软件供应链的战斗。不过，别担心，我们也有解决方案。请继续阅读。

3. Codecov：在“干草堆”中隐藏数月未被发现的针（2021年）

不到一年时间，一群技术高超的黑客发起了一场与SolarWinds类似的复杂攻击。这次，他们利用技能从Codecov的Docker镜像创建过程中窃取了凭据。然后，他们悄悄地修改了公司的Bash Uploader脚本。由于这个与语言无关的报告工具适用于大多数操作系统（例如Windows、Linux和macOS）以及流行的开发者平台如GitHub，其影响是巨大的。

他们做得如此出色，以至于获得了对任何使用Codecov代码测试脚本的系统的代码执行权限。幸运的是，在这种情况下，没有什么能永恒存在。即使对于涉及使用代码签名证书预先签名的、已遭破坏代码的精心策划的骗局也是如此。

实际上，正是代码签名的数字签名帮助终结了这场灾难性的攻击。一天，一位客户手动检查了GitHub上可用的Bash Uploader的代码完整性验证值。当他们发现哈希值与网站上列出的不匹配时，客户向公司发出了警报。由于一位有洞察力的用户和代码完整性验证，游戏结束了。

图片说明：此图显示了代码完整性验证如何能减轻Codacov攻击的影响。

4. 3CX 漏洞：双重供应链攻击（2023年）

如果您认为一次供应链攻击就很糟糕，那么想象一下一系列此类攻击可能造成的损害。不幸的是，这正是2023年3CX软件漏洞的受害者亲身经历的。

根据进行调查的谷歌网络安全子公司Mandiant的说法，这是该公司首次看到软件供应链攻击直接导致另一次软件供应链攻击。

那么，攻击者是如何得逞的呢？他们向3CX桌面应用程序的合法（且经过数字签名的）版本中注入了恶意代码，这是一款适用于Windows和macOS设备的聊天、视频、语音和会议呼叫软件。（据估计，全球有超过1200万用户使用该软件。）

然而，根据Mandiant的说法，感染早在一年前就开始了。一名3CX员工在他们的计算机上安装了X_TRADER。这款由Trading Technologies开发的专业交易软件包，曾遭篡改并通过先前的软件供应链攻击进行分发。

这个世界真小，是吧？正如90年代深夜电视购物主持人总爱说的：“但是等等，还有更多！”雪上加霜的是，X_TRADER平台已于2020年停用——比软件被入侵整整早了两年。然而，已停用的代码在2022年仍可从合法的Trading Technologies网站下载。

此外，这个未使用的软件包仍然由“Trading Technologies International, Inc.”使用一个本应在2022年10月到期的证书进行了正式签名。这些因素的结合是一场等待发生的灾难。

图片说明：图形显示了导致3CX供应链攻击的缺陷。

那么，两个恶意代码都经过签名。这是否意味着代码签名本身就有缺陷？不，恰恰相反。请记住：代码签名保护您的软件免受篡改，但仅限于您对其应用数字签名和时间戳的那一刻起。此外，如果您没有流程和政策来检查签名前代码的完整性，您就有可能认可已遭破坏的代码。

这强化了代码完整性验证在整个软件开发生命周期中的根本作用。从软件的诞生到消亡，对代码的任何添加和更改都必须经过验证，尤其是在允许您的软件被签名之前。这样，问题就能在您的产品发布、被客户或其他最终用户下载或安装之前被发现。

现在，在回到当下之前，让我们再看一个最近发生的事件。

5. 下载量达230万的恶意Chrome扩展程序（2025年）

新年，新攻击。在2025年7月的第一周，Koi Security发现并报告了18个看似独立的恶意Chrome扩展程序，这些扩展程序可在Chrome和Edge商店下载。更糟的是，其中几个扩展程序拥有谷歌的已验证徽章或特色展示位置，并且已经获得了超过230万次下载。

事实证明，这些扩展程序都是一个名为RedDirection的中心化攻击活动的一部分，该活动使用恶意软件来监控所有浏览器标签页的活动。根据他们的调查，似乎所有被感染的扩展程序在开发者最初上传时都是合法且未被篡改的。（显然，多年来一直如此。）这就是为什么Koi的研究人员认为攻击者是在后来才破坏了这些扩展程序的代码，而不是在最初发布时。

对于攻击者来说，这部分很容易，因为谷歌的自动更新功能会在不主动通知或要求用户做任何事情的情况下，向用户提供软件的最新版本。这是一个重大缺陷，因为它剥夺了用户在安装软件更新之前手动进行代码完整性验证（例如，比较下载代码的哈希值与原始哈希值）的机会。

图片说明：图形显示了当扩展程序或应用程序的自动更新过程存在缺陷时会发生什么。

谷歌确实移除了一些受感染的扩展程序。但这只是恶意软件海洋中的一滴水。无论如何，您真的会让一个自动化过程在您无法运行任何代码完整性验证的情况下，在您的设备上安装某些东西吗？

您现在就可以实施的与代码完整性验证相关的4项行动

我们回到了现在。可以清楚地看到代码完整性验证在预防企业最糟糕噩梦发生方面所扮演的无价角色。它本可以帮助预防从代价高昂的数据泄露到毁灭性的恶意软件感染等一切问题。

但是，直接受这些事件影响的公司本可以采取一些措施来减轻影响。猜猜怎么着？您也可以实施这些措施。

1. 保护您的访问凭据

无论多么诱人，永远、永远不要使用默认或硬编码的凭据和密钥。

• 遵循密码策略最佳实践。
• 将所有默认用户名和密码替换为唯一的、强大的登录信息。
• 选择多因素身份验证（MFA）。
• 如果可以，采用无密码身份验证。

2. 实施代码完整性验证政策

为您的代码完整性验证政策和流程提供全面的指导。

• 强制执行一项政策，要求通过代码签名和事件日志记录相结合的方式进行代码完整性验证。
• 确保该政策不仅适用于生产和分发，还适用于开发过程的每一步。

3. 保护您的SDLC

强化您的软件开发生命周期。

• 建立持续的监控和日志记录。这将使您能够密切关注谁访问了什么，以及在整个开发过程中进行了哪些更改。
• 使用静态代码分析工具，如GitHub Advanced Security或OWASP Automated Software Security Toolkit (ASST)。其中大多数是免费的，它们可以帮助您识别编码错误和安全漏洞，以便立即修复。
• 通过将安全性嵌入整个SDLC和您的CI/CD实践中，实现安全左移。

4. 使用PKI保护您的组织

充分利用公钥基础设施（PKI）来保护您的公共和私有资源。这个多功能框架使组织能够对用户和设备进行身份验证，保护数据的机密性并确保其完整性。

最棒的部分是什么？它不限于代码完整性验证。PKI对几乎每个组织都有众多应用。除了使用代码签名证书签署您的软件和应用程序外，PKI还使您能够：

• 使用安全套接字层/传输层安全性（SSL/TLS）证书保护您的网站和虚拟专用网络（VPN）访问。
• 使用电子邮件签名证书保护您的电子邮件并对设备进行身份验证。
• 使用文档签名证书对您的敏感文档进行身份验证并保护其完整性。
• 在您的整个IT生态系统中，对物联网和“智能”技术进行身份验证并实现安全通信。

PKI是您实现端到端安全的王牌。了解它是什么、如何工作以及您可以在何处实施它。

关于本可通过代码完整性验证预防的5个现实软件噩梦的最后思考

网络安全威胁不会消失。攻击者总会寻找新的策略和弱点来利用。像哈希计算、代码签名以及SDLC持续监控和日志记录这样的代码完整性验证机制，都是在最坏情况发生时可以帮助您公司的行动。

因此，既然我们回到了现在，就开始采用这些代码完整性验证最佳实践吧。它将帮助您为您的软件、组织和客户确保一个更安全的未来。