Android系統中通過RSSI廣播洩漏敏感資料的漏洞詳情披露(CVE-2018-9581)
前言
本文所分析的CVE-2018-9581漏洞，和 ofollow,noindex">前段時間 所分析的CVE-2018-9489和CVE-2018-15835屬於同一漏洞系列，這三個漏洞具有相同的發生機理。
CVE-2018-9581允許程序間通訊，導致資訊洩漏。雖然Android系統上的應用程式通常由作業系統彼此隔離，同時各應用與作業系統本身隔離，但在需要時在它們之間仍然存在共享資訊的機制，如intent，Android使用兩種不同的intent定期廣播有關WiFi連線的資訊。
而CVE-2018-9489能將有關使用者裝置的資訊暴露給裝置上執行的所有應用程式，包括WiFi網路名稱、BSSID、本機IP地址、DNS伺服器資訊和MAC地址。它使惡意應用程式得以繞過許可權檢查和現有的防護，訪問系統廣播資訊。根據該通報，安全漏洞CVE-2018-9489不太可能得到任何修復。這一漏洞能影響安卓9.0 Pie以前的所有安卓版本。有了這些資訊，攻擊者可能會帶來各種型別的攻擊，比如進一步嗅探和攻擊本地WiFi網路。此外，由於MAC地址是硬編碼的，所以即使使用MAC地址隨機化，它們也可用於唯一地識別和跟蹤任何Android目標。
至於CVE-2018-15835，來自Android作業系統的intent訊息會洩露了有關電池的詳細資訊，攻擊者可在沒有特殊許可權的情況下，利用這些intent訊息識別和跟蹤使用者。目前可以確定的是，Android 5.0會受到影響，但Google似乎不打算修復將其歸類為安全漏洞。
這3個漏洞都是由於在Android作業系統的系統廣播暴露了WiFi接收的訊號強度指示（RSSI），利用該漏洞，攻擊者可以在不需要額外許可權的情況下，利用惡意軟體獲取此資訊。它允許與WiFi路由器物理接近的攻擊者跟蹤路由器範圍內使用者的位置，從而根據附近的WiFi路由器來定位或跟蹤使用者（靠近WiFi路由器的手機將接收到更強的訊號）。同樣的問題也適用於底層Android API，但需要額外的許可權。
目前所有的Android版本都受到該漏洞的影響，且Google尚未計劃修復此漏洞。但在Android 9.0 Pie或更高版本中，CVE-2018-9489漏洞已經得到了修復，系統廣播已經不再顯示敏感資料。研究人員表示，他們不確定這種漏洞是否已在野外被開發利用。
CVE-2018-9581的漏洞利用原理
據估計，目前全球有超過20億臺裝置在執行Android。 Android上的應用程式通常被作業系統彼此隔離，當然，它們也與作業系統之間相互隔離。但是，仍然存在一些機制（比如Intent），可以實現程序之間的通訊，以及程序與作業系統的互動。Intent（Intent）主要是解決Android應用的各項元件之間的通訊。Intent負責對應用中一次操作的動作、動作涉及資料、附加資料進行描述，Android則根據此Intent的描述，負責找到對應的元件，將Intent傳遞給被呼叫的元件，並完成元件的呼叫。因此，Intent在這裡起著一個媒體中介的作用，專門提供元件互相呼叫的相關資訊，實現呼叫者與被呼叫者之間的解耦。
雖然存在限制閱讀此類訊息的許可權，但應用程式開發人員通常忽略正確實施這些許可權或遮蔽敏感資料。這導致Android應用程式中的常見漏洞，其中在同一裝置上執行的惡意應用程式可以監視並捕獲由其他應用程式廣播的訊息。
Android中存在的另一種安全機制是許可權的設定，它們都是保護使用者隱私的安全措施。應用程式必須通過應用程式列表（“AndroidManifest.xml”）中的特殊“uses-permission”標記明確請求訪問某些資訊或功能。Intent解析機制主要是通過查詢已註冊在AndroidManifest.xml中的所有IntentFilter及其中定義的Intent，最終找到匹配的Intent。在這個解析過程中，Android是通過Intent的action、type、category這三個屬性來進行判斷的。根據許可的型別（“正常”、“危險”等），Android系統可以在安裝期間向用戶顯示相應的許可資訊，或者可以在執行期間再次提示。不過某些許可權只能由系統應用程式使用，並且不能由常規開發人員使用。
Google+Play/">Google Play安裝期間和應用程式執行期間的許可權提示如下所示：
CVE-2018-9581的漏洞詳細資訊
Android系統會定期在系統範圍內廣播WiFi強度值（RSSI），無需特殊許可權就可以訪問此資訊。 RSSI值表示裝置接收的訊號的相對強度，但不與實際物理訊號強度（dBm）直接相關。這是通過兩個獨立的Intent（Android 9之前的“android.net.wifi.STATE_CHANGE” ;以及所有Android版本中的 “android.net.wifi.RSSI_CHANGED”）釋出的。
雖然應用程式也可以通過WifiManager訪問此資訊，但根據規範，還需要應用程式列表中的“ACCESS_WIFI_STATE”許可權。而在Android 9及以上的版本中，新增的WiFi RTT功能還需要“ACCESS_FINE_LOCATION”許可權，才能捕獲使用者的WiFi位置。但是，如果攻擊者在監聽系統廣播時，則不需要這樣的許可權，惡意應用程式在使用者不知情的情況下捕獲此資訊。
這樣，就會產生兩個單獨的安全漏洞：
1.只要繞過通常所需的許可權檢查（“ACCESS_WIFI_STATE”），RSSI值就可通過廣播資訊獲得；
2.通過廣播或WifiManager所獲取的RSSI值，可以用於室內定位，無需特殊位置許可；
漏洞復現
普通使用者可以按照如下步驟來複現此漏洞
1.從Google Play中下載“Internal Broadcasts Monitor”（內部廣播監控）應用程式（由Vilius Kraujutis開發的）；
2.開啟應用程式，然後點選“開始”監控廣播；
3.觀察捕獲的系統廣播資訊，注意Android 9以及之前版本的資訊是“android.net.wifi.STATE_CHANGE”，而“android.net.wifi.RSSI_CHANGED” 資訊存在於所有Android版本中。
觀察的系統廣播的截圖：
通過程式碼的方式實現漏洞復現
要通過程式碼的方式實現漏洞復現，就需要由專門的軟體研發人員來實現。首先是建立一個廣播接收器，並將其進行註冊，註冊完了後，才能接收“android.net.wifi.STATE_CHANGE”（僅限Android v8.1及以下版本）和“android.net.wifi.RSSI_CHANGED”。
示例程式碼如下所示：
public class MainActivity extends Activity { @Override public void onCreate(Bundle state) { IntentFilter filter = new IntentFilter(); filter.addAction(android.net.wifi.STATE_CHANGE); filter.addAction(android.net.wifi.RSSI_CHANGED); registerReceiver(receiver, filter); } BroadcastReceiver receiver = new BroadcastReceiver() { @Override public void onReceive(Context context, Intent intent) { Log.d(intent.toString()); …. } };
本文的漏洞測試方法
裝置配置
本文的研究人員在測試過程，使用了以下裝置：
1.Pixel 2，Android 8.1.0系統，補丁更新至2018年7月；
2.Nexus 6P，Android 8.1.0系統，補丁更新至2018年7月；
3.Moto G4，Android 7.0系統，補丁更新至2018年4月；
4.Kindle Fire HD第八代，Fire OS 5.6.10系統，補丁更新至2018年4月；
5.路由器使用華碩RT-N56U，執行最新版本韌體。
經過測試，Kindle Fire所使用的Android版本系統都存在以上漏洞。
測試步驟
測試步驟如下：
1.安裝Broadcast Monitor應用程式；
2.將手機置為飛航模式；
3.開始Broadcast Monitor應用程式；
4.關閉飛航模式（觸發RSSI廣播）；
5.從廣播中獲取的兩個RSSI值有：
android.net.wifi.RSSI_CHANGE – newRssi 值和android.net.wifi.STATE_CHANGE – networkInfo / RSSI
6.在每個測試裝置上，重複步驟3-4。
測試結果清除顯示每個裝置都具有獨特的RSSI值範圍，測試期間收集的RSSI值的列表如下。
