研究人員最近發現了依賴存儲庫劫持的情況非常普遍，這是一個隱藏的漏洞，允許任何人在用戶更改用戶名的情況下劫持存儲庫。這個漏洞類似于子域接管，利用起來很容易，并且會導致遠程代碼注入。在分析了這個漏洞的開源項目并總結了搜索它們的依賴關系圖后，研究人員發現有超過70000個開源項目受到影響，這包括來自谷歌、GitHub、Facebook等公司的流行項目和框架。為了緩解這個漏洞，請確保你的項目不依賴于GitHub的直接URL或使用依賴關系鎖定文件和版本固定。

[[350806]]

什么是Repo Jacking?

依賴存儲庫劫持(又名“Repo Jacking”)是供應鏈上一個鮮為人知的漏洞，在概念上類似于子域名接管，影響超過7萬個開源項目，影響從web框架到加密貨幣的所有操作。這個漏洞利用起來很不容易，會導致遠程代碼注入，并影響來自谷歌、GitHub、Facebook、Kubernetes、NodeJS、Amazon等公司的重大項目。研究人員在最近的一次活動中首次發現這個漏洞后，就想知道這個漏洞有多普遍，于是就對所有開源項目進行了遞歸分析，結果發現它非常普遍。

哪些對象易受Repo Jacking攻擊?

每個編譯依賴于GitHub存儲庫動態鏈接代碼的項目都可能受到攻擊，不過攻擊要成功，需要滿足以下兩個條件：

• 你的代碼需要直接引用GitHub存儲庫(通常作為依賴關系)。
• 存儲庫的所有者需要更改/刪除他們的用戶名。

當鏈接的存儲庫所有者更改其用戶名時，任何人都可以立即重新注冊該用戶名。這意味著，任何鏈接回原始存儲庫URL的項目現在都很容易受到依賴劫持的遠程代碼注入的攻擊。惡意攻擊者可以注冊舊的GitHub用戶名，重新創建存儲庫，并使用它向依賴它的任何項目提供惡意代碼。

即使依賴于GitHub存儲庫的項目現在還不容易受到攻擊，但如果其中一個依賴關系的所有者更改了他們的用戶名，那么該項目和其他依賴于該舊鏈接的項目就會受到repo jacking的攻擊。當存儲庫更改位置時，可能會出現某種警告，比如“404 -未找到存儲庫”之類的漏洞，但實際上沒有。此外，Github的一項小功能(存儲庫重定向)使此漏洞明顯更加危險。

“存儲庫重定向”使攻擊更加嚴重

當GitHub用戶更改存儲庫的名稱或用戶名時，GitHub設置了一個從舊URL到新URL的重定向，這種重定向同時適用于HTTP和Git請求。當用戶更改其用戶名、傳輸存儲庫或重命名存儲庫時，就會創建此重定向。這里的漏洞是，如果重新創建原始存儲庫(在本例中為“twitter/bootstrap”)，重定向將中斷，并將你發送到新創建的存儲庫。

示例場景

鏈接https://github.com/twitter/bootstrap指向資源庫“twitter/bootstrap”，但實際上會將你重定向到“twbs/bootstrap”資源庫。

如果Twitter更改了他們的GitHub用戶名，那么任何人都可以重新注冊它，重新創建一個名為“bootstrap”的資源庫，任何對https://github.com/twitter/bootstrap的新請求都將進入新創建的資源庫。

任何依賴于https://github.com/twitter/bootstrap的項目現在都將開始從這個新存儲庫加載代碼。

重定向是一個方便的功能，因為它意味著當你重命名你的帳戶時鏈接不會立即中斷。但這也意味著你的項目可能在不知不覺中變得容易受到Repo Jacking的攻擊。從你的角度來看，什么都沒有改變，你的代碼編譯仍然是一樣的，一切都按照它應該的方式工作。但是，你的項目現在很容易受到遠程代碼注入的攻擊，而且你并不知道。

三種劫持場景

更具體地說，從技術上講，有三種不同的方式可以使存儲庫變得可以被劫持：

• GitHub用戶重命名其帳戶。這是存儲庫可劫持的最常見方式，因為用戶重命名其帳戶并不罕見，并且在用戶重命名帳戶后，由于存儲庫重定向，一切都會按預期進行。
• Github用戶將其存儲庫轉移到另一個用戶或組織，然后刪除其帳戶。用戶轉移存儲庫時，將建立重定向，并通過刪除其用戶來打開它，使其被任何人劫持。
• 用戶刪除其帳戶。這是三者中影響最小的，因為從原始用戶刪除帳戶的那一刻起，任何引用該帳戶的項目在嘗試獲取存儲庫時都會開始出現漏洞。

