國內Android App漏洞檢測發展簡史
前言：本文是《移動APP客戶端安全筆記》系列原創文章中的第一篇，主要講的是企業移動APP自動化漏洞檢測平臺建設，移動APP漏洞檢測發展史與前沿技術，APP漏洞檢測工具與平臺，以及筆者的一些思考。希望能對移動App自動化漏洞檢測感興趣的同學有所幫助，限於筆者技術水平與文章篇幅，有些內容暫沒有逐一詳細分析，後續我爭取多學習多分享，在此也歡迎大家指點和交流。
一、國內Android App漏洞檢測發展簡史
1.1石器時代 （2007-2011）
關鍵詞：反編繹，人工審計
2007年11年，Google正式發佈了Android操作系統，2011年12月，Google發佈了Android 2.3版本，Android 應用市場App數量突破10萬個，隨着Android系統的完善及Android設備數量的增加，Android超過塞班成爲主流智能手機操作系統。與此同時，一些安全研究人員已經敏感的嗅到了Android客戶端安全可能會成爲未來的安全熱點之一，不少傳統的二進制安全研究人員開始轉戰移動安全。
這個時間段國內對Android安全問題的關注主要集中在惡意App分析與檢測，App逆向與破解以及Android系統Root。對於Android客戶端安全問題剛主要集中在信息泄露，敏感權限使用的方面，通常使用反編繹工具分析APK源碼，然後進行人工審計。
1.2農業時代 (2012-2014)
關鍵詞：自動化審計、靜態分析、動態分析
2012到2014年間，Google發佈了Android4.0-5.0系統，此間爆出不了不少Android 相關漏洞，比如影響深遠的Webview遠程代碼執行漏洞，HTTPS中間人漏洞，讓越來越多的安全研究人員的焦點慢慢轉向Android App客戶端本身的安全漏洞挖掘上來。
國內一些廠商也開始研發自己Android App自動化審計系統，其中最早的對外發布的騰訊金剛審計系統算是國內這類產品的鼻祖之一，其早期版本在功能上實現了Android App自動化靜態分析與簡單的動態分析，審計點包括：明文保存敏感信息，文件權限問題，日誌信息泄露，組件權限問題，明文傳輸，拒絕服務等。
此時遇到Android APP自動化審計遇到的主要問題有：1.靜態分析主要依賴於關鍵詞匹配，如果缺少上下文分析與可達性分析，開發者正好自定義了一個相同關鍵詞的函數，或者存在漏洞的代碼根本沒有調用到，則會產生誤報。2、大多Android App的代碼與UI是緊密交互的，如果動態分析部分只進行了簡單安裝啓動App與自動隨機點擊，無法覆蓋App大部分界面與功能，則無法覆蓋更多的應用執行路徑，產生有效業務數據，容易導致漏報。
圖2 金剛審計系統主界面
1.3工業時代 (2015-至今)
關鍵詞：模糊測試、污點分析、通用脫殼、UI自動化遍歷
從2015年開始，360捉蟲獵手（現改名爲360顯微鏡），阿里聚安全等開放的在線Android App漏洞檢測平臺的出現讓開發者和安全研究者更加方便的進行漏洞審計，一些開源在線檢測平臺的出現（如MobSF）也降低了定製化APP漏洞審計系統的開發門檻。同時模糊測試，污點分析，通用脫殼，UI自動化遍歷等學術界與工業界技術也開始被應用到移動App漏洞審計中。下面簡單談談幾種技術在Android App漏洞檢測領域的應用，如果有讀者感到興趣的話後續再做詳細分享。
1.3.1 Android App Fuzzing
一般而言Fuzzing技術常用於二進制漏洞挖掘，在移動安全領域常見於挖掘系統組件漏洞（如libstagefright），文件解析類應用漏洞（如adobe reader，視頻播放器）及第三方組件漏洞，常使用的工具有：peach/afl/honggfuzz，以及DroidFuzzer（https://github.com/manfiS/droidfuzzer）/MFFA（https://github.com/fuzzing/MFFA）等框架，爲了提升成功率，通常可將幾種工具與框架組件使用，如AFL+PEACH+MFFA。除此之外，fuzzing技術同樣可用於測試Android
進程間通信（IPC），比如intent fuzzer（https://github.com/MindMac/IntentFuzzer）可以直接檢測App拒絕服務等漏洞。
污點分析可分爲靜態污點分析與動態污點分析。靜態污點分析不需要運行程序，以FlowDroid爲例，目前主流的App靜態污點分析技術主要包括如下步驟：
1. 解析應用AndroidManifest.xml，Layout配置文件和相關Dex字節碼，根據預先建模的Android LifeCycle Model生成超調用圖 ，又稱過程間控制流圖(Inter-procedural control flow graph, ICFG)；
2. 根據定義的污點源和錨點(Source and Sink)，將其轉換爲基於ICFG的後向或前向數據流問題進行求解；
3. 根據求解結果，回答是否存在從某輸入到輸出的數據流流動路徑，以顯式Intent問題爲例，FlowDroid會檢測到一個以發送intent的sink方法到最後接收intent的source的路徑存在。
動態污點分析則是在程序運行中過程，通過跟蹤變量、內存及寄存器的值，依據執行流程跟蹤污點數據的傳播，最後達到跟蹤攻擊路徑與獲取漏洞信息的目的，以TaintDroid爲例，需要對Android系統進行定製化修改以便對App運行過程中的污點數據進行跟蹤，但由於Android設備或模擬器性能瓶頸問題，動態污點分析無法獲取App所有可能的可執行路徑。
以往污點分析常用於Android惡意App分析，信息泄露檢測等問題，現在越來越多的廠商也應用於App漏洞檢測上（如阿里聚安全使用的基於TaintDroid方案）。相比傳統的App漏洞檢測，污點分析可以跟蹤污點數據的傳播過程，確定漏洞是否在實際環境中可能被觸發，檢測能力更加強大。目前也有不少開源的Android污點分析方案與工具如：TaintDroid、FlowDroid、amadroid及CodeInspect，在此之上也發展出一些針對Android App漏洞檢測方面的工具，如騰訊科恩實驗室Flanker之前開源的JAADS（https://github.com/flankerhqd/JAADAS）。
1.3.4移動 AppUI自動化遍歷
App UI自動化遍歷常在App開發測試中用於檢測App性能與兼容性，目前在App漏洞檢測領域用的比較少（主要由於效率較低）。一般主流的App漏洞檢測平臺都包含動態分析，主要是安裝App後自動運行App並監測App行爲，通常使用的是Android Monkey test腳本或其它工具隨機點擊APP界面。
實際上，爲了更深入的檢測App敏感信息泄露與後端WEB接口漏洞，僅靠隨機點擊App界面進行動態分析是不夠的（比如現在大部分App功能需要註冊登錄後才能使用），如果能更好的模擬正常用戶使用App的過程，則可以擴展監測Logcat日誌，本地文件存儲，網絡通信等數據審計能力。
目前APP UI測試框架按原理可分爲黑盒與白盒兩種，白盒測試需要在App開發時添加測試組件並調用，需要App完整源碼，黑盒測試一般提取App界面的UI元素並根據算法進行遍歷，無需App源碼。筆者推薦的黑盒APP UI測試框架與工具主要有AndroidViewClient（https://github.com/dtmilano/AndroidViewClient）及國人基於Appium開發的appCrawler（https://testerhome.com/topics/5718）。
二、Android App漏洞檢測
2.1 國內Android App在線漏洞檢測平臺
騰訊金剛審計系統 http://service.security.tencent.com/kingkong 免費 無限制
騰訊御安全 http://yaq.qq.com/ 免費 查看漏洞詳情需認證
阿里聚安全 http://jaq.alibaba.com/ 免費 查看漏洞詳情需認證
360顯微鏡 http://appscan.360.cn/ 免費 無限制
360APP漏洞掃描 http://dev.360.cn/html/vulscan/scanning.html 免費 無限制
百度MTC http://mtc.baidu.com 9.9元/次 無限制
梆梆 https://dev.bangcle.com 免費 無限制
愛內測 http://www.ineice.com/ 免費 無限制
通付盾 http://www.appfortify.cn/ 免費 無限制
NAGA http://www.nagain.com/appscan/ 免費 無限制
GES審計系統 http://01hackcode.com/ 免費 無限制
注：排名不分先後
2.2開源Android App漏洞檢測工具
1.MobSF
Github:https://github.com/ajinabraham/Mobile-Security-Framework-MobSF
Mobile Security Framework(MobSF)是印度安全公司（http://opensecurity.in）開發的一個智能化、一體化的開放源代碼的移動應用（Android / iOS）自動化測試框架，支持靜態和動態分析，App後端Web API漏洞檢測。
主要特點：基於Python Django的開源在線漏洞檢測框架，前端UI完善，基礎功能全面，安裝佈署方便，但總體來說審計點偏少，不適合實戰，更適合輔助分析與二次開發，國內目前不少在線APP檢測的平臺都有這個框架的影子。
2.Drozer
Drozer是MWR Labs開發的一個開源Android 安全測試框架，支持編寫自定義模塊。目前已經有不少介紹Drozer文章，這裏就不多說了。
3.Marvin
Github:https://github.com/programa-stic/
Marvin是西班牙Programa STIC組織發佈一個開源Android App漏洞檢測框架，該框架主要分爲四個項目：
（1）Marvin-Django
主要包含框架前端UI界面與數據庫部分；
（2）Marvin static analyzer
一個主要基於Androguard 及Static Android Analysis Framework (SSAF)的Android App靜態分析引擎。
（3）Marvin Dynamic Analyzer
一個APP動態分析引擎，基於OpenNebula及Android-x86 模擬器，可搭建分佈式分析系統，用於復現靜態分析發佈的漏洞與動態檢測漏洞。
（4）Marvin toqueton
一個自動化遍歷APP UI的工具，用於分析APP UI控件並進行自動化交互遍歷，輔助動態分析。
主要特點：
筆者剛看到這個項目發佈時研究了一番，主要特點有可直接搜索下載Google應用商店或者上傳應用進行分析，可編寫自定義靜態分析腳本，使用動態引擎複查靜態分析的結果提升準確性，使用本地應用去遍歷APP UI等，但仔細實踐後發現動態分析環境（ubuntu+openNebula+Android-X86）的佈署很麻煩，多次嘗試都未成功。
https://github.com/ac-pm/Inspeckage
一個Xposed插件，用於調試分析Android App。
主要特點：
使用方便，自帶WEB界面，裝Xposed插件可以分分鐘開始挖漏洞；2.功能全面：查看Manifest信息，監控本地文件讀寫，查看文件內容，查看Logcat日誌，查看網絡通信請求（支持SSL uncheck），監控IPC通信，查看加密操作，調用未導出組件等。
三、iOS App漏洞檢測
一般來說iOS App由於iOS系統安全限制（非越獄環境），且無法直接反編繹獲取App源碼，其在安全性上遠高於Android App，但近兩年前隨着XcodeGhost(https://security.tencent.com/index.php/blog/msg/96)，iBackDoor，AFNetworking中間人等後門事件與漏洞的曝光，iOS App安全性也慢慢受到國內開發者與安全研究人員的關注。
測試iOS App安全性離不開一臺越獄過的iOS設備，以及一些測試利器。在此簡單簡介兩個iOS App安全測試工具：
1.Idb
Github：https://github.com/dmayer/idb
Idb是一款開源的iOS App安全評估工具，作者是Danl A.Mayer。
主要功能：
1.查看應用以下信息：應用包名；註冊的URL Schemes；SDK版本；應用數據文件夾位置；應用權限等，
2.查看/下載應用數據文件；
3.查看應用文件保護級別；
4.Dump iOS keychain；
5.檢測應用是否加密；
6.檢測應用編繹安全選項(ASLR/PIE, DEP, ARC)；
7.查看應用的shared libraries；
8.提取應用binary中的字符串；
9.Class dump;
10.查看應用URL Handler；
11.Invoke and fuzz URL handlers；
12.查看系統剪切板
13.截屏
14.安裝系統證書；
15.編輯 /etc/hosts文件；
16.查看系統日誌；
Needle是MWR Labs開發的一個開源iOS安全測試框架，同樣支持開發自定義模塊來擴展Needle的功能，目前主要功能包含對iOS應用數據存儲，IPC，網絡通信，靜態代碼分析，hooking及二進制文件防護等方面的安全審計。
與drozer類似，Needle提供了一個shell界面，基本idb有的功能needle都有或者說以後也會有（因爲可以自己寫模塊），而Needle還同時支持Cycript與Frida兩個hooking方案，可以方便的加載hook腳本與執行命令。
3.2 iOS App自動化漏洞檢測
在很長一段時間內，iOS安全研究都主要集中在iOS系統安全漏洞挖掘中，由於iOS相對安全的系統機制保護與嚴格的審覈機制，iOS App安全性一般比Android App要高不少，歷史上出現的過一些iOS App漏洞也主要集中在iOS越獄環境下，但近年來XcodeGhost，AFNetworking框架中間人漏洞以及多個惡意SDK曝光也說明了iOS App安全性並沒有我們想像的那麼高，建設iOS App自動化漏洞審計平臺對於擁有大量iOS App產品的企業來說還是很有必要的。
爲了提升公司iOS App安全漏洞審計能力與應急能力，筆者與riusksk（林大夫）從2015年底開始一起研發iOS App漏洞審計系統（後續併入金剛），目前已經成功上線近半年，也輔助發現了一些iOS App業務安全漏洞，詳情可參考文章：https://security.tencent.com/index.php/blog/msg/105
此外360NirvanTeam（http://nirvan.360.cn）也上線了在線檢測功能，開源方案MobSF也有iOS App在線審計功能。此類審計平臺主要審計點有：BIN文件分析，第三方庫漏洞檢測，XCodeGhost檢測，惡意SDK檢測等。相對來說金剛更爲全面，適合開發上線前自查與安全研究人員輔助分析，包含了私有API檢測，開放端口檢測，應用文件審計，網絡通信數據審計，日誌審計，classdump等功能，後續還會繼續優化iOS App UI自動化遍歷功能與URL scheme Fuzzing功能。
筆者僅從個人角度談談對如何構建移動App漏洞檢測平臺的幾點看法：
（1）在平臺建設之初可以參考業界優秀的同類產品與開源方案，目前大部分移動App漏洞檢測平臺後端基本功能都是使用Python/Java開發，便於快速開發迭代。
（2）移動APP安全威脅是不斷變化的，漏洞審計規則也應該支持快速更新，同時企業移動App漏洞檢測平臺應該滿足移動App產品正式上線前審計，上線後日常排查兩個基本需求。
（3）很多開發人員和安全工程師對漏洞的理解是不一致的，在輸出漏洞檢測報告後，還需要提供詳細的漏洞利用場景講解與修復指引。
（4）多多關注學術界與工業界的新研究成果，如果能加入優化與利用，可以推動平臺整個技術能力的進步。
（5）平臺的主要建設者應該精通移動App漏洞挖掘實戰，能夠針對企業重點產品特性（如動態加載，熱補丁等技術）提供專業的解決方案。
同時筆者提出了一個甲方/乙方企業通用的移動App漏洞檢測平臺架構，企業可以在此基礎上直接接入Web漏洞掃描系統掃描App後端Web漏洞，也可以收集URL測試業務安全漏洞。
五、未來移動App漏洞檢測平臺發展方向
在Google最新發布的Android 7.0系統增加了不安全特性，如APP開發者可以使用系統提供的接口自主配置信任的證書，默認也不再信任用戶安裝的第三方CA證書，此舉可提升Android App網絡通信的安全性。
可見未來移動APP安全問題還將不斷變化，目前大部分移動APP漏洞檢測平臺最終的檢測結果也需要專業的安全研究人員評估實際風險，歷史上很多移動端嚴重漏洞也是需要結合業務場景的，所以說移動App漏洞檢測平臺也只是企業移動App安全建設中的一環，此外推動移動安全人才培養，移動App安全開發規範，應用加固，盜版監測等體系建設也同樣重要。
筆者個人認爲未來移動APP漏洞檢測平臺可發展的幾個方向有：
機器學習在網絡安全領域常用於惡意軟件檢測，流量檢測等方面，目前也已經出現一些利用機器學習進行Android惡意應用等方面的開源工具（https://github.com/mwleeds/android-malware-analysis）與研究，未來同樣也可能應用於Android App漏洞檢測。
2.威脅感知與大數據
如何從移動App中挖掘數據，並分析，整合進而利用於漏洞檢測與威脅感知也是未來移動APP漏洞檢測發展方向之一。目前部分漏洞檢測平臺已經開始支持採集應用市場所有移動APP源碼及運行過程中產生的網絡通信數據（如域名，IP，URL等），進行聚合分析與WEB接口漏洞檢測。同時四維智創，梆梆等安全公司開始推廣移動應用威脅感知產品，此類產品通過SDK收集應用的行爲與網絡數據，用於檢測APT攻擊，防刷單等場景。
3.社區化
目前國內已經有一些社區化的WEB漏洞檢測平臺，如Seebug，Tangscan等，盤古即將公測的Janus（http://appscan.io）也同樣開始主打社區化，Janus支持社區用戶自定義檢測規則，後臺結合海量全網應用數據，可用於全網應用快速漏洞掃描。同時社區化加入了安全研究員的人工審計流程，後續可以不斷提升漏洞特徵建模的細度與廣度，提升平臺檢測能力。
參考資料：
[1] http://www.ijcaonline.org/research/volume134/number7/dhavale-2016-ijca-907855.pdf
[2] http://www.droidsec.cn/
[3] https://loccs.sjtu.edu.cn/
[4] http://jaq.alibaba.com/community/index.htm
[5] http://drops.wooyun.org/
[6] https://blog.flanker017.me/
原文地址： https://security.tencent.com/index.php/blog/msg/109