摘要：阿里聚安全的應(yīng)用漏洞掃描服務(wù)，可以檢測出應(yīng)用的文件目錄遍歷風(fēng)險(xiǎn)。阿里聚安全對開發(fā)者建議對重要的壓縮包文件進(jìn)行數(shù)字簽名校驗(yàn)，校驗(yàn)通過才進(jìn)行解壓。

因?yàn)閆IP壓縮包文件中允許存在“../”的字符串，攻擊者可以利用多個(gè)“../”在解壓時(shí)改變ZIP包中某個(gè)文件的存放位置，覆蓋掉應(yīng)用原有的文件。如果被覆蓋掉的文件是動(dòng)態(tài)鏈接so、dex或者odex文件，輕則產(chǎn)生本地拒絕服務(wù)漏洞，影響應(yīng)用的可用性，重則可能造成任意代碼執(zhí)行漏洞，危害用戶的設(shè)備安全和信息安全。比如近段時(shí)間發(fā)現(xiàn)的“寄生獸”漏洞、海豚瀏覽器遠(yuǎn)程命令執(zhí)行漏洞、三星默認(rèn)輸入法遠(yuǎn)程代碼執(zhí)行漏洞等都與ZIP文件目錄遍歷有關(guān)。

阿里聚安全的應(yīng)用漏洞掃描服務(wù)，可以檢測出應(yīng)用的ZIP文件目錄遍歷風(fēng)險(xiǎn)。另外我們發(fā)現(xiàn)日本計(jì)算機(jī)應(yīng)急響應(yīng)小組（JPCERT）給出的修復(fù)方案存在缺陷。如果使用不當(dāng)（它提供的示例文檔就使用錯(cuò)誤），可能起不到防止ZIP文件目錄遍歷的作用，并且國內(nèi)有修復(fù)方案參考了此方案。

在Linux/Unix系統(tǒng)中“../”代表的是向上級目錄跳轉(zhuǎn)，有些程序在當(dāng)前工作目錄中處理到諸如用“../../../../../../../../../../../etc/hosts”表示的文件，會跳轉(zhuǎn)出當(dāng)前工作目錄，跳轉(zhuǎn)到到其他目錄中。

Java代碼在解壓ZIP文件時(shí)，會使用到ZipEntry類的getName()方法，如果ZIP文件中包含“../”的字符串，該方法返回值里面原樣返回，如果沒有過濾掉getName()返回值中的“../”字符串，繼續(xù)解壓縮操作，就會在其他目錄中創(chuàng)建解壓的文件。

如我們構(gòu)造的ZIP文件中有如下文件：

進(jìn)行解壓的代碼如下，沒有對getName進(jìn)行過濾：

解壓操作時(shí)的日志：

此ZIP文件存放在SD卡中，想讓解壓出來的所有文件也存在SD卡中，但是a_poc.txt文件卻存在了應(yīng)用的數(shù)據(jù)目錄中：

以海豚瀏覽器遠(yuǎn)程代碼執(zhí)行漏洞為例。

海豚瀏覽器的主題設(shè)置中允許用戶通過網(wǎng)絡(luò)下載新的主題進(jìn)行更換，主題文件其實(shí)是一個(gè)ZIP壓縮文件。通過中間人攻擊的方法可以替換掉這個(gè)ZIP文件。替換后的ZIP文件中有重新編譯過的libdolphin.so。此so文件重寫了JNI_OnLoad()函數(shù)：

此so文件以“../../../../../../../../../../data/data/mobi.mgeek.TunnyBrowser/files/libdolphin.so”的形式存在惡意ZIP文件中。海豚瀏覽器解壓惡意ZIP文件后，重新的libdolphin.so就會覆蓋掉原有的so文件，重新運(yùn)行海豚瀏覽器會彈出Toast提示框：

能彈出Toast說明也就可以執(zhí)行其他代碼。

這里分析下此漏洞產(chǎn)生的原因是：

1、主題文件其實(shí)是一個(gè)ZIP壓縮包，從服務(wù)器下載后進(jìn)行解壓，但是解壓時(shí)沒有過濾getName()返回的字符串中是否有“../”：

2、動(dòng)態(tài)鏈接庫文件libdolphin.so，并沒有放在應(yīng)用數(shù)據(jù)的lib目錄下，而是放在了files目錄中：

加載使用的地方是com.dolphin.browser.search.redirect包中的SearchRedirector：

