安卓隐私泄露
Post-GDPR Threat Hunting on Android Phones: Dissecting OS-level Safeguards of User-unresettable Identifiers
1 动机
许多安卓应用程序从移动设备上收集个人身份信息，以跟踪用户来增强用户体验和个性化。
许多类型的信息是用户不可重置的，如设备ID和SIM卡信息，将这些称为用户不可重置标识符（UUI）。
对个人数据的保护已经得到了全世界的广泛关注。许多国家已经制定了立法，以规范个人数据的收集和使用。例如著名的欧盟通用数据保护条例（GDPR）。
安卓系统的数据泄露已经得到了广泛的研究。然而，关于操作系统是否全面地保护UUI的问题缺乏系统和严格的评估。
2 前置知识
2.1 安卓操作系统
Android是一个开源的，基于Linux的移动设备软件平台和操作系统，主要使用于移动设备，如智能手机和平板电脑。Android 操作系统的架构包括 4 层，由上到下依次是应用程序层、应用程序框架层、核心类库和 Linux 内核。AOSP指的是由谷歌维护的安卓开源项目，AOSP是所有安卓设备的代码基础。OEM指原始设备制造商，例如华为、小米、三星等手机厂商，它们基于AOSP为自己的设备定制操作系统。
2.2 安卓权限机制
安卓系统通过继承自Linux的安全机制，对其应用程序实施了强烈的隔离。应用程序的执行和数据存储是严格的沙箱的，采用了一种基于权限的机制来调节应用程序的资源访问。设备上的所有数据和服务都受到权限标签的保护，只有被授予正确权限的应用程序才能访问数据。
权限标签根据敏感性可以分为三个保护级别：
1、最低级别是正常级别，该级别的权限会在安装时自动授予应用程序。许多基本但不敏感的权限被归类为这个级别，如壁纸设置和振动。
2、较高的保护级别是危险级别。如果应用程序要访问任何受危险级别权限保护的API，必须在其清单文件中声明权限，并在运行时获得用户的同意。典型的危险权限包括访问照片和地理位置。非系统应用程序最多只能获得危险级别的权限。
3、最高的保护级别是签名级别。此级别的权限只能授予系统应用程序，如设置和相机应用程序。
2.3 用户不可重置标识符
用户不可重置标识符指可以直接或间接识别设备的信息，通过用户不可重置标识符区分不同的设备。一般指与设备具有永久绑定的标识符，例如，硬件设备ID，可以称为用户不可重置的标识符（UUI）。因为用户不能重置或撤销这些标识符的信息，因此被称为用户不可重置。
2.4 安卓系统对数据法规的回应
近年来，世界各地的许多政府都发布了相关的法律法规，以加强对用户隐私的保护。例如欧盟出台的《通用数据保护条例》，简称为GDPR。为了应对这些规定，移动设备制造商开始采取行动。安卓还实施了严格的隐私政策来规范应用程序在处理用户数据时的作用。
在安卓系统早期版本中，应用程序提供了两种方便的方式来获取可以识别设备的信息。首先，他们可以请求一个AndroidID，AndroidID根据设备硬件ID和用户ID生成。其次，他们可以请求主要处于危险保护级别的权限来读取设备或系统状态，包括序列号和MAC地址。
在谷歌推出了一系列隐私规则后，这两种方式都被禁用了。安卓系统8以后，Android ID成为应用程序唯一的。这可以防止跨应用用户跟踪。Android 10系统以来，谷歌已经升级了访问uui的权限。大多数UUI都需要一个新的特权权限READ_PRIVILEGED_PHONE_STATE，它只授予系统应用程序，因此非系统应用程序的访问被撤销。
3 本文贡献
主要贡献总结如下：
1、了解操作系统级的UUI保护。对安卓操作系统级的UUI保护进行了首次全面的研究。补充了现有的关于应用程序级数据采集行为的研究。
2、提出了一种系统的评估方法。提出了一套分析技术来自动发现和评估安卓手机上的UUI访问通道。方法以混合分析为特点，适用于更广泛的安卓设备和未来的安卓版本。
3、揭示了UUI保护的现状。在主要制造商的最新流行的安卓手机中展示了UUI保护措施的前景。并向制造商发出警告，鼓励决策者进一步扩大设备级数据保护的法规范围。
4 方法描述
4.1 识别UUI
由于缺乏一个全面的Android uui列表作为研究目标，作者试图识别一些UUI来指导评估方法的设计。首先作者从安卓的官方文档中识别UUI。当新版本（10和11）发布时，它们的隐私更新会在开发者文档中披露，引入这些更新是为了修复安全和隐私漏洞，或遵守数据保护法规。同时这些更新也说明这些数据引起了用户、安卓开发者和决策者的担忧，从而成为一个理想的数据来源。重点关注两种类型，第一种是任何隐私功能都被指定要保护的项目，例如安卓10中引入了MAC地址随机化，防止应用程序获得真正的MAC地址。第二种是涉及任何权限级别更新的项目，或新进入安卓权限控制的项目，例如IMEI的权限要求从READ_PHONE_STATE权限升级到READ_PRIVILEGED_PHONE_STATE，前者可以授予非系统应用程序，但后者仅限于系统应用程序。除了安卓系统的官方文档外，还参考了其他UUI类型的文献，但是由于UUI并没有被广泛地讨论，作者将范围扩展到了关于Android数据收集的文献。
最终通过以上两个来源识别到了6个UUI，如表所示
这6个公认的uui可以根据它们与之相关联的组件分为两类，第一类是芯片和蜂窝标识符，蜂窝就是我们常说的4G，5G网络。第一个是序列号，每部手机都有一个序列号，用于制造商在制造过程和售后保修服务中跟踪其产品。第二个是设备ID，每台配备了蜂窝网络模块的手机都拥有一个设备ID，对于注册使用全球移动通信系统（GSM）服务的设备，设备ID为国际移动设备标识符（IMEI），而对于码分多址（CDMA）设备，设备ID为移动设备标识符（MEID）。第三个第四个为SIM卡ID，包括集成电路卡ID（ICCID）和国际移动用户标识（IMSI）。这四种uui在最新的安卓版本中被认为是高度敏感的。在Android 10之前，如果应用程序被授予名为READ_PHONE_STATE的危险级别权限，就可以访问它们。自安卓10系统以来，只有系统应用程序可以获取。第二类是无线模块标识符，包括两个UUI，即蓝牙MAC地址和WiFi MAC地址，用于在通信过程中识别设备，Android 10以后，蓝牙和WIFI MAC地址都只能在随机化后返回。
4.2 目标
作者设计并实现了U2-I2，来系统地研究OS级别的UUI保护，有三个目标：
1、检测恶意的非系统应用程序是否可以在不需要必要权限地情况下访问UUI
2、识别获取UUI的实际权限和安卓文档策略的不一致性
3、检测OEM操作系统不符合AOSP的隐私策略的行为
4.3 威胁模型
威胁模型具体指攻击者的能力。首先，攻击者只作为受害者设备上的非系统应用程序，或作为由非系统应用程序导入的软件库来运行其UUI收集器。其次，攻击者的应用程序被授予互联网权限，仅用于传输收集到的数据。除此之外，它在使用非文档的通道时不需要获得任何权限。当使用文档中的接口时，它可以被授予在早期的Android版本中有效的权限。第三，攻击者能够在各种安卓设备和操作系统上离线进行侦察、分析。对此没有任何限制，这意味着攻击者可以通过root设备、逆向工程，获取包/类/方法的签名和文件系统结构。
4.4 挑战
1、识别未记录的访问通道
由于Android的复杂性，可能存在未记录在文档中的接口。OEM制造商也可以引入定制的接口。因此，需要探索其他可能的访问通道。
2、自动化评估过程
在安卓设备上访问特定UUI的方式可能会有很大的不同。由于目标是全面评估AOSP和OEM手机中的多个访问通道，其评估过程尽可能自动化，尽可能可扩展。
3、定位自定义UUI
设备制造商OEM可能会定义新型的uui，因此，采用了一种差分测试来精确定位由设备制造商定制的uui。
5 评估文档中的通道
首先评估文档中记录的通道，安卓开发文档详细介绍了访问设备上数据的可编程接口。因此，通过搜索文档中的API，以检索六个已知的UUI，确定了9个不同的相关API，如图所示。U2-I2构建了一个非系统应用程序来测试这些API，验证官方文档中指定的安全策略是否符合各种Android版本和各种设备，主要考虑两个问题：第一个，遗留权限。安卓10以来，对每个UUI施加的权限控制与早期版本的有所不同，一些设备可能无法保持其权限控制为最新状态。为了识别这种类型的不符合性，授予测试应用程序仅对早期版本有效的权限，或不授予所需的权限，然后检查它是否仍然可以获得UUI。第二个，缺少去识别化。Android文档还声称，一些API将随机的UUI返回到非系统应用程序，例如，蓝牙MAC地址。因此通过授予测试应用程序所需的权限，并将返回值与真实UUI进行比较，以验证是否对UUI进行了随机化。
6 发现和评估未经文档记录的访问通道
6.1 总体流程
U2-I2提出了一种四阶段的方法来探索和评估未经文档记录的访问通道，如图所示。首先探索访问通道，然后检索入口点并测试，最后确认UUI。
6.2 探索访问通道
访问通道探索将6个已知的UUI作为种子。考虑到其他未知的UUI可能共享同一组接入通道，它使用以下两种技术来探索未记录的访问通道：分别是静态控制流分析和文件系统。
6.2.1 静态控制流分析
当Android应用程序调用服务管理器中的API来访问系统源时，调用将到达Binder proxy中的本地接口。然后，代理通过Android的进程间通信（IPC）机制向一个stub发送请求，即Binder。stub最终会调用一个系统服务，它直接或间接地（例如，调用另一个组件）为请求提供服务。
首先，以一个API（例如，getImei()）作为入口点，使用开源的静态分析器soot，提取方法级的调用关系 (SA.I)。得到一个结束于服务管理器的本地接口的路径（例如，getImeiForSlot()），定义在一个Binder代理（Itelephony$Stub$Proxy）中
然后，我们将本地接口映射到远程接口，在Binder stub类(SA.II)。
第三，目标是定位远程接口调用的组件。首先遍历远程接口的继承，以定位重写该接口的方法(SA.III)，找到了PhoneInterfaceManager中的getImeiForSlot()。然后从该方法开始提取调用堆栈（SA.IV），发现大多数情况下调用路径都在系统服务中。例如在图2-A中，路径结束于GsmCdmaPhone中的getImei（），它属于系统服务，因此将系统服务视为在后面进行评估的访问通道之一。
然后，检查在系统服务之外的路径中的类，以探索其他访问通道。如图2-B中，序列号不是直接从系统服务中读取的，而是最终从系统属性中查询到的。因此，我们将系统属性视为第二种类型的访问通道。系统属性用于存储硬件和操作系统的配置和状态信息，是键值对存储的，其值存储在系统目录中。
6.2.2 文件系统
U2-I2在设备镜像中搜索6个uui的值。
从data/system/users/ 目录中的.xml中捕获到了UUI（例如，蓝牙MAC地址）。
这个目录中有三个xml文件，分别是Settings.Secure, Settings.Global 和 Settings.System,，都是系统设置文件。
这些设置作为键值数据库，存储由操作系统和系统应用程序定义的系统级设备首选项列表，因此将系统设置作为第三个访问通道。
6.3 检索入口点
获取完访问的通道之后，利用Android调试桥（ADB）来识别三个访问通道的入口点。
对于系统服务，它使用adb shell service list命令来检索电话上所有服务的完整服务列表和软件包名。
对于系统属性，它使用adb shell getprop来检索所有存储条目的键，例如，gsm.imei1。
对于系统设置，它使用adb shell content query来检索所有存储条目的键，例如，System.sim1_imsi。
6.4 测试
6.4.1 系统服务
U2-I2通过Java反射来绕过获取系统服务的权限检查。下图是通过系统服务获取到序列号的一个示例代码。
首先，U2-I2使用Java反射调用getService()方法来获得IBinder对象（图3中的第3行）。这里的服务名称，例如，示例中的“knoxcustom”，是在入口点检索期间获得的。
然后指定要构造包裹的服务名称和包名（第6行）。在获得IBinder对象后，U2-I2调用它的transact()方法（第7行），该方法与Binder的onTransact()接口相匹配。后者然后通过Android的绑定机制在服务器端调用服务对象。这里的第一个参数表示要调用的方法的标识符，它是一个从1到2^24-1之间的整数。U2-I2在测试期间枚举1到2^24-1，以便调用在每个绑定服务中定义的每个方法。一旦方法成功返回，U2-I2将捕获返回的数据（第8行）。
6.4.2 系统属性和系统设置
系统属性可以可以通过 System.getProperty() 查询其键来访问。U2-I2枚举在入口点检索期间获得的所有键，以获取其值。
对于系统设置，它们的值可以通过系统设置提供商（android.provider.Settings）来访问，U2-I2查询存储在所有三个表中的所有键。
6.5 确认UUI
在这个阶段，从测试的输出中识别UUI。它首先识别六种已知类型的值，通过将输出与通过文档化的方法获取的值相匹配。
在此之后，关键的任务是确定未知的或OEM定义的UUI。为此目的，采取了以下两个步骤。
过滤。首先排除了那些大小不足的值，即包含小于4个十六进制数字的字符串，因为它们不足以识别一个设备。
差分分析。对这些值进行差异分析。它排除了跨设备之间相同的值。保持那些在恢复出厂设置后保持不变的设备。
7 实验结果与评价
将U2-I2应用于市场上流行的13款流行的安卓智能手机。测试的手机来自9个不同的手机制造商，包括谷歌Pixel、华为、联想、一加、Oppo、三星、智能手机、Vivo和小米。对除谷歌Pixel(已安装AOSP）之外的手机，分配从A到H的代码。当提到一个设备时，我们使用下标数字来表示它上安装的安卓版本。例如，E代表制造商三星，E10代表安装了安卓10的三星设备。
7.1 操作系统级UUI保护的现状
U2-I2已经检测到51个独特的漏洞，导致65次UUI泄漏。它能够检测涉及6个已知UUI的泄漏点 ，如图所示。
涉及未知或OEM定义的UUI的泄漏点如下图所示。
如图显示了这些泄露点的分布，包括UUI的类型，设备类型，访问通道。总的来说，几乎所有设备（除了AOSP 11）都至少有一个泄漏，如图4-A所示。
在官方的AOSP中，UUI的错误处理行为与OEM操作系统相比较少。谷歌Pixel手机是所有设备中漏洞最少的，只有AOSP 10中的一个漏洞。在AOSP 10中，发现SIM卡ID的两个api中的一个，即getIccid()，不断返回实际的ICCID，违反了安卓系统的隐私政策。
OEM操作系统比AOSP有更多的UUI处理问题。安装了基于安卓10的操作系统继承了AOSP（即CVE-2021- 0428）的漏洞。例如华为(A)在其序列号和设备id的API中错误地暴露了uui。OEM操作系统通常将UUI值存储到系统设置和系统属性中，这种做法可能很方便在他们的系统应用程序之间共享数据，但违反了AOSP的隐私政策。
7.2 UUI泄漏漏洞的描述
UUI类型之间的漏洞分布。所有6个已知的uui都有在至少一个设备中泄漏，除此之外，还确定了14种新型的uui。称它们称为杂项的uui。试图通过这些UUI的名字来解释它们，并在网上搜索有关它们的详细信息，其中10个是嵌入式设备的标识，如相机、指纹传感器、NFC模块。两个是启动镜像的标识；其余两个的类型未知。
图4-B总结了接入通道之间的泄漏分布。错误暴露的系统属性占泄漏量的50%以上（37/65），另外10个泄漏量是通过系统设置发生的，对系统服务的调节不当，导致了另外5次泄漏，通过Java反射调用的函数是调用链中的中间函数，作者建议调用链中的所有中间函数都应该被纳入权限监管范围。
7.3 现有应用程序收集的UUI
从官方的谷歌Play商店和小米应用商店中收集应用，搜索前150个应用程序，总共搜集300个应用程序。进行逆向，将应用中的.class文件逆向为smali代码（smali类似于汇编语言），扫描出现的文档接口的API名称、读取系统设置和系统属性的方法，以及Java反射方法和系统服务管理器的名称。在300个被扫描的应用程序中，有12个应用程序使用了收集到的方法，说明很多应用程序在利用漏洞收集用户信息。
7.4 白名单
作者在华为（A10）手机上进行的实验中，发现一些应用程序在没有任何危险级别或签名级别的许可的情况下，设法获得了序列号和设备ID。通过调查镜像，发现维护了一个白名单用于权限检查（图5中的第7行）。在白名单中列出的应用程序可以绕过它的权限控制。在所有的手机上进行调查，发现华为、Oppo和Vivo的设备中找到了三个白名单问题。
7.5 从UUI泄漏中吸取的教训
所识别出的漏洞的原因可以归纳为以下三种类型：
1、AOSP和OEM操作系统中的缺陷。AOSP和OEM操作系统中的缺陷构成了已确定的51个漏洞的直接原因。它们中的绝大多数发生在OEM操作系统中，其根本原因是这些操作系统中的定制组件。AOSP中的缺陷比OEM操作系统中的其他缺陷具有更广泛的影响范围，因为它们很可能被所有OEM设备所继承。
2、OEM的意识不足。识别出的漏洞不仅仅是由于无意的编程错误，而且在大多数情况下也是由于隐私保护意识不足造成的结果。大多数OEM的定制都专注于功能，但忽视了对安卓安全和隐私准则的遵从性。
3、OEM操作系统中的开放通道。一些制造商将第三方应用列入白名单以方便他们的UUI访问，与安卓加强隐私保护的政策相悖。
总结
1、提出了第一个对安卓手机中的UUI保护的全面研究，以补充现有的应用程序级数据收集的研究。
2、设计并实现了U2-I2，它使用一套分析技术来发现和评估UUI访问通道。
3、评估了来自9家制造商的最受欢迎的13款手机，它们安装了官方的AOSP和OEM操作系统，并确定了51个独特的漏洞。
