开源风险治理平台“伏羲”在开源生态投毒检测中取得进一步重要进展,助力开源软件安全治理
2024-12-25 00:0:0 Author: mp.weixin.qq.com(查看原文) 阅读量:6 收藏

研究背景:恶意代码威胁软件供应链安全

开源软件已成为现代软件生态中不可或缺的一部分。然而,随着开源软件的普及,软件供应链安全问题日益突出,给开源软件生态系统带来了重大威胁[1]。在软件供应链安全风险中,恶意软件包投毒是一种常见的攻击手段,即将恶意代码注入到托管在软件包仓库中的软件包中,并伪装成合法的软件包,进而诱导开发人员下载和调用,从而感染用户主机,达到执行恶意行为的目的。近年来,两个被广泛使用的包管理仓库NPM和PyPI中涌现出大量的恶意软件包[2],对下游应用程序带来了严重的安全威胁。根据 Sonatype 2024年度软件供应链报告显示[1],2024年发现的恶意软件包数量是2023年的2倍,并呈现出快速增长的趋势。

图1 Sonatype 2024年度软件供应链报告

面对软件包投毒攻击,自动化恶意软件包检测工具是有效的方法之一。尤其是 NPM,作为最大的 Node.js 包管理和分发中心,拥有超过两百万个软件包,因此有效检测恶意软件包至关重要。目前已有不少自动化恶意软件包检测工具,一些方法采用静态分析或动态分析,并基于启发式规则,虽然简单高效,但误报率高。另一些方法使用无监督学习来检测新的恶意软件包,也有一些方法通过提取元数据和源码特征来训练检测分类器,但这类方法在将代码转化为离散特征表示时往往丢失了恶意代码行为,导致误报率较高。还有一些方法采用提示工程来检测恶意软件包,但由于使用成本高,使得大规模检测难以实现。

恶意软件包示例

以恶意软件包colour-string-1.5.3和bitcionjslib-1.0.0为例。如图2所示,colour-string-1.5.3软件包中的恶意行为包含敏感 API 调用之间的控制流和数据依赖,例如http.get、fs.createWriteStream、fs.chmod和child_process.exec等 API。然而,现有工具使用预定义规则(如正则表达式匹配)提取这些 API 调用时,只能将它们映射为粗粒度的行为,例如将 http.get 映射为网络操作,或者将 API 映射为向量的表示,而丢失了其语义信息。此外,现有工具还往往未能提取像 neroli.write 这样的敏感 API 调用,也未能追踪 API 调用之间的控制流和数据依赖关系,导致了较高的误报率。

图2 colour-string-1.5.3恶意代码片段

此外,恶意软件包还会使用第三方依赖实现恶意行为。如图3所示,bitcionjslib-1.0.0软件包中的恶意行为通过引入第三方依赖 nodemailer 来实现窃取,使用敏感 API createTransport 连接邮件服务器,并使用 sendMail 发送邮件。现有工具通常忽略第三方依赖中的敏感 API,导致较高的漏报。

图3 bitcionjslib-1.0.0恶意代码片段

总而言之,目前的检测工具存在以下几点不足:

●  现有工具无法准确、全面地建模恶意行为,恶意行为不仅涉及敏感API的调用,还包括这些API调用之间的控制流和数据依赖关系。

●  现有工具对敏感API的抽取依赖于人工标定,并且不支持第三方依赖中的敏感API抽取。

●  现有工具在实际使用中需要大量人力投入,原因在于较高的误报率以及缺乏详细的定位信息用于辅助查看,例如恶意代码具体所在的位置。

研究进展:基于图模型的行为分析与匹配的NPM恶意软件包检测技术

复旦大学CodeWisdom团队的开源风险治理平台“伏羲”提出了一种基于图模型的行为分析与匹配的NPM恶意软件包检测技术SpiderScan,能够有效建模软件包行为并实现恶意代码检测,助力开源软件安全治理。相关研究论文“SpiderScan: Practical Detection of Malicious NPM Packages Based on Graph-Based Behavior Modeling and Matching”已发表于ASE 2024。该工作的流程框架如图4所示,包含五个关键组件:可疑行为提取、脚本分析、混淆检测、恶意检测,以及恶意验证。

图4  SpiderScan的流程框架图

