大家读完觉有帮助记得关注和 点赞!!!
摘要
小型卫星在科学、商业和国防任务中不可或缺,但对商用现成(COTS)硬件的依赖扩大了其攻击面。尽管供应链威胁在其他网络物理领域已有深入研究,但其在空间系统中的可行性和隐蔽性仍未被充分探索。先前研究集中于飞行软件,其受益于严格的安全实践和监督。相比之下,辅助性COTS组件通常缺乏稳健的安全保障,却能同等访问关键机载资源,包括遥测、系统调用和软件总线。尽管拥有此特权访问权限,COTS硬件供应链的内部威胁却鲜少受到关注。
本文提出SpyChain——首个针对小型卫星的独立且共谋硬件供应链威胁的端到端设计与实现。利用NASA卫星模拟器(NOS3),大家证明SpyChain可规避测试、窃取遥测数据、破坏处理,并通过绕过地面监控的隐蔽通道发起拒绝服务(DoS)攻击。本研究追踪了从单一组件到动态协同恶意软件的升级过程,提出涵盖五种场景的隐蔽性分类法。我们揭示了辅助组件中的隐性信任如何实现隐蔽持久性,并披露新型攻击向量,重点介绍了一种新型多组件执行技术(该科技已被纳入SPARTA矩阵)。NASA的NOS3团队已确认并认可我们的发现。最后,我们实现了轻量级机载防御(包括运行时监控)以应对SpyChain类威胁。
1 引言
卫星产业近年蓬勃发展,2024年估值达2940亿美元[53]。增长主要源于星链(Starlink)等大规模星座[47,64],推动在轨卫星数量年增30%[11]。小型卫星(质量低于180千克的航天器[38])是扩张的核心[38]。其经济性和多功能性重塑了任务规划,支持大规模部署于通信、地球观测和国防监视领域,并日益用于卫星互联网和自主在轨实验等新兴场景[56],凸显其在科学、商业和国防领域的重要性。
这一迅猛发展由短周期构建、机载自主性和灵活载荷的设计理念驱动。小型卫星日益采用多任务载荷配置[10],集成AI实现实时决策[41],并重度依赖第三方硬件[61]。这些能力通过模块化架构达成,其核心框架如NASA的核心飞行系统(cFS)提供稳定基线,同时允许按需添加或升级外围组件(传感器、诊断或通信设备)。与经过严格验证和监管链实践的cFS不同[1,48],外部组件未必遵循同等保障流程。
与地面体系类似,供应链威胁是空间任务完整性的公认隐患[17]。尽管卫星直接访问受限,研究者仍发现机载软硬件弱点,包括可被利用的固件漏洞[70]以及因成本兼容性而持续依赖的传统组件[17,18]。更令人担忧的是商用现成(COTS)部件的广泛使用——其来源和内部逻辑往往不透明[16]。这些“辅助性”模块仍可订阅遥测、在软件总线上发布命令、操纵共享内存,从而对飞行栈产生深远影响。先前研究假设核心飞行软件存在内部篡改[14,23],或仅理论探讨供应链风险[44],却极少关注恶意功能如何嵌入COTS模块并在集成、发射和运行中持续隐匿。这一被忽视的向量使第三方组件成为长期入侵的可行路径,尤其随着小型卫星的激增。
为研究此风险,大家研发了SpyChain——部署于NASA小型卫星操作模拟器(NOS3)[36]的供应链威胁框架。威胁模型假设存在具有发射前访问权限的供应链内部人员。考虑到卫星传感器、相机等硬件组件普遍依赖外部供应商和承包商[18,42,29],此类攻击者具有现实性。与核心飞行软件不同,辅助性COTS模块面临更少的安全要求,却拥有同等遥测、软件总线和系统调用访问权。这种不对称性使攻击者能建立隐蔽通道、窃取遥测或注入任意命令,同时融入合法消息流。SpyChain利用此结构弱点,证明辅助模块如何提供隐匿持久的立足点,贯穿集成、发射和运行全周期。
SpyChain研究五种攻击场景,重点探索静态与动态触发的单组件及多组件攻击。在多组件攻击中,我们利用软件总线和临时文件协调以规避基于遥测的地面防御——实现攻击隐蔽性。结果验证了硬件供应链入侵可通过重用可信系统调用和通信接口实现。实验还揭示系统性缺陷:小型卫星因硬件限制缺乏软件总线认证、访问控制和机载运行时防御。为此,我们提出针对cFS和NOS3的轻量级防御方案:系统调用与消息速率的运行时行为监控、软件总线认证与访问控制,以及seccomp等阻断隐蔽通道的系统调用限制机制。更广泛而言,我们倡导采用零信任模块设计、供应链透明度措施和操作员培训,以提升应对SpyChain类攻击的韧性。
主要贡献:
多级攻击:实现五种场景,展示从单组件攻击到利用隐蔽文件通信的多组件攻击
传感器驱动逻辑:揭示恶意软件如何利用实时卫星遥测作为动态触发器
合法接口隐蔽性:证明数据窃取、故障注入和持久性可完全通过授权API实现
新型卫星恶意软件技术:成功将SpyChain战术映射至SPARTA矩阵[63],发现的新型执行技术将被纳入该矩阵
可行建议与NASA合作:提出系统级缓解策略,获NASA NOS3团队认可并计划合作
2 背景与相关工作
本节概述理解SpyChain所需的技巧与背景基础。首先描述小型卫星如何通过模块化第三方组件组装,以及此集成模式的风险;其次分析卫星框架的独特挑战;终于梳理卫星网络安全研究现状,包括模拟攻击和防御措施,并指出当前知识空白。
表1:近期研究与攻击场景对比
研究 | 目标实体 | 影响范围 | 测试平台 |
|---|---|---|---|
Yoon等[73] | 星间链路 | DoS | NetSim-3 |
Willbold等[70]* | 固件 | - | QEMU |
Hansen等[23] | 飞行软件栈 | DoS | NOS3 |
Donchev等[14] | 飞行软件栈 | DoS | Raspberry Pi 4B |
SpyChain | 第三方组件 | DoS/窃取/持久/欺骗 | NOS3 |
注:该研究聚焦固件分析
2.1 COTS组件的问题
COTS组件的采用显著降低了小型卫星制作门槛,但经济优势伴随严重风险。操作员常集成供应商硬件,却对其内部逻辑、特权访问或更新机制知之甚少[22]。一旦入轨,此类组件实际不可变:卫星无法物理维护、难以远程修补或监控,并在可能持续多年的任务中持续暴露于攻击者。
因此,集成商对外部供应商过度信任,仅关注功能实现而非操作逻辑验证。商业模块通常仅提供接口规范、二进制固件和驱动[25],供应商将内部逻辑作为专有IP保护,使集成商无法进行接口级测试之外的审计。例如在ESA的OPS-SAT任务中,研究者不得不凭借QEMU模拟进行灰盒模糊测试[21]。
无源代码时,隐藏负载几乎无法检测:静态分析和代码审查不可行,逆向工程和模糊测试成本高昂且超出立方星团队能力[50]。资源和进度限制进一步阻碍深度检测——快速集成优先于对抗分析[37]。
这些盲点可被利用。恶意软件可分散于多个模块,仅协同激活,并对标准验证隐形。由于安全或声誉顾虑,事件鲜少披露,导致未审核第三方组件的风险被系统性低估——即使这些模块控制关键遥测、通信或导航功能。
卫星安全的独特挑战:
国家关键基础设施拥护:包括5G/6G连接[15],使卫星成为单点故障[18]
监管真空:空间网络安全要求高度碎片化[18,42,17]
物理不可达性:发射后无法实时响应异常[13,49],卫星可能成为持续威胁源
3 威胁模型
本节定义SpyChain可行的关键要素,包括攻击者模型、卫星攻击面及假设。
3.1 攻击者模型
假设供应链内部人员通过供应商获取硬件组件预发射访问权限。攻击者熟悉目标卫星飞行软件和操作系统,能构建功能性恶意代码。NASA的cFS作为最常用开源飞行软件[68],降低了知识壁垒。操作系统知识(如Linux、RTOS)则用于访问进程间通信和网络调用等接口以创建隐蔽通道。硬件供应商天然具备此类知识,因其需针对特定环境设计模块。尽管硬件制造门槛高,但承包商的存在和高成功率催生了包括国家行为体在内的类似威胁行为者[65,39]。FCC已确认供应链威胁为优先事项[19]。
另假设攻击者拥有位于卫星轨道覆盖范围内的地面站,可周期性接收窃取的遥测数据。软件定义无线电和SatNOGS[43]等社区任务进一步降低了拦截卫星下行链路的技能门槛。图1对比了合法地面站与秘密接收关键材料的恶意地面站。
图1:卫星飞越合法与恶意地面站示意图

