原文标题：Towards Measuring Supply Chain Attacks on Package Managers for Interpreted Languages

原文作者：Ruian Duan, Omar Alrawi, Ranjita Pai Kasturi, Ryan Elder, Brendan Saltaformaggio, and Wenke Lee.

原文链接：https://arxiv.org/pdf/2002.01139.pdf

原文来源：NDSS'21

笔记作者：[email protected]

笔记小编：[email protected]

1 背景介绍

包管理器已经成为现代软件开发过程的重要组成部分，它们允许开发人重用第三方代码、共享自己开发的代码、最小化他们的代码库，并简化构建过程。然而，在最近的报告中显示，包管理器已经被攻击者滥用来分发恶意软件，给开发人员和最终用户带来重大的安全风险。

安全研究员已经发现了这种攻击，并提出了一些解决方案来解决类似问题。Zimmerman 等人系统的研究了609个已知的安全问题，揭示了Npm生态中存在巨大的安全风险。另一方面， BreakApp 可以隔离不可行的包，来防御对证书的窃取和敏感数据的访问，但是还是不能阻止挖矿程序和后门。此外，还有很多解决方案，假设存在信任关系，并侧重于查找包中的错误，而不是恶意包。更糟糕的是，一些攻击是非常邪恶的，他们会利用社会工程学来伪装自己，首先发布一个“有用的”包，然后等待目标来使用它，然后再进行更新，植入恶意代码。尽管很多安全研究人员正在积极研究这些攻击方法并提出解决方案，但是这些方法都临时性的或者一次性的解决方案。更好的方法是了解软件供应链滥用程序，以及攻击者是如何利用它们的。同时这个方法必须能够客观的比较不同生态系统中安全的现状。

2 论文主要贡献

作者该篇文章主要做出了以下贡献：

• 分析了供应链生态安全性，并提出了 MALOSS 框架
• 使用 MALOSS 框架用以检测包的安全性，并取得了一定成果

3 方法

为了更加全面地评估包管理生态系统中的安全隐患，作者首先对 312 个供应链攻击样本进行了分析，然后对包管理生态系统中的管理和开发过程进行建模，设计了一个定性分析的框架，以确定当前 PyPI、Npm 以及 RubyGems 三个包管理生态系统可能面临的安全风险。

本文整体对比框架如下图：

在该对比框架中，作者首先将包注册管理中心的特征分为三类（即功能性、审查和补救措施），并分别表明了这些特征在不同的包管理平台中是否具有强制性。在该框架当中，作者人工评估了功能性的每个特性，而对于审查和补救措施特性，作者则直接联系了包注册中心的维护人员，此外还从包注册中心的指导文档和博客中收集信息以进行辅助分析。

4 供应链攻击分析

作者首先提出了供应链攻击中的主要角色，并调研了当前技术和攻击报告中所涉及的攻击向量和恶意行为，总结出了一定的攻击手段。攻击者往往是通过对上游人员（即包管理中心的管理人员以及包开发者）的攻击，从而影响和攻击到下游人员（即利用现有包进行开发的开发人员和终端用户）。

定性分析及相关技术

作者通过注册表供应链攻击的分析，发现当前注册中心的审查功能十分不健全，大多依赖于开源社区的报告，没有自动化检测的能力。因此需要创建一个具有审查功能的流水线，用于分析包并发现潜在的攻击。下图是审查工作流。

1. 元数据分析

元数据分析集中收集包的辅助信息（例如包名、作者、版本、下载量和依赖关系），并根据不同的标准聚合它们，所有信息都直接从注册表API获取，元数据分析可以标记可疑包，以及识别与已知恶意软件类似的包。例如：包名的编辑距离可以帮助它们的名称对包进行分组，允许精确定位流行包的伪造包；作者信息可以对包进行分组，允许识别来自恶意包作者的包。元数据分析还包括包中附带的文件类型，以确定是否存在二进制文件或本地扩展。

2. 静态分析

静态分析侧重于分析每个包管理器对应的解释语言的源文件，跳过嵌入的二进制文件和本地扩展。分析包括三部分：API手工标注、API使用分析和数据流分析。为了在存在大量依赖的情况下实现高效处理，我们使用包摘要执行模块化分析。

3. 动态分析

动态分析集中分析执行包时的系统调用。与静态分析相比，动态分析考虑源文件、二进制文件和本地扩展，但它对运行时的环境没有可见性（例如不能跟踪eval）。分析由两部分组成，使用Docker容器作为沙箱执行包，使用sysdig进行动态跟踪，来提高效率和可用性。

5 评估实验及分析

实验环境主要使用了20个本地工作站，硬件环境为64GB内存和8个3.60GHz的Intel Xeon cpu，操作系统为Ubuntu 16.04。

实验主要从数据分析、静态分析和动态分析三个方面来分析供应链攻击的特点和脆弱性，并提出一定的补救措施。实验共检查了PyPI处理的包为 186K，Npm处理的包为 997K，RubyGems处理的包为 151K。

元数据分析

左图可以看出不同注册中心有相似的分布，意味着跨注册中心有着相似的发布模式。而右图表面大多的数据包有着更多的依赖项，一旦收到破坏，因此产生的影响也会很大。

静态分析及动态分析

左图展示了使用可疑 API 下载量前10K包的百分比。该图显示 7% 的 PyPI 包和 10% 的 RubyGems 包使用代码生成 API。此类代码生成的 API 不仅常用于供应链攻击，而且如果它们的输入没有得到校验，也可能存在代码注入漏洞。

右图可以看出，Npm 和 PyPI 比 RubyGems 拥有更多带有意外网络活动（IP访问和DNS解析）的包。需要注意的是，安装期间的意外行为会被依赖包放大，导致右图中出现大量标记的包，随后通过检查依赖树来消除这种误报。

6 总结与展望

尽管 MALOSS 确实有着不错的实用价值，但是还面临以下局限性。

• 运行环境较为单一
• 静态分析需要大量人工手段，开销不定
• 均使用现有分析工具，并未能工具创新

安全学术圈招募队友-ing 
有兴趣加入学术圈的请联系 secdr#qq.com