APP漏洞掃描器之本地拒絕服務檢測詳解

APP漏洞掃描器之本地拒絕服務檢測詳解

作者：伊樵@阿里聚安全

阿里聚安全的Android應用漏洞掃描器有一個檢測項是本地拒絕服務漏洞的檢測，採用的是靜態分析加動態模糊測試的方法來檢測，檢測結果準確全面。本文將講一下應用漏洞掃描器在針對本地拒絕服務的檢測方法。

一、本地拒絕服務產生原因和影響

Android應用使用Intent機制在元件之間傳遞資料，如果應用在使用getIntent()，getAction()，Intent.getXXXExtra()獲取到空資料、異常或者畸形資料時沒有進行異常捕獲，應用就會發生Crash，應用不可使用（本地拒絕服務）。惡意應用可通過向受害者應用傳送此類空資料、異常或者畸形資料從而使應用產生本地拒絕服務。

阿里聚安全的部落格以前有一篇文章《Android應用本地拒絕服務漏洞淺析》，裡面詳細講了產生本地拒絕服務的四種情況：

    1、NullPointerException空資料異常：應用程式沒有對getAction()等獲取到的資料進行空指標判斷，從而導致空指標異常而導致應用崩潰。

    2、ClassCastException型別轉換異常：程式沒有對getSerializableExtra()等獲取到的資料進行型別判斷而進行強制型別轉換，從而導致型別轉換異常而導致應用崩潰。

    3、IndexOutOfBoundsException陣列越界異常：程式沒有對getIntegerArrayListExtra()等獲取到的資料陣列元素大小的判斷，從而導致陣列訪問越界而導致應用崩潰。

    4、ClassNotFoundException異常：程式沒有無法找到從getSerializableExtra ()獲取到的序列化類物件的類定義，因此發生類未定義的異常而導致應用崩潰。

當應用被惡意應用攻擊時，本地拒絕服務一般會導致正在執行的應用崩潰，首先影響使用者體驗，其次影響到後臺的Crash統計資料，另外比較嚴重的後果是應用如果是系統級的軟體，可能導致手機重啟。Nexus 5曾經出現過這樣的情況，它預裝了一個用來測試網路連通性的系統應用，這個應用是隱藏狀態，無法在桌面上開啟，包名為com.lge.SprintHiddenMenu。在Android 4.4.3之前的版本里，這個應用裡有大量匯出的activity，這些 activity不需要任何許可權就可以被外部呼叫。其中一個為com.lge.SprintHiddenMenu.sprintspec.SCRTN的元件是匯出的，並且沒有任何許可權限制，給它傳送一個空Intent，可導致Nexus 5手機重啟。

二、阿里聚安全掃描器的進化提升

一個簡單的本地拒絕服務類漏洞，要想進行大規模的自動化掃描，掃描器也要做不少的工作，並且隨著對本地拒絕服務漏洞的認識，阿里聚安全的漏洞掃描器也在不斷進行優化提高。

2.1 空Intent階段

這個階段的掃描器是初級階段，一般只是通過AndroidManifest.xml檔案獲取應用匯出的元件，然後使用adb命令傳送空intent給匯出元件，捕獲應用日誌輸出，檢視是否有崩潰產生。

針對空Intent導致的本地拒絕服務情況可傳送如下命令測試：

adb shell am start -n com.jaq.dosappsample/.DosActivity 
adb shell am startservice -n com.jaq.dosappsample/.DosService 
adb shell am broadcast -n com.jaq.dosappsample/.DosReceiver

何為匯出的元件？

在AndroidManifest.xml檔案中如果應用的元件android:exported屬性顯式指定為“true”，或者並沒有顯式指定為“true”也沒有顯式指定為“false”，什麼也沒有寫，但是有intent-filter並指定了相應的Action，則此元件為匯出的元件。

2.2 解析Key值階段

空Intent導致的拒絕服務畢竟只是一部分，還有型別轉換異常、陣列越界異常等導致的本地拒絕服務。在解析Key值階段掃描器需要分析元件程式碼中是否使用了一些關鍵函式。

在Activity元件中的onCreate()方法中，Service元件中的onBind()和onStartCommand()方法中，BroadcastReceiver元件的onReceive()方法中，如果元件沒有做好許可權控制，都可接受任意外部應用傳過來的Intent，通過查詢getIntent()、getAction()和getXXExtra()這些關鍵函式，檢測其是否有try catch異常保護，如果沒有則會有本地拒絕服務風險。

在這一階段掃描器遇到的挑戰是找到這些關鍵函式中的Key值，Action值，不僅要找到，還要找到key對應的型別，來組裝adb命令，傳送命令給安裝好的應用進行測試。

2.3 通用型拒絕服務階段

2015年年初的時候，業界又爆出了通用型拒絕服務，由於應用中使用了getSerializableExtra() 的API，應用開發者沒有對傳入的資料做異常判斷，惡意應用可以通過傳入序列化資料，導致應用本地拒絕服務。此種方法傳入的key值不管是否與漏洞應用相同，都會丟擲類未定義的異常，相比解析Key值階段通用性大大得到了提高。

針對這個常用的手工檢測POC程式碼如下：

此階段掃描器遇到的難題是無法直接通過adb命令進行測試，因為無法用adb命令傳遞序列化物件給應用。業界大部分漏洞掃描器也因為無法傳送序列化物件給應用都止步解析Key值組裝adb命令階段，而阿里聚安全的漏洞掃描器能夠傳送序列化物件資料給指定的應用，再結合靜態分析查詢匯出的元件和關鍵函式，動態執行應用，精確識別出會發生本地拒絕服務的應用元件，同時實現了大規模自動化測試。

