手机出厂即中毒:谁把恶意代码写进了供应链,谁就在用户开机前夺走了安全权?"

admin 2026-10-15 14:36:17 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

手机出厂即中毒:谁把恶意代码写进了供应链,谁就在用户开机前夺走了安全权?

原创

何威风
何威风

河南等级保护测评

2026年10月13日 00:00
河南

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

我们通常认为,手机安全取决于用户是否安装了恶意应用、是否点击了钓鱼链接、是否及时更新系统。但一种更加隐蔽的威胁正在打破这种安全认知。手机还没有交到用户手中,恶意代码就已经进入了设备固件;用户第一次按下电源键时,设备可能已经处于攻击者的控制范围之内。用户没有下载恶意软件,没有主动授予可疑应用权限,甚至还没有开始使用手机,却可能已经成为恶意网络的一部分。这不是传统意义上的用户操作失误,而是一次发生在产品交付之前、隐藏在供应链深处的安全失守。

2026年10月,安全研究人员披露了一起名为 Midnight Mimosa 的安卓恶意软件活动。研究人员在采用联发科平台的部分低成本安卓设备中发现了预装于固件的恶意系统组件。在过去约两年里,相关活动已涉及超过150个国家和地区,研究人员观察到数千台独立受影响设备。恶意组件伪装成系统应用,拥有系统级权限,能够在用户不知情的情况下安装、删除应用,授予其他应用权限,并从远程服务器加载代码。它并不依赖用户主动打开某个恶意程序,而是利用设备本身已经具备的系统权限开展活动。

这类威胁最可怕的地方,在于它改变了传统安全防护的起点。以往的安全思路通常是先保证设备和操作系统可信,再通过应用审核、权限管理、病毒查杀和行为监测防止后续感染。但当恶意代码已经被写入固件,并以系统组件的身份运行时,普通用户面对的就不再是一个可以简单卸载的恶意应用。相关样本能够静默安装其他程序、动态加载远程模块,并在安装载荷前暂时禁用Google Play商店,以规避相关安全检测,随后再重新启用。研究人员还发现了与该恶意软件活动有关的13款应用,它们曾通过 Google Play分发,具有相同家族特征,但并不具备预装系统组件所拥有的全部特权。由此可见,应用商店审核、终端查杀和用户安全意识都很重要,却无法单独解决固件本身已经失去可信性的问题。

从目前披露的技术行为看,这一恶意软件活动主要围绕非法牟利展开。受感染设备可以被用于隐藏广告展示、自动点击广告、收集设备及已安装应用的相关信息,也可能被改造成住宅代理网络节点。所谓住宅代理,是利用真实用户设备的网络连接转发其他人的流量,使外部活动看起来像是从普通家庭或个人网络发出。一台手机的异常行为可能并不起眼,但当成千上万台设备被集中控制时,就可能形成可供进一步利用的网络资源,甚至为其他恶意活动提供基础设施。手机因此不再只是受害者的个人终端,也可能在用户完全不知情的情况下,成为攻击者网络中的一个节点。需要强调的是,研究人员观察到了相关代理基础设施和恶意功能,但不能据此认定每台受感染设备都已被实际用于拒绝服务攻击。

更值得警惕的是,恶意代码究竟在哪个供应链环节进入设备,目前仍未得到明确确认。可能的环节包括原始设计制造商、固件集成商、物流合作方或其他参与设备交付的主体。研究人员还发现部分受影响固件使用了与深圳市某企业名称相关的签名证书,但明确指出,证书的出现并不能证明证书所属企业参与了恶意软件植入,也不能证明其知情。发现恶意代码,不等于已经查明责任主体;发现证书关联,也不等于已经证明实施者。 只有进一步核查固件来源、构建环境、签名流程、版本发布记录和供应链交接证据,才能逐步厘清恶意代码的实际植入环节和责任归属。