3.2 攻击面
小型卫星攻击面源于其结构设计:模块化应用在无细粒度隔离下共享广泛隐信任的系统资源,为恶意组件颠覆通信、存储和传输通道创造机会。
通信通道:软件总线帮助内部通信,允许任何机载应用无认证收发遥测和命令;无线电拥护外部通信,允许未认证连接
系统接口:飞行软件暴露文件系统和OS接口,可被用于建立隐蔽存储或通信通道
日志与取证缺陷:硬件限制导致系统调用、文件运行和网络应用未被记录[49],任何生成日志也常为易失性[74]
操作约束:为功耗、质量和带宽效率牺牲安全控制,内存和CPU限制阻碍实时异常检测
安全机制缺失:小型卫星“几乎无”专用入侵检测、访问控制或运行时验证工具[9]
3.3 利益相关方
SpyChain类攻击可对多方造成巨大损害:
供应商:面临责任和声誉风险
飞行软件开发者:恶意逻辑融入合法消息流破坏信任
卫星开发商:集成过程受威胁
任务操作员:直接威胁任务成功与数据完整性
终端用户:面临数据降级、任务中断或敏感载荷泄露
像 SpyChain 这样的攻击可能会对广泛的利益相关者造成巨大损害。对于供应商来说,这会带来责任和声誉风险,因为他们的卫星组件可能成为妥协的载体。对于飞行软件开发人员来说,SpyChain 暴露了恶意逻辑如何融入合法的消息流,从而破坏了对保证流程的信心和软件框架本身的可信度。卫星开发人员面临着将受损组件集成到飞行系统中的风险。错过后门或隐藏的管用负载可能会削弱对其集成过程的信心,并损害他们作为值得信赖的构建者的声誉。任务操作员承担作后果。他们负责卫星的日常飞行和维护,这意味着任何隐蔽的妥协都会直接威胁到任务成功、数据完整性和运营商信任。最终用户(包括研究人员、客户或国防分析师)最终会感受到下游影响。他们可能会面临数据完整性下降、任务中断或敏感有效载荷结果泄露,而通常从一开始就没有意识到卫星受到了损害。