2.4 動態註冊BroadcastReceiver階段

BroadcastReceiver元件一般分為兩種，一種是靜態註冊，提前在AndroidManifest.xml宣告元件；另外一種是動態註冊，在程式碼中使用registerReceiver()方法註冊BroadcastReceiver，只有當registerReceiver()的程式碼執行到了才進行註冊。

動態註冊BroadcastReceiver的常見使用方法如下：

很多開發者沒有意識到，如上使用registerReceiver()方法註冊的是全域性BroadcastReceiver，和靜態註冊BroadcastReceiver android:exported屬性為true性質一樣，如果沒有指定許可權訪問控制（permission引數），可以被任意外部應用訪問，向其傳遞Intent，根據具體情況產生的危害可能不同，一種比較普遍的情況是容易產生本地拒絕服務漏洞。

動態註冊BroadcastReceiver導致匯出的Receiver這種情況非常少被大家注意，現有的一些安全檢測工具、掃描器都不能發現動態註冊的BroadcastReceiver。在此階段，動態註冊BroadcastReceiver隱藏在所有程式碼中，在應用的任何地方都可能出現，需要掃描器全域性分析應用的程式碼找出關鍵函式registerReceiver，還要找出其IntentFilter所設定的Action和Receiver的許可權設定，現在一般一個普通的正常Android應用都有幾十M的大小，反編譯成smali程式碼會更多，掃描器遇到的挑戰主要是查詢的時間和空間挑戰，還有多個引數查詢的準確性。目前業界只有阿里聚安全的掃描器有準確掃描動態註冊BroadcastReceiver導致的本地拒絕服務的能力。

通過阿里聚安全的漏洞掃描器對一些樣本進行了檢測，也發現了不少動態註冊BroadcastReceiver導致的本地拒絕服務攻擊。

三、本地拒絕服務漏洞現狀

為了瞭解本地拒絕服務漏洞的現狀，阿里聚安全的應用漏洞掃描器針對國內外的各行業主要APP進行了掃描，共掃描了三百多款APP。

國內行業主要是通過採集國內某應用市場的APP，我們採集了各個行業的TOP APP總共有151個，發現拒絕服務漏洞的總個數為970個，平均個數為6.4個，其中影音播放類的APP本地拒絕服務個數最多，健康類安全類和運營商類比較少、遊戲類的最少。

國內行業APP本地拒絕服務漏洞情況：

柱狀圖是國內各個行業APP按本地拒絕服務漏洞平均個數排序：

下圖是各個元件引起的本地拒絕服務的數量、佔比情況：

國內行業動態註冊BroadcastReceiver導致的本地拒絕服務漏洞有247個，約佔拒絕服務漏洞總數的25%，比靜態註冊BroadcastReceiver的要多不少：

國外行業主要是通過採集Google Play上的APP，我們也採集了各個行業的TOP APP總共有177個，發現拒絕服務漏洞的總個數是649個，平均漏洞個數為3.7個，平均漏洞個數最多的是辦公類應用，最少的和國內行業一樣是遊戲。

國外行業APP本地拒絕服務漏洞情況：

國外各個行業的應用本地拒絕服務漏洞平均個數排序：

各個元件引起的本地拒絕服務的數量、佔比情況：

國外行業動態註冊BroadcastReceiver導致的本地拒絕服務漏洞有147個，約佔拒絕服務漏洞總數的23%，比國內的情況略少，可見動態註冊BroadcastReceiver導致的本地拒絕服務都沒有引起大家的重視。

總體上來看，本地拒絕服務風險因為具有Android版本無關性，漏洞本身對APP影響也不大，只與應用開發者是否注意、重視有關，所以現在還經常在應用中出現。在各大廠商的安全應急響應中心評級為低危漏洞，也有廠商不收此類漏洞，但是這些攻擊面依然存在，如果深入分析這些元件，有的不僅僅是引發本地拒絕服務風險，必須遵循最小許可權原則，沒有必要匯出的元件不要匯出。

四、阿里聚安全對開發者建議

（1）阿里聚安全的漏洞掃描器已經具備覆蓋動態註冊Receiver產生的拒絕服務漏洞（目前，還沒發現友商的漏洞掃描器有這樣的能力），使用阿里聚安全的漏洞掃描器進行掃描，可及時發現這些漏洞。 

（2）不必要匯出的元件將其exported屬性顯式的設為“false”，這樣可以減少應用的攻擊面。 

（3）匯出的元件在getIntent()後，Intent.getXXXExtra()時用try…catch做好異常處理。 

（4）在匯出的元件設定好許可權控制，不讓任意第三方應用訪問。 

（5）對於動態註冊的BroadcastReceiver，儘量少用registerReceiver()方法，如果只在本應用內通訊，改用LocalBroadcastManager的registerReceiver()進行本地註冊，如果必須匯出給外部應用，在使用registerReceiver()時要指定好相應的訪問許可權。

五、參考

1、Android APP通用型拒絕服務漏洞分析報告，http://blogs.360.cn/blog/android-app%E9%80%9A%E7%94%A8%E5%9E%8B%E6%8B%92%E7%BB%9D%E6%9C%8D%E5%8A%A1%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90%E6%8A%A5%E5%91%8A/ 

2、 Android應用本地拒絕服務漏洞淺析，https://jaq.alibaba.com/blog.htm?id=55 

3、https://developer.android.com/guide/components/activities.html 

4、https://developer.android.com/guide/components/services.html 

5、https://developer.android.com/reference/android/content/Context.html 

6、https://labs.mwrinfosecurity.com/advisories/2014/11/05/nexus-5-4-4-2-local-dos/