引 言
9月17日下午三点，黎巴嫩有几千台寻呼机同时响起了哔哔声，提示用户查看信息，几秒钟之后，这些寻呼机同时爆炸，整个黎巴嫩陷入一片混乱，造成至少12人死亡，约2800人受伤。
十几天来，各方已经从政治、军事、外交等不同角度对这起事件进行了深入的分析。本文将着重从技术角度，分析寻呼机的供应链在其中扮演的角色，进而引出今年的另外一起并不是那么引人注目，但是在软件开发者群体中造成重大影响的“XZ后门事件”。最终结合这两起事件，说明对于软硬件供应链管理的必要性，和目前已有或者即将出台的一些措施。
文｜崔伟
清华大学博士
浙江大学金融学系校外导师
IEEE PES中国区常务理事
这些寻呼机是怎么引爆的？
八零后或者更加年长一点的读者，对于“寻呼机”并不陌生。二十多年前，它还是我们日常生活中不可或缺的通信工具，它的工作原理是：用户先呼叫寻呼台，说明自己的呼叫对象和信息；寻呼台将信息发送至对应的寻呼机。机主通过寻呼机，就能看到呼叫信息。它的工作流程如下图所示：
▲ 寻呼机的工作原理，作者绘制课间饭后，“哔哔”之声响起，大家看到别人发来的问候信息，或者需要回电，就到处找公用电话回电话，这是当年常见的场景。但是，随着移动手机逐渐走入历史舞台，寻呼机在中国市场中几乎已经走入通信博物馆。
▲ 很多七零后、八零后都曾经拥有一台这样的设备，中国联通展览照片那么，为什么今天还有人需要使用寻呼机（Pager）？
事实上，这是一个一直相当稳定的市场，也有着一群长期的供应商，因为在移动互联网时代，它依然具备一些独特的优势。下表列出了它相对于手机的优劣：
对于一些特殊组织而言，最看重的是它的“单向信息传输”功能，也就是不会暴露被叫用户的具体位置，类似于收音机。
但是这样做也存在一个明显的劣势：寻呼机的保密性和安全性较差，一旦呼叫服务公司被攻破，就可能会收到恶意的、虚假的信息。这正是这些爆炸的寻呼机收到了一个恶意引爆信息的原因。
那么，寻呼机本身为什么会爆炸呢？
显然，光靠自身的小型电池，是不可能造成如此严重的后果的。
爆炸专家通过对爆炸视频的研究表示，传呼设备中应被放置了大小与铅笔橡皮擦相仿的小型炸药，这些炸药可能在投放前经过了改装。该型号传呼设备的电池是可拆卸的，采用的是锂电池，确有可能被改装安放炸药。
所以综合而言，这起事件中涉及了三个核心的环节：
尤其是其中第二步，显然是最难的，因为需要在神不知鬼不觉之中，改变常规产品的内部构成，又能够通过一系列的后期测试，在日常的检查中（例如飞机安检）又不会露出马脚，这需要大量的准备工作和技术手段。
在这起事件中，根据媒体的追踪，一家位于欧洲的空壳公司早在三年前，就和寻呼机的制造厂商建立起了合作关系，一开始只是进口，后来提出自己制造，并获得该品牌的授权。
通过这种方式，空壳公司得以对产品进行篡改，进而最终结合特定的提示信息，引爆寻呼机。
▲ 此次事件中爆炸的寻呼机，其中“Gold Apollo,. LTD”公司是原供应商，但是实际产品是空壳公司提供的开源软件
是另外一条隐秘的供应链战线
此次事件之后，估计各个国家都会加强对于硬件产品供应链的管理。在全球化的生产模式下，一个产品的生产可能涉及多个地区、多家企业，从原材料的采购、零部件的生产，到组装、运输和销售，任何一个环节出现问题都可能导致严重的后果。
但是，明枪易躲，暗箭难防。相对于来源比较容易跟踪（查询供货过程），影响也非常显著（如爆炸）的硬件供应链而言，要防范软件代码供应链的安全攻击，则要难得多。
在现代软件开发中，软件供应链的复杂性日益凸显，涉及代码的编写、开源模块的使用、软件库的集成，以及对各种第三方开发工具和平台的依赖。一个软件产品可能由多个团队，甚至多个国家的开发者共同完成，动辄就有几十万行、数百万行代码。
开发中使用的开源模块虽然为软件开发带来了便利，降低了开发成本和时间，但也带来了潜在的安全风险，因为这些模块的开发往往由个别独立团队完成，在互联网上发布，再由开发者社区自行选择使用，整个过程中并没有一个权威机构对其进行专门的审核和控制，主要依赖于团队自身。
▲ 常见开源组件，作者绘制一旦团队失控，即最重要的内部审核权被别有用心的人所获得，则可能会给使用这些模块的产品带来安全隐患。
今年3月，就发生了一起这样的案例，被称为是开源软件史上首个“史诗级”的人为注入漏洞。
XZ-Utils（以下简称XZ）是一款开源的无损压缩命令行工具，是用C语言编写的跨平台工具，可以用于类Unix系统和Windows系统，目前是大多数Linux发行版本的默认工具之一。几乎可以说，每台服务器都有它。
2024年3月29日，微软工程师Andres Freund在X上发出警告，称在做测试时，发现XZ的新版本让SSH 的启动时间慢了500毫秒。之后，Freund向Openwall项目的开源安全邮件列表报告了他的发现，并引起多家软件厂商的注意，最终被确认是XZ的5.6.0和5.6.1版本中存在SSH后门
SSH（Secure Shell）是一种网络协议，为计算机之间提供了一种安全的加密通信方式，常用于远程登录系统、安全地传输文件等操作，通过对数据进行加密和认证，能够有效防止信息泄露、中间人攻击等安全问题
▲ 微软工程师Andres Freund的社交媒体发言这件事顿时震惊了业界，因为这时距离这个新版本纳入主流 Linux 发行版，只差几天。如果没有及时发现，就意味着世界上几乎所有的服务器都带有可供黑客长驱直入的后门，后果不堪设想。
开源软件的一个优点是所有的代码提交和讨论都在线进行，有迹可循。经过安全人员事后的详细分析，梳理出了整起事件的来龙去脉。
显然，就像上面提到的黎巴嫩寻呼机爆炸事件一样，这次XZ后门攻击的起点，也是三年前的一个看似毫不起眼的举动。
2021年，一个用户创建了名为“JiaT75”的GitHub账户（以下简称JT），并开始为多个项目做出贡献。在那一年，JT共提交了546次代码。
2022年6月10日，JT在XZ项目中进行了第一次正式的代码提交，用途是做一些基本的硬件功能测试，人畜无伤，代码被成功合并（merge）进入了XZ的主分支代码。之后JT开始频繁向团队贡献代码，并逐渐获得了团队主要成员Lasse Collin的信任。
然后，突然出现了几位网友，在项目用于沟通的邮件列表中向管理员建议，XZ项目缺乏人手，响应迟缓，应该给予“JiaT75”管理员权限。
这个建议被团队采纳。在事故发生之后，人们调查发现，这几个网友都是陌生的邮件地址和名字，根本找不到其他痕迹。
2023年7月8日，JT在oss-fuzz项目中提交了一个请求，该项目负责对XZ等多个开源软件项目进行自动错误检测。这个请求实际上关闭了一种特定的错误检测方式，从而防止oss-fuzz发现XZ项目中潜藏的恶意代码。
就这样，JT逐步成为项目的管理员，拥有独立发布新版本的权限，并先后发了几个版本。虽然这些代码可能没有明显问题，但是为三年后的恶意改动打下了基础。
换句话说，黑客经过长时间的潜伏，成功获得了开源团队的认可。他们伪装成合法的开发者，参与到开源项目的开发过程中。
终于，到了2024年2月，JT开始正式展开了攻击行动：
2024年2月23日，JT在XZ项目的测试文件夹中加入了两个含有隐藏后门的测试文件。
这使得攻击者可以远程控制软件的运行，获取用户的敏感信息。更让人难以发现的是，这个后门直接从源代码是看不出来的，要在构建阶段才会生成，即使有开发者仔细审查代码也很难发现。
JT在发布这个新版本（5.6.0）以后，开始发信催促几个大型Linux发行版团队，尽快整合他的这个版本。如果不是这时候微软程序员因为500毫秒的延迟而提出警报，任何使用了这个版本及以后版本的XZ都存在安全风险，这个后门也将可能会成为有史以来覆盖范围最广的漏洞。
后面的事情我们就知道了：
2024年3月29日，这个漏洞被及时发现。此后，JT此人就此消失不见，没有留下任何踪迹。很多安全人员试图通过他的访问记录、代码提交时间等查找他的蛛丝马迹，最终一无所获。
以上就是对这起有史以来，可能是准备时间最长的开源代码攻击事件的梳理。显然，黑客利用开源模块的开放性而发起的攻击，这并不是第一次，也不会是最后一次。
如何应对软件供应链的安全挑战
在当今数字化时代，信息就是财富，就是权力。软件作为信息处理和存储的重要工具，其安全性直接关系到用户的个人隐私、企业的商业机密以及国家的安全利益。
如果软件供应链存在安全漏洞，黑客和恶意攻击者就可以利用这些漏洞获取用户的敏感信息，进行诈骗、盗窃等违法活动。例如，金融机构的软件系统如果被攻破，可能会导致客户资金被盗取；医疗机构的软件系统如果被泄露，可能会涉及患者的隐私信息被曝光。
因此，加强软件供应链安全管理是保障信息安全的关键。
但是，随着软件供应链的全球化，一个软件产品可能涉及多个国家的开发者和供应商。这使得软件供应链的管理变得更加复杂和困难。此外，由于软件供应链的碎片化，各个环节之间的联系可能不够紧密，这也增加了安全管理的难度。
同时，正如上面XZ案例所揭示的，黑客和恶意攻击者的技术水平不断提高，他们在不断寻找新的攻击方法和手段。
总体而言，笔者有下面几点建议：
1、企业要加强对于开源模块的安全管理
软件开发者在选择和使用开源模块时，应该加强对其的安全管理。首先，要对开源模块进行全面的安全评估，包括其代码质量、安全性、更新频率等方面。其次，企业要建立开源模块的使用管理制度，明确规定哪些开源模块可以使用，如何使用等。最后，要定期对开源模块进行更新和维护，确保其安全性。
2、个人也需要增强安全技术水平和意识
为了应对恶意攻击者的技术不断提高的问题，我们应该提高安全技术水平和人员素质。首先，要加强安全技术的研发，开发出更加先进的安全防护技术和工具。其次，要加强人员的培训，增强人员的安全意识和技能。通过提高安全技术水平和人员素质，增强软件供应链的安全防护能力。
最后需要补充一点，为了加强软件供应链的安全管理，目前也有了相关的国家标准。
例如今年4月发布、11月1日开始施行的GB-T 43698-2024《网络安全技术：供应链安全要求》，对软件供应链的各个环节进行了严格的设定，包括软件的开发、测试、发布、更新等过程。例如，标准要求软件开发者在使用开源模块时，必须对其进行严格的安全检查，确保其不存在安全漏洞。同时，标准还要求软件企业建立完善的软件供应链安全管理制度，明确各部门的职责和权限，加强对软件供应链的监控和管理。
