DIVA簡介：

DIVA（該死的不安全和易受攻擊的應用程式）是故意設計的存在很多漏洞的Android app。
原始碼連結：https://github.com/payatu/diva-android
apk檔案連結：http://payatu.com/wp-content/uploads/2016/01/diva-beta.tar.gz

闖關工具：

Java JDK 1.8

Android SDK Tools

夜神模擬器

Apktool

dex2jar、jd-gui

AXMLPrinter2.jar

環境部署：

1. 將adb通過USB與夜神模擬器進行通訊。
   要在通過USB連線的裝置上使用adb，必須在裝置的系統設定中啟用USB除錯。在搭載 Android 4.2 及更高版本的裝置上，“開發者選項”螢幕預設情況下處於隱藏狀態。開啟夜神模擬器，點選設定->關於平板電腦，可以看到Android 版本為7.1.2，點選版本號7次，即可啟用開發者模式，返回上一螢幕，開發者選項->USB除錯即開啟USB除錯功能。

   ​ 現在可以將adb連線模擬器。

   ​ 從Nox/bin/目錄進入命令列，輸入連線命令，並驗證裝置是否已連線。

   輸入
   adb connect 127.0.0.1:62001
   或
   adb connect 127.0.0.1:52001
   即可以連線到adb
   檢視連線情況輸入命令 
   adb devices
   

   返回以下內容說明成功。

   ​ 擴充套件：Android 11 及更高版本支援使用 adb從工作站以無線方式部署和除錯應用。例如，可以將可除錯應用部署到多臺遠端裝置，而無需通過 USB 實際連線裝置。這樣就可以避免常見的 USB 連線問題，例如驅動程式安裝方面的問題。
   詳情：https://developer.android.google.cn/studio/command-line/adb

2. 將靶場拖進模擬器，開啟靶場。

開始闖關：

第一關 不安全的日誌輸出

產生原因：由於app程式碼中將敏感資訊（如憑據，會話ID，財務詳細資訊等）通過log.e輸出，所以在app的表單中輸入的內容，可以在相關的日誌中輸出。

1. 提交資料後，輸入命令adb logcat檢視日誌

   也可以進入互動式shell，輸入ps | grep -i diva先找到diva的pid值(2732)，再通過logcat | grep [pid]獲取日誌資訊。

2. 可以通過反編譯在logActivity.class中看到程式碼中使用了log.e輸出。

第二關 硬編碼—第一部分

硬編碼

• 某些需要比較字串的值為硬編碼，如：啟用碼
• 加密的key或者salt為硬編碼，如MD5的salt

1. 直接檢視原始碼，發現vendor key的值

第三關 不安全的資料儲存—第一部分

產生原因：使用了SharedPreferences類，該類是Android平臺上一個輕量級的儲存類，主要是用來儲存一些常用的配置，本例中是用該類儲存了使用者名稱和密碼，因此是具有風險的。SharedPreferences類儲存的資料會以.xml的形式儲存在/data/data/app的包名/shared_prefs目錄下。

1. 首先隨意輸入使用者名稱和密碼 admin/admin 點選儲存

2. 進入shell模式，在/data/data/jakhar.aseem.diva/shared_prefs/目錄中檢視jakhar.aseem.diva_preferences.xml檔案，也可以輸入adb pull /data/data/jakhar.aseem.diva/shared_prefs ./將檔案複製出來檢視

3. 在InsecureDataStorage1Activity.class中可以看到產生風險的地方

第四關 不安全的資料儲存—第二部分

產生原因：將敏感資料儲存在本地的sqlite3資料庫中，對應的資料庫目錄: /data/data/app的包名/databases

1. 同樣先輸入admin/123456

2. 進入/data/data/jakhar.aseem.diva/databases/目錄中sqlite3檢視資料庫檔案ids2

3. 在InsecureDataStorage2Activity.class中可以看到產生風險的地方

第五關 不安全的資料儲存—第三部分

產生原因：將敏感資料儲存在臨時檔案中，對應的臨時檔案目錄: /data/data/app的包名/

1. 同樣輸入之後，進入/data/data/jakhar.aseem.diva/目錄中檢視該目錄下臨時檔案uinfo-1464421317tmp

2. 在InsecureDataStorage3Activity.class中可以看到產生風險的地方

第六關 不安全的資料儲存—第四部分

產生原因：將敏感資料儲存在sd卡中，對應的目錄一般在： /mnt/sdcard，也可以通過logcat檢視儲存路徑。

1. 進入/mnt/sdcard/目錄中檢視儲存sd卡的檔案.unifo.txt

2. 在InsecureDataStorage4Activity.class中可以看到產生風險的地方

第七關 輸入校驗問題—第一部分

產生原因：某些不安全控制元件內輸入sql或其他資料庫的一些語句，因為在使用前未進行檢驗長度和過濾等操作，從而達到欺騙伺服器執行惡意程式碼影響到資料庫的資料

1. 首先輸入test'和test''試探一下，test'什麼也不返回，而test''正常返回

2. 輸入萬能密碼test' or '1'='1嘗試，即得到了所有使用者的資料

3. 在SQLInjectionActivity.class中可以看到並沒有對輸入資料進行處理且語句直接拼接

第八關 輸入校驗問題—第二部分

產生原因：在處理轉跳時存在漏洞，導致允許從http域跨向file域，實現跨域漏洞，在 File 域下，同源策略跨域訪問則能夠對私有目錄檔案進行訪問

