找到惡意軟件包：Go 語言生態系統中的供應鏈攻擊是怎樣的？
近期發生的嚴重的 SolarWinds 攻擊事件和新型 “依賴混淆“攻擊，讓供應鏈攻擊成為討論焦點：攻陷供應鏈中不太安全的元素，導致更安全的目標遭攻陷。
供應鏈攻擊的流行目標一直都是流行編程語言的很多包管理系統，如 NPM (JavaScript)、Rubygems (Ruby) 以及 PyPI (Python)。這些系統常年來遭受惡意攻擊，攻擊者上傳惡意包并等待受害者安裝。
目前為止，尚未看到關于 Go 生態系統的供應鏈攻擊情況。鑒于 Go 語言是我的新寵，我決定自己做一些調查。
好在依賴混淆并未Go 開發人員需要擔心的攻擊，因為導入數據包時來源總是顯而易見的，因此當 Go 得到外部依賴關系時，不會遇到如何獲取的困擾：
然而，Go 開發人員可能會遇到 “誤植域名 (typosquatting)“的情況，即攻擊者利用人們經常從鍵盤按下錯誤按鍵的事實。攻擊者可以注冊 github.com 的常用打字錯誤，在主機域名上執行誤植域名攻擊，或者只是在 GitHub 或其它程序包主機上注冊一個新用戶，而常見的打字錯誤是程序包所有人的用戶名。
鑒于此，我構建了一款工具，用于找到潛在在野 typosquat 程序包：
-
大量獲取 Go 包導入路徑列表（如 github.com/stretchr/testify） -
排列每個唯一程序包的用戶名稱，獲得潛在的typosquat列表 -
檢查平臺上是否存在其中任何typosquat用戶 -
如找到了潛在的typosquat用戶，則檢索其所有存儲庫 -
記錄名稱和所檢查的原始程序包名稱一樣的倉庫
結果，我構建了一款工具，名為 “pkgtwist”，如有興趣嘗試捕獲惡意 Go 程序包，可訪問：https://gitlab.com/michenriksen/pkgtwist。
排列
pkgtwist 最重要的部分很可能是生成良好的用戶名排列，從而增加檢測到typosquat 的幾率。一番研究后，我進入zntrio/typogenerater，它看似是生成潛在用戶名輸入錯誤的完美程序包。該程序包執行了非常長的排列策略，我從中挑選了一些，因此 pkgtwist 僅檢查我認為最可能是輸入錯誤的情況即可：
缺失：刪除單一字符（缺少按鍵， stretchr => strechr）
重復：重復字符（兩次按鍵，gobuffalo => gobuffallo）
Bitsquatting：很可能的位翻轉錯誤 (stretchr => strftchr)
換位：交換相鄰字符（按錯誤順序按鍵，stretchr => strethcr）
這意味著，如果 pkgtwist 獲得程序包 github.com/stretchr/testify 作為輸入，那么它會檢查如下用戶是否存在于 GitHub 上，如存在，則檢查是否擁有一個名為 testify 的倉庫：
tretchr sretchr stetchr strtchr strechr strethr stretcr stretch sstretchr sttretchr strretchr streetchr strettchr stretcchr stretchhr stretchrr rtretchr qtretchr ptretchr wtretchr vtretchr utretchr ttretchr suretchr svretchr swretchr spretchr sqretchr srretchr ssretchr stsetchr stpetchr stqetchr stvetchr stwetchr sttetchr stuetchr strdtchr strgtchr strftchr stratchr strctchr strbtchr streuchr strevchr strewchr strepchr streqchr strerchr streschr stretbhr stretahr stretghr stretfhr stretehr stretdhr stretcir stretcjr stretckr stretclr stretcmr stretcnr stretcor stretchs stretchp stretchq stretchv stretchw stretcht stretchu tsretchr srtetchr stertchr strtechr strecthr strethcr stretcrh
主題
接下來是找到程序包列表并進行檢查。最初我以為可以找到類似于“前幾大 Go 程序包”的列表，但并未如愿，因此對托管在 github.com 和 gitlab.com 上的來自 Go Module Index（共731個程序包）的程序包運行了 pkgtwist。
結果
對這731個程序包運行了幾個小時后，pkgtwist 篩選出7個可能存在 typosquat的程序包進行進一步的調查。說實話雖然我本來認為會更多，但目前來看 Go 生態系統尚未遭惡意 typosquat 程序包感染，這一點讓人高興。
然而，有幾個 typosquat 程序包映入我的眼簾。
github.com/siruspen/logrus
sirupsen 提供的 logrus 包是很多 Go 項目都在使用的非常流行的日志記錄程序包（在 GitHub 上獲得 17.3k 個star），從而成為 typosquat 供應鏈攻擊的目標。因此當我看到用戶 siruspen（注意字母替換）具有一個名稱類似的倉庫時，快速查看了它的目的。
結果發現該項目是原始 logrus 倉庫的 fork，因此將二者做比對非常容易。在本文成稿之時，這個潛在的 typosquat 倉庫中添加的唯一內容是一個配有單獨的 PrintIn 調用的很小的 init 函數：
雖然從各個角度來講，它并非惡意，但未來很可能會被所有人快速修改，因此我肯定會關注這個倉庫。同時建議使用 logrus 的用戶確保自己使用的是真正的程序包！
github.com/utfave/cli
Urfave/cli是構建 CLI 項目的流行 Go 程序包（在 GitHub 上獲得15.4k個star）。因此當我看到用戶 utfave 也擁有一個名為 cli 的倉庫時，警鐘敲響并進一步調查。
結果發現，倒數第二個 commit 引入了一個非常可疑的 init 函數：
看起來作者 utfave 想要了解使用他們的 urfave/cli 版本的機器的主機名、操作系統和架構。該函數提取了系統信息，然后通過 HTTP 調用添加到某互聯網公司的 IP 地址 122.51.124.140，并將該系統信息添加為 URL 參數。
雖然通過該代碼無法獲得對系統的訪問權限，但非常可疑，收集了這些信息，他們就能發現某個有價值或感興趣的系統，然而迅速更改此代碼，通過反向shell 進行回調。
我已將問題告知 GitHub并希望能在不久之后撤銷該倉庫。在此之前，我建議 urfave/cli 用戶仔細檢查是否使用了“誤植域名“版本。
結論
雖然這個小小的研究項目并未涵蓋所有的 Go 程序包，但足以粗略了解到 Go 生態系統中的供應鏈攻擊情況。Siruspen/logrus 和 utfave/cli 倉庫僅僅是我認為可疑的7個被標記出的倉庫，我會持續關注余下項目，因為從理論上將講，它們隨時可能轉變為惡意倉庫。
我認為相比其它編程語言，Go語言的情況更好，因為每次程序包被使用時，其來源都會被明確地寫出來，但代碼編輯器自動化將使“誤植域名“攻擊更可能發生，開發人員常常不會手動編寫導入路徑。例如，如果 VS Code 的 Go 擴展被安裝，那么開發人員一般只會在第一次使用時輸入程序包導入，之后當該程序包名稱被使用時，編輯器將會自動在其它文件中添加導入。如果開發人員在第一次錯誤地輸入導入路徑，那么惡意程序包會被引入并在 Go 項目中駐留很久。
資料專區
《手撕GO語言》，從?基礎數據類型、流程控制、符合數據類型、函數、包、結構體、方法、并發、測試、常用標準庫等15個模塊做了詳細的講解，219頁的文檔，需要的朋友點擊?閱讀原文?領取網盤鏈接和提取碼。
領取資料請戳：https://iiv.h5.xeknow.com/s/1ueGrH 【微信打開領取網盤鏈接和提取碼】
文章轉自奇安信代碼衛士
https://codesafe.qianxin.com