1.软件供应链安全综述 何熙巽

1.1 前置介绍

软件供应链：一个通过一级或多级软件设计、开发阶段编写软件, 并通过软件交付渠道将软件从软件供应商送往软件用户的系统。

软件供应链的安全：软件供应链上软件设计与开发的各个阶段中来自本身的编码过程、工具、设备或供应链上游的代码、模块和服务的安全, 以及软件交付渠道安全的总和。

PS：SDL：安全开发生命周期，将软件开发流程划分多个阶段，在各个阶段引入各种安全措施，保障软件开发以及软件终端用户的安全，并建立了漏洞发现和处理框架机制。ICT：信息通信技术。

XcodeGhost：感染非官方渠道发布的 Xcode —-> 编译出注入病毒的app

1.2 现状

技术手段文献偏少，大多都是管理手段。

攻击途径：

1. 开发环节的开发工具
2. 开发环节的源代码
3. 交付环节的下载网站
4. 软件更新网站

技术思路：

1. 软件漏洞挖掘
   • 基于源代码的漏洞挖掘【需要源代码】
   • 基于代码特征的漏洞挖掘【根据已发现的漏洞提取漏洞特征，然后检测目标中是否含有该特征，与机器学习结合】
   • 基于模糊测试的漏洞挖掘【不需要源代码】
2. 恶意软件及模块的识别和清除
   • 静态分析：统计分析以及机器学习
   • 动态分析：沙箱
3. 网络劫持
   中间人攻击or其他，劫持或篡改用户与软件交付或维护升级渠道之间的数据, 使得用户从交付渠道获得了非预期的恶意软件, 或者在软件维护和升级的过程中被植入了恶意代码。
   • 网络流量异常？

2 开源软件供应链安全研究综述 纪守领, 王琴应

这篇文章对开源软件供应链的定义加了第三方组件在里面

攻击点（之前没有的）：

1. 由于开源协作的新模式, 源码管理可能存在新的缺陷, 如攻击者可以向源码管理工具提交具有缺陷或后门的源代码【由于第三方组件的来源不可信, 第三方组件分发市场的验证审核机制不够完善, 导致开源软件供应链中组件的完整性被破坏】
2. 下载更新通道被劫持的风险【在 DNS 劫持、中间人攻击、钓鱼攻击等】

保护考虑的方面：

1. 供应链视角下组件及软件的漏洞检测、面向第三方组件分发市场的风险识别【如 PyPI、NPM、RubyGem、OPKG 等主流第三方组件分发市场】
   • 面向包管理器的第三方组件风险识别【大批量规模化地对包管理器及其他分发市场上的第三方组件进行检测分析】
   • 第三方语音技能分发市场的第三方组件风险识别【语音抢注攻击、语音伪装攻击】
   • 面向自动化应用程序组件分发市场的第三方组件风险识别【通过深度学习来计算自动化应用程序逻辑的相关性, 来挖掘不同第三方组件组合形成的潜在的物理渠道及其交互, 最终利用行为建模和聚类的方法识别是否存在风险（没看懂）】
2. 在对软件分发市场如安卓软件商店等中软件的风险识别
3. 软件下载更新时网络劫持的风险识别及软件风险识别

不足：

1. 当前的研究方案都针对特定已知的攻击设计, 在发现新漏洞的能力上仍有所欠缺
2. 新的开发和应用场景随着现代化的进展也在不断涌现，当前研究对物联网分发市场的研究仍处于初级探索阶段, 对新的开发和应用场景的第三方组件风险检测研究仍有待研究，如多架构的物联网设备固件、人工智能平台和模型中也依赖大量第三方组件, 且存在安全风险
3. 关于协作开发的风险识别的研究较少, 考虑到开源生态环境的来自不同开发人员的代码提交数量多、项目提交动态更新等特点, 当前仍没有较好的方案能实现大规模、自动化且可扩展的风险识别方案, 也无法支持动态增量式的轻量级的风险识别。

未来：

1. 结合深层次代码语义表征、基于人工智能的程序语义解混淆等智能化技术来提高应用软件风险识别的抗混淆能力, 结合复杂图数据构建与分析等技术来提取目标程序中的复杂依赖关系并进行进一步的分析。
2. 研究持续性风险识别技术来对不同研究人员的代码提交进行自动化持续性的检测, 如持续性模糊测试, 对修改或添加的代码进行定向模糊测试等
3. 研究新型安全防御技术如代码水印、代码混淆技术来实现应用软件的知识产权保护, 避免攻击者篡改应用软件；在组件和应用软件开发环节实现对目标组件及软件的补丁存在性检测、漏洞评估及自动化补丁加固等技术, 且要求能够通过有效的渠道快速准确地部署到相应的软件系统上；
4. 管理方案：如利用知识图谱对开源软件供应链中第三方组件、应用软件、开发人员等知识进行建模, 并结合深度学习等技术, 帮助实现开源软件供应链的知识分析、管理和评估

