代码完整性验证可预防的5大真实软件灾难案例

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开发人员确实对软件进行了签名。然而,他们被公司软件开发生命周期(SDLC)的构建和审查流程和政策所拖累。(公司没有在整个SDLC或其CI/CD实践中强制要求代码签名。对SolarWinds的客户来说不幸的是,公司仅在开发过程结束时使用代码签名。)

这证实了,虽然代码签名是保护软件免受篡改的优秀工具,但它不能单独赢得安全软件供应链的战斗。不过别担心,我们也有解决方案。请继续阅读。

3. Codecov:数月未被发现的代码"干草堆"中的针(2021年)

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

他们做得如此出色,以至于获得了对任何使用Codecov代码测试脚本的系统的代码执行访问权限。幸运的是,在这种情况下,没有什么能持续 forever。即使对于涉及使用代码签名证书签名的受损代码的精心策划的骗局也是如此。

实际上,正是代码签名数字签名帮助结束了这场灾难性的攻击。有一天,一位客户手动检查了GitHub上可用的Bash Uploader的代码完整性验证值。当他们意识到哈希值与网站上列出的不匹配时,客户提醒了公司。多亏了一位有洞察力的用户和代码完整性验证,游戏结束了。

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月到期。这些综合因素是一场等待发生的灾难。

因此,两个恶意代码都已被签名。这是否意味着代码签名本身存在缺陷?不,恰恰相反。请记住:代码签名保护您的软件免受篡改,但仅从您应用数字签名和时间戳的那一刻起。此外,如果您没有在签名前检查代码完整性的流程和政策,您就有可能认可受损代码。

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

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

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持续监控和日志记录,都是可以在最坏情况发生时帮助您的公司的行动。

所以,既然我们现在回到了现在,开始拥抱这些代码完整性验证最佳实践吧。它将帮助您为您的软件、组织和客户保证更安全的未来。
更多精彩内容 请关注我的个人公众号 公众号(办公AI智能小助手)
对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号(网络安全技术点滴分享)

公众号二维码

公众号二维码

posted @ 2025-10-29 14:09  qife  阅读(5)  评论(0)    收藏  举报