论文阅读--Towards Measuring Supply Chain Attacks on Package Managers for Interpreted Languages
论文阅读——Towards Measuring Supply Chain Attacks on Package Managers for Interpreted Languages
论文链接：https://cyfi.ece.gatech.edu/publications/NDSS_21.pdf
开源项目地址：https://github.com/osssanitizer/maloss
这篇论文来自NDSS 21，第一作者是来自佐治亚理工学院的Ruian Duan。这是一篇对解释型语言的包管理生态的评估研究。其中有很多人工分析部分工作，但是做得非常全面，系统，细致。
引言
包管理器（package manager 或称registry）在现代软件开发过程中扮演十分重要的角色。通过包管理，开发者可以直接复用第三方代码，防止重复造轮子，实现高效开发。然而近年来包管理被发现存在安全问题，攻击者可能通过包管理发起供应链攻击：攻击者向包管理上传恶意包，让供应链下游开发者使用这些恶意包，实现攻击终端用户。
为了分析评估包管理供应链生态以及强调包管理供应链攻击的危害性，论文设计一个针对包管理的分析框架，定性评估包管理的功能特征和安全特征，并设计了针对解释性语言的包管理器分析工具 MALOSS,综合运用元数据分析、静态分析和动态分析技术，发现和证明包管理器中缺失审查机制会导致存在许多在野恶意包。作者研究了来自PyPI、Npm和RubyGems的100多万个包，发现了339个新的恶意包，作者也向注册管理机构报告了这些包以供检测。包管理器维护者从339个报告的包中确认了278个(82%)，包括3个CVE认证，其中3个包的下载量超过100，000次。
主要内容
设计与实现
一、包管理生态
如图一包管理生态所示，按照包从开发、管理、使用的过程，论文作者将包管理生态划分为4个部分：
（1）Package Maintaining Framework (PM)
在这个阶段，包开发人员会使用代码托管平台（e.g. github）进行包的开发、迭代和部署,他可能会在开源社区接收其他开发者的修改请求。
（2）Registry Maintaining Framework (RM)
Registry为各种包提供管理仓库并为开发者提供接口，是辅助开发者访问下载包的管理角色。在这个阶段，由registry web app 对包开发者上传的包进行管理，由registry client binaries 向开发者提供查询和访问包接口。PM要向RM发布包前，需要进行注册。应用开发者向RM查询和安装包时无需任何凭证。
（3）App Development Framework
开发者可以向包管理器下载包，重复造轮子。通常，包的漏洞也需由开发者修复。
（4）Ended User
终端用户使用开发者开发的应用或服务，虽然不直接接触包，但是作为整条供应链的利益端，驱动供应链。
二、定性分析
首先，为了文章针对包管理器生态进行深入分析，以了解哪个部分被攻击者滥用，谁应对此负责，如何最好地防止此类攻击，以及可以采取什么措施进行补救，作者结合已了解的攻击实例和自身经验理解设计了如图2所示的分析框架，包括包管理的功能性、审查机制和补救方法的评估。比如包管理器的功能模块，评估对上游包开发者（package maintainers）提供的注册方式、发布包的方式和管理包的方式，对下游developer考虑查询包方式和安装包方式。作者使用这个框架对三个使用最热门的包管理器PyPI、Npm、RubyGems做了分析，发现三个包管理机制在审查方面没有均没有任何措施，因此作者认为这将导致现在存在很多在野恶意包。
三、程序分析
因为包管理器没有审查机制，所以论文设计一个如图3所示的分析工具对大规模已发布的包进行分析，发现恶意攻击。该工具结合元数据分析、静态分析和动态分析手段，不过动静态分析均使用现有成熟技术，并且有较多的人工验证部分。
（1）元数据分析（Metadata Analysis）
元数据分析侧重于收集包的辅助信息(如包名、作者、版本、下载和依赖关系)，并根据不同的标准对它们进行聚合。所有信息都是直接从注册表API中检索的。元数据分析可以标记可疑包，以及识别与已知恶意软件相似的包。例如，可以根据名称对软件包进行分组，从而精确定位热门软件包的候选拼写；作者信息有助于根据作者对包进行分组，从而识别来自已知恶意作者的包。
（2）静态分析（Static Analysis）
静态分析侧重于为每个包管理器分析相应解释语言的源文件，并跳过嵌入的二进制文件和本机扩展。该分析包括三个部分，手动API标记、API使用分析和数据流分析。
（3）动态分析（Dynamic Analysis）
动态分析侧重于执行包和系统调用。与静态分析相比，动态分析考虑源文件以及嵌入的二进制文件。
（4）TP验证（True Positive Verification）
设定启发式规则判断，并人工分析fp后更新规则。
实验评估
如图4所示，作者按照制定好程序分析流程对PyPI、Npm和RubyGems这三个包注册中心的包进行分析，其中PyPI有186785个包，Npm有997561个包，RubyGems有151783个包。作者最终发现了339个新的恶意包，其中包括PyPI中的7个恶意包、Npm中的41个恶意包和RubyGems中的291个恶意包。作者分别向管理人员报告了这些包，管理人员确认和并删除了其中的278种(82%)，其中7种来自PyPI，19种来自Npm，252种来自RubyGems。在移除的包中，对其中三个(即paranoid2、simple_captcha2和datagrid)下载量超过100k的包，作者还申请了CVE(CVE 2019-13589、CVE-2019-14282、CVE-2019-14281)，希望潜在受害者能够及时得到补救通知。
作者对供应链攻击的攻击手段、恶意行为、恶意包的生存周期（persistence）、恶意包的影响（impact）和恶意包的感染范围（infection）进行统计分析。值得一提的是，“恶意包的影响”通过包的下载量体现，而下载量无法直接反映“dev和user的感染范围”，由于malicious包里会有较多DNS查询行为，所以如图5所示论文作者通过人工分析获取恶意包中的DNS查询信息，然后与一个ISP合作，收集被动DNS（passive DNS query)。比如n.cdn-radar.com在18年12月被移除后仍然有DNS查询，说明registry没有进行remediation通知。
总结
这是一篇对解释型语言下包管理生态的评估性论文。整体来看做得非常全面，系统，细致。首先文章提出一个分析框架来定性地评估解释性语言的包管理器的功能和安全特性，然后利用应用程序分析技术研究包管理被滥用问题。其中作者利用成熟的分析技术设计了一个分析工具，但是最终从100多万的包中发现339个新的恶意包，其中有278个被确认，认证了3个CVE，检测效果非常不错。
检测效果不错主要原因其一是分析技术较大，论文找了超过100万已发布包进行检测；其二是该工具存在一些借助经验和专业知识的人工分析部分，如TP规则。论文使用一个非创新非自动化的工具这点比较让人疑惑，但是毕竟这篇论文的重点在于揭露包管理供应链生态的安全问题，引起社区关注，所以这个分析其实并非论文核心，该工具只是作者为了证明 包管理器缺失审查环节会导致存在很多在野恶意包。同时通过本论文也可以看出，包管理供应链上确实存在较大的问题。在平时的学习中大家都会经常用到如Npm等包管理，这篇文章也启发了我关注身边的安全问题。