(一)单个恶意组件。

(二)多个恶意组件。

(三)具有 FIFO 的多个恶意组件。
发布位置测量数据的组件,其数据可作为触发器。触发器也可基于时间。当触发时,攻击代理可执行素材外泄或发动DoS攻击。图2(一)展示使用单一组件的攻击管道(场景1和场景2);图2(二)对应多组件架构(场景3和场景4);图2(三)展示运用文档作为通信通道的多组件架构(场景5)就是图2:攻击架构展示独立与共谋组件。攻击管道用红色标示。GNSS传感器
4 SpyChain方法
本节详述SpyChain的攻击策略、场景及从激活到执行的完整时间线,并描述恶意代理在模拟卫星环境中的具体实现。
4.1 攻击目标
SpyChain框架旨在演示供应链攻击者在小型卫星环境中的三大目标:数据窃取、拒绝服务和持久性。
拒绝服务(DoS):模拟系统故障,压制事件响应
素材窃取:获取长期情报优势
持久性:在任务全生命周期保持立足点
干扰:操纵遥测或注入欺骗命令侵蚀操作员信任
4.2 攻击架构
所有攻击场景共享以下设计原则以实现隐蔽性、协同性和数据窃取:
合法外观:恶意组件实现为标准cFS应用
原生环境调用:利用Linux嵌入式环境的标准调用
模块化设计:支持单/多组件攻击及动静触发策略
合法订阅重用:恶意应用订阅合法遥测流
触发激活:仅在预定触发条件下激活
4.3 攻击场景
实现五种逐步复杂的攻击场景(图2展示攻击流程):
场景1——单组件静态时间触发
架构:单个恶意cFS应用
触发:系统启动后固定倒计时
流程:倒计时结束后直接向恶意地面站发送遥测
场景2——单组件动态传感器触发
架构:单组件动态激活
触发:GNSS遥测检测入轨条件
流程:检测到入轨后通过无线电发送遥测
场景3——多组件静态触发+总线协同
架构:触发代理与攻击代理双组件
触发:触发代理固定倒计时
协同:cFS软件总线消息传递
流程:触发代理发布协同消息,攻击代理启动遥测发送
场景4——多组件动态触发+总线协同
架构:双组件动态激活
触发:触发代理监测GNSS遥测
协同:软件总线消息
流程:检测入轨后触发代理发消息,攻击代理响应
场景5——多组件动态触发+文件协同
架构:双组件动态激活
触发:触发代理监测GNSS
协同:卫星文件系统临时文件读写
流程:触发代理写FIFO记录,攻击代理轮询读取后启动
4.4 攻击时间线
以场景5为例说明供应链恶意软件如何通过可信接口隐蔽操作(图3):
供应链入侵:集成阶段植入恶意组件
休眠运行:发射后执行正常任务
触发激活:检测入轨后写FIFO文件
材料窃取:攻击代理读取文件后利用无线电发送遥测
终止或持久化:可触发段错误或持续窃取
图3:场景5攻击时间线
(1)组件预埋恶意软件→(2)触发代理等待条件→(3)写FIFO记录→(4)窃取材料→(5)终止或持续攻击)
4.5 卫星模拟
使用NASA的NOS3模拟器评估可行性。该框架通过cFS、模拟硬件驱动、实时遥测和COSMOS地面站工具模拟飞行条件,无需物理硬件即可完成真实实验。
核心NOS3运行于cFS——政府、商业和学术任务广泛采用的模块化飞行软件框架。应用通过发布-订阅软件总线通信,缺乏消息认证和访问控制,反映现实限制。图4对比真实与模拟卫星架构,显示模拟环境保持结构和接口保真度。
图4:真实与模拟卫星架构对比

