183      阿裏雲  技術社區[雲棲]

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

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

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導致的本地拒絕服務情況可發送如下命令測試：

何為導出的組件？

在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通用型拒絕服務漏洞分析報告，https://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/

最後更新：2017-04-10 21:02:15

  上一篇： Local privilege escalation for OS X 10.11.6 via PEGASUS

  下一篇： 國內 Android 手機典型勒索軟件詳情分析(附解鎖方法)