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