(一)真实卫星物理架构

(二)NOS3 模拟
图4:真实与模拟卫星组件架构的比较。模拟设置保留了结构和界面保真度,从而实现了真实的测试。
4.6 实现细节
以场景5为例说明恶意组件实现:
触发代理配置:
订阅GNSS遥测(NOVATEL_OEM615_DEVICE_TLM_MID)
检测入轨后写"toggle_exfil"至FIFO文件
后期写"kill"触发段错误
攻击代理配置:
用mkfifo()创建FIFO文件(内置同步且无痕)
订阅卫星状态遥测
轮询读取FIFO文档,收到指令后发送遥测
无线电遥测下行链路:
滥用GENERIC_RADIO的UDP套接字
通过sendto()注入任意UDP数据包
无线电应用无条件转发至硬件模型
4.7 隐蔽特性
SpyChain经过以下特性在正常任务操作中隐藏恶意活动:
利用可信API
在飞行软件正常权限内运行
激活前避免异常遥测模式
表2:攻击场景及对策
场景 | 攻击者 | 触发方式 | 协同机制 | 隐蔽性 | 对策 |
|---|---|---|---|---|---|
场景1 | 单组件 | 时间 | - | ✗ | 运行时行为监控 |
场景2 | 单组件 | 动态 | - | ✗ | 运行时行为监控 |
场景3 | 多组件 | 时间 | 软件总线 | ✗ | 总线认证与访问控制 |
场景4 | 多组件 | 动态 | 软件总线 | ✗ | 总线认证与访问控制 |
场景5 | 多组件 | 动态 | FIFO材料 | ✓ | 系统调用过滤/OS加固 |
5 结果
模拟实验证明可在小型卫星上成功嵌入隐蔽持久恶意软件。主要发现如下:
5.1 组件协同
所有多组件场景中,触发代理与攻击代理通过cFS软件总线(场景3-4)或隐蔽FIFO文件(场景5)成功协同。软件总线协同启用常规消息,FIFO通道通过文件读写同步,均对操作员不可见。
5.2 素材窃取
所有场景中,攻击代理隐蔽窃取状态遥测、事件日志、总线统计和时间同步数据至未授权地面站。操作员未收到无线电使用警报或遗留日志。
5.3 欺骗
恶意软件能向软件总线发送任意消息和命令,生成虚假诊断报告、伪造遥测或消息洪泛。这些活动可掩盖真实异常、混淆故障检测甚至触发其他应用意外行为。注入消息与合法遥测混合,误导操作员归因。
5.4 持久性与拒绝服务
所有场景中,SpyChain成功从数据窃取升级至DoS。攻击代理依据空指针解引用故意崩溃,产生模仿常见软件故障的段错误。崩溃可循环以维持中断并增加恢复难度。操作员视其为合理软件缺陷,为攻击者提供推诿空间。
替代方案中,SpyChain持久运行,持续窃取遥测并混入正常操作。攻击代理处理总线消息并生成状态材料维持合法外观,触发代理可基于轨道条件重新激活窃取。
5.5 新型策略识别
开发SpyChain涉及多种战术、技术与过程(TTP)。表3将所用TTP映射至标准化SPARTA矩阵[63],显示攻击方式与现实场景一致。但现有矩阵忽略了关键技术创新:受损组件的共谋行为。该技术通过分散恶意逻辑避免集中式签名检测,提升持久性和隐蔽性。大家在场景3-5中成功应用此技术,证明其有效性。
表3:SpyChain中涉及的SPARTA技术
类别 | TTP | 名称 |
|---|---|---|
侦察 | REC-0001.01 | 收集航天器设计信息:软件设计 |
侦察 | REC-0001.04 | 收集航天器设计信息:数据总线 |
初始访问 | IA-0010 | 安全模式下的未经授权访问 |
初始访问 | IA-0001.02 | 供应链妥协:软件供应链 |
初始访问 | IA-0009.0 | 信任关系:供应商 |
执行 | EX-0002 | 位置、导航和定时地理围栏 |
执行 | EX-0010 | 恶意代码 |
执行 | EX-0009.01 | 利用代码漏洞:飞行软件 |
执行 | EX-0008 | 时间同步执行 |
执行 | EX-0013 | 泛洪攻击 |
持久化 | PER-0002.01 | 后门:硬件后门 |
外泄 | EXF-0003.02 | 信号拦截:下行链路外泄 |
影响 | IMP-0001 | 欺骗 |
影响 | IMP-0002 | 破坏 |
影响 | IMP-0003 | 拒绝 |
影响 | IMP-0006 | 窃取 |
防御规避 | TBA | 组件共谋以规避防御 |
说明:本表格列出了SpyChain攻击中利用的SPARTA战术、技术和程序(TTP)。每个TTP对应攻击模型中的特定行为。最后一行为我们提出的新TTP,将在下一版SPARTA矩阵中发布。
6 防御措施
迄今为止,尚无公开运行的星载入侵检测/防御系统(IDS/IPS)解决方案。哪怕已有基于NOS3的实验性IDS被提出[33],但其基于探针的设计范围狭窄,无法检测SpyChain所演示的隐蔽技能。这一差距凸显了需要为卫星量身定制轻量级嵌入式防御措施。
下文将概述SpyChain所利用的弱点,并推荐相应的应对措施以增强系统韧性。表2总结了攻击场景及最有用的缓解方案。我们首先提出针对NOS3和cFS的具体防御措施,随后给出强化卫星系统应对供应链威胁的更广泛建议。
6.1 针对NOS3和cFS的具体建议
这些策略针对NOS3和核心飞行软件(cFS)生态系统特有的结构弱点。
6.1.1 改进运行时行为监控
如表2所示,场景1和场景2演示了恶意软件如何伪装成正常执行。这些组件应用正常的API和合法的软件总线订阅,但其行为模式(如频率、流量、时序或平台调用)存在异常。现有的IDS原型[33]仅限于探测命令流量和通用总线特征,因此会漏报隐藏的FIFO通道或过多的内部遥测订阅等隐蔽技术(这些行为从不改变地面指令流)。
建议:我们提议在飞行软件内部部署轻量级运行时监控或行为审计代理。这些代理可以跟踪每个应用程序的环境调用使用情况,监控文件和网络访问,并观察消息总线活动以发现频率或订阅异常。即使是简单的启发式方法(如流量或无线电传输的异常峰值)也可作为有效的入侵指标。
代码实现:为说明可行性,我们在NOS3模拟中实现了一个运行时监控原型。我们的概念验证在攻击代理内部添加了一个轻量级消息速率限制器:内部计数器在短时间窗口内跟踪消息传输,一旦超过阈值(例如100条消息),组件即进入限制状态,抑制后续传输。每当触发限制时都会记录警告事件,为运行时违规提供可见性和问责机制。尽管在模拟中测试,但该机制模拟了一种遏制响应,可移植到真实的cFS组件中,并扩展至审计无线电使用、指令活动或其他指示隐蔽恶意软件的行为。
6.1.2 软件总线认证与访问控制
如表2所示,场景3和场景4利用了软件总线缺乏认证和访问控制的弱点来协调行动和泄露数据。触发代理和攻击代理行在无需验证的情况下订阅系统范围的遥测流(包括关键任务数据),并可随意发布任意消息和命令。此种缺乏强制执行的能力使得恶意组件能够监控敏感信息并发出隐蔽信号,同时在飞行软件生态系统中显得合法。
建议:引入软件总线访问控制列表和消息认证。每个模块应被要求在其清单中注册其主题和操作,并在运行时进行验证。此更改将防止攻击模块简单地订阅私有遥测流。
代码实现:为演示可行性,我们修改了一个cFS应用程序以强制执行授权消息ID的白名单。在完成任何软件总线订阅请求之前,应用程序会根据预定义策略检查请求的ID。未经授权的请求将被拒绝并记录,防止组件静默订阅受限的遥测流。尽管此原型在单个组件内部本地实施策略强制执行,但它说明了如何将访问控制集成到cFS框架本身。未来的扩展可包括集中式清单、每个组件的配置文件或加密签名,以供应更强的系统范围强制执行。
6.1.3 限制未监控的环境调用
场景5使用基于FIFO的隐蔽信令,严重依赖于对mkfifo()等系统调用的访问。如表2所示,限制或过滤对此类调用的访问是最有效的对策,能完全阻断隐蔽协调。
建议:应在运行时限制系统调用的使用,以降低恶意软件的隐蔽性和有效性。这可以使用操作系统级安全机制来实现——例如Linux中的seccomp或实时操作系统中的等效沙箱框架——配置为强制执行每个组件允许的系统调用白名单。在此策略下,试图调用敏感功能(例如mkfifo()或sendto())的第三方模块将在隐蔽通道或未经授权的数据泄露发生之前被阻止。更广泛地说,卫星操作系统应进行加固,以最小化暴露给飞行软件的不必要内核接口,从而缩小供应链恶意软件可用的攻击面。
代码实现尝试:尽管由于兼容性和初始化问题,将seccomp完全集成到NOS3中具有挑战性,但我们探索了一个概念性实现。系统调用过滤器将在组件初始化期间调用,定义一组最小允许的系统调用,并默认拒绝所有其他调用。任何不允许的系统调用(例如用于打开套接字或文件的调用)都将触发进程立即终止。尽管仅在模拟中测试,但此机制说明了如何在小卫星的基于cFS的环境或强化操作系统部署中采用轻量级的、按组件的系统调用限制,以提高软件隔离性并减少攻击面。
6.2 通用安全建议
SpyChain利用了受信任的软件接口、诊断角色、平台调用和监控不足的漏洞。这些漏洞并非cFS独有,而是反映了小卫星制作实践中的普遍弱点,并因缺乏可部署的检测工具而放大。
6.2.1 零信任飞行软件设计
在大家的场景中,恶意软件之所以成功,是因为组件被隐式信任,拥有对遥测、文档和网络功能的广泛访问权限。此种模型使得恶意代码很容易融入并滥用合法接口进行隐蔽泄露。
通过建议:飞行软件必须建立在任何模块都可能被入侵的假设之上,并将防御层融入其设计中。开发者可以通过声明每个应用程序可以访问哪些遥测流、文件路径和网络接口来强制执行最小权限原则,默认拒绝其他所有访问。清单驱动的访问控制确保模块仅订阅或发布到批准的主题。此外,跟踪消息速率、命令频率或套接字利用情况能够为异常行为提供早期预警。这些实践共同创造了更强的边界,使隐蔽滥用更难隐藏,即使在没有太空级IDS的情况下也是如此。至关重要的是,开发者要将安全性架构性地构建到飞行软件中,而不是在架构薄弱的软件上应用补丁。
6.2.2 供应链验证与透明度
采用COTS组件会在集成第三方部件时产生盲点,因为对其内部逻辑的了解很少。一旦入轨,这些模块实际上是不可变的——难以修补、监控或更换——使得任何隐藏的有效负载都成为长期负债,而SpyChain正是利用了这一点。
建议:飞行软件团队应要求所有集成组件具有可验证的来源和可重现性。这包括供应商披露来源、可重现的构建流水线以及对交付的二进制记录进行安装后分析。维护软件物料清单(SBOM)并将其与集成测试相关联,将在供应链中提供可追溯性,并支持发射后的取证分析。这些措施有助于确保黑盒组件不会成为沉默的故障点。
6.2.3 操作基线与培训
即使有工艺保障,检测最终取决于操作员识别系统行为异常的能力。然而,地面人员很少接受培训以区分良性异常与协同恶意软件的细微痕迹。没有参考基线,隐蔽的数据泄露或不寻常的诊断活动可能会被忽视。
建议:制定操作员手册,记录基线遥测模式、预期消息速率和正常进程行为。培训团队标记偏差,例如软件总线中的意外消息。定期进行模拟供应链泄露的桌面推演,可以使操作员做好准备在不确定情况下果断响应。将这种操作意识嵌入任务程序可确保安全不仅仅是设计上的关注点,而是持续的飞行中的实践。
利用将安全视为基线设计需求而非事后考虑,任务可以提高入侵成本,并降低隐蔽供应链恶意软件在轨持续未被发现的可能性。
7 讨论
我们的研究表明,供应链攻击能够在小卫星环境中未被察觉地运行。
真实的,当数据完整性被悄无声息地破坏时,最终用户面临任务关键风险。同时,必须承认我们模拟的局限性,以澄清这些发现的范围并概述未来研究的方向。就是与先前关注孤立漏洞利用或假设对核心软件有内部访问权限的卫星安全研究不同,我们的工作在NASA的NOS3环境中演示了现实的多组件供应链攻击。我们的发现强调了对各利益相关方的关键影响:供应商必须加强即插即用模块的保障实践,飞行软件开发者得采用运行时监控和访问控制,操作员不能假设格式良好的遥测数据
局限性:我们的模拟演示了在NASA广泛使用的NOS3框架内,将隐蔽恶意软件嵌入小卫星环境的可行性。然而,NOS3无法完全捕捉轨道任务的操作动态和物理约束。辐射引发的故障、热应力和可变链路质量等影响仍超出其范围。
我们的数据泄露方法借助合法无线电链路注入遥测,成功到达COSMOS地面站而未产生新连接或日志。尽管这在模拟中验证了隐蔽通道,但现实世界的通信涉及轨道动力学、预定过顶和波动链路质量,这可能使数据泄露复杂化或延迟。需要进一步研究以评估在操作条件下的持久性。
社区需求:我们的发现揭示了利益相关方(包括卫星开发者和安全研究人员)之间迫切需要更深入的接触。尽管小卫星在国防、气候科学和商业应用中的依赖日益增加,但其软件开发生命周期通常缺乏严格的安全验证。应对这个问题需要标准化的测试框架、共享的基准测试以及可跨任务适配的模块化检测工具。像NOS3这样的开源环境给予了坚实的基础,但社区努力必须向具有异常检测、遥测验证和攻击模拟功能的完整测试平台发展。
通过同样重要的是学术界、工业界和政府利益相关方之间更广泛的合作,以制定指南、工具和政策。攻击模式、恶意软件示例和安全软件模板的公共存储库能够加速安全实践的采用,而将形式化验证、合规性检查和持续威胁建模集成到生命周期中将增强韧性。这些措施共同有助于确保未来的卫星能更好地抵御隐蔽的、源自供应链的威胁,同时不损害小卫星极具价值的性能或模块化。
8 结论
小卫星日益成为复杂、自主的平台,依赖第三方组件,这放大了隐蔽软件入侵的风险。在NASA的NOS3环境中搭建的SpyChain,首次给出了在此环境下协同多组件恶意软件的端到端演示,展示了受信任组件如何共谋以泄露遥测、在重启后持久化并利用合法接口破坏运行。
通过引入逐步升级的隐蔽性和复杂性分类法,验证传感器感知和共谋恶意软件行为,并将其提炼为可管理的强化策略,我们的工作既强调了空间系统中供应链入侵的可行性,也凸显了增强韧性的迫切需求。
在整个卫星生命周期中嵌入零信任原则、经过认证的遥测、异常检测和发射后验证,并将NOS3等平台扩展为网络安全测试平台,对于保障下一代小卫星任务的安全至关重要。
浙公网安备 33010602011771号