如需转载请注明出处，侵权必究。
论文题目：Post-GDPR Threat Hunting on Android Phones: Dissecting OS-level Safeguards of User-unresettable Identifiers
发表会议：NDSS 2023
本篇文章作者孟华松来自于新加坡国立大学，主要研究系统安全，程序分析和可信人工智能。
背景介绍
IMEI等个人信息能够对设备进行唯一标识，且用户不能够进行重置，这类无法重置的身份标识称为UUI，应用程序一旦获取到此类标识信息将导致用户被持续追踪，单纯切换账号是无用的。根据AOSP隐私规范，UUI在安卓10之后普通应用程序将无法获取，仅仅允许系统应用程序才能够获取。但是作者发现设备制造商（下称“厂商”）的系统在实现的过程中可能因为部分功能的需要，暴露出一部分API供普通应用程序调用，此举严重违反了AOSP的隐私规范，侵犯了用户隐私，因此作者首次研究了系统层面各厂商对UUI的保护现状。
作者的UUI收集有两个来源，第一个是安卓的官方文档，第二个是相关的文献。官方文档来源中分为被设计为保护的隐私以及权限组新增或升级的隐私。文献方面的隐私信息通过人工检查后判断是否为UUI。最终作者收集的UUI如图1所示。
图1 识别的UUI列表
其中，序列号、设备ID、集成电路卡ID（ICCID）、国际移动用户身份（IMSI）属于芯片和手机识别码信息；蓝牙及WIFI设备MAC地址属于无线模块标识符。前人的工作主要集中于应用程序收集隐私或彼此违规分享隐私信息的行为，缺乏考虑系统本身存在的隐私泄露问题。
威胁模型
攻击者可作为受害者设备上一个非系统应用或由非系统应用导入的软件库运行在设备中。
攻击者除了需要互联网权限用来传输数据外，还能够被赋予在早期安卓版本中调用官方API需要的权限，而通过非官方方式获得UUI信息不会被赋予任何权限。
攻击者可以对各种安卓设备与操作系统上进行离线侦察、剖析和分析，如root设备、逆向固件、调试操作系统、构建操作系统及固件的动静态信息等。
U2-I2
作者设计了工具U2-I2用于识别安卓操作系统中存在的UUI泄露问题，该工具不仅可以识别出上述六类UUI，还可以识别出厂商自定义的UUI信息。
设计思路
为了了解UUI有哪些访问通道，作者首先对安卓系统利用Soot构建控制流图，再将上述六类UUI及其对应的API作为入口（如图2所示）进行正向分析，记录其路径上所有的调用，发现大多数调用链最终会到达系统服务中的函数，因此作者首先将系统服务作为一类UUI访问通道。作者随后排除了与系统服务相关的调用，并发现一些 API 可以获取 UUID 信息。通过分析其调用链的终点，作者发现这些 API 最终是通过系统属性查询来获取 UUID 信息的。因此，作者将系统属性列为第二类访问通道。最后作者将UUI的值直接在系统镜像中进行搜索，发现部分UUI会出现在特定的XML文件中，而恰好这些文件被用作系统设置进行存储，因此作者将系统设置作为第三类UUI访问通道。
图2 UUI对应的API列表
评估系统获取UUI的能力
对这三类访问通道，作者分别使用"adb shell service list"、"adb shell getprop"、"adb shell content query –uri content://settings/xxx"获得敏感信息真实键值。随后作者通过设计设备上的应用对各系统获取UUI的能力进行评估：
1. 对系统服务，通过反射获得各服务的IBinder对象，再对transact()函数code值进行遍历（0~224-1），以此遍历该服务所有接口，作者参数构造时只考虑没有参数或者0、1这类简单参数。
2.对系统属性，在测试应用中使用"System.getProperty()"与获取到的键名获得。
3.对系统设置，在测试应用通过 "android.provider.Settings"对象来获取系统设置信息。"android.provider.Settings"类提供了访问和修改设备系统设置的方法。
图3 U2-I2工作流
识别厂商自定义的UUI
作者设计了新的策略识别厂商自定义的UUI（如图4所示），主要有以下规则：
若值长度小于四个十六进制字符串，则因其无法唯一标识设备而忽略。
设备在经过重启与重置后仍然未变的值会被认为是新的UUI，同时排除了相同型号但不同设备中相同的数值。
图4 厂商自定义UUI列表
Findings
作者使用了9个厂商的13台设备进行测试，实验结果如图5所示：
图5 实验结果
RQ1 工具在识别UUI泄露的表现如何？根据已有发现，最新安卓手机中UUI的保护现状如何？OEM厂商的系统是否符合AOSP的隐私政策？
作者利用设计的工具总共发现了51个漏洞，漏洞除涉及上述六类UUI外还发现了一些OEM厂商引入的UUI。其中仅一个是AOSP漏洞，且因兼容性原因无法修复，其余的UUI泄露漏洞皆来自于OEM厂商系统，因此作者认为UUI泄露的现象在安卓手机中是普遍的。AOSP对UUI的保护较为完善，但其他厂商存在利用非文档渠道进行泄露的情况，不符合AOSP的隐私政策。
此外，作者还发现厂商对部分UUI访问设置了白名单，但是存在被绕过的风险，导致安卓的权限控制失效。
RQ2 根据实验结果，哪些UUI被泄露给了非系统应用程序，典型的泄漏点是什么？
ICCID、序列号、设备ID是泄露数量前三的UUI，其中ICCID是由于AOSP因兼容性无法修复的漏洞导致，其他厂商系统也继承了该漏洞。在65个UUI泄露案例中，系统属性访问通道占比超过了56.9%（37/65），系统设置访问通道占比15.4(10/65)，系统服务占比27.7%(18/65)，前两种访问通道是厂商自定义UUI普遍使用的。
RQ3 文中确认的三类UUI访问通道是否被在野应用滥用了？
作者从GooglePlay与小米应用商店各抓取150个应用程序进行分析，发现文中确认的系统服务、系统属性、系统设置三类UUI访问通道都有被使用的情况，但是使用这些通道的只有12个应用程序，因此不能认为上述三个访问通道存在滥用的情况了。
总结
作者通过识别确定UUI的访问通道、设计自动化UUI评估流程，发现了不同厂商安卓系统中存在已知及特有UUI泄露的问题，并在野验证了该漏洞存在但并不广泛。作者分析漏洞发现AOSP存在的漏洞极有可能被厂商系统继承下去，厂商在设计额外功能的时候也并没有考虑到遵守AOSP原本的隐私准则，对隐私安全存在认知上的不足，同时厂商设计UUI访问控制时采用白名单等方式，没有进行足够的安全测试。开发者、厂商与执法机构应当进一步共同努力，保障用户的隐私安全。
供稿：王清宇
审稿：廉轲轲、邬梦莹、洪赓
排版：边顾
戳“阅读原文”即可查看论文原文哦~
复旦白泽战队
一个有情怀的安全团队
还没有关注复旦白泽战队？
公众号、知乎、微博搜索：复旦白泽战队也能找到我们哦~
如有侵权请联系:admin#unsafe.sh