NodeJS 应用仓库钓鱼

前言

城堡总是从内部攻破的。再强大的系统，也得通过人来控制。如果将入侵直接从人这个环节发起，那么再坚固的防线，也都成为摆设。

下面分享一个例子，如果利用应用仓库，渗透到开发人员的系统中。

应用仓库

应用仓库对于开发人员再熟悉不过了。apt-get，brew，yum，npm ... 无非就是个命令行版的 App Store，方便各种工具以及依赖库的安装。

他们大致原理都差不多。今天讲解的是 NodeJS 应用仓库 —— NPM 的安全试探。

NPM 平台

如果 NodeJS 只能单机运行，那就和 WScript 差不多了。好在 NPM 平台的出现，让整个社区互动起来。

开发者可以通过 NPM 安装需要的库，用户也可以通过它完成项目的安装。以至于短短几年时间里，数以万计的 NodeJS 项目被发布到 NPM 上，每天都有几千万次的下载量。如此大的用户群体，是否会存在安全隐患？

仓库篡改

最容易想到的，就是 NPM 账号被盗。一旦密码被泄露，攻击者就可以发布项目的新版本。正常用户一旦更新，就安装上了恶意脚本程序。

不过，要获取平台账号谈何容易。而且活跃度高的项目被篡改，很快就会被发现。

仓库钓鱼

改人家的东西肯定不靠谱，那就只能用自己的。但自己凭空创建的项目是毫无人气的，因此得设法引诱部分用户过来。

攻击者可以取一个和活跃项目差不多的名字。例如人气很高的 uglify-js，可以山寨一个叫 uglifyjs 的李鬼。一旦用户拼错了单词，就安装上了冒牌的项目。

为了不让用户发现，可以直接克隆原版项目，让用户能和正常版本完全一样的使用，很难发现其中的破绽。然后在某些隐蔽的模块里做些手脚，一旦用户运行了脚本，其中的恶魔就释放出来了！

安装时入侵

如果用户发现装错了项目，还没运行就卸载了，是否就无法入侵了？

事实上，NPM 提供了无比强大的功能，甚至可以在安装时就能 执行额外的命令 。

在 scripts 字段里，可以定义各个阶段的命令扩展。

例如 postinstall ，即可在仓库包安装完成后执行。

这样，只要用户敲入 npm install xxx 时手一抖，系统就可能被入侵了。

这听起来似乎有些天方夜谭。不过经测试，一个山寨的活跃项目，每天也有几十到上百的安装量（误装量~）。虽然数量很少，还不到原版的一个零头，但都是潜在的高质量用户。

其中大多都是开发人员，一旦系统被控制，即可渗透到企业内网里。

持续性入侵

一旦开发人员的系统被控制，产生的后果远比想象中的严重。除了各种信息被泄露外，还会有更恐怖的事。

以 uglify-js 为例，如果开发人员安装了钓鱼版本，那么会出现什么后果？

它本身就是一个类似编译器的压缩工具。把测试完毕的源代码，转成不可读的黑盒程序 —— 这很有可能就是上线前的最后一步，如果这个环节被黑客操控，那么即使已通过审核的源码，也难逃魔掌了。

也许，钓鱼工具会在压缩后的脚本里插入一段隐蔽的 XSS，开发者不仔细查看很难发现。一旦脚本被发布，线上成千上万的用户就遭殃了。

攻击者不费一兵一卒，直接从最源头攻下这个堡垒。

当然，不仅仅可以感染 Web，其他客户端的更有可能。一些很少关注的开源库，或者头文件代码，都可能是恶意代码的藏身之处。

钓鱼推广

毕竟手误的用户是有限的。为了能扩大感染量，不排除攻击者会主动推广自己的钓鱼项目。

当然，这种推广不会太明显，甚至根本完全感觉不到其中正真的意图。

攻击者可以转载一些近期热门的文章，然后将其中的演示地址替换成自己的钓鱼项目。于是，前来围观的看客们就在毫无防备的情况下，被悄悄控制了。

或者更加直接的，在论坛或社交圈里推广自己的项目，并配上一些亮瞎的文字和炫酷的图片。于是一些好奇心强的人们，正好中了攻击者的下怀。

总结

除了 NPM 外，其他一些无需审核的应用平台，都有可能出现钓鱼应项目风险。

因此，平时安装项目时，得格外小心。忘记了名字的项目，必须得查证后在安装。

同时，对于一些来路不明的项目，也得谨慎尝试。毕竟，安装一个项目和直接打开一个应用程序的意义是一样的。