邊策 金磊 發(fā)自 凹非寺
量子位 報道 | 公眾號 QbitAI
論攻擊科技巨頭有多難？
非常容易，而且是簡單到極致的那種。
只需要制造虛假的pip、npm軟件包，就可以輕松攻破微軟、蘋果、特斯拉、PayPal、Yelp等數(shù)十家科技公司服務(wù)器。
沒錯，就是我們再熟悉不過的那些安裝命令。
這是一位名叫Alex Birsan的黑客最近發(fā)現(xiàn)的巨大漏洞：只要上傳和科技公司內(nèi)部軟件包名字相同的“李鬼”，就可以讓他們在不知不覺中感染惡意軟件。
波及范圍之廣、攻擊方式之簡單，令人咋舌。
Birsan由此發(fā)現(xiàn)了30多家科技公司的存在漏洞，有兩家公司已經(jīng)獎勵他3萬美元的的bug賞金。
怎么一回事？
事情起源于2020年夏天。
另一位黑客在網(wǎng)上分享了一段GitHub上有趣的Node.js源代碼。這段代碼原來僅供PayPal內(nèi)部使用。
Birsan發(fā)現(xiàn)，package.json文件列出了安裝軟件所需的各種依賴項(xiàng)：
其中有來自npm的公共軟件包，也有PayPal內(nèi)部的私有軟件包（紅色），后者是由PayPal內(nèi)部托管，這些軟件包在公共npm注冊表中搜索不到。
Birsan因此產(chǎn)生了很多的疑問：
如果有人假冒PayPal私有軟件包的名字，將惡意代碼上傳到npm會發(fā)生什么？
PayPal的內(nèi)部項(xiàng)目是否有可能因此使用假冒的軟件包，而不是原來的私有軟件包？
系統(tǒng)是否會因?yàn)榘惭b假冒軟件包而運(yùn)行惡意代碼？
如果這種攻擊方法行得通，可以從中獲得科技公司的漏洞賞金嗎？
這種攻擊還會對其他公司起作用嗎？
攻擊方法
帶著這些想法，Birsan將同名的“惡意” Node程序包上傳到npm注冊表，這樣PayPal的程序員如果安裝他們的私有軟件包，就會被假的軟件欺騙和替代。
當(dāng)然，Birsan的“惡意軟件”并不包含破壞成分，它只有一個功能，當(dāng)對方使用npm安裝上與原軟件同名的“李鬼”時，就會發(fā)送信息通知Birsan。
“惡意軟件”將返回用戶名、主機(jī)名、安裝路徑等信息，一方面可以幫助公司安全團(tuán)隊(duì)根據(jù)這些信息確定可能受到攻擊的系統(tǒng)，同時還可以避免將Birsan的測試誤認(rèn)為是實(shí)際的攻擊。
不過，要讓安裝假軟件的服務(wù)器向自己發(fā)出信息并不容易。因?yàn)楣緝?nèi)部電腦都受到防火墻的保護(hù)，DNS滲透是解決辦法。
Birsan通過DNS協(xié)議將信息發(fā)送到他的服務(wù)器，
Birsan數(shù)據(jù)經(jīng)過十六進(jìn)制編碼，將數(shù)據(jù)偽裝成DNS查詢的一部分，DNS查詢直接或通過中間解析器到達(dá)了他自定義的服務(wù)器。
通過這種攻擊方式，他記錄了每臺計(jì)算機(jī)下載軟件包的記錄。
尋找攻擊目標(biāo)
有了攻擊的基本計(jì)劃，Birsan決定尋找更多可能的攻擊目標(biāo)。
首先就是把攻擊的軟件生態(tài)范圍擴(kuò)大，除了Node.js外，他還將代碼移植到Python和Ruby上，這樣使用PyPI和RubyGems的公司也會受到影響。
接下來就是尋找各大公司的私有軟件包名稱。
在搜索了整整幾天后，Birsan發(fā)現(xiàn)，可以在GitHub以及主要軟件包托管服務(wù)中找到，也可以通過各種互聯(lián)網(wǎng)論壇上的帖子。
甚至沒必要那么麻煩，其實(shí)找到私有程序包名稱的最佳位置，是在各家公司的javascript文件。
這和前面在package.json找到依賴項(xiàng)類似。同樣，require()這些文件中泄漏的內(nèi)部路徑或調(diào)用也可能包含依賴項(xiàng)名稱。
蘋果、Yelp和特斯拉都可以通過這種方式找到。下面就是從Yelp網(wǎng)站上發(fā)現(xiàn)的依賴項(xiàng)。
接下來，就開始“攻擊”了。
攻擊結(jié)果如何？
“成功率簡直讓人吃驚。”
Brisan在按照上述方法進(jìn)行攻擊后，不禁發(fā)出這樣的感慨。
他將這樣的bug叫做依賴性混亂（dependency confusion），并稱已經(jīng)在超過35個組織、所有三種測試編程語言中，均有發(fā)現(xiàn)：
有一點(diǎn)非常明確：非法占用有效的內(nèi)部包名稱，幾乎成了一種萬無一失的攻擊方法。
絕大多數(shù)受此影響的公司，規(guī)模都是超過1000名員工的，這很可能反映出大型公司內(nèi)部庫的使用率很高。
并且，由于Javascript 依賴名稱更容易找到，幾乎75% 的已記錄回調(diào)來自 npm 包，但這并不一定意味著 Python 和 Ruby 不易受到攻擊：
事實(shí)上，盡管在我的搜索過程中只能識別出8個組織的內(nèi)部Ruby gem名稱，但其中有4個公司很容易因?yàn)镽ubyGems而產(chǎn)生“依賴性混亂”。
Brisan還舉了個栗子。
加拿大電商巨頭Shopify就中過招，然后他們?yōu)榱诵迯?fù)這個bug，特意設(shè)立了3萬美元的賞金。
無獨(dú)有偶，在去年8月，他向npm上產(chǎn)了一個Node包，這個包的代碼被蘋果內(nèi)部的多臺電腦中執(zhí)行。
蘋果為此也設(shè)立的3萬美元的獎勵，但當(dāng)這位黑客向蘋果反映“這個漏洞可能允許威脅參與者在蘋果 ID 中注入’后門’”，蘋果公司卻不這么認(rèn)為：
在運(yùn)營服務(wù)中實(shí)現(xiàn)“后門”需要更復(fù)雜的事件序列。
但與此同時，蘋果也確實(shí)證實(shí)，通過使用 npm 包技術(shù)，蘋果服務(wù)器上的遠(yuǎn)程代碼執(zhí)行是可以實(shí)現(xiàn)的。
最后，Birsan奉勸大家不要隨意嘗試，因?yàn)樗芯康?5家公司，都有公共漏洞賞金計(jì)劃或允許通過私有協(xié)議對安全性進(jìn)行測試。
如果未經(jīng)公司授權(quán)，請不要嘗試這種測試！
大公司緣何頻頻中招？
看到這里，或許你也會產(chǎn)生疑問：
為什么會發(fā)生這種情況？
大公司在面對這樣的攻擊時，為何會如此脆弱？
Brisan表示，大公司不愿意透露其在“修復(fù)”過程中的細(xì)節(jié)信息，但在他與安全團(tuán)隊(duì)溝通過程中，卻發(fā)現(xiàn)了些有意思的事情。
例如，造成Python“依賴性混亂”的罪魁禍?zhǔn)祝坪蹙褪清e誤地使用了一個名為extra-index-url的“design by insecure”命令行參數(shù)。
當(dāng)同時使用這個參數(shù)和pip install library，來指定你自己的包索引時，雖然達(dá)到的效果和預(yù)期差不多，但實(shí)際上 pip 在幕后做的事情是這樣的：
檢查指定的（內(nèi)部）包索引上是否存在庫。
檢查公共包索引（PyPI）中是否存在庫。
以找到的版本為準(zhǔn)進(jìn)行安裝。如果兩個版本的軟件包都存在，則默認(rèn)從版本號較高的源碼安裝。
因此，若是將一個名為庫9000.0.0的包上傳到PyPI，就會導(dǎo)致上述例子中的依賴關(guān)系被“劫持”。
雖然這種事情是廣為人知的，但若是在GitHub上搜索“extra-index-url”，就可以找到一些屬于大型組織的易受攻擊腳本——包括一個影響微軟.NET Core組件的bug。
這個漏洞可能允許在.NET Core中添加“后門”，但不幸的是，微軟并沒有把這個漏洞放在“.NET錯誤賞金計(jì)劃”的范圍內(nèi)。
還會有新攻擊方法
對此，Brisan認(rèn)為，雖然現(xiàn)在很多大型公司已經(jīng)意識到了這個bug的存在，也在它們的基礎(chǔ)設(shè)施中進(jìn)行了修復(fù)，但還是有更多需要被發(fā)現(xiàn)的東西。
具體而言，他相信要是存在一種更聰明的新方法來泄露內(nèi)部包名稱，那么將會暴露出更多更容易受到攻擊的系統(tǒng)。
而若是尋找替代的編程語言和存儲庫作為目標(biāo)，就會發(fā)現(xiàn)一些額外的“依賴性混亂”bug的攻擊面。
……
如此看來，大型公司還需要在這種看似基礎(chǔ)的漏洞上，再下點(diǎn)功夫了。
