邊策 金磊 發自 凹非寺
量子位 報道 | 公眾號 QbitAI
論攻擊科技巨頭有多難？
非常容易，而且是簡單到極致的那種。
只需要制造虛假的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的攻擊面。
……
如此看來，大型公司還需要在這種看似基礎的漏洞上，再下點功夫了。