3 程序逆向分析在软件供应链污染检测中的应用研究综述 武振华

着重点：自动化程序逆向分析技术

分析点：软件供应链下游。在软件供应链下游的污染检测能够发现上游、中游的所有污染。检测目标主要为可执行程序，因此，需要用到程序逆向分析技术对其进行分析。

技术：

	静态分析	动态分析	符号执行	污点分析
方式		基于qemu全系统模拟； 代码插桩； 使用硬件特性记录程序的执行序列；		将敏感数据标注为污点源，如果污点数据被网络发送，则说明发生了信息泄露。
优势	可执行文件结构解析 控 制 流 分 析 数 据 流 分析 库函数识别 反编译
缺点	恶意程序常在运行过程中动态解密、释放指令或数据，静态分析方法很难检测该问题。	分析覆盖率有限；	路径空间爆炸； 约束求解； 时间开销大；
攻击点	代码混淆技术：控制流扁平化、不透明谓词、花 指令、API 混淆
改进		（1）路径探索技术； （2）动静结合； 【传统的基于特征码的恶意代码检测、基于熵的分析方法以及静态间接控制流转移识别能够辅助恶意代码检测或指导动态分析朝着目标区域进行动态执行和分析。】 【基于特征码的方法能够从程序代码中找出包 含恶意行为特征的字节序列，从而快速完成已知恶意代码的扫描; 基于熵的方法能够帮助分析系统标注可能存在加壳行为的代码片段】 （3）目前尚未有工作实现了针对大型软件的深度的动静结合分析方法。	（1）动态执行过程部分代码符号执行，剩余具体执行； （2）通过静态分析获取原数据； （3）减小路径空间：程序切片、程序抽象、等价路径约减； （4）约束求解：查询缓存和重用，优化查询路径条件【对非线性算术运算的约束无能为力】；

4 Towards Measuring Supply Chain Attacks on Package Managers for Interpreted Languages为了测量对解释语言的包管理器的供应链攻击

前言

比如像PyPI、Npm。

https://github.com/osssanitizer/maloss

现有的供应链攻击检测主要依赖于社区进行报告，而没有自动化解决方案。

4.1 方法

在该框架中，作者将包注册管理中心的特征分为三类，即功能性、审查和补救措施。

这些攻击者主要利用对上游人员的攻击（即包管理中心的管理人员以及包开发者）来对下游的包使用者展开攻击（即利用现有包进行开发的开发人员和终端用户）。

1. 元数据分析
   • 包名称、作者、发布、下载和依赖关系（比如将作者分组，识别来自已知恶意作者的包）
2. 静态分析
   • 根据已有敏感API列表手动对包中的API进行标记、API使用分析和数据流分析。
3. 动态分析
   • 动态分析侧重于执行包和系统调用。与静态分析相比，动态分析考虑源文件以及嵌入的二进制文件。通过捕获包执行过程中的动态行为，判断包是否存在先前定义的恶意行为

4.2 反分析技术

1. 多级有效载荷
2. 代码混淆
3. 逻辑炸弹
   • 如果只在某些情况下才会执行或触发的恶意应用程序逻辑，如不在生产环境中执行，静态和动态都检测不出来。
4. 旧版本

4.3 防御

1. 包注册中心管理者
   • 从功能的角度，RM可以通过提供MFA和代码签名、提高密码强度、检测异常登录等来显著提升账户保护能力。还可以通过在注册客户端检测包名混淆和限制发布容易与流行包产生混淆的包名来打击恶意包名。
   • 从审计的角度，RM可以使用如本文展示的程序分析手段系统的检测待审核的包，也可以通过众包的方式，引入人工评审，当检测到可疑的包时，将此信息广播给相应的开发人员。
   • 从补救的角度，RM可以从服务器上删除恶意包和发布者，还能够利用各种通知渠道，如电子邮件、安全咨询和客户端检查，向利益相关方通报安全事件。
2. 包维护者
   • PM可以通过采用MFA、代码签名和强密码等技术来保护他们的账户。还要对新的贡献者保持谨慎，手动检查他们提交的包。
3. 开发者
   • 开发者可以使用已知的安全包版本以避免来自上游利益相关者的供应链攻击，并定期检查安全建议、及时更新以避免已知的漏洞。开发者可以手动检查不受信任的包。
4. 终端用户
   • 用户可以利用反病毒工具来保护他们的设备。此外，用户可以提高自己的安全意识，只访问官方的和信誉良好的网站

4.4 不足

