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