这正是网络安全供应链治理必须正视的问题。供应链安全不能只理解为采购时审查供应商资质、签订安全责任书、索取产品检测报告,或者在设备交付后做一次漏洞扫描。真正的供应链安全,必须覆盖产品设计、软件开发、固件集成、编译构建、代码签名、生产制造、出厂测试、交付验收、版本更新和运行维护的全过程。任何一个环节缺乏有效控制,都可能让恶意代码以正常产品的形式进入组织,甚至通过批量交付把同一风险扩散到大量用户和多个国家。采购合同中写明“产品符合安全要求”,并不等于产品实际上安全;供应商出具检测报告,也不等于设备运行的固件就是报告所检验的那个版本。

从责任单位的角度看,这类事件对产品采购和使用管理提出了更加现实的要求。采购低成本终端、行业专用设备、物联网设备或其他嵌入式产品时,不能只关注价格、功能和交付周期,还应审查制造商、原始设计制造商、固件提供方及更新维护方之间的关系,明确谁负责固件安全、谁控制签名密钥、谁有权发布更新、谁负责漏洞响应,以及发现恶意代码后谁必须采取措施。对重要业务使用的终端和设备,应建立型号、序列号、固件版本、签名信息、供应商及更新记录之间的关联,确保设备来源可追溯、版本变更可核验、异常问题可定位。对于无法说明固件来源、无法提供可信更新机制、无法解释异常系统组件的产品,不能仅凭外观正常或功能可用就认定其符合安全要求。

验收环节也必须从“能不能用”转向“是否可信、是否符合设计、是否持续可控”。对风险较高的设备,应根据业务重要性和安全风险,采取固件完整性校验、数字签名验证、软件物料清单核查、系统组件与权限审查、网络通信行为分析,以及必要的独立技术检测。对于系统级应用,尤其需要关注其权限是否与实际功能相匹配,是否存在未经授权的静默安装、异常权限授予、远程代码加载和不可解释的外联行为。检测结论必须与实际交付的设备型号、固件版本和配置状态对应,不能用某一版本的检测报告替代其他版本的安全验证,更不能把供应商的一纸承诺当作技术证据。

与此同时,供应商管理也必须从一次性的资质审查转向持续性的安全责任管理。供应商应当对其交付的软件、固件和组件来源负责,建立安全开发、构建发布、签名密钥保护、漏洞管理和安全事件报告机制;涉及外包开发、代工制造或第三方固件集成时,还应把安全要求延伸到实际参与产品交付的各方。采购方则需要通过合同约定、抽样复核、版本核验、问题通报、整改验证和必要的退出机制,防止安全责任在多层转包中被不断稀释。当出现产品缺陷或恶意代码时,不能仅要求供应商口头解释,更应形成从发现、隔离、溯源、整改、验证到责任追究的证据链。

对于已经购入相关型号或发现异常系统应用的用户和组织,处置也不能停留在简单卸载可疑应用。由于恶意组件可能位于系统分区并具有较高权限,普通恢复出厂设置或常规应用卸载未必能够清除问题。应首先核实设备型号、固件版本和厂商安全公告,必要时限制设备接入敏感网络,避免其继续访问关键业务系统或处理敏感数据;随后依据可信的厂商修复方案进行固件修复、重新刷写或更换设备,并在修复后复核设备完整性和网络行为。对组织管理的终端,还应评估设备是否曾接触业务凭据、内部网络和敏感信息,视情况撤销会话、轮换凭据、检查异常连接,并保留必要的调查证据。对个人用户而言,如果无法可靠确认固件已修复,直接更换设备可能比自行尝试复杂的系统级操作更加稳妥。

从更深层次看,这起事件揭示的不只是安卓设备的技术风险,而是数字产品供应链中的信任问题。用户购买产品,实际上也在购买制造商、软件开发者、固件集成商和更新维护体系共同提供的信任。只要其中一个环节能够未经授权地植入代码,这份信任就可能被滥用;只要采购方缺乏验证能力,产品就可能在外观、功能和文档都正常的情况下,把隐蔽风险带进组织。网络安全产品和服务市场同样如此:资质不等于能力,报告不等于事实,合同不等于落实,交付不等于安全。安全要求只有转化为可以检查、可以复核、可以追责的过程控制和技术证据,才能真正产生约束力。

