Python、Docker 等 3.5 万个代码库被黑?GitHub 辟谣:只是被恶意克隆

整理 | 郑丽媛

出品 | CSDN(ID:CSDNnews)

据说,GitHub 又双叒叕遭遇恶意攻击了,这次还有超过 3.5 万个代码库受影响?

本周三,一位软件工程师 Stephen Lacy 突然发推表示:“我发现 Github 上存在广泛的大规模恶意攻击行为。目前已有超过 35000 个代码库被感染,波及范围涵盖 Crypto(加密)、Golang、Python、js、bash、Docker 和 k8s 等,其中恶意代码被添加到 npm 脚本、Docker 图像和安装文档中。”

此消息一出,那一溜十分眼熟的代码库名称引得广大开发者颇为心惊:什么?是这么多个官方代码库都出问题了吗?!

看似无害的 commit

从 Stephen Lacy 的推特个人介绍来看,身为软件工程师的他主要从事领域为密码学和开源,而他发现这次攻击的契机,是审查一个通过谷歌搜索找到的开源项目。

“这些被感染的 commit 看起来大多都挺无害的,一般带有‘bump version to 0.3.11’这类像是版本更新的名字。”此外,通过检查这些代码库的历史记录,Stephen Lacy 发现有些 commit 来自项目作者,但未经 GPG 验证,有些则来自目前已不存在的用户。

(注:GPG 是 GNU Privacy Guard 的缩写,是一种基于密钥的加密方式,使用了一对密钥对消息进行加密和解密,以保证消息的安全传输。)

一旦开发者使用这些包含着恶意代码的资源库后,其整个环境变量 (ENV) 就会被泄露并上传至攻击者的服务器上,ENV 包括安全密钥、Amazon Web Services 访问密钥、加密密钥等等。

听到这里,那些使用 GitHub 上 Crypto(加密)、Golang、Python、js、bash、Docker 和 k8s 等库的开发者们是不是有些紧张了?

放心,据技术网站 Bleeping Computer 报道称:“实际上那 35000 个项目并未受到任何影响或损害,Crypto(加密)、Golang、Python、js、bash、Docker 和 k8s 等官方项目也不受影响。”而那些含有恶意代码的项目大多是这些官方合法项目的分叉或克隆版本。

35k+ 不是受感染的代码库数量

在推特中,Stephen Lacy 也提到了这一点:“攻击者会构建假的代码库链接,并将合法项目的克隆版本推送到 GitHub,以此甩锅给代码库的原作者!”

发现这一问题后,Stephen Lacy 迅速向 GitHub 报告了这一问题,呼吁其在代码库中搜索是否包含以下恶意 URL:

hxxp://ovz1.j19544519.pr46m.vps.myjino[.]ru

不仅如此,另一位开发者 James Tucker 分析得出,包含此恶意 URL 的克隆代码库不仅会泄露用户的环境变量 ,其中还包含一个后门,将允许攻击者远程在所有安装和运行这些恶意代码的系统上执行任意代码。

在 GitHub 上搜索该 URL 后,Bleeping Computer 发现共有 35788 个搜索结果,即这些文件均包含恶意 URL——但这个数字只是受感染的文件数,而非受感染的代码库数量。Stephen Lacy 不久后也更正了这一点:GitHub 上显示受感染的 35k+ 是代码段数量,不是代码库。

进一步分析后,Bleeping Computer 指出在这 3.5 万多个文件中,绝大多数的克隆存储库都在上个月的某个时段被注入了恶意代码,其中有超过 13000 个搜索结果均来自一个名为“redhat-operator-ecosystem”的存储库。不过目前该库似乎已从 GitHub 中删除,显示 404(未找到)错误。

而事发当天的晚上,收到 Stephen Lacy 报告的 GitHub 便出面进行了回应:

GitHub 正在调查 2022 年 8 月 3 日星期三发布的推文:

*没有存储库受到损害

*恶意代码是发布到克隆存储库,而不是存储库本身

*那些克隆存储库已经被封,且没有明显证据表明 GitHub 或维护者账户被盗用

据 Bleeping Computer 报道,Github 在收到恶意事件报告后,目前已清除了大部分包含恶意内容的代码库。

使用 GPG 密钥来验证

本质上来说,在 GitHub 上克隆开源项目是一种十分常见的行为,甚至很多开发者还乐见其成。但这次攻击事件告诫我们,最好还是使用项目的官方代码库,同时要注意某些仿冒的域名和克隆存储库,因为它们可能只是看起来与原项目相同,但其中隐藏了恶意软件。

更可怕的是,某些克隆存储库还会继续以项目原作者的用户名和电子邮件地址提交代码,由此造成误导性,令其他开发者错认为克隆存储库的更新 commit 也是由项目原作者进行的,以此换取信任。

因此,正如 Stephen Lacy 在推特上提出的建议一样:“识别伪造 commit 的最佳策略,就是使用 GPG 密钥来验证。”

参考链接:

https://www.bleepingcomputer.com/news/security/35-000-code-repos-not-hacked-but-clones-flood-github-to-serve-malware/https://news.ycombinator.com/item?id=32327903

相关文章

最近一直在开发Apworks框架的案例代码,同时也在一起修复Apw...
最近每天都在空闲时间努力编写Apworks框架的案例代码WeText。...
在《Kubernetes中分布式存储Rook-Ceph部署快速演练》文章中,...
最近在项目中有涉及到Kubernetes的分布式存储部分的内容,也...
CentOS下Docker与.netcore(一) 之 安装 CentOS下Docker与.ne...
CentOS下Docker与.netcore(一) 之 安装 CentOS下Docker与.ne...