正文

Android系统中通过RSSI广播泄漏敏感数据的漏洞详情披露(CVE-2018-9581)

admin
admin V管理员 /0 评论 /16 阅读
0409
此篇文章发布距今已超过1121天，您需要注意文章的内容或图片是否可用！

前言

本文所分析的CVE-2018-9581漏洞，和前段时间所分析的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安装期间和应用程序运行期间的权限提示如下所示：

1.png

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版本中。

观察的系统广播的截图：

2.png

通过代码的方式实现漏洞复现

要通过代码的方式实现漏洞复现，就需要由专门的软件研发人员来实现。首先是创建一个广播接收器，并将其进行注册，注册完了后，才能接收“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值的列表如下。

4.jpg

Google的反应和缓解措施

Google已经将此漏洞划分在中等危险，并命名为CVE-2018-9581。目前Google尚未修复CVE-2018-9581，但在Android 9/P上，“android.net.wifi.STATE_CHANGE”将不再显示敏感数据，因为该问题已经在CVE-2018-9489中被修复，目前尚不清楚这个漏洞是否在野外利用的情况。