前言：
360手機(jī)安全研究團(tuán)隊(duì)vulpecker近日發(fā)現(xiàn)了一種新型的安卓app安全漏洞，市面上數(shù)以千萬(wàn)的app都受該漏洞影響。該漏洞一旦被攻擊者利用，可以直接在用戶手機(jī)中植入木馬，盜取用戶的短信、照片以及銀行、支付寶等賬號(hào)密碼，vulpecker以“寄生獸”命名這個(gè)漏洞。
目前vulpecker團(tuán)隊(duì)已經(jīng)通過補(bǔ)天平臺(tái)將相關(guān)詳情通知給各大安全應(yīng)急響應(yīng)中心，也向受此影響的各大廠商進(jìn)行了通報(bào)，在此提醒用戶關(guān)注各APP廠商修復(fù)進(jìn)程，并及時(shí)下載更新安裝最新的APP。
寄生獸是日本作家?guī)r明均創(chuàng)作的漫畫《寄生獸》中的一種怪物，初始形態(tài)是一種蟲子，會(huì)鉆進(jìn)生物的體內(nèi)并奪取大腦，因人類嚴(yán)重的環(huán)境污染而誕生，該漏洞的攻擊方式類似寄生獸的感染，可以長(zhǎng)期駐留在受害者的手機(jī)內(nèi)，本文將詳細(xì)分析這個(gè)漏洞，揭開漏洞的秘密。
一.關(guān)于app的緩存代碼
安卓的應(yīng)用程序apk文件是zip壓縮格式的文件，apk文件中包含的classes.dex文件相當(dāng)于app的可執(zhí)行文件，當(dāng)app運(yùn)行后系統(tǒng)會(huì)對(duì)classes.dex進(jìn)行優(yōu)化，生成對(duì)應(yīng)的odex格式的文件。
odex文件相當(dāng)于app的可執(zhí)行文件的緩存代碼，一般安卓系統(tǒng)在第一次加載運(yùn)行apk時(shí)會(huì)將系統(tǒng)生成odex文件存放于/data/dalvik-cache目錄下。
如圖:
可以看到該目錄下的文件只有system用戶有寫權(quán)限，只有在擁有system權(quán)限的情況下才能對(duì)odex文件進(jìn)行寫操作。
二.廣泛流行的插件機(jī)制
由于安卓應(yīng)用的升級(jí)都需要重新安裝程序，頻繁的升級(jí)給用戶體驗(yàn)和開發(fā)都帶來(lái)了不便，所以市面上的app都開始采用插件機(jī)制，利用插件機(jī)制可以做到無(wú)縫升級(jí)和擴(kuò)展功能，app只需要引入相應(yīng)的插件文件就可以做到功能添加或升級(jí)，無(wú)需再重新安裝程序。
app插件機(jī)制的實(shí)現(xiàn)方式是把相關(guān)功能編寫成單獨(dú)的apk或jar文件，然后在程序運(yùn)行時(shí)用DexClassLoader動(dòng)態(tài)加載，進(jìn)行反射調(diào)用。我們來(lái)看一下DexClassLoder的定義
public DexClassLoader (String dexPath, String optimizedDirectory, String library
Path, ClassLoader parent)
dexPath：是要加載的jar/apk的路徑
optimizedDirectory：目標(biāo)odex的路徑
libraryPath：依賴的native library(so文件)路徑
parent：父加載器
下面是常見的調(diào)用DexClassLoader的代碼片段
String dexFiles = “/data/data/com.test.dexload/app_al_sdk/drozer.apk”;
2. final File optimizedDexOutputPath = appcontext.getDir(“outdex”, 0);
3. appcontext.getClassLoader();
4. DexClassLoader classLoader = new DexClassLoader(dexFiles, optimizedDexOutputPath
.getAbsolutePath(), null, ClassLoader.getSystemClassLoader());
5. …
如圖drozer.apk插件在被調(diào)用后生成了drozer.dex緩存文件，注意dex這個(gè)文件是odex格式,且這個(gè)目錄是app的私有目錄。
三. 插件機(jī)制引入的攻擊點(diǎn)
在2013年，國(guó)外的mwr實(shí)驗(yàn)室給出了一個(gè)利用中間人的方式劫持app升級(jí)插件的攻擊案例，參考
https://labs.mwrinfosecurity.com/blog/2013/11/20/applovin-ad-library-sdk-remote-command-execution-via-update-mechanism/幾年前，大部分采用插件機(jī)制的app，在載入插件前都沒有對(duì)插件文件進(jìn)行完整性校驗(yàn)，導(dǎo)致黑客可以通過中間人劫持的方式替換app的升級(jí)插件，在插件中嵌入惡意代碼控制用戶的app和手機(jī)。
現(xiàn)今，大部分采用插件機(jī)制的app都加強(qiáng)了安全性，如最早使用插件開發(fā)方式的微信等app，在下載使用插件前都會(huì)校驗(yàn)插件文件的簽名，黑客已經(jīng)無(wú)法通過中間人的方式替換插件攻擊app。
四. 插件機(jī)制新的攻擊點(diǎn)
近日，國(guó)外的nowsecure公司公布了三星輸入法的一個(gè)漏洞，利用過程直接替換了系統(tǒng)app的odex緩存代碼。參考：
https://www.nowsecure.com/blog/2015/06/16/remote-code-execution-as-system-user-on-samsung-phones/三星輸入法是擁有系統(tǒng)最高級(jí)別的 system 權(quán)限，可以直接替換任意app的緩存文件。那安卓app插件的緩存代碼是否和APP主程序直接產(chǎn)生的緩存代碼一樣能被任意替換？
我們?nèi)ndroid源碼中驗(yàn)證了一下，通過DexClassLoader() 加載jar/apk文件，最終會(huì)通過native接口openDexFileNative() 進(jìn)入到native層。
對(duì)應(yīng)于android-4.2.2_r1/dalvik/vm/native/dalvik_system_DexFile.cpp中的Dalvik_dalvik_system_DexFile_openDexFileNative() 方法，在native層對(duì)幾個(gè)參數(shù)做一系列校驗(yàn)，如果檢測(cè)到第二個(gè)參數(shù)指定的odex文件存在，則會(huì)調(diào)用dvmOpenCachedDexFile() 直接打開，調(diào)用處的代碼如下：
fd = dvmOpenCachedDexFile(fileName, cachedName,
dexGetZipEntryModTime(&archive, entry),
dexGetZipEntryCrc32(&archive, entry),
isBootstrap, &newFile, /*createIfMissing=*/true);
很明顯，第3、4個(gè)參數(shù)對(duì)應(yīng)的是優(yōu)化前的classes.dex的時(shí)間戳和crc校驗(yàn)值。最終會(huì)調(diào)用
dvmCheckOptHeaderAndDependencies(fd, true, modWhen, crc,
expectVerify, expectOpt)
如果crc、modWhen參數(shù)正確，則返回該odex的文件句柄；若crc、modEWhen校驗(yàn)錯(cuò)誤，則嘗試刪除錯(cuò)誤的odex，并重建新的odex。所以，攻擊者如果要注入目標(biāo)odex，需要對(duì)修改后的odex文件的crc及modWhen做修改。
下面是一個(gè)修改后的odex文件實(shí)例，dex_old是修改前的odex文件，dex_new是修改后的dex文件，兩個(gè)文件的md5不一樣，但是crc及modWhen卻是一樣的，這樣就可以繞過DexClassLoader的校驗(yàn)。
五. “寄生獸”漏洞的真正危害
安卓應(yīng)用的代碼緩存機(jī)制是程序在執(zhí)行時(shí)優(yōu)先加載運(yùn)行緩存代碼，而google卻只對(duì)緩存代碼做了可以偽造的弱校驗(yàn)，這明顯是一個(gè)安全架構(gòu)實(shí)現(xiàn)上的嚴(yán)重漏洞。
廣大app開發(fā)者在使用插件機(jī)制開發(fā)app時(shí)可以對(duì)插件文件做完整性校驗(yàn)，而系統(tǒng)生成的緩存代碼卻無(wú)法做到有效保護(hù)，一旦攻擊者將惡意代碼注入到緩存代碼中，開發(fā)者對(duì)app插件文件做的各種保護(hù)都將失效。這種攻擊很難被發(fā)現(xiàn)，即使關(guān)機(jī)后重啟，只要app一運(yùn)行，惡意代碼也會(huì)隨之運(yùn)行，同時(shí)安全軟件對(duì)這一塊的檢查和防御也幾乎為零。
六.現(xiàn)實(shí)中的“寄生獸”漏洞攻擊案例
(1）利用zip解壓縮漏洞覆蓋緩存代碼
在三星輸入法漏洞的利用中，作者用到了安卓下的zip解壓縮漏洞，這個(gè)漏洞是單獨(dú)的一個(gè)漏洞，且由來(lái)以久，在google官方的文檔中已經(jīng)做了警告，存在問題的是ZipEntry.getName()方法，我們看一下google文檔中對(duì)該函數(shù)的描述：
鏈接：http://developer.android.com/reference/java/util/zip/ZipEntry.html#getName()
Gets the name of this ZipEntry
Security note: Entry names can represent relative paths. foo/../bar or ../bar/baz ,
for example. If the entry name is being used to construct a filename or as a path
component, it must be validated or sanitized to ensure that files are not written outside
of the intended destination directory.
可以看到google對(duì)該方法給出了一個(gè)安全提示，提示開發(fā)者如果該方法的返回值中包含有”../”跳轉(zhuǎn)符，需要特別注意不要將文件寫到了目標(biāo)文件夾之外。如果不對(duì)”../”跳轉(zhuǎn)符做過濾，就有可能遍歷目錄，在解壓zip文件時(shí)以本app的權(quán)限覆蓋任意文件。
下面是一個(gè)安卓zip解壓縮的常用代碼片段
1. ZipFile zip = new ZipFile(zipFile);
2. for(Enumeration entries = zip.entries();entries.hasMoreElements();){
3. ZipEntry zipEntry = (ZipEntry)entries.nextElement();
4. File file = new File(outputDirectory + File.separator+ zipEntry.getName());
5. …
6. }
如果沒有對(duì) zipEntry.getName進(jìn)行檢查，盲目解壓創(chuàng)建文件，將會(huì)穿越目錄建立文件，如圖:
我們檢測(cè)后發(fā)現(xiàn)市面上幾乎所有使用zip解壓縮功能的app都存在漏洞，為“寄生獸”漏洞的攻擊提供了便利，主要分為三類情況：
APP關(guān)聯(lián)文件類
這類漏洞主要影響有皮膚功能的APP，如輸入法，瀏覽器類APP .很多app在manifest中做了zip類文件的關(guān)聯(lián)，如果注冊(cè)的文件格式被點(diǎn)擊，對(duì)應(yīng)的app就會(huì)啟動(dòng)解壓文件。下圖是app注冊(cè)文件關(guān)聯(lián)的一個(gè)示例
這個(gè)app關(guān)聯(lián)了一個(gè)ssf格式的文件，其實(shí)這個(gè)文件的格式是zip壓縮格式，用戶在手機(jī)中下載打開ssf文件時(shí)，就會(huì)啟動(dòng)對(duì)應(yīng)的app自動(dòng)解壓文件，文件中包含的惡意代碼可以覆蓋該app的緩存代碼。
驗(yàn)證某輸入法app漏洞視頻
APP自升級(jí)類
這類漏洞主要影響有自動(dòng)升級(jí)下載zip類文件功能的app，在app下載文件過程中可以被中間人劫持攻擊，我們發(fā)現(xiàn)地圖類的app和sdk插件最容易收到攻擊，app在下載解壓資源文件的過程中被攻擊
驗(yàn)證某地圖app漏洞視頻
APP默認(rèn)解壓類
這類漏洞主要影響默認(rèn)有解壓縮zip文件功能的app，如瀏覽器直接下載zip文件打開后，app就被感染緩存代碼。
驗(yàn)證某瀏覽器漏洞視頻:
(2）利用adb backup覆蓋緩存代碼
如果開發(fā)者沒有在manifest里指定allowBackup="false" ，就可以在不需要root權(quán)限的情況下備份、恢復(fù)app私有目錄下的數(shù)據(jù)。如果該app用到了插件機(jī)制，則對(duì)應(yīng)的插件的odex文件也會(huì)被備份。攻擊者可以先用adb backup備份用戶數(shù)據(jù)，對(duì)備份下來(lái)的odex文件進(jìn)行修改，然后用adb restore恢復(fù)回去，就可以替換掉正常的odex文件，造成代碼劫持。
(3）其他可能的APP數(shù)據(jù)讀寫
如果一個(gè)木馬病毒利用root權(quán)限實(shí)施“寄生獸”漏洞攻擊方式，將能實(shí)現(xiàn)隱蔽的apt木馬攻擊方式，長(zhǎng)期潛伏在用戶的手機(jī)類，安全軟件很難發(fā)現(xiàn)app的緩存代碼被感染了。
七. “寄生獸”漏洞的防護(hù)方案
“寄生獸”漏洞的核心有兩點(diǎn)，一是google沒有考慮odex的安全問題需要開發(fā)者自己做防護(hù)，另一個(gè)是要阻斷漏洞的攻擊入口和利用方式，這里我們給出一些防護(hù)建議緩解該漏洞的攻擊。
(1）對(duì)odex文件進(jìn)行完整性校驗(yàn)
由于對(duì)odex一般是由系統(tǒng)(DexClassLoader)自動(dòng)生成的，且odex與apk/jar是相對(duì)獨(dú)立的，開發(fā)者事先無(wú)法知道odex文件的MD5等信息，所以很難通過MD5校驗(yàn)等手段保護(hù)odex的完整性；同時(shí)，系統(tǒng)的DexClassLoader函數(shù)只是校驗(yàn)了odex中的crc、modWhen字段，可以很輕易的被繞過。
所以，目前對(duì)odex的防護(hù)只能由app自身來(lái)做，可以在每次運(yùn)行DexClassLoader之前，清除已經(jīng)存在的odex；
另外，在odex第一次生成之后，存儲(chǔ)odex文件的MD5值，以后每次調(diào)用DexClassLoader的時(shí)候都對(duì)odex文件進(jìn)行MD5校驗(yàn)。
(2）對(duì)可能的劫持odex的攻擊入口漏洞進(jìn)行修復(fù)
對(duì)zip解壓縮的漏洞，只需要在調(diào)用zipEntry.getName()的時(shí)候，過濾返回值中的”../”跳轉(zhuǎn)符。
對(duì)于引用的第三方的zip庫(kù)也需要注意，可以用上面的測(cè)試用例測(cè)試一下第三方庫(kù)是否有zip解壓縮的漏洞；
調(diào)用DexClassLoader動(dòng)態(tài)加載dex的時(shí)候，第二個(gè)參數(shù)不要指定在sdcard上；
在manifest里指定allowBackup=”false”，防止應(yīng)用數(shù)據(jù)備份覆蓋
【原文：
影響數(shù)千萬(wàn)APP的安卓APP“寄生獸”漏洞技術(shù)分析 安全脈搏 Expl0r3r 整理發(fā)布】
