論攻擊科技巨頭有多難？非常容易，而且是簡單到極致的那種。只需要製造虛假的pip、npm軟件包，就可以輕鬆攻破微軟、蘋果、特斯拉、PayPal、Yelp等數十家科技公司服務器。沒錯，就是我們再熟悉不過的那些安裝命令。這是一位名叫Alex Birsan的黑客最近發現的巨大漏洞：只要上傳和科技公司內部軟件包名字相同的“李鬼”，就可以讓他們在不知不覺中感染惡意軟件。

波及範圍之廣、攻擊方式之簡單，令人咋舌。

Birsan由此發現了30多家科技公司的存在漏洞，有兩家公司已經獎勵他3萬美元的的bug賞金。

怎麼一回事

事情起源於2020年夏天。

另一位黑客在網上分享了一段GitHub上有趣的Node.js源代碼。這段代碼原來僅供PayPal內部使用。

Birsan發現，package.json文件列出了安裝軟件所需的各種依賴項：

其中有來自npm的公共軟件包，也有PayPal內部的私有軟件包（紅色），後者是由PayPal內部託管，這些軟件包在公共npm註冊表中搜索不到。

Birsan因此產生了很多的疑問：

如果有人假冒PayPal私有軟件包的名字，將惡意代碼上傳到npm會發生什麼？

PayPal的內部項目是否有可能因此使用假冒的軟件包，而不是原來的私有軟件包？

系統是否會因為安裝假冒軟件包而運行惡意代碼？

如果這種攻擊方法行得通，可以從中獲得科技公司的漏洞賞金嗎？

這種攻擊還會對其他公司起作用嗎？

攻擊方法

帶著這些想法，Birsan將同名的“惡意” Node程序包上傳到npm註冊表，這樣PayPal的程序員如果安裝他們的私有軟件包，就會被假的軟件欺騙和替代。

當然，Birsan的“惡意軟件”並不包含破壞成分，它只有一個功能，當對方使用npm安裝上與原軟件同名的“李鬼”時，就會發送信息通知Birsan。

“惡意軟件”將返回用戶名、主機名、安裝路徑等信息，一方面可以幫助公司安全團隊根據這些信息確定可能受到攻擊的系統，同時還可以避免將Birsan的測試誤認為是實際的攻擊。

不過，要讓安裝假軟件的服務器向自己發出信息並不容易。因為公司內部電腦都受到防火牆的保護，DNS滲透是解決辦法。

Birsan通過DNS協議將信息發送到他的服務器，Birsan數據經過十六進制編碼，將數據偽裝成DNS查詢的一部分，DNS查詢直接或通過中間解析器到達了他自定義的服務器。

通過這種攻擊方式，他記錄了每台計算機下載軟件包的記錄。

尋找攻擊目標

有了攻擊的基本計劃，Birsan決定尋找更多可能的攻擊目標。

首先就是把攻擊的軟件生態範圍擴大，除了Node.js外，他還將代碼移植到Python和Ruby上，這樣使用PyPI和RubyGems的公司也會受到影響。

接下來就是尋找各大公司的私有軟件包名稱。

在搜索了整整幾天后，Birsan發現，可以在GitHub以及主要軟件包託管服務中找到，也可以通過各種互聯網論壇上的帖子。

甚至沒必要那麼麻煩，其實找到私有程序包名稱的最佳位置，是在各家公司的javascript文件。

這和前面在package.json找到依賴項類似。同樣，require()這些文件中洩漏的內部路徑或調用也可能包含依賴項名稱。

蘋果、Yelp和特斯拉都可以通過這種方式找到。下面就是從Yelp網站上發現的依賴項。

接下來，就開始“攻擊”了。

攻擊結果如何？

“成功率簡直讓人吃驚。”

Brisan在按照上述方法進行攻擊後，不禁發出這樣的感慨。

他將這樣的bug叫做依賴性混亂 （dependency confusion），並稱已經在超過35個組織、所有三種測試編程語言中，均有發現：

有一點非常明確：非法佔用有效的內部包名稱，幾乎成了一種萬無一失的攻擊方法。

絕大多數受此影響的公司，規模都是超過1000名員工的，這很可能反映出大型公司內部庫的使用率很高。

由於Javascript 依賴名稱更容易找到，幾乎75% 的已記錄回調來自npm 包，但這並不一定意味著Python 和Ruby 不易受到攻擊：

事實上，儘管在我的搜索過程中只能識別出8個組織的內部Ruby gem名稱，但其中有4個公司很容易因為RubyGems而產生“依賴性混亂”。

Brisan還舉了個例子。

加拿大電商巨頭Shopify就中過招，然後他們為了修復這個bug，特意設立了3萬美元的賞金。

無獨有偶，在去年8月，他向npm上產了一個Node包，這個包的代碼被蘋果內部的多台電腦中執行。

蘋果為此也設立的3萬美元的獎勵，但當這位黑客向蘋果反映“這個漏洞可能允許威脅參與者在蘋果ID 中註入’後門’”，蘋果公司卻不這麼認為：

在運營服務中實現“後門”需要更複雜的事件序列。

但與此同時，蘋果也確實證實，通過使用npm 包技術，蘋果服務器上的遠程代碼執行是可以實現的。

最後，Birsan奉勸大家不要隨意嘗試，因為他研究的35家公司，都有公共漏洞賞金計劃或允許通過私有協議對安全性進行測試。

如果未經公司授權，請不要嘗試這種測試！

大公司緣何頻頻中招？

看到這裡，或許你也會產生疑問：

為什麼會發生這種情況？

大公司在面對這樣的攻擊時，為何會如此脆弱？

Brisan表示，大公司不願意透露其在“修復”過程中的細節信息，但在他與安全團隊溝通過程中，卻發現了些有意思的事情。

例如，造成Python“依賴性混亂”的罪魁禍首，似乎就是錯誤地使用了一個名為extra-index-url的“design by insecure”命令行參數。

當同時使用這個參數和pip install library，來指定你自己的包索引時，雖然達到的效果和預期差不多，但實際上pip 在幕後做的事情是這樣的：

檢查指定的（內部）包索引上是否存在庫。

檢查公共包索引（PyPI）中是否存在庫。

以找到的版本為准進行安裝。如果兩個版本的軟件包都存在，則默認從版本號較高的源碼安裝。

因此，若是將一個名為庫9000.0.0的包上傳到PyPI，就會導致上述例子中的依賴關係被“劫持”。

雖然這種事情是廣為人知的，但若是在GitHub上搜索“extra-index-url”，就可以找到一些屬於大型組織的易受攻擊腳本——包括一個影響微軟.NET Core組件的bug。

這個漏洞可能允許在.NET Core中添加“後門”，但不幸的是，微軟並沒有把這個漏洞放在“.NET錯誤賞金計劃”的範圍內。

還會有新攻擊方法

對此，Brisan認為，雖然現在很多大型公司已經意識到了這個bug的存在，也在它們的基礎設施中進行了修復，但還是有更多需要被發現的東西。

具體而言，他相信要是存在一種更聰明的新方法來洩露內部包名稱，那麼將會暴露出更多更容易受到攻擊的系統。

而若是尋找替代的編程語言和存儲庫作為目標，就會發現一些額外的“依賴性混亂”bug的攻擊面。

……

如此看來，大型公司還需要在這種看似基礎的漏洞上，再下點功夫了。