作者没有提出创新性的恶意包检测技术，只是将现有的工具结合了起来。而且运行环境单一，在静态分析时使用了大量人工手段，暂不清楚具体开销。

总体而言，作者创新性的提出了一个比较全面的方案定性评估包管理器的功能和安全特性，还提出了一套全面的分析框架。虽然没有技术创新，他设计的分析流程和规则非常完善。

5 Investigating Package Related Security Threats in Software Registries调查软件注册表中与包相关的安全威胁

前言

论文以软件供应链中的海量软件包为分析对象，对npm、PyPI、Maven、Go、NuGet、Cargo等六大开源软件生态开展大规模安全性分析，深入解析了软件包的发布、下载、更新、删除等过程，识别出十二个软件供应链攻击向量，影响多个软件源和镜像站。

5.1 攻击

1. 免费（UAF）攻击
   • 用户依赖于要检索程序包的唯一标识符。如果注册表允许包维护人员重用已删除的包的名称，则可能会发生包UAF攻击。攻击者可以持续监视注册表的包列表，并使用恶意删除的包。然后，尝试使用以前的软件包的用户将下载由攻击者发布的新的（恶意的）软件包。此外，如果一个项目集成了以前的包，更新过程将用恶意包替换良性包。
2. 软件包维护者帐户劫持攻击
3. 包装重定向劫持攻击(U3)
   • 在不影响目标包的当前维护者帐户的情况下劫持一个包
4. 镜像软件包覆盖攻击
   • 镜像仍然可能存储上游注册表中不存在的包。
   • 维护者发布内部包；可能不会同步注册表已删除的软件包。
5. 案例敏感性混淆攻击
   • 名称？
6. typosquatting
   • 一些注册表生态系统，如Maven 、npm和Go，使用一个分段包名方案，该方案由一个作用域段和一个名称段组成：前者在注册表中应该是唯一的，后者可以复制。在这种情况下，攻击者可以通过构建一个与受害者包具有完全相同的名称段和类似的作用域段的包来进行类型类型化攻击。
7. 软件包引用攻击（非注入
   • 将恶意代码直接输入到现有的包中
8. 镜像幽灵包攻击
   • 如果注册表镜像无法与包取消发布操作中的官方注册表精确同步，则已在官方注册表中未发布的一些包仍可以在镜像中访问。
9. 依赖性混淆攻击
   • 攻击者可以简单地将同名但版本号更高的恶意替代品发布给公共注册中心，迫使用户在不知情的情况下下载恶意版本。
10. 软件包版本的降级攻击
11. 软件包版本重用攻击
    • 注册表允许版本重用（即，使用相同版本号但已修改过代码的包），它可能允许攻击者偷偷地注入恶意代码。
12. 软件包篡改攻击
    • 没咋个看懂呢。

5.2 做法

1. 爬虫和包解释器
   • 爬虫收集包信息
   • 提取每个包的存储库信息（例如，注册表或镜像信息）、包的名称、版本、包的发布时间、维护者、联系信息、依赖项包和文件哈希值
   • npm和Maven中心允许我们直接从公共来源获取账户信息。
   • 对于package，通过源代码存储库URL提取他们的帐户信息。
   • 对于PyPI，通过联系信息来推断维护者的帐户。
2. 事件监视器和差异分析仪
   • 包的添加，删除，修改，程序包文件特定版本的内容是否被修改。
   • 对注册镜和相应的官方注册镜之间的内容进行了差异分析
3. 漏洞检测器
   列出了一些细节
   • 使用WHOIS查找服务，通过检查nx域状态（它表示一个未注册的域）来查找过期的域名，然后其帐户将被认为是易受攻击的。
   • 利用GitHub和GitLab提供的api来查找被删除的帐户。如果哈希值是两个元组存储库、包名、版本、哈希值的唯一差异，那么将检测版本重用。

5.3 结果

1. 首次揭示了其中6个潜在的攻击向量.
2. 设计并实现了RScouter工具，对六大主流开源软件生态进行了为期一年的大规模监测分析，共采集了超过400万个独立软件包，总计5300万个不同版本的软件包。
3. 发现有16807个包维护者帐号可被攻击者窃取，影响40327个软件包；PyPI和npm各有85192和38496个软件包受到Package Use-After-Free攻击威胁。
4. 发现了广为使用的镜像站存在多个安全问题，例如，国内某知名npm镜像站中有数千个包可被大小写混淆攻击，多个镜像站中存在着数以千计的恶意软件包，对镜像站的用户造成威胁。

6 Backstabber’s KnifeCollection: A Review of Open Source Software Supply对开源软件供应的回顾

前言

分析了 200 个来自 npm、RubyGems 和 PyPI 的恶意软件包，试图根据现有恶意软件包的特征，提取可用于检测新恶意软件的信息。

