微软不作为:VSCode 恶意插件层出不穷

作者:Sender Su  来源:本站原创  发布日期:2024-10-06  最后修改日期:2024-10-07

放长假其实挺无聊的,到哪里都是人从众,还是写写公众号罢了。

微软的 Visual Studio Code(VSCode)已经成为很多程序员的必备代码编辑器甚或是完整的开发环境,甚至诸位读者在读的这篇文章,也是笔者在 VS Code 上起的稿。

不过,VS Code 已经成为软件供应链攻击的重要目标!

article banner

笔者:国际认证信息系统审计师、软考系统分析师、软件工程硕士

最新的情况是 Lehmann Lorenz [1] 在社交平台上发布关于他自己差点中招的经历。

据 Lehmann 称,幸亏他不是使用 Windows 操作系统(不支持 PowerShell 脚本),否则就只要点击一下鼠标,恶意扩展程序就会得以有效运行,他的计算机就无可避免地沦陷。

情况

故事起因是 Lehmann 是一位区块链开发人员,使用 Solidity 是必然的选择。因此他打算安装一个 VSCode 扩展以自动进行代码风格整理,这几乎是每个程序员都会做的事,除了为了避免降本增笑而故意写屎山代码的之外......于是他用关键字查找到相关的流行扩展并点击了安装按钮。

malicoius extension

图片来自@LehmannLorenz

然而,这个看上去非常流行、5星好评、下载量达一百七十万次甚至比真的还多的插件,是个假冒的恶意插件。

唯一能直观地发现的特征只是这个插件的开发者未经验证(unverified)。以及如果再细心点,会发现这些好评和下载量,居然都是在一天内达成的。

malware detail

图片来自@LehmannLorenz

这必然是通过僵尸网络刷出来的下载量和好评。

至于验证的蓝标,实际上要获得它也相当简单:

按 VSCode Marketplace 的规则,只需要创建一个域名,通过设置DNS解析验证的方式与发布扩展的账户相互绑定,扩展的介绍上就会被打上蓝色的标记:Verified Domain。

只是这个“域名已验证”,很容易被误解为该扩展已被验证无害。熟悉域名欺骗手法的读者都应该懂。

分析

事后分析的具体情况包括:

插件在安装时运行了其中包含的 extension.js 文件。这个文件被混淆。Lehmann 在其他朋友的帮助下对该文件进行反混淆后会发现,这个 JS 文件执行的操作是秘密地从一个 .ru 域名后缀的服务器下载了一个5MB大小名为“1.cmd”的脚本文件并运行。

当然,1.cmd 这文件也是被混淆了的,Lehmann 对该脚本同样进行了反混淆处理,并在还原得到的脚本命令中加插了输出过程日志的命令以跟踪观察其执行过程,这些都是程序员基本功了。

通过在虚拟机中运行该脚本,Lehmann 发现该脚本文件实现的攻击过程是利用了 PowerShell,且完全在内存中运行,动态地创建对象和调用对象方法,属于典型的无文件恶意软件攻击。为了避免被检测,脚本文件还使用了 AES 加密封装远程加载的恶意代码,而且该恶意代码还会检查自己是否在虚拟机环境中运行而避免被逆向工程。

相当完整和有效的入侵技巧组合拳。完整的分析报告可以在这里找到: 

https://hybrid-analysis.com/sample/e96f8f61e3af77c429ae6af54c128f7b8420a45a0a63bdfcacd682773b8e5fc1/66fd73bb76b66e90c507e4b9

Lehmann 还使用了 JoeSandbox 对 1.cmd 进行了检查,JoeSandbox 报告称其属于 Quasar RAT[2]。

Quasar RAT 是一个开源的 Windows 远程管理工具,可能是因为被滥用得太厉害,作者在不久前已经停更了该项目并将之归档[3]。

由于 Lehmann 不是网络安全人员,所以对恶意插件的分析就到此为止。有兴趣的读者还可以到 VirusTotal 查看其它分析发现。地址:

https://www.virustotal.com/gui/file/e96f8f61e3af77c429ae6af54c128f7b8420a45a0a63bdfcacd682773b8e5fc1/
原委