总体流程包含离线阶段和在线阶段两个阶段,在离线阶段,针对现有收集得到的恶意软件包,通过可疑行为提取组件构建程序的可疑行为图。在可疑行为图中可能包含一些与恶意行为无关的敏感API,这些API并非恶意行为所必需的一部分。因此,有必要通过半自动化的裁剪方式,提取出最小的恶意行为图。通过这一过程,我们提取出一系列用于表示不同恶意行为的图,记为恶意行为图(Malicious Behavior Graph,MBG),用于后续的图匹配过程。在在线阶段,输入待检测的 NPM 软件包后,首先分析其配置文件中包含的安装脚本,识别是否存在恶意行为,并确定安装阶段和导入阶段的执行文件入口。接着,对代码文件进行混淆检测。对于未经过混淆处理的软件包,分别生成不同阶段的程序可疑行为图,并与离线阶段生成的已知恶意行为图进行匹配,从而实现恶意行为的检测。对于成功匹配的特定恶意行为,基于动态分析,采用 API 挂钩的方法获取指定 API 的参数内容,并结合 API 类型,由LLM进行进一步的恶意行为判定。

(一)脚本分析:分析软件包配置文件package.json中包含的安装脚本和main入口文件,并识别安装脚本中是否存在恶意的shell命令。具体而言,通过正则匹配分析软件包在安装阶段和导入阶段的执行文件入口,这些入口用于后续行为图生成。对于安装脚本,使用LLM进行恶意行为检测,判断脚本是否涉及敏感数据读取和上传等恶意操作。为了提高检测精度,工具还利用现有的恶意行为案例和已知攻击数据集来优化LLM的检测能力。

(二)混淆检测:恶意代码常常采用混淆手段以掩盖其恶意行为,检测工具随后对混淆代码进行检测。具体而言,混淆检测的特征包括代码的语义信息(如代码行数、空白字符数量、混淆标识符数量等)和句法特征(基于AST遍历序列和n-grams模型提取)。检测过程依赖于训练得到的随机森林二分类器,若检测到混淆,则工具判断代码是恶意的。

(三)可疑行为提取:基于静态分析工具Joern生成程序行为图(PBG)并提取敏感API调用,进而构建可疑行为图的过程。具体而言,给定执行入口,遍历控制流图以模拟程序的执行过程,生成程序的行为图,在遍历的过程中,将遇到的节点加入到程序的行为图中,并根据原始控制流图和数据依赖图中边的信息,向行为图中添加相应的边。特别地,在遍历的过程中,主要针对四个类型的节点做分析处理,包括:

●  导入节点(import或require):导入语句用于导入模块,当遇到这类节点时,分析所导入模块的类型,将其分类为内置模块、第三方模块或本地模块,并记录对应的别名。

●  函数调用节点(Function Call):函数调用语句是指对已声明函数的调用。当遇到此类节点时,根据调用图(Call Graph, CG)定位相应的被调函数(Callee)。接着,基于数据依赖图判断是否存在与该函数调用参数相关的数据依赖。如果存在这样的依赖,通过数据依赖边将函数调用节点与被调函数节点连接起来;如果不存在,则使用控制流边将它们连接。

●  API调用节点(API Call):API调用语句是指调用内置模块或第三方依赖提供的API。每个API调用节点可以分为敏感或非敏感两类。对于识别敏感的内置API,我们通过获取API的官方文档,并预先设定相应的敏感行为类型,例如文件读取、网络请求等,然后利用LLM对API的官方描述进行分类,以识别敏感API。对于敏感的第三方API,我们通过分析源代码和API的注释,同样借助LLM进行分类,从而实现对敏感API的识别。对于敏感API,其对应的返回值类型也会被记录,以辅助对返回值所涉及的API调用进行的分析。

●  赋值节点(Assignment):针对赋值语句,首先分析右侧表达式的类型。如果右侧表达式为API调用,则进一步分析该API调用的行为类别和返回值类型,并将这些信息绑定到赋值左侧的对象上。

最终,工具生成一个只包含敏感API调用的子图(SBG),其中节点之间的边表示控制流或数据依赖关系。