應(yīng)用使用的是System.load()來加載libdolphin.so而非System.loadLibrary()，在Android中，System.loadLibrary()是從應(yīng)用的lib目錄中加載.so文件，而System.load()是用某個(gè).so文件的絕對路徑加載，這個(gè).so文件可以不在應(yīng)用的lib目錄中，可以在SD卡中，或者在應(yīng)用的files目錄中，只要應(yīng)用有讀的權(quán)限目錄中即可。

在files目錄中，應(yīng)用具有寫入權(quán)限，通過網(wǎng)絡(luò)中間人攻擊，同時(shí)利用ZIP文件目錄遍歷漏洞，替換掉文件libdolphin.so，達(dá)到遠(yuǎn)程命令執(zhí)行的目的。

應(yīng)用的lib目錄是軟鏈接到了/data/app-lib/應(yīng)用目錄，如果libdolphin.so文件在lib目錄下就不會被覆蓋了，第三方應(yīng)用在執(zhí)行時(shí)沒有寫入/data/app-lib目錄的權(quán)限：

在研究中我們發(fā)現(xiàn)JPCERT提供的修復(fù)方案存在缺陷。它是利用Java的File類提供的getCanonicalPath()方法過濾掉zipEntry.getName()返回的字符串中所包含的“../”，然后檢查這個(gè)字符串是否是以要解壓到的目標(biāo)目錄字符串為開頭，如果是，返回getCanonicalPath()獲取到的字符串，如果不是，則拋出異常：

但是在JPCERT給出的示例代碼中，對validateFilename()的調(diào)用對于APP來說不會達(dá)到防止任意目錄遍歷的目的：

其使用“.”，作為要解壓到的目的目錄，“.”表示當(dāng)前目錄，經(jīng)測試APP進(jìn)程的當(dāng)前工作目錄是根目錄“/”：

查看進(jìn)程狀態(tài)，得到的APP進(jìn)程的當(dāng)前工作目錄cwd是鏈接到了根目錄：

如下的Demo，如果采用JPCERT示例中validateFilename(entry.genName(), “.”)的調(diào)用方式，還是會產(chǎn)生目錄遍歷讀到系統(tǒng)配置文件：

讀到的hosts文件內(nèi)容：

正確的調(diào)用validateFilename()形式是傳入的要解壓到的目的目錄不要用“.”，而是指定一個(gè)絕對路徑。

對重要的ZIP壓縮包文件進(jìn)行數(shù)字簽名校驗(yàn)，校驗(yàn)通過才進(jìn)行解壓。

檢查Zip壓縮包中使用ZipEntry.getName()獲取的文件名中是否包含”../”或者”..”，檢查”../”的時(shí)候不必進(jìn)行URI Decode（以防通過URI編碼”..%2F”來進(jìn)行繞過），測試發(fā)現(xiàn)ZipEntry.getName()對于Zip包中有“..%2F”的文件路徑不會進(jìn)行處理。

在應(yīng)用上線前使用阿里聚安全的安全掃描服務(wù)，盡早發(fā)現(xiàn)應(yīng)用的安全風(fēng)險(xiǎn)。

阿里聚安全掃描器建議修復(fù)方案：在使用java.util.zip包中ZipInputStream類的進(jìn)行解壓操作時(shí)，進(jìn)行檢查。示例如下

也可以使用java.util.zip包中的ZipFile類，直接讀取Zip包中的所有entries，然后檢查getName()的返回值是否包含“../”：

[1] https://www.jpcert.or.jp/present/2014/20140910android-sc.pdf
2] [《海豚瀏覽器與水星瀏覽器遠(yuǎn)程代碼執(zhí)行漏洞詳解》
3] [《影響數(shù)千萬APP的安卓APP“寄生獸”漏洞技術(shù)分析》
4] [《三星默認(rèn)輸入法遠(yuǎn)程代碼執(zhí)行》
[5] http://www.oracle.com/technetwork/articles/java/compress-1565076.html
[6] http://stackoverflow.com/questions/1099300/whats-the-difference-between-getpath-getabsolutepath-and-getcanonicalpath
[7] http://stackoverflow.com/questions/7016391/difference-between-system-load-and-system-loadlibrary-in-java

目錄
Android安全開發(fā)之Provider組件安全
Android安全開發(fā)之淺談密鑰硬編碼
Android安全開發(fā)之淺談網(wǎng)頁打開APP
Android應(yīng)用安全開發(fā)之淺談加密算法的坑

作者：伊樵、呆狐@阿里聚安全，更多安全技術(shù)文章，請?jiān)L問阿里聚安全博客