其实在不久之前也就是2024年的6月份,已经有研究员发现[4],VSCode 的扩展市场也就是 Visual Studio Code Marketplace,夸张点说,是个黑客乐园。

重点是,终端安全软件对安装到 VSCode 的恶意扩展难以进行检测和告警,原因在于 VSCode 的底层平台:Electron。

基于 Electron 实现的 VSCode 在运行时会频繁创建和终止子进程,以及频繁读取用户安装的 VSCode 插件的支持数据,终端安全软件难以从行为上判别 VSCode 内的某个插件的行为是否存在风险。

研究员创建了名为 ExtensionTotal 的工具对 VSCode 的扩展进行检测,当时就发现了至少1283个扩展包含了可被检测的恶意代码,且总共被下载安装了2.29亿次之多[5](不排除有刷量)。

这片乐土的成因,就是 VSCode 的扩展市场缺乏控制和代码审查机制,导致要滥用该市场是相当容易。而且,VSCode 的扩展程序没有通过细分权限进行功能限制,一旦下载安装运行就和 VSCode 本身同等权限,可以读写文件和执行任意代码。

更可怕的是,通过利用该市场而瞄准的关键目标都是计算机专业人员,如果由此达成软件供应链攻击,可谓是效益巨大。

展望

其实早在2018年,VSCode 的 github 项目上就有人通过 Issue 提出了非常详细和完整的建议[6],认为应该对扩展程序增加权限控制、安全沙箱和更新管理等功能。

但截止本文编写之日,该 Issue 在经历了三年又三年的讨论后仍处于 Open 状态,项目组方面并未真正投入关注。

话说 Nadella 不久之前高呼“安全优先于一切”( Prioritizing security above all else) [7],还对 U.S. CISA 承诺了要 Secure By Design[8],看来在成本面前,软件巨人都只是说说而已。

联想一下国内的软件开发行业,我们自己的以设计达安全的情况又如何呢?

注:题头图用豆包生成。话说笔者发现,要让它按某位名家的画风生成该名家从未画过的内容时,生成的结果就会错误百出。

[1] @LehmannLorenz
https://x.com/LehmannLorenz

[2] JoeSandbox 1525473
https://joesandbox.com/analysis/1525473

[3] Quasar - Free, Open-Source Remote Administration Tool for Windows
https://github.com/quasar/Quasar

[4] Malicious VSCode extensions with millions of installs discovered
https://www.bleepingcomputer.com/news/security/malicious-vscode-extensions-with-millions-of-installs-discovered/

[5] VSCode extensions with malicious code installed 229M times
https://www.scworld.com/news/vscode-extensions-with-malicious-code-installed-229m-times

[6] [Feature Request] Extension Permissions, Security Sandboxing & Update Management Proposal #52116
https://github.com/microsoft/vscode/issues/52116

[7] Prioritizing security above all else
https://blogs.microsoft.com/blog/2024/05/03/prioritizing-security-above-all-else/

[8] CISA Announces Secure by Design Commitments from Leading Technology Providers
https://www.cisa.gov/news-events/news/cisa-announces-secure-design-commitments-leading-technology-providers

本栏目相关
  •  2024-10-08 最新发现 CUPS 漏洞可被用于 DDoS 放大攻击,9.9分值不值?
  •  2024-10-18 等微软作为太迟:主动防御 VS Code 恶意扩展
  •  2022-05-11 CIS-CAT 配置评估工具介绍及操作实践
  •  2022-03-16 Windows 系统安全基线及软件工具介绍
  •  2022-08-28 网络攻防中的色彩象征
  •  2022-03-11 安装RHEL/CentOS时如何选择配置安全策略?
  •  2022-03-17 详细了解微软安全合规工具包(SCT)
  •  2022-03-25 从甲方角度介绍“CIS互联网安全中心”
  •  2023-02-27 注意:TightVNC 2.8.75 释出,修补 zlib 漏洞 CVE-2022-37434
  • 本站微信订阅号:

    微信订阅号二维码

    本页网址二维码: