一、 閑聊
說到移動安全，可能大家比較陌生，因為這方面的研究是在最近幾年才逐漸火起來的。那么什么是移動安全呢？首先，我們知道，移動安全無非就是ios平臺和安卓平臺上的一些安全性的問題，包括平臺系統系統本身的一些問題和應用層面上的問題。當然在客戶端和服務端在進行交互的時候還需要涉及一些通信協議，主要是http及https協議，當然還有一些其他的協議，比如websocket等等。這些協議本身的缺陷我們就不做過多的關注了，我們需要關注的是數據包在傳輸的過程中是否有進行必要的加密，服務端是否有對用戶的操作權限進行控制，服務端的一些業務邏輯處理是否存在缺陷等等，這一方面的思路基本和web滲透差不多，但也有一些不同。
二、木馬攻擊
說到移動安全，當然少不了病毒和木馬的攻擊，常見的遠控木馬有droidjack、spynote等等，還有前一段時間如雨后春筍般涌現的鎖機軟件。
圖1Droidjack
圖2 鎖機軟件
攻擊者可以利用Droidjack這類軟件，生成木馬程序，這種惡意的木馬程序一般存在于一些三流的apk市場里。一般來說，攻擊者會在這些apk中投放一些帶有誘惑性的信息，比如免費觀看某某美女視頻，某某視頻免廣告客戶端，某某爽圖瀏覽器等等。攻擊者將這些帶有誘惑性信息的apk發布到網絡上后，會在遠程服務器上起一個服務端程序，一旦用戶安裝運行了這個惡意程序，黑客就可以在遠程服務端對用戶手機進行操控，監視用戶的各種行為，進而竊取用戶隱私信息。
歸根結底，這些木馬病毒層面的攻擊，主要還是由于用戶安全意識方面太薄弱，就不做為主要的討論對象了，我們主要還是針對安卓的應用層面的安全性進行一些討論。
三、App服務端漏洞挖掘
那么我們該如何進行app漏洞的挖掘呢？首先，對于從web安全轉戰移動端漏洞挖掘的安全工作者而言，當然想挖一挖和自己所在領域比較相近的漏洞，而app的服務端基本和web安全領域的服務端差不多，只是web程序它的客戶端更多的是瀏覽器，而移動應用它一般都有一個可以安裝在移動設備上的app程序。所以，對于app服務端漏洞的挖掘上面，我們照樣可以憑借以往的web經驗，對其中的一些xss，ssrf，sql注入，任意文件讀取等漏洞進行挖掘。
在對web應用進行漏洞進行挖掘時，我們可以通過在瀏覽器配置代理，來對我們web應用進行抓包分析，那么對移動端應用我們該怎么進行數據包分析呢？?
其實，安卓應用的數據包分析也是要基于代理的，只是代理的配置相對復雜點罷了。我們在burptsuit或者fiddler中配置相應的代理后就可以使用他們進行數據包的截取和重放操作了。具體的步驟這里就不做詳細闡述，網上都有教程，各位可自行查閱。
這里，對于xss，sql注入等一些經典的漏洞我就不做多說了，也沒什么好說的，這里主要說下移動應用的越權漏洞。我們知道，web安全里，越權漏洞一般時由于服務端沒有對用戶請求進行權限校驗，只憑用戶id就執行了用戶請求而導致的。那么正確認證方式是一種什么樣的過程呢？用文字簡要的描述就是:用戶在登陸認證成功后，服務端會將標識用戶權限寫進cookie，然后返回給瀏覽器，瀏覽器保留下這個cookie；用戶在之后發起的請求包中帶上這個cookie，服務端對數據包中的cookie做校驗，從而識別用戶權限，執行相應權限的操作。
圖3 cookie認證過程
當然，還有一種認證方式是session認證。Session認證和cookie認證都可以對用戶的身份進行認證，那么，Session認證和cookie認證方式的區別什么呢？ ???
簡單來說，cookie存放在客戶端，而session存放在服務端。從安全的角度來說的話，cookie相對不安全，而session相對安全些，因為cookie是存放在客戶端的，攻擊者可以在客戶端獲取cookie，如果用于標識用戶身份的字段沒有進行加密，容易被枚舉，那么，攻擊者就可以對cookie進行偽造，進而進行越權操作。而如果啟用了session認證，那么客戶端登入成功后獲得的僅僅是對應的session的id。這個id是一串加密的字符串，是無法被遍歷的。
那么它的認證過程又是什么樣的呢？首先我們要知道，session認證也需要依賴于cookie的，用戶在登陸成功后，服務端會將用戶對應的session寫進服務端的數據庫中，session中帶有用戶的一些身份標識等信息，然后服務端會將這個session對應的id發送給客戶端，所以客戶端中的cookie的內容一般就只有一串sessionid=xxxxxx這樣的字符串。用戶在之后發起的請求中需要帶上這個sessionid，服務端通過識別sessionid，然后查詢數據庫，獲得相應的用戶權限信息，然后再判斷用戶是否有權限執行響應的操作。
顯然，session機制要相對安全一些，但安全的另一面也是需要付出代價的，相對cookie來說，session機制會更加消耗服務器的性能。
圖4 Session認證過程
但是，在移動端，用戶身份認證是不用cookie的，而是基于token進行識別。那么它又是一種什么樣的認證方式呢？用簡要的文字表述的話，它的認證過程一般是這樣的，客戶端登陸驗證成功后，服務端會返回一個token字符串，這個字符串就是該用戶的會話憑證，用戶在此后與服務端進行交互時，都要帶上這個token，這樣才能對用戶身份進行識別。
圖5 Token認證過程
如果我們在分析數據包的時候，發現有請求是不帶token的，那么這個數據包很有可能就存在越權漏洞，當然還得結合具體的場景進行分析，判斷其是否對業務邏輯有影響。這是我們在移動端挖掘越權漏洞的一般姿勢。但是，這種姿勢未免太弱智，沒什么門檻，基本是誰碰到都能挖。
針對越權漏洞，還有一種挖掘姿勢，說起來，感覺也比較奇葩，這種越權漏洞的產生根本原因是由于認證策略本身的失誤。記得在很久以前，對一款直播軟件進行過一次協議的分析，發現其認證邏輯是這樣的：用戶登入校驗成功后，服務端返回用戶id，然后本地生產用戶token，在此后的請求中，帶上這個token作為用戶身份的憑證。這個顯然是有bug的，因為這個用戶id是可以遍歷的，而token的生成算法是在本地，所以攻擊者只要獲取到其他用戶的id然后將本地的token生成算法摳出來，就可以自己計算token，然后偽造用戶登陸了。
當然這種越權漏洞的挖掘難度還是比較大的，這要求漏洞挖掘者有比較深的逆向分析能力和編碼能力。但是，作為開發者，絕不能因為這種難度而放松對應用安全方面的加固，特別是用戶認證這種非常重要的功能模塊，一定要做好安全方面的防護。
四、Apk客戶端漏洞挖掘
1、常用工具介紹
至于客戶端的漏洞，主要是通過反編譯工具對app客戶端進行反編譯，獲得源碼，然后結合一些經驗及安全知識進行靜態源碼審計。常見的反編譯工具有apkide，jeb，apktools等。下面給大家截個圖，了解一下：
圖6 改之理
圖7 Jeb
當然我最喜歡用的還是android逆向助手，非常實用。
圖8android逆向助手
結合jeb使用，基本可以滿足日常逆向分析。
安卓應用平臺主要分為native層和java層。Java層的話，我們可以使用以上工具進行分析，而native層的話，則要借助ida來進行分析。Ida是一款非常好用的反匯編工具，我們可以通過ida對apk的so文件進行反匯編，然后利用其f5功能，將arm匯編代碼轉為c++偽代碼，對其中的邏輯算法進行分析。它還支持動態調試，可遠程調試apk應用，我們可以利用ida動態調試，bypass掉一些so層中的校驗，如二次打包校驗，或者進行動態調試脫殼。
2、應用脫殼簡介
說到應用脫殼，這在apk分析過程中是很有必要的。在說脫殼之前，我們先來了解下什么是加殼。加殼即在應用運行之前優先獲得程序的控制權，之后再把程序的控制權交給原來的程序。在安卓平臺上的加殼實現是將原本的dex文件加密并隱藏起來，然后通過殼程序獲取原本的dex文件再還原回去；還有一種是將函數指令抽取出來，在運行的時候，通過hook相應的類加載函數，將指令填充回去。
對于加殼后的應用，原程序的邏輯基本面目全非了，我們無法通過加殼后的程序來進行安全分析。所以，我們需要對應用進行脫殼處理。常見的自動化脫殼工具有drizzledump和dexhunter。Dexhunter很好用，但需要刷機，而且很多加密廠商都對其進行了檢查，所以直接用是行不通的，需要做一些修改，bypass一些檢測。至于詳細的使用方式，大家可以自行上網尋找教程，這里就不做贅述了。如果工具不能用，那最后只好上ida了。
3、靜態源碼審計
下面我們來詳細看一下針對源碼層面的安全檢測需要注意的問題。
組件安全
首先是組件方面的安全問題，我們知道安卓應用有四大組件，分別是：activity，service，content provider，broadcast receiver。這些組件如果不是很有必要，應該將其導出屬性即exported設置為false，即禁止導出。如果設置為true的話就會被外部應用調用，可能造成信息泄露，權限繞過等漏洞。另外，在使用Intent.getXXXExtra() 獲取或處理數據的時候，如果沒有做 ? ?try…catch進行異常處理的話，就可能出現拒絕服務漏洞，這些異常包括但不限于：空指針異常、類型轉換異常、數組越界訪問異常、類未定義異常、序列化反序列化異常。
像上面提到的組件安全，我們一般都是通過分析安卓的androidManifest.xml文件來判斷的。AndroidManifest.xml是Android應用的入口文件，它描述了package中暴露的組件（activities, services, 等等），他們各自的實現類，各種能被處理的數據和啟動位置。 除了能聲明程序中的Activities, ContentProviders, Services, 和Intent Receivers,還能指定permissions和instrumentation（安全控制和測試）。通過分析這個manifest.xml文件，我們還可以發現例如應用數據備份和應用可調式這些漏洞。當然這些漏洞一般屬于比較低危的漏洞，即對程序的業務邏輯不會造成太大的影響。而且應用可調式這個漏洞，其實即使設置了debuggable禁止攻擊者調試該應用，也不能夠阻止攻擊者對應用進行調試，因為開發者只能控制應用本身不受調試，但控制不了用戶的系統。攻擊者只要設置下內存中的一個屬性即可對系統中的所有應用進行調試，無論應用是否設置可被調試。但，此處還是有必要做下這個禁止調試的設置的，因為并不是所有的逆向分析者都知道能夠繞過這個設置的。
webview安全問題
要說安卓客戶端應用中比較嚴重的漏洞，那肯定是webview方面的漏洞了?，F在很多App里都內置了Web網頁，比如說很多電商平臺，淘寶、京東、聚劃算等等，如下圖：
圖9 webview展示圖
其實這些都是android中的一個組件webview實現的。WebView是一個基于webkit引擎、展現web頁面的控件，它的作用是顯示和渲染web頁面，直接使用html文件作布局，與javascript交互調用。Webview可以單獨使用，也可以結合其他子類一起使用。Webview最常用的子類有WebSettings類、WebViewClient類、WebChromeClient類。這里就不做過多介紹了，如果對安卓編程感興趣的，可以百度查找更多資料。
Webview這個組件可謂是一個兩面刀，一方面，它的出現可以減輕客戶端開發的負擔，將程序的主要邏輯放到服務端上進行實現，本地只要使用webview加載相應的網頁即可，但如果配置不恰當，就可能存在遠程命令執行漏洞。相關的cve有cve-2012-6636，cve-2014-1939，cve-2014-7224。
cve-2012-6636這個漏洞是源于程序沒有正確限制使用WebView.addJavascriptInterface方法。遠程攻擊者可通過使用Java Reflection API ? ?利用該漏洞執行任意Java ? ?對象的方法。
cve-2014-1939 這個漏洞是由于java/android/webkit/BrowserFrame.java 使用 addJavascriptInterface API ? ?并創建了SearchBoxImpl類的對象，攻擊者可通過訪問searchBoxJavaBridge_ 接口利用該 ? ? ? ?漏洞執行任意Java代碼。
cve-2014-7224 攻擊者主要是利用了accessibility和accessibilityTraversal 這兩個 ? ?Java Bridge來執行遠程攻擊代碼。
Webview遠程命令執行的產生還需要依賴java的反射機制。Webview ? ?中的addJavascriptInterface方法可以往 WebView里注入了一個 ? ?Java Object, ?而這個Jave Object 的方法可以被Javascript 訪問。之所以提供 ? ? ? ?addJavascriptInterface， 是為了WebView中的Javascript可以和本地的 ? ? ? ? ? ?App 通訊。這確實是一個很強大的功能，這么做的好處在于本地App邏輯不變的情況下，不需要升級App ? ? ? ? ? ? ? ?就可以對程序進行更新，修改相應的 Web頁面就可以了。但是在Android 的早期版本并沒有對可以訪問的方法做限制，利用 ? ? ? ? ? ? ? ? ? ?Java ?的反射機制，可以調用任意對象的任意方法，這就是WebView?漏洞 ? ? ? ? ? ? ? ? ? ? ? ?的根本成因。
apk更新包攻擊 (中間人攻擊)
上面提及的幾個漏洞是安卓應用中比較常見也是影響比較大的漏洞，還有一些漏洞相對影響比較輕，但如果利用得當它的危害還是比較嚴重的。比如中間人攻擊，它需要攻擊者和受害者處于同一個局域網下，受害者的流量受到攻擊者的控制。中間人攻擊能干什么？彈個xss嗎？獲取用戶 ? ?cookie？當然這里顯然獲取用戶cookie沒有用，應該是token ? ?信息。在移動端攻擊中，中間人攻擊利用得當甚至可以導致遠程命令執行。比如控制應用更新時下載的更新包，將其替換為惡意的攻擊數據包，應用沒有對更新包做必要的簽名校驗就執行了這個被攻擊者改造后的返回包中的更新程序，這就可能導致惡意程序程序被執行。
五、Apk漏洞靜態掃描工具實現
1、項目介紹
對于客戶端的漏洞檢測，目前沒有什么好的掃描引擎。前一段時間調研了下某數字公司，某梆，某加密的apk安全掃描工具，效果一般，基本差不多，都是基于反編譯后的源碼進行的簡單漏洞驗證。那么我們是否也可以自己寫一個自動化檢測工具呢？我此前也自己寫了一個 ? ?apk自動化漏掃工具。
下面我來講一下我的實現思路，首先我們知道，我們主要的分析對象是AndroidManifest.xml和dex 文件，但這兩個都是編譯后的二進制文件，我們需要將他們反編譯出來。反編譯 ? ?AndroidManifest.xml需要用到的工具是AXMLPrinter.jar，而反編譯 dex文件需要用到的文件是 ? ? ? ?baksmali.jar。其實這兩個jar包也是一些逆向工具常用的 jar包。我們來看下 ? ? ? ? ? ?android逆向助手這款反編譯工具的程序目錄：
圖10 安卓逆向助手程序目錄
這個名叫android逆向助手的逆向工具主要就是用了這兩個工具實現對AndroidManifest 和 ? ?dex文件進行反編譯的。
我們的自動化漏掃工具中只要編寫相應的邏輯，調用這兩個工具將AndroidManifest和dex 文件反編譯出來后，我們就可以通過匹配一些漏洞特征，對漏洞進行檢測了。
下面是項目目錄結構的簡要介紹：
圖11 Apk漏洞掃描項目目錄及簡介
首先我們需要應用的包名，然后對application的一些設置進行檢測，如是否允許備份，是否可調式等；然后獲得acvitiy ， ? ?service，content provider，broadcast receiver 這四個組件的一些配置信息，判斷其是否可導出；然后獲取應用申請的權限，判斷其是否過于敏感；獲取應用自身創建的權限，判斷下它是否做好了權限限制。
接下來對反編譯后的smali文件進行漏洞特征檢測。這主要是依賴與我們事先收集好的漏洞特征。這里我把漏洞特征寫到了一個xml 文件中，在啟動漏洞掃描的時候，加載到內存中，供程序調用。我們可以自定義這些漏洞特征，讓我們的程序可以掃描到更多的漏洞。目前漏洞特征的定義支持字符串和正則形式。這個項目目前還在維護，不過基本功能都已經實現，可以滿足日常的掃描檢測，只要稍微對掃描結果進行一些排誤即可。
2、目前軟件支持的漏洞檢測類型
1、任意文件讀寫漏洞
2、密鑰硬編碼漏洞
3、強制類型轉換本地拒絕服務漏洞
4、系統組件本地拒絕服務漏洞
5、Intent Schema URL漏洞
6、Content Provider組件本地SQL ? ? ? ?注入漏洞
7、代碼動態加載安全檢測
8、證書弱校驗
9、主機名弱校驗
10、HTTPS敏感數據劫持漏洞
11、Hash算法不安全
12、AES弱加密
13、Locat泄露隱私信息
14、日志泄漏風險
15、PendingIntent誤用風險
16、Intent隱式調用
17、數據庫文件任意讀寫
18、WebView系統隱藏接口漏洞檢測
19、WebView組件遠程代碼執行漏洞檢測
20、WebView忽略SSL證書錯誤檢測
21、WebView明文存儲密碼
22、SharedPreferences任意讀寫
23、任意文件讀寫
24、隨機數使用不安全
25、組件權限檢查
26、應用是否可調式檢查
27、應用權限檢查
28、應用自定義權限檢查
30、應用備份漏洞檢查
3、使用方法
1、將需要掃描的apk文件放到workspace/apk ? ? ? ?目錄下
2、點擊AndroidCodeCheck.exe或執行python AndroidCodeCheck.py ? ? ? ?即可執行漏洞掃描
4、報告輸出
報告輸出路徑在report下
1）txt格式
算是程序的運行日志吧，也可以作為掃描結果參考。
2）html格式
html格式的報告有目錄，點擊目錄中的漏洞名稱即可跳轉到相應的漏洞類型說明。在類型說明處可點擊返回目錄返回到漏洞目錄列表，方便漏洞審閱。
最后給一個漏洞掃描的報告截圖，有點簡陋，后期會逐步完善。
? ? ? ? ? ? 圖12 報告目錄首頁
圖13 漏洞詳情
5、項目地址
Apk靜態源碼漏掃工具項目地址：
https://github.com/zsdlove/ApkVulCheck
