Android 應用程序是在開發應用程序時建立的數據和資源文件的歸檔文件。 Android 應用程序的擴展名是.apk,意思是應用程序包,在大多數狀況下包括如下文件和文件夾:php
爲了驗證這一點,咱們可使用任何歸檔管理器應用程序(如 7zip,WinRAR 或任何首選應用程序)簡單地解壓縮應用程序。 在 Linux 或 Mac 上,咱們能夠簡單地使用unzip命令來展現壓縮包的內容,以下面的截圖所示android
Android 應用程序由各類組件組成,它們一塊兒建立可工做的應用程序。 這些組件是活動,服務,廣播接收器,內容供應器和共享首選項。 在繼續以前,讓咱們快速瀏覽一下這些不一樣的組件: git
Android應用程序只是一個數據和資源的歸檔文件。 即便這樣,咱們不能簡單地解壓縮歸檔包(.apk)來得到可讀的源代碼。 對於這些狀況,咱們必須依賴於將字節代碼(如在classes.dex中)轉換爲可讀源代碼的工具github
在mac os系統上反編譯android apk,首先須要準備好如下3個文件:算法
一、apktool:https://ibotpeaches.github.io/Apktool/install/ shell
二、dex2jar:https://github.com/pxb1988/dex2jar 數據庫
三、jd-gui:http://jd.benow.ca後端
打開jd-gui工具,將classes-dex2jar.jar拖入便可 瀏覽器
使用 Apktool 逆向 Android 應用 緩存
另外一種逆向 Android應用程序的方法是將.dex文件轉換爲 smali 文件。 smali 是一種文件格式,其語法與稱爲 Jasmine 的語言相似。咱們如今不會深刻了解 smali 文件格式。有關更多信息,請參閱在線 wikihttps://code.google.com/p/smali/wiki/,以便深刻了解 smali
1)將.apk文件與 Apktool 二進制文件一塊兒傳遞給命令行。一旦反編譯完成,Apktool 將使用應用程序名稱建立一個新的文件夾,其中會存儲全部的文件。爲了反編譯,咱們只需調用apktool d [app-name].apk (-d標誌表示反編譯)
2)apktool b [decompiled folder name] [target-app-name].apk 生成class.DEX2jar.jar 文件
Android 應用程序一般包含許多安全漏洞,大多數時候是因爲開發人員的錯誤和安全編碼實踐的無視
許多應用程序使用內容供應器來存儲和查詢應用程序中的數據或來自電話的數據。 除非已經定義了內容提供者可使用權限來訪問,不然任何其餘應用均可以使用應用所定義的內容供應器,來訪問應用的數據。 全部內容供應器具備惟一的統一資源標識符(URI)以便被識別和查詢。 內容提供者的 URI 的命名標準慣例是以content://開始。
若是 Android API 版本低於 17,則內容供應器的默認屬性是始終導出。 這意味着除非開發人員指定權限,不然任何應用程序均可以使用應用程序的內容供應器,來訪問和查詢數據。 全部內容供應器都須要在AndroidManifest.xml中註冊。 所以,咱們能夠對應用程序使用 Apktool,並經過查看AndroidManifest.xml文件檢查內容供應器
定義內容供應器的通常方法以下所示:
<provider
android:name="com.test.example.DataProvider"
android:authorities ="com.test.example.DataProvider">
</provider>
簡單地查看定義它們的AndroidManifest.xml文件,或者咱們可使用一個簡單的grep命令,從應用程序代碼中獲取內容供應器 ,使用grep –R 'content://'
經過建立另外一個沒有任何權限的應用程序來查詢內容供應器,而後查詢漏洞應用程序的內容供應器。 爲了快速得到信息,咱們還可使用adb查詢內容供應器,咱們能夠在如下命令中看到:
adb shell content query - - uri [URI of the content provider]
還可使用 MWR 實驗室的另外一個名爲 Drozer 的工具,以便在 Android 應用程序中找到泄漏的內容供應器漏洞。 咱們能夠從官方網站https://labs.mwrinfosecurity.com/tools/drozer/下載並安裝 Droze
一旦咱們安裝了它,咱們須要將代理組件agent.apk安裝到咱們的模擬器,它位於下載的.zip文件內。 該代理是系統和設備相互交互所需的。 咱們還須要在每次啓動模擬器時轉發一個特定的端口(31415),以便創建鏈接。 要在 Mac 和其餘相似平臺上安裝設備,咱們能夠按照https://www.mwrinfosecurity.com/system/assets/559/original/mwri_drozer-users-guide_2013-09-11.pdf上提供的在線指南
此後,咱們須要訪問終端並啓動 Drozer,並將其鏈接到模擬器/設備。 爲此,咱們須要輸入drozer console connect
dz> run app.provider.finduri com.threebanana.notes
Scanning com.threebanana.notes…
content://com.threebanana.notes.provider.NotePad/notes
content://com.threebanana.notes.provider.NotePadPending/notes/
content://com.threebanana.notes.provider.NotePad/media
content://com.threebanana.notes.provider.NotePad/topnotes/
content://com.threebanana.notes.provider.NotePad/media_with_owner/
content://com.threebanana.notes.provider.NotePad/add_media_for_note
content://com.threebanana.notes.provider.NotePad/notes_show_deleted
content://com.threebanana.notes.provider.NotePad/notes_with_images/
一旦咱們有了 URI,咱們如今可使用 Drozer 應用程序查詢它。 爲了查詢它,咱們須要運行app.provider.query模塊並指定內容供應器的 URI,以下面的截圖所示
若是 Drozer 可以查詢和顯示來自內容供應器的數據,這意味着內容供應器泄漏數據而且存在漏洞,由於 Drozer 沒有被明確地授予使用數據集的任何權限。
爲了修復此漏洞,開發人員須要作的是,在建立內容供應器時指定參數android:exported = false,或者建立一些新的權限,另外一個應用程序在訪問供應器以前必須請求它
一般,開發人員爲應用程序存儲數據時,未指定文件的正確文件權限。 這些文件有時被標記爲全局可讀,而且能夠由任何其它應用程序訪問而不須要請求權限,
爲了檢查這個漏洞,咱們所須要作的是訪問adb shell,以後使用cd進入/data/data/[package name of the app]
若是咱們在這裏執行一個簡單的ls -l,就能夠看到文件和文件夾的文件權限:
# ls -l /data/data/com.aditya.example/files/userinfo.xml
-rw-rw-rw- app_200 app_200 22034 2013-11-07 00:01 userinfo.xml
這裏咱們可使用find來搜索權限。
find /data/data/ -perm [permissions value]
若是咱們執行cat userinfo.xml,它儲存了應用的用戶的用戶名和密碼。
#grep 'password' /data/data/com.aditya.example/files/userinfo.xml
<password>mysecretpassword</password>
這意味着任何其餘應用程序也能夠查看和竊取用戶的機密登陸憑據。 能夠經過在開發應用程序時指定正確的文件權限,以及一塊兒計算密碼與鹽的散列來避免此漏洞
顧名思義,應用程序中的路徑遍歷漏洞容許攻擊者使用漏洞應用程序的供應器讀取其餘系統文件。
此漏洞也可使用咱們以前討論的工具 Drozer 進行檢查。 在這裏,咱們用例子來講明由 Seafastian Guerrero 發現的 Adobe Reader Android 應用程序漏洞(http://blog.seguesec.com/2012/09/path-traversal-vulnerability-on-adobe-reader-android-application)。 此漏洞存在於 Adobe Reader 10.3.1 中,並在之後的版本中進行了修補。 你能夠從http://androiddrawer.com下載各類 Android 應用程序的舊版本
咱們將啓動 Drozer,並運行app.provider.finduri模塊來查找內容供應器 URI。
dz> run app.provider.finduri com.adobe.reader
Scanning com.adobe.reader...
content://com.adobe.reader.fileprovider/
content://com.adobe.reader.fileprov
一旦咱們找到了 URI,咱們如今可使用app.provider.read搜索並利用本地文件包含漏洞。 在這裏,我嘗試從系統中讀取一些文件,如/etc/hosts和/proc/cpuinfo,它們默認存在於全部的 Android 實例中,由於它是基於 Linux 的文件系統。
dz> run app.provider.read content://com.adobe.reader.fileprovider/../../../../etc/hosts
127.0.0.1 localhost
客戶端攻擊一般發生在應用程序未檢查用戶輸入的時候。 例如,在對 SQLite 數據庫的查詢期間,應用程序正在解析用戶輸入,由於它位於查詢語句中。
讓咱們舉一個應用程序的示例,它檢查本地 SQLite 數據庫,來根據登陸憑據驗證用戶。 所以,當用戶提供用戶名和密碼時,正在運行的查詢將以下所示:
SELECT * FROM 'users' where username='user-input-username' and password='user-input-password'
如今,在正常狀況下,這將正常工做,用戶輸入其真正的登陸憑據,而且查詢取決於條件將返回true或false。
SELECT * FROM 'users' where username='aditya' and password='mysecretpass
可是,若是攻擊者輸入 SQL 語句而不是正常的用戶名怎麼辦? 請參考如下代碼:
SELECT * FROM 'users' where username='1' or '1' = '1' - - and password='mysecretpassword
所以,在這種狀況下,即便用戶不知道用戶名和密碼,他們能夠經過使用1'or'1'='1查詢來輕鬆繞過它,這在全部狀況下都返回true。 所以,應用程序開發人員必須在應用程序中進行適當的檢查,來檢查用戶輸入。
咱們還可使用 Drozer 的app.provider.query來利用 SQL 注入漏洞。 其語法看起來像:
run app.provider.query [Content Provider URI] --projection "* FROM SQLITE_MASTER WHERE type='table';- -"
如今,這將返回 SQLite 數據庫中整個表的列表,它的信息存儲在SQLITE_MASTER中。 您還能夠繼續並執行更多的 SQL 查詢,來從應用程序提取更多的信息。 爲了使用 Drozer 實戰漏洞利用,你能夠從https://www.mwrinfosecurity.com/products/drozer/community-edition/下載他們的漏洞應用程序
Web 應用程序開放安全項目(OWASP)是涉及安全和漏洞搜索的標準之一。 它還發布了前 10 名漏洞的列表,其中包括在各類平臺中最多見和重要的漏洞。
能夠在https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks上找到 OWASP 移動版的前 10 個指南。 若是咱們查看 OWASP 移動項目,如下是它涵蓋的移動應用程序的 10 個安全問題:
讓咱們逐一介紹它們,並快速瞭解它們在移動應用程序中的關係,以及咱們如何檢測它們:
第一個 OWASP 漏洞是服務端弱控制,顧名思義,服務端不以安全的方式將數據從移動應用程序發送到服務端,或者在發送數據時暴露一些敏感的 API。 例如,考慮一個 Android 應用程序發送登陸憑據到服務器進行身份驗證,而不驗證輸入。 攻擊者能夠以這樣的方式修改憑證,以便訪問服務器的敏感或未受權區域。 此漏洞可視爲移動應用程序和 Web 應用程序中的一個漏洞。
這僅僅意味着,應用相關信息以用戶可訪問的方式在設備上存儲。 許多 Android 應用程序在共享首選項,SQLite(純文本格式)或外部存儲器中,存儲與用戶相關的私密信息或應用程序信息。 開發人員應該始終記住,即便應用程序在數據文件夾(/data/data/package-name)中存儲敏感信息,只要手機已 root,惡意應用程序/攻擊者就能夠訪問它。
許多 Android 開發人員依賴於經過不安全模式的網絡來發送數據,例如 HTTP 或沒有正確實現 SSL 的形式。 這使得應用程序易受到網絡上發生的全部不一樣類型的攻擊,例如流量攔截,從應用程序向服務器發送數據時操縱參數,以及修改響應來訪問應用程序的鎖定區域。
當應用程序將數據存儲在自己易受攻擊的位置時,會出現此漏洞。 這些可能包括剪貼板,URL 緩存,瀏覽器 Cookie,HTML5DataStorage,統計數據等。 一個例子是用戶登陸到他們的銀行應用程序,他們的密碼已經複製到剪貼板。 如今,即便是惡意應用程序也能夠訪問用戶剪貼板中的數據。
若是 Android 應用程序或通常的移動應用程序在沒有適當安全措施的狀況下,嘗試基於客戶端檢查來驗證或受權用戶,則這些應用程序最容易受到攻擊。 應該注意的是,一旦手機已 root,大多數客戶端保護能夠被攻擊者繞過。 所以,建議應用程序開發人員使用服務器端身份驗證和受權進行適當的檢查,一旦驗證成功,請使用隨機生成的令牌,以便在移動設備上驗證用戶。
這僅僅表示使用不安全的密碼函數來加密數據部分。 這可能包括一些已知存在漏洞的算法,如 MD5,SHA1,RC2,甚至是沒有適當的安全措施的定製算法。
這在Android應用程序中是可行的,主要成因是使用 SQLite 進行數據存儲。 咱們將在本書的各章中執行注入攻擊。
在移動應用程序中,開發人員應始終過濾和驗證用戶提供的輸入或其餘相關輸入,而且不該該像在應用程序中那樣使用它們。 不受信任的輸入一般會致使應用程序中的其餘安全風險,如客戶端注入。
在爲移動應用程序執行會話處理時,開發人員須要處理不少因素,例如認證 cookie 的正常過時,安全令牌建立,cookie 生成和輪換,以及沒法使後端的會話無效。 必須在 Web 應用程序和 Android 應用程序之間維護正確的安全同步。
這意味着不能正確地防止應用程序被逆向或反編譯。 諸如 Apktool 和 dex2jar 之類的工具可用於逆向 Android 應用程序,若是沒有遵循正確的開發實踐,它會暴露應用程序的各類安全風險。 爲了防止經過逆向攻擊來分析應用程序,開發人員可使用 ProGuard 和 DashO 等工具。
在本章中,咱們學習了使用各類方法來逆轉 Android 應用程序並分析源代碼。 咱們還學習瞭如何修改源代碼,而後從新編譯應用程序,來繞過某些保護。 此外,咱們還看到了如何使用 Drozer 等工具尋找 Android 應用程序中的漏洞。 你還能夠經過http://labs.securitycompass.com/exploit-me/親自嘗試 Exploit-Me 實驗室中的各類漏洞,它由 Security Compass 開發。