超級安卓漏洞 “寄生獸”影響數(shù)千萬手機(jī)應(yīng)用

2015-07-02 10:24:31 安全牛　點擊量：評論 (0)

一個被研究人員命名為寄生獸的安全漏洞影響市面上數(shù)以千萬的APP，包括互聯(lián)網(wǎng)巨頭BAT等廠商的眾多流行移動產(chǎn)品。利用該漏洞，攻擊者可以直接在用戶手機(jī)中植入木馬，盜取用戶的短信照片等個人隱私，盜取銀行、支付

一個被研究人員命名為“寄生獸”的安全漏洞影響市面上數(shù)以千萬的APP，包括互聯(lián)網(wǎng)巨頭BAT等廠商的眾多流行移動產(chǎn)品。利用該漏洞，攻擊者可以直接在用戶手機(jī)中植入木馬，盜取用戶的短信照片等個人隱私，盜取銀行、支付寶等賬號密碼等。

發(fā)現(xiàn)該漏洞的360手機(jī)安全研究團(tuán)隊VulpeckerTeam向安全牛表示，寄生獸屬于APK緩存代碼劫持漏洞，他們已經(jīng)向補(bǔ)天漏洞響應(yīng)平臺提交了這個漏洞。目前補(bǔ)天已經(jīng)將相關(guān)詳情通知給各大廠商的安全響應(yīng)中心（src），請各廠商及時自查和修復(fù)。

漏洞原理

由于安卓應(yīng)用的升級都需要重新安裝程序，為了避免頻繁升級給用戶體驗和開發(fā)都帶來了不便，所以現(xiàn)在市面上的app大都使用插件機(jī)制來做到無縫升級和擴(kuò)展功能，APP只需要引入相應(yīng)的插件文件即可完成升級。但這種做法卻隱藏了不為人知的安全隱患。

VulpeckerTeam的安全專家黎博解釋，APP插件機(jī)制的實現(xiàn)方式是把相關(guān)功能編寫成單獨(dú)apk或jar文件，然后在程序運(yùn)行時用DexClassLoader函數(shù)動態(tài)加載，進(jìn)行反射調(diào)用。由于安卓應(yīng)用的代碼緩存機(jī)制會優(yōu)先加載運(yùn)行APK的緩存代碼odex，因此如果針對插件的odex文件進(jìn)行攻擊，開發(fā)者對于插件文件所做的各種保護(hù)都將失效。

安全人員檢測了市面上一些用到插件機(jī)制的主流app，發(fā)現(xiàn)部分app對DexClassLoader的第一個參數(shù)的插件文件做了校驗，在加載前對要加載的apk或jar做了簽名或者M(jìn)D5等校驗。這在一定程度上保護(hù)了插件的完整性，防止了代碼注入攻擊。但是，幾乎沒有廠商對第二個參數(shù)的緩存文件進(jìn)行保護(hù)，這就導(dǎo)致了新的攻擊點的出現(xiàn)。

經(jīng)過在安卓源碼中的驗證，攻擊者需要修改odex文件中的兩個參數(shù)crc及modWhen以實現(xiàn)惡意代碼的注入。

上圖dex_old是修改前的odex文件，dex_new是修改后的dex文件。兩個文件的md5不一樣，但是crc及modWhen卻是一樣的，這樣就可以繞過DexClassLoader的校驗。

APK緩存代碼感染雖然危害很大，但是一般情況下，開發(fā)者都會將odex的緩存目錄選在App的私有目錄下，google官方文檔也提示開發(fā)者，不要將odex的緩存路徑選擇在外部存儲器(SD卡)上。所以，攻擊者如果沒有足夠的權(quán)限是無法替換app私有目錄下的文件的。

在之前安全牛報道過的三星輸入法漏洞利

用中，攻擊者用到了安卓zip解壓縮的一個漏洞。可以遍歷目，并在解壓zip文件時以原app的權(quán)限覆蓋任意文件。如果該app用到了插件機(jī)制，則對應(yīng)的插件的odex文件也會被備份。攻擊者可以先用adb backup備份用戶數(shù)據(jù)，對備份下來的odex文件進(jìn)行修改，然后用adb restore恢復(fù)回去，就可以替換掉正常的odex文件，造成代碼劫持。

漏洞危害

安全人員測試了市面上幾款主流的app，凡是用到了這種插件機(jī)制的app，都沒有對DexClassLoader的第二個參數(shù)做校驗，一旦攻擊者將惡意代碼注入APK的緩存代碼(odex)中，開發(fā)者對apk/jar做的各種保護(hù)都將失效。而且這種攻擊，APK自身很難發(fā)現(xiàn)，即使重啟或關(guān)機(jī)，只要app一運(yùn)行，惡意代碼就會隨之運(yùn)行。

為了證明漏洞危害的嚴(yán)重性，安全人員選擇了三類代表性的APP驗證漏洞：

輸入法類APP：搜狗輸入法，百度輸入法等

可感染代碼輸出logcat

瀏覽器類APP：UC瀏覽器等

替換支付寶SDK，盜取密碼

通用類SDK：高德地圖SDK，微信SDK等

感染代碼輸出logcat

由于驗證漏洞需要花大量精力，因此還需要各大廠商自查并修復(fù)。

解決方案

APK緩存劫持漏洞的核心有兩點，一個是軟件開發(fā)者沒有考慮odex的安全問題，另一個是沒有對zip解壓縮時的惡意文件名做檢測，所以防護(hù)上也應(yīng)該從這方面做考慮。

•odex完整性校驗

由于對odex一般是由系統(tǒng)(DexClassLoader)自動生成的，且odex與apk/jar是相對獨(dú)立的，開發(fā)者事先無法知道odex文件的MD5等信息，所以很難通過MD5校驗等手段保護(hù)odex的完整性；同時，系統(tǒng)的DexClassLoader函數(shù)只是校驗了odex中的crc、modWhen字段，可以很輕易的被繞過。所以，目前對odex的防護(hù)只能由app自身來做，可以在每次運(yùn)行DexClassLoader之前，清楚已經(jīng)

存在的odex；另外，在odex第一次生成之后，存儲odex文件的MD5值，以后每次調(diào)用DexClassLoader的時候都對odex文件進(jìn)行

MD5校驗。

•對劫持odex的攻擊入口的修復(fù)

對zip解壓縮的漏洞，只需要在調(diào)用

zipEntry.getName()的時候，過濾返回值中的"../"跳轉(zhuǎn)符。對于引用的第三方的zip庫也需要注意，可以用上面的測試用例測試一下第

三方庫是否有zip解壓縮的漏洞；調(diào)用DexClassLoader動態(tài)加載dex的時候，第二個參數(shù)不要指定在sdcard上；在manifest里指

定allowBackup=”false”。

責(zé)任編輯：大云網(wǎng)

免責(zé)聲明：本文僅代表作者個人觀點，與本站無關(guān)。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實，對本文以及其中全部或者部分內(nèi)容、文字的真實性、完整性、及時性本站不作任何保證或承諾，請讀者僅作參考，并請自行核實相關(guān)內(nèi)容。

我要收藏

個贊