360手機安全研究團隊vulpecker近日發現了一種新型的安卓app安全漏洞，市面上數以千萬的app都受該漏洞影響。該漏洞一旦被攻擊者利用，可以直接在用戶手機中植入木馬，盜取用戶的簡訊、照片以及銀行、支付寶等帳號密碼，vulpecker以「寄生獸」命名這個漏洞。
目前vulpecker團隊已經通過補天平臺將相關詳情通知給各大安全應急響應中心，也向受此影響的各大廠商進行了通報，在此提醒用戶關注各APP廠商修復進程，並及時下載更新安裝最新的APP。
寄生獸是日本作家巖明均創作的漫畫《寄生獸》中的一種怪物，初始形態是一種蟲子，會鑽進生物的體內並奪取大腦，因人類嚴重的環境汙染而誕生，該漏洞的攻擊方式類似寄生獸的感染，可以長期駐留在受害者的手機內，本文將詳細分析這個漏洞，揭開漏洞的秘密。
0x01 關於app的緩存代碼安卓的應用程式apk文件是zip壓縮格式的文件，apk文件中包含的classes.dex文件相當於app的可執行文件，當app運行後系統會對classes.dex進行優化，生成對應的odex格式的文件。
odex文件相當於app的可執行文件的緩存代碼，一般安卓系統在第一次加載運行apk時會將系統生成odex文件存放於/data/dalvik-cache目錄下。
如圖
可以看到該目錄下的文件只有system用戶有寫權限，只有在擁有system權限的情況下才能對odex文件進行寫操作。
0x02 廣泛流行的插件機制由於安卓應用的升級都需要重新安裝程序，頻繁的升級給用戶體驗和開發都帶來了不便，所以市面上的app都開始採用插件機制，利用插件機制可以做到無縫升級和擴展功能，app只需要引入相應的插件文件就可以做到功能添加或升級，無需再重新安裝程序。
app插件機制的實現方式是把相關功能編寫成單獨的apk或jar文件，然後在程序運行時用DexClassLoader動態加載，進行反射調用。我們來看一下DexClassLoder的定義
public DexClassLoader (String dexPath, String optimizedDirectory, String libraryPath, ClassLoader parent)dexPath：是要加載的jar/apk的路徑optimizedDirectory：目標odex的路徑libraryPath：依賴的native library(so文件)路徑parent：父加載器
下面是常見的調用DexClassLoader的代碼片段
String dexFiles = "/data/data/com.test.dexload/app_al_sdk/drozer.apk";
final File optimizedDexOutputPath = appcontext.getDir("outdex", 0);
appcontext.getClassLoader();
DexClassLoader classLoader = new DexClassLoader(dexFiles, optimizedDexOutputPath .getAbsolutePath(), null, ClassLoader.getSystemClassLoader());
...
如圖drozer.apk插件在被調用後生成了drozer.dex緩存文件，注意這個文件是odex格式.
0x03 插件機制引入的攻擊點在2013年，國外的mwr實驗室給出了一個利用中間人的方式劫持app升級插件的攻擊案例，參考
https://labs.mwrinfosecurity.com/blog/2013/11/20/applovin-ad-library-sdk-remote-command-execution-via-update-mechanism/
幾年前，大部分採用插件機制的app，在載入插件前都沒有對插件文件進行完整性校驗，導致黑客可以通過中間人劫持的方式替換app的升級插件，在插件中嵌入惡意代碼控制用戶的app和手機。
現今，大部分採用插件機制的app都加強了安全性，如最早使用插件開發方式的微信等app，在下載使用插件前都會校驗插件文件的籤名，黑客已經無法通過中間人的方式替換插件攻擊app。
0x04 插件機制新的攻擊點近日，國外的nowsecure公司公布了三星輸入法的一個漏洞，利用過程直接替換了系統app的odex緩存代碼。參考：
https://www.nowsecure.com/blog/2015/06/16/remote-code-execution-as-system-user-on-samsung-phones/
三星輸入法是擁有系統最高級別的system權限，可以直接替換任意app的緩存文件。那安卓app插件的緩存代碼是否和APP主程序直接產生的緩存代碼一樣能被任意替換？
我們去android源碼中驗證了一下，通過DexClassLoader() 加載jar/apk文件，最終會通過native接口openDexFileNative() 進入到native層。
對應於android-4.2.2_r1/dalvik/vm/native/dalvik_system_DexFile.cpp中的Dalvik_dalvik_system_DexFile_openDexFileNative() 方法，在native層對幾個參數做一系列校驗，如果檢測到第二個參數指定的odex文件存在，則會調用dvmOpenCachedDexFile() 直 接打開，調用處的代碼如下：
fd = dvmOpenCachedDexFile(fileName, cachedName,
dexGetZipEntryModTime(&archive, entry),
dexGetZipEntryCrc32(&archive, entry),
isBootstrap, &newFile, /createIfMissing=/true);
很明顯，第3、4個參數對應的是優化前的classes.dex的時間戳和crc校驗值。最終會調用
dvmCheckOptHeaderAndDependencies(fd, true, modWhen, crc,
expectVerify, expectOpt)
如果crc、modWhen參數正確，則返回該odex的文件句柄；若crc、modEWhen校驗錯誤，則嘗試刪除錯誤的odex，並重建新的odex。所以，攻擊者如果要注入目標odex，需要對修改後的odex文件的crc及modWhen做修改。
下面是一個修改後的odex文件實例，dex_old是修改前的odex文件，dex_new是修改後的dex文件，兩個文件的md5不一樣，但是crc及modWhen卻是一樣的，這樣就可以繞過DexClassLoader的校驗。
0x05 「寄生獸」漏洞的真正危害安卓應用的代碼緩存機制是程序在執行時優先加載運行緩存代碼，而google卻只對緩存代碼做了可以偽造的弱校驗，這明顯這是一個安全架構實現上的嚴重漏洞。
廣大app開發者再使用插件機制開發app時可以對插件文件做完整性校驗，而系統生成的緩存代碼卻無法做到有效保護，一旦攻擊者將惡意代碼注入到緩存代碼中，開發者對app插件文件做的各種保護都將失效。這種攻擊很難被發現，即使重啟或關機，只要app一運行，惡意代碼也會隨之運行，同時安全軟體對這一塊的檢查和防禦也幾乎為零。
0x06 現實中的「寄生獸」漏洞攻擊案例1）利用zip解壓縮漏洞覆蓋緩存代碼
在三星輸入法漏洞的利用中，作者用到了安卓下的zip解壓縮漏洞，這個漏洞是單獨的一個漏洞，且由來以久，在google官方的文檔中已經做了警告，存在問題的是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 pathcomponent, it must be validated or sanitized to ensure that files are not written outsideof the intended destination directory.
可以看到google對該方法給出了一個安全提示，提示開發者如果該方法的返回值中包含有"../"跳轉符，需要特別注意不要將文件寫到了目標文件夾之外。如果不對"../"跳轉符做過濾，就有可能遍歷目錄，在解壓zip文件時以本app的權限覆蓋任意文件。
我們檢測後發現市面上幾乎所有使用zip解壓縮功能的app都存在漏洞，為「寄生獸」漏洞的攻擊提供了便利，主要分為三類情況：
APP關聯文件類
這類漏洞主要影響有皮膚功能的APP，如輸入法，瀏覽器類APP .很多app在manifest中做了zip類文件的關聯，如果註冊的文件格式被點擊，對應的app就會啟動解壓文件。下圖是app註冊文件關聯的一個示例
這個app關聯了一個ssf格式的文件，其實這個文件的格式是zip壓縮格式，用戶在手機中下載打開ssf文件時，就會啟動對應的app自動解壓文件，文件中包含的惡意代碼可以覆蓋該app的緩存代碼。
驗證某輸入法app漏洞視頻
http://v.youku.com/v_show/id_XMTI3NDA2MjkyNA==.html
APP自升級類
這類漏洞主要影響有自動升級下載zip類文件功能的app，在app下載文件過程中可以被中間人劫持攻擊，我們發現地圖類的app和sdk插件最容易收到攻擊，app在下載解壓資源文件的過程中被攻擊
驗證某地圖app漏洞視頻
http://v.youku.com/v_show/id_XMTI3MzgyMDU0MA==.html
APP默認解壓類
這類漏洞主要影響默認有解壓縮zip文件功能的app，如瀏覽器直接下載zip文件打開後，app就被感染緩存代碼。
驗證某瀏覽器漏洞視頻: http://v.youku.com/v_show/id_XMTI3NDIxMzUzMg==.html
2）利用adb backup覆蓋緩存代碼
如果開發者沒有在manifest裡指定allowBackup="false" ，就可以在不需要root權限的情況下備份、恢復app私有目錄下的數據。如果該app用到了插件機制，則對應的插件的odex文件也會被備份。攻擊者可以先用adb backup備份用戶數據，對備份下來的odex文件進行修改，然後用adb restore恢復回去，就可以替換掉正常的odex文件，造成代碼劫持。
3）其他可能的APP數據讀寫
如果一個木馬病毒利用root權限實施「寄生獸」漏洞攻擊方式，將能實現隱蔽的apt木馬攻擊方式，長期潛伏在用戶的手機類，安全軟體很難發現app的緩存代碼被感染了。
0x07 「寄生獸」漏洞的防護方案「寄生獸」漏洞的核心有兩點，一是google沒有考慮odex的安全問題需要開發者自己做防護，另一個是要阻斷漏洞的攻擊入口和利用方式，這裡我們給出一些防護建議緩解該漏洞的攻擊。
對odex文件進行完整性校驗
由於對odex一般是由系統(DexClassLoader)自動生成的，且odex與apk/jar是相對獨立的，開發者事先無法知道odex文件的MD5等信息，所以很難通過MD5校驗等手段保護odex的完整性；同時，系統的DexClassLoader函數只是校驗了odex中的crc、modWhen欄位，可以很輕易的被繞過。
所以，目前對odex的防護只能由app自身來做，可以在每次運行DexClassLoader之前，清除已經存在的odex；
另外，在odex第一次生成之後，存儲odex文件的MD5值，以後每次調用DexClassLoader的時候都對odex文件進行MD5校驗。
對可能的劫持odex的攻擊入口漏洞進行修復
對zip解壓縮的漏洞，只需要在調用zipEntry.getName()的時候，過濾返回值中的"../"跳轉符。對於引用的第三方的zip庫也需要注意，可以用上面的測試用例測試一下第三方庫是否有zip解壓縮的漏洞；
調用DexClassLoader動態加載dex的時候，第二個參數不要指定在sdcard上；
在manifest裡指定allowBackup=」false」，防止應用數據備份覆蓋;