(四)恶意检测:通过将敏感行为图与离线阶段构建的恶意行为图(MBG)进行映射和匹配。具体来说,工具会寻找所有可能的从SBG到MBG的映射,要求映射后的API调用节点的行为类型一致。映射完成后,工具会检查MBG中节点之间的控制流和数据依赖边是否也存在于SBG中。如果存在匹配,表示检测到恶意行为,工具将输出匹配到的代码及其文件位置。

(五)恶意验证:对于部分匹配的恶意行为类型,可能会出现误报,因为非恶意行为也可能呈现相同的行为图结构。为了减少误报,工具采用动态分析和LLM进行进一步分析,最终确认是否为恶意行为。

实验评估:助力开源软件安全治理

为了评估该方法的有效性,复旦大学CodeWisdom团队进行了大规模的实验评估,我们收集了公开数据集以及来自安全博客中披露的恶意软件包,为了更好地验证工具的有效性,我们对收集到数据进行了去重。实验对比了四个SOTA工具,如图5所示,SpiderScan在数据集中达到了96.5%的准确率,89.7%的召回率以及92.9%的F1-Score值,其中F1-Score相比于其他SOTA工具提升了8.7%至34.4%。

图5 数据集上工具有效性评估结果

为了进一步评估该方法的实用性,复旦大学CodeWisdom团队将工具转换为原型系统,并在实际NPM生态中进行了实时检测。为了对比SpiderScan和其它工具在真实场景下的检测效果,我们也部署了其它SOTA工具,并持续监控了NPM在三个月内新发布的软件包。SpiderScan共计检测到了249个新恶意软件包,涉及数据窃取、木马、反弹Shell等多种恶意行为,并且这些恶意软件包均已获得NPM的官方确认,同时收到了70封感谢信。如图6所示,SpiderScan相较于其它工具误报率降低了25.4%-59.1%,且有着最低的漏报率(SAP因为其报告数量过大,超出了人工审核的范畴)。这一结果不仅体现了工具的实用性,且较低的误报率还显著减少了人工审核的数量,从而节省了人力资源和审查成本。

图6 真实场景下的检测结果

目前该原型系统仍在持续实时检测新发布的软件包,旨在第一时间发现恶意软件包以降低其对开源软件供应链安全的影响。此外,我们也将基于图行为分析与匹配的方法应用于PyPI恶意软件包的检测。目前该系统已经检测到了超过2000+新的恶意软件包,并收到官方1000+感谢信。

关于“伏羲”

“伏羲”是复旦大学CodeWisdom团队推出的开源风险治理平台,旨在推动学术与合作交流,同时提高开源风险的治理水平。“伏羲”在高质量开源软件供应链知识(包括漏洞知识等)汇聚的基础上,利用高精度程序分析技术(包括代码差异分析、调用图分析等)实现多种开源软件供应链风险(包括安全风险、法律风险等)的分析与治理服务。目前“伏羲”提供了漏洞库、组件库等知识,以及漏洞传播影响分析、生态投毒检测等服务。“伏羲”将在漏洞质量增强方向持续攻关,打造高质量漏洞知识库。可以点击文末的“阅读原文”,跳转到开源风险治理平台“伏羲”进行体验和试用,也欢迎提出宝贵的意见和建议!

本文作者:黄艺恒、陈碧欢

往期回顾:

复旦CodeWisdom团队发布开源风险治理平台“伏羲”

开源风险治理平台“伏羲”在开源生态投毒检测中取得重要进展

开源风险治理平台“伏羲”对 Go 生态进行了大规模分析

开源风险治理平台“伏羲”在漏洞影响组件识别中取得重要进展,助力开源漏洞质量增强

[1] Sonatype. 2024. State of the Software Supply Chain. Retrieved from Dec 17, 2024 from https://www.sonatype.com/state-of-the-software-supply-chain/Introduction
[2] The Hacker News. 2024. Malicious npm Packages Found Using Image Files to Hide Backdoor Code. Retrieved Dec 17, 2024 from https://thehackernews.com/2024/07/malicious-npm-packages-found-using.html

文章来源: https://mp.weixin.qq.com/s?__biz=MzU4NDU4OTM4OQ==&mid=2247511306&idx=1&sn=868e24909f5221b1cfbc2b14588dc07f&chksm=fd956428cae2ed3e42a9b7c315e538fed6c87f79831f27ce3b625a57cc6a87d20156ff5c1009&scene=58&subscene=0#rd
如有侵权请联系:admin#unsafe.sh