开源包托管服务存在的供应链安全问题

原文作者：Ruian Duan, Omar Alrawi, Ranjita Pai Kasturi, Ryan Elder, Brendan Saltaformaggio, Wenke Lee
原文标题：Towards Measuring Supply Chain Attacks on Package Managers for Interpreted Languages
发表会议：NDSS 2021
原文链接：https://arxiv.org/pdf/2002.01139.pdf

现代编程开发会依赖于各种功能丰富的库包, 许多编程语言都维护着一套包管理工具以及相应的代码托管平台, 这些的出现大大推进了开发的效率, 同样开发者们也能轻松地编写代码包发布给社区, 和社区成员进行协作分享和互动. 但随着社区规模的日益扩大, 带来的就是依赖包的信任问题, 也就是供应链安全问题.

本文我们来介绍一篇NDSS 2021上的论文"Towards Measuring Supply Chain Attacks on Package Managers for Interpreted Languages", 该论文大规模测量了当前主流的三个开源包托管平台(PyPi, Npm, RubyGems)上的代码, 并检出了339个新型恶意软件包, 其中有278(82%)个已被平台确认并移除.

包管理生态里的各个角色

首先作者将包管理生态分为了以下四种角色:

• 托管平台维护者: 负责平台的运行,管理和维护, 为开发者提供软件包的搜索和安装功能. 通常包含一个提供和管理软件包的WEB应用程序(比如pypi.org)和一个帮助访问包的客户端应用程序(比如pip). 托管平台要求开发者注册账户才允许发布自己的代码包.
• 软件包维护者: 负责软件包的日常维护和开发, 将代码托管到平台上, 通常使用平台如Github来进行协作开发, 可以使用持续集成/持续开发流程自动化地进行包的编译和部署.
• 开发者: 普通开发者可以进行代码包的开发, 同时也是发布包的直接使用者.
• 终端用户: 终端用户是供应链的下游, 虽然没有直接跟包和平台进行接触, 但用户会使用到最终的产品.

平台方安全检查

论文作者对PyPi/Npm以及RubyGems的安全性分三部分(功能性/代码审查/响应措施)进行了测量评估.

• 功能性检查侧重于检查平台方对包管理者的认证授权以及一些安全性的辅助功能.
• 审核检查则在于平台方检出存在漏洞代码/恶意代码包的能力. 遗憾的是测试的三个平台没有一个具备该能力.
• 补救响应功能则在于平台方在出现安全事故后是否积极地根据报告移除代码包, 封禁攻击者账户, 通知受害者尽快移除本地的危险包以及提供修复建议.

攻击向量

• 利于平台服务的漏洞来篡改或注入恶意代码
• 别名抢注: 注册跟热门包相似名称的包, 使不小心下载错误包的开发者执行恶意功能.

恶意包的功能通常包括窃取用户的敏感信息, 注入后门, 加密文件并进行勒索, 用于挖矿, 传播病毒, 黑产等.

分析方法

• 元数据分析: 提取包的元数据信息(比如包名,作者,发布版本,下载次数,依赖等)标记出可能的恶意包.
• 静态分析:
• 敏感API标记: 标记网络/文件系统/进程/代码生成相关的API, 并可用于后续的数据流分析.
• API使用情况分析: 将源码解析成AST形式然后搜寻标记API的使用情况.
• 数据流分析: 检查代码的数据流的源, sink点和传播节点
• 动态分析:
• 执行代码包: 通过直接的install命令来安装, 对于嵌入在包内的二进制则在隔离的docker环境内进行执行, 对于import包则触发其包导入时的初始化逻辑, 对于导出函数则进行fuzz测试来触发其功能.
• 动态跟踪: 使用sysdig来捕获代码运行时的系统调用trace.
• 启发式规则: 作者定义了一系列的启发式规则来帮助分析和检测.