还提出了两种通用攻击树，以提供有关将恶意代码注入下游用户的依赖树以及在不同时间和不同条件下执行此类代码的技术的结构化概述。

第一个攻击树的目的是将恶意代码注入下游用户的软件供应链，而第二个攻击树的目的是在不同情况下触发其恶意行为。

6.1 攻击树1 注入恶意代码

目标：将恶意代码注入到下游软件包的依赖树中。

要将软件包注入依赖树中，攻击者可能会采用两种可能的策略，即感染现有软件包或提交新软件包。

1. 使用其他人未使用的名称开发和发布新的恶意程序包可以避免干扰其他合法项目维护者。但是，此类程序包必须由下游用户发现并引用，以便最终进入受害者程序包的依赖关系树中。
   • 可以通过使用与现有软件包名称类似的名称（抢注）或通过开发和推广木马病毒来实现
2. 感染已经具有用户、贡献者和维护者的现有软件包。
   • 攻击者可以模仿良性的项目贡献者。例如，攻击者可能通过创建带有错误修复或看似有用的功能或依赖项的拉取请求（PR）来假装解决现有问题。后者可以用来创建对使用先前描述的技术从头创建的攻击者-控制器程序包的依赖关系。
     • 此PR必须由合法的项目维护者批准并合并到主代码分支中。或者攻击者可能会通过使用脆弱或受到破坏的凭据或对安全敏感的API令牌将攻击者的全部恶意代码提交给项目的代码库。
   • 攻击者可以通过社会工程成为维护者。在任何情况下，无论恶意代码如何添加到源中，无论在哪里进行构建，它都将在下一个发行版本中成为正式软件包的一部分。

6.2 攻击树2 执行恶意代码

目标：一旦某个项目的依赖关系树中存在恶意代码，上图所示的攻击树就具有在不同条件下触发恶意代码的顶级目标。这样的条件可以用来逃避对特定用户和系统的检测和/或目标攻击。

条件执行会使恶意开源软件包的动态检测复杂化，因为在沙箱环境中可能无法理解或满足相应条件。

6.3 结果

从观察到的案例和相关工作中得出了两个攻击树。一种用于将恶意程序包注入开源生态系统，另一种用于执行恶意代码。这些攻击树可对过去和将来的攻击进行系统描述。能够创建第一个手动管理的恶意开源软件包的数据集，该数据包已在现实世界的攻击中使用。从2015年11月到2019年11月，它包含174个恶意软件包（npm 62.6％，PyPI 16.1％，RubyGems 21.3％）。

手动分析显示，大多数软件包（56％）会在安装时触发其恶意行为，另有41％使用进一步的条件确定是否运行。超过一半的软件包（61％）利用域名抢注将自身注入到生态系统中，而数据泄露是最常见的目标（55％）。这些软件包通常与操作系统无关（53％），并且经常采用混淆处理（49％）来隐藏自身。 最终可以通过不同的编程语言，通过重用的代码来检测恶意软件包的多个群集。

6.4 未来

希望有新的技术和工具来扫描整个程序包存储库中的可疑程序包，例如根据观察发现恶意代码可在同一广告系列的程序包甚至语言之间重复使用。在这种情况下，手动管理和标记的数据集允许有监督的学习方法，这些方法支持对恶意软件包的自动化和整个存储库范围内的搜索。此外，关于现有和新的缓解策略，这个文章提出的数据集可作为基准。

https://dasfreak.github.io/Backstabbers-Knife-Collection

7.Taxonomy of Attacks on Open-Source Software Supply Chains开源软件供应链攻击分类

7.1 前言

论文链接：https://arxiv.org/abs/2204.04008

Github链接：https://github.com/SAP/risk-explorer-for-software-supply-chains

项目链接：https://sap.github.io/risk-explorer-for-software-supply-chains

文章内容：研究人员对过去一段时间各种针对开源软件供应链攻击的系统化归类研究工作。

7.2 内容

首先展示了开源软件供应链生态。在当前的开源软件供应链生态中，和传统的企业（巨硬公司为代表）开发相比，参与的角色更多元化。

进行攻击向量的分类调研的流程：

1. 先对科研文献和网络相关资料进行大规模的收集，整理得出attack vector和safeguard
2. 对威胁模型和攻击树模型进行建模，得出初步的分类
3. 邀请领域专家和开发人员参与，确定最终的攻击向量分类和safeguard

制作了一个攻击模型，上面的项目链接，攻击树的根节点表示攻击者的顶级目标，该目标由其子目标迭代细化为子目标。根据细化的程度，这些叶对应于或多或少具体和可操作的任务。 比如：

可以互动式地查看整个攻击分类树，下面也有相关的参考文献

具体看safeguard