注意：在用戶刪除帳戶和項目嘗試獲取存儲庫之間，有幾次攻擊者重新注冊已刪除的用戶名，詳情請點此。

GitHub的回應

在發布本文之前，研究人員已與GitHub聯系，他們表示雖然這是一個已知漏洞，但是他們目前尚無任何計劃來更改重定向或用戶名重用的方式。他們只是通過禁止重新注冊導致刪除一周之內具有100個以上新復制的存儲庫名稱來為某些受歡迎的存儲庫提供了一些緩解此問題的方法，如下所述。這確實提供了一定程度的保護，但不是萬無一失的解決方案，因為許多較小的存儲庫不符合此標準，但仍然可以為流行項目所依賴。

這里的根本漏洞不是GitHub允許重定向和用戶名重用，而是開發人員從不安全的位置提取代碼。GitHub無法監督那些出于意外目的使用其服務的開發人員。有許多可用的包管理器(事實上，GitHub本身就有一個)用于解決遠程代碼依賴漏洞，開發人員有責任確保他們從安全位置加載代碼。

漏洞影響范圍

漏洞影響范圍有多大，事實證明，篩選所有開放源碼項目，編譯它們的依賴關系，找到所有可被劫持的存儲庫，并構建易受攻擊的存儲庫的依賴關系圖并不容易。

步驟1：數據收集

對開源軟件進行大規模分析時，最困難的部分之一是初始數據收集。為所有開源項目找到一個最新的、準確的、容易搜索的索引是很困難的。研究人員主要使用兩個數據集進行分析:

(1) GitHub活動數據

這是由Github自己提供的，是一個巨大的數據集，包括超過280萬個存儲庫，以及它們的所有文件和內容，整個數據集的內容超過3TB。方便的是，它被托管為谷歌云平臺(GCP)上的一個公共BigQuery數據集，這意味著研究人員可以使用BigQuery從GCP本身內部在整個數據集上運行SQL命令，而不需要下載整個3TB文件。

為了實際執行搜索，研究人員生成了一個正則表達式，用于捕獲任何Github URL或其他常見的Github依賴鏈接格式，如Github:username/reponame。使用這個正則表達式，研究人員能夠為包含對GitHub鏈接的引用的每個文件提取存儲庫、文件名和文件內容。這將研究人員的搜索空間從3TB縮小到更易于管理的4GB。經過過濾的數據集包括400萬個獨特的GitHub鏈接和超過70萬個不同的GitHub用戶。

(2) libraries.io

libraries.io是一個開源項目，旨在將來自多個不同打包程序管理器的所有依賴聚合成一個類似圖表的數據集。這是令人驚奇的，因為它不僅為研究人員完成了連接什么依賴什么的所有繁重工作，而且它還提供了整個數據集可供免費下載。未壓縮時，該數據集超過100GB，但可以直接加載到數據庫中，以便于處理。

研究人員使用這兩個數據集是很重要的，因為每個數據集擅長不同的事情。“Github活動數據”數據集允許研究人員找到存儲庫中引用的每一個可能的Github鏈接，即使它沒有被用在明顯的地方，比如包管理器清單中。一些最有趣的發現并不一定是直接的代碼依賴，研究人員經常發現，在bash腳本中直接使用Github url來復制存儲庫或docker映像，這些映像將在構建時從Github提取存儲庫。

示例安裝腳本;任何人都可以注冊GitHub的鏈接

另一個常見的發現是可劫持的存儲庫作為Git子模塊，這是標準依賴分析可能會忽略的。

另一方面，“libraries.io”數據集是一個已經清理、過濾和格式化的數據集，它使我們能夠構建依賴圖并輕松評估此漏洞的廣泛性。通過這些數據集，我們可以更全面地了解此漏洞對開源項目的總體影響。

步驟2：清理