1. 輸入一段url點選可以看到訪問了這個頁面

2. 將http協議換成File協議，檢視之前儲存在sd卡的賬號檔案

3. 在InputValidation2URISchemeActivity.class中可以看到並沒有對輸入資料進行處理直接loadUrl

   擴充套件：webview域控制不嚴格漏洞
   先看Android裡的WebViewActivity.java，當其他應用啟動此 Activity 時， intent 中的 data 直接被當作 url 來載入（假定傳進來的 url 為 file:///data/local/tmp/attack.html ），其他 APP 通過使用顯式 ComponentName 或者其他類似方式就可以很輕鬆的啟動該 WebViewActivity 並載入惡意url。

   解決方案：

   對於不需要使用 file 協議的應用，禁用 file 協議:

   對於需要使用 file 協議的應用，禁止 file 協議載入 JavaScript。

   方法分析：

   1、setAllowFileAccess()
   使用 file 域載入的 js程式碼能夠使用進行同源策略跨域訪問，從而導致隱私資訊洩露，如果不允許使用 file 協議，則不會存在上述的威脅，但同時也限制了 WebView 的功能，使其不能載入本地的 html 檔案。

   2、setAllowFileAccessFromFileURLs()
   設定為false，禁止從 file url 中載入的 js 程式碼讀取其它本地檔案，在Android 4.1前預設允許，在Android 4.1後預設禁止。

   3、setAllowUniversalAccessFromFileURLs()
   設定為false，禁止從 file url 中載入的 js 程式碼可以訪問其他的源(包括http、https等源)。

第九關 訪問控制問題—第一部分

1. 點選按鈕獲取到API 憑據

2. 而我們的目標是不使用按鈕就獲取到API憑據。

   檢視diva-beta.apk/AndroidManifest.XML檔案，檢視和供應商API憑據提供相關的activity

   通過觀察程式碼發現，這個activity被intent filter所“保護”，當intent filter被activity等元件使用，這個activity可能會被外部任何應用程式所呼叫

3. adb啟動activity元件，輸入命令

   $adb shell am start jakhar.aseem.diva/.APICredsActivity
   或者
   $adb shell am start -n jakhar.aseem.diva/.APICredsActivity -a jakhar.aseem.diva.action.VIEW_CREDS
   am start: 啟動activity 管理工具
   -a：指定action
   -n：指定完整 component 名
   命令詳情：https://developer.android.google.cn/studio/command-line/adb#am
   

4. 之後模擬器上就彈出了之前的憑據頁面

第十關 訪問控制問題—第二部分

1. 從題目裡可得註冊後才能擁有tveeter API Credentials，所以要通過不註冊來獲取API Credentials

2. 嘗試上一關的方式

   結果跳到了未註冊時的activity，這表明程式做了相應的措施

3. 檢視原始碼APICreds2Activity.class

   可以看到，getIntent獲取到上個activity傳來的boolean值（2131492985），當這個值為false時才視為使用者已註冊，再看看上個activity，檢視AccessControl2Activity.class

   這個類中bool值是通過單選項來決定的，而且把值傳給下個activity，這時我們可以使用–ez來傳遞一個boolean鍵值對，但是還要獲取到2131099686值對應的key值是什麼。

4. 一般情況下使用apktool反編譯的字串檔案存放在apktoo/diva-beta/res/vaules/strings.xml檔案下，在反編譯的情況下所有的索引值都儲存在strings.xml同目錄下的public.xml檔案中，所以，我們現在public中檢視16進位制的2131099686（0x7f060026）對應的name值

   然後再strings檔案下查詢chk_pin，最後得到key 為check_pin

5. 最後adb啟動activity命令，成功彈出

   $adb shell am start -a jakhar.aseem.diva.action.VIEW_CREDS2 -n jakhar.aseem.diva/.APICreds2Activity --ez check_pin false
   

第十一關 訪問控制問題—第三部分

1. 由題可知，這是個私人筆記app，一開始需要設定密碼才能使用，現在我們嘗試不設定密碼就開始使用。

2. 同樣檢視AndroidManifest.XML檔案

   這裡使用了ContentProvider，android:enabled表示是否能由系統初始化，android:exported表示是否能被其他應用使用，android:authorities標識這個ContentProvider，呼叫者可以根據這個標識來找到它，看到2個值都為true，我們就可以使用content://訪問裡面的資料了，檢視包含content://的字串檔案apktool/diva-beta/smali/jakhar/aseem/diva/NotesProvider.smali

   和我們在AndroidManifest所看到的一樣

3. 我們可以使用以下命令隨意的訪問該uri

   $adb shell content query –-uri content://jakhar.aseem.diva.provider.notesprovider/notes
   

第十二關 硬編碼—第二部分

1. 檢視原始碼Hardcode2Activity.class，這裡使用了DivaJni類

   點選檢視 DivaJni.class

   這裡載入了divajni庫，一般庫檔案都放在/lib下，在目錄下找到libdivajni.so檔案，linux下可以使用strings方便的檢視二進位制檔案裡的字串

   $strings libdivajni.so
   

2. 逐個嘗試，發現olsdfgad;lh成功

第十三關 輸入校驗問題—第三部分

1. 正常輸入

2. 當輸入超級多的資料時，程式崩潰了

3. 檢視logcat可以發現緩衝區溢位了

4. 檢視原始碼，可以看到這裡使用的是strcpy，使用strcpy_s更加安全