因此,供应链安全治理的核心,不是简单地排斥某一类低价产品,也不是把全部责任推给最终用户,而是建立覆盖产品全生命周期的可信机制。监管部门需要推动责任主体依法落实安全义务,供应商需要对产品实际安全质量负责,采购和使用单位需要履行选择、验收、运行监测与问题处置责任,检测评估机构则必须确保结论有事实依据、检测对象与交付产品相对应。任何一方都不能以“其他环节已经检查过”为由,放弃自己应当承担的责任。

当恶意代码在手机开机之前就已潜伏,安全治理就不能等到用户点击之后才开始;当风险隐藏在产品交付链条之中,责任追究就不能止于最终使用者。真正的供应链安全,是让每一个关键环节都留下可信证据,让每一个参与主体都承担明确责任,让每一件交付产品都经得起独立验证。否则,用户买到的可能不只是一台手机,而是一张由他人控制、却由自己承担后果的网络入场券。

安全物理环境

等级保护建设:物理环境选择

等级保护建设:物理访问控制

等级保护建设:防盗窃和防破坏

等级保护建设:安全物理环境—防雷击

等级保护建设:安全物理环境—防火

等级保护建设:防水和防潮

等级保护建设:安全物理环境—防静电

等级保护建设:安全物理环境—电磁防护

安全通信网络

等级保护建设:安全通信网络—网络架构

等级保护建设:安全通信网络—通信传输

等级保护建设:安全通信网络—可信验证

安全区域边界

等级保护建设:安全区域边界—边界防护

等级保护建设:安全区域边界—访问控制

等级保护建设:安全区域边界—入侵防范

等级保护建设:安全区域边界—恶意代码和垃圾邮件防范

等级保护建设:安全区域边界—安全审计

等级保护建设:安全区域边界—可信验证

安全计算环境

等级保护建设:安全计算环境—身份鉴别

等级保护建设:安全计算环境—访问控制

等级保护建设:安全计算环境—入侵防范

等级保护建设:安全计算环境—安全审计

等级保护建设:安全计算环境—恶意代码防范

等级保护建设:安全计算环境—可信验证

等级保护建设:安全计算环境—数据完整性

等级保护建设:安全计算环境—数据保密性

等级保护建设:安全计算环境—数据备份恢复

等级保护建设:安全计算环境—剩余信息保护

等级保护建设:安全计算环境—个人信息保护

安全管理中心

等级保护建设:安全管理中心—系统管理

等级保护建设:安全管理中心—审计管理

等级保护建设:安全管理中心—集中管控

等级保护建设:安全管理中心—安全管理

安全管理制度

等级保护建设:安全管理制度—安全策略

等级保护建设:安全管理制度—管理制度

等级保护建设:安全管理制度—制定和发布

安全管理机构

等级保护建设:安全管理机构—岗位设置

等级保护建设:安全管理机构—人员配备

等级保护建设:安全管理机构—授权和审批

等级保护建设:安全管理机构—沟通和合作

等级保护建设:安全管理机构—审核和检查

安全管理人员

等级保护建设:安全管理人员—人员录用

等级保护建设:安全管理人员—人员离岗

等级保护建设:安全管理人员—外部人员访问管理

安全建设管理

等级保护建设:安全建设管理—定级和备案

改一个数字就能看到别人的订单越权漏洞凭什么20年没治好" 网络安全文章

改一个数字就能看到别人的订单越权漏洞凭什么20年没治好"

本文深入剖析越权漏洞(IDOR/BOLA)的原理、真实案例与长期存在原因,指出其本质是系统只验证认证未验证授权。文章列举T-Mobile、Optus等重大数据泄露事件及国内司法判例,强调法律风险。作者提供两个可操作方案:静态自查脚本扫描高危代码模式,以及归属校验装饰器修复方案,并建议将自查挂入CI流程。内容专业实用,兼具技术深度与工程实践指导价值。
评论:0   参与:  0