收集了所有這些數據后，研究人員需要對其進行清理和規范化，這是一項任務量很大的工作，因為研究人員需要考慮每個程序包管理器的不同格式。此外，研究人員希望刪除所有實際上沒有作為依賴關系使用的鏈接。這些鏈接中有很多是在注釋中使用的，例如//code inspired from github.com/username/reponame，或者在文檔文本文件中。由于研究人員主要關心代碼注入的可能性，所以研究人員刪除了代碼不會直接使用的任何內容。這就給研究人員留下了超過200萬個獨特的GitHub鏈接，這些鏈接被文件以有意義的方式引用。

步驟3：可劫持的用戶名

現在研究人員有了一個直接依賴于GitHub鏈接的清晰項目列表，研究人員需要找到當前未注冊的用戶。到目前為止，研究人員有大約650k個Github用戶名需要整理。使用GitHub API，研究人員可以檢查用戶名是否存在，但研究人員的速度限制在每小時5000個請求，這意味著檢查所有用戶名要花費5天以上的時間。通過一些巧妙的邏輯和GitHub GraphQL API，研究人員能夠將掃描所有650k用戶的時間縮短到2小時多一點。

那么，結果如何呢?研究人員發現，研究人員收集的用戶名中有7%(約50k)是未注冊的。老實說，研究人員沒想到這個數字會這么高。研究人員認為只有不到1%的用戶名是可以被劫持的。顯然，人們對自己的用戶名感到厭倦的程度遠遠超過預期。

步驟4：易受攻擊的項目

一旦研究人員有了所有可能被劫持的用戶名，漏洞就只是對研究人員的數據集進行反向搜索，每個項目都依賴于一個用戶名所擁有的存儲庫。經過進一步的過濾和清理誤報后，研究人員發現總共有18000個項目直接容易受到庫劫持的攻擊。這些項目在GitHub上總共有超過50萬顆星星，并且包括了來自一些最大的開源組織的幾乎每種語言的項目。

僅這個數字就令人恐懼，但是現代代碼庫并不是運行在單個存儲庫中的龐大整體。相反，它們在功能上依賴于許多其他項目。這對于可維護性和可重用性來說是很好的，但這意味著單個流行依賴關系中的漏洞會極大地影響依賴關系鏈上的許多項目。實際上，任何依賴于18000個直接易受攻擊項目的項目本身也是易受攻擊的。

步驟5：依賴性分析

現在研究人員就有了一個直接易受攻擊的項目列表，將其與以前的數據集一起用于執行依賴關系圖污點搜索，并找到每個依賴其供應鏈中易受攻擊的倉庫的項目。在此分析中，研究人員包括了普通的依賴關系和不太明顯的依賴關系，比如開發依賴關系或不在主包清單文件中的依賴關系。如果這些輔助依賴關系中的一個容易受到repo sniping的影響，則影響可能需要更長的時間才能在依賴關系鏈上傳播，因為這種影響可能僅在開發人員發布新版本時才會發生。考慮到這一點，研究人員開始了攻擊分析。

由于易受攻擊項目的數量可能會呈指數級增長，研究人員會慢慢進行遍歷。在每次傳遞過程中，研究人員都手動檢查結果，并刪除任何明顯的誤報，以最小化漏洞傳播，并確保研究人員的結果不會被誤報所掩蓋。

經過5次遍歷后，研究人員不得不停下來。因為在第5輪之前，數據的增長都是可以預測的，且每一輪搜索都花費了合理的時間，但當研究人員進行第6輪遍歷時，數據開始不可控制地增長。看看第五輪的結果，原因就清楚了，研究人員已經建立了多個大型的基礎框架，并被成千上萬的其他項目所依賴。這足以讓研究人員理解這一漏洞的影響。截至目前，研究人員已經發現了超過7萬個受影響的項目，其中GitHub明星項目總數超過150萬個，這比GitHub前8大資料庫加起來還要多。雖然這很難精確衡量，但研究人員估計這些項目的總下載量至少有200萬。

受影響的項目包括來自大型組織(例如Google，GitHub，Facebook，Kubernetes，NodeJS，Amazon等)的存儲庫。從小型個人用戶項目到成千上萬個組織使用的流行Web框架，一切都受到影響。有趣的是，它會影響很多不同類型的軟件。研究人員發現了易受攻擊的路由器固件、游戲、加密錢包、移動應用程序和許多其他獨特的項目。

緩解措施

• 不要直接鏈接到GitHub存儲庫。
• 版本固定和鎖定文件。

本文翻譯自：https://blog.securityinnovation.com/repo-jacking-exploiting-the-dependency-supply-chain