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