今天给大家带来的是发表于NDSS 2023的一篇关于移动安全的论文Post-GDPR Threat Hunting on Android Phones: Dissecting OS-level Safeguards of User-unresettable Identifiers，由澳大利亚昆士兰大学TrustLab投稿。
背景
Android自诞生以来就以其高度的开放性著称。当前的Android生态下有着成千上万的应用程序（Apps）满足用户对于智能手机的各种需求。然而，伴随着其高度开放性，人们对于Android生态下用户隐私保护的担忧也随之而来。随着智能手机越发融入到用户的生活，用户身份识别信息（Personally Identifiable Information）也随时面临着被泄露的风险。特别是一些用户不可重置的识别信息（User-unresettable Identifiers, 后文简称UUIs），一旦泄露，将长期与用户的身份绑定，并带来很多隐私被侵犯的风险。
欧盟GDPR颁布之后，全球社会对个人电子产品隐私保护的要求日趋增高，各国政府对于侵犯个人隐私的行为也祭出了高额罚款（例如GDPR规定高至2000万欧元或者企业全球营收4%的罚款）。为了应对全球日益收紧的隐私保护政策，Google不断完善Android的隐私保护机制。具体做法体现在系统层面针对UUI的读取权限日益收紧。特别是在10.0版本开始，第三方Apps被限制，甚至禁止读取一些常用的手机设备识别信息，例如手机序列号，IMEI，ICCID等。
在此背景下，我们不免产生疑惑：用户的隐私果真被系统牢牢地保护起来了吗？使用最新的Android系统就能为我们的个人隐私构建“铜墙铁壁”吗？带着这种疑惑，来自于昆士兰大学、字节跳动、新加坡国立大学等科研机构的团队设计了一款名叫U2I2的分析工具，并对市面上最新的多款Android设备进行分析，最终发现即便用户的手机安装了最新的Android版本（10.0或更高），一些UUI仍然可以被第三方App轻易获取。作者们在13款不同型号的Android设备上共发现了65处系统级别（OS-level）的UUI保护漏洞，截止到文章发表时已经有8个CVE被正式注册（如下图）。这说明，在如今这个被称为“后GDPR“的时代里，Android生态的个人隐私保护仍然存在着较大的问题。
目标UUI
通过阅读Android开发者文档和参考现有的文献，作者共锁定6个已知UUI（如下图所示）。这6个UUI全部都在近几年Android系统升级迭代过程中被提升访问权限。其中涉及到手机主板芯片和通信功能的UUI均被限制为只有系统应用才可以读取（READ_PRIVILEGED_PHONE_STATE）。另外两个UUI（WiFi和蓝牙的MAC地址）虽然仍对第三方应用开放读取，但是读取规则和访问权限同样产生了变化。
此外，作者表示这6个目标UUI绝非涵盖所有的UUI，相反，他们只是作为发现更多UUI的一个线索，被用于识别尽可能多的UUI访问渠道（access channels），其中既包括了官方读取渠道（即通过API读取，论文中称为documented渠道），也包含了非官方的、甚至未知的渠道（undocumented渠道）。
-
包含三个数据表的系统设置（system settings）；
-
系统服务（system services）；
-
沿袭自Linux系统的系统属性（system properties）。
分析工具
文章中作者将undocumented UUI的分析过程描述为四个阶段，如下图所示，分别为识别访问渠道，遍历这些访问渠道，测试，以及筛查并识别UUI。
在寻找到尽可能多的访问渠道后，作者设计出一款可以自动实现设备测试的工具并命名为U2I2。U2I2被封装称为一个Android应用，测试者可以将其安装在任何一台Android设备上然后触发测试过程。整个测试过程包括了对所有涉及到的API使用legacy permissions以及不完整的权限进行测试。接下来，对所识别出的三个undocumented渠道进行穷举式的访问，并从所获取的信息中找出UUI。首先从这些信息中通过比对找出6个目标UUI，接下来进行格式筛选和差异化分析，最终将筛选后的结果定义为miscellaneous UUI——这些信息将很可能是目前尚未识别的，同样可以用于识别用户的UUI。
发现
截止论文发表时，总共有65个系统级UUI保护漏洞被发现。其中47个漏洞涉及到我们预先锁定的6个目标UUI，还有18个漏洞是通过U2I2分析工具经过差异分析后确定的全新UUI（即Misc UUIs）。这65个漏洞中包含了51个独立漏洞（作者将多个厂商设备中发现的相同漏洞定义为一个独立漏洞）。其中，绝大多数漏洞是通过undocumented渠道获取的，超过一半的漏洞是通过读取系统属性（system properties）实现的。从漏洞产生者角度统计，只有一个独立漏洞是源于AOSP代码的，即Google在编写Android系统时造成的，剩余50个漏洞均为厂商定制ROM过程中产生。AOSP的漏洞也毫不意外地出现在所有的厂商ROM当中。
AOSP漏洞
在发现的漏洞中包括一个AOSP 10的漏洞CVE-2021-0428。该漏洞涉及到ICCID的读取，是由于Google在为API更新鉴权逻辑时产生的遗漏造成。根据开发者文档得知，开发者可以通过两个API读取设备ICCID，但是，Android只更新了其中一个API的鉴权逻辑，而遗忘了另一个。这使得第三方App仍旧可以通过被遗忘的那个API顺利读取ICCID。更加有意思的是，在Google注册了相应的CVE并修复该漏洞后，又很快地以系统兼容性为理由撤回了这个修复。这意味着此漏洞将永远无法在Android 10系统中得到修复，唯一的解决方案就是用户自行将设备更新到Android 11或者更新的版本。
白名单机制漏洞
作者在实验过程中还发现了一个更加严重的白名单问题。白名单机制本来不是为第三方App设计，设备厂商更应该谨慎使用该机制。但是，在针对各个厂商的设备进行大规模测试的过程中，作者发现有一些厂商在为自己设备发行的系统ROM中写入了为特定第三方应用设计的白名单机制。一旦一个第三方App处于白名单当中，既可以越过Android系统对其进行的鉴权机制，从而在用户不知情的情况下自动获得高级权限（由于越过鉴权，系统将在用户无法看到弹窗提醒的情况下自动放行），从而轻松获取UUI以及诸如GPS位置等一系列用户隐私信息。
基于此发现，作者对某个厂商的ROM实施了逆向工程，最终锁定了其白名单的代码实现，如下图所示，厂商对AOSP中负责鉴权的源代码进行了修改，私自加入了其白名单判断语句（黄色高亮代码）。更重要的是，在写入白名单机制越过系统原生鉴权逻辑之后，该ROM并没有对白名单内的App进行签名验证。这意味着对于任何一个App，只要它把包名（package name）设定为白名单内的任意一个应用名字（例如支付宝、微信等广泛预装在出厂ROM内的应用），就有机会利用白名单机制获取高级权限。
讨论与启示
-
原生Android（AOSP）并非完美无瑕，一旦出现漏洞将很有可能遍布于所有Android设备当中。当然，绝大多数UUI保护的漏洞是设备厂商在定制ROM过程中造成的。其中一些漏洞源于OEM ROM中新增加的功能，这凸显出设备厂商对于UUI保护的疏忽。
-
透过白名单问题发现少数厂商存在给特定App“开绿灯”的行为。白名单机制下放给第三方App侵犯了用户的知情权，造成用户在不知情的状态下个人隐私被第三方读取。此外，由于白名单机制没有搭配最基本的签名验证程序，使得恶意App有机可乘，化身任意一个白名单App即可随心所欲获取用户隐私。
-
设备厂商应该强化用户隐私保护意识，在自身的代码中严格遵守Android最新的开发规范。在发布OEM ROM之前应当进行充分的测试，确保其设备的合规。此外，应尽量避免一切非常规的系统资源调用，包括系统设置、系统属性等undocumented渠道。
-
最后，作者也呼吁包括执法机构、厂商和开发者在内的各方面加强合作，共同营造一个安全合规的Android生态。
论文下载：https://baigd.github.io/files/NDSS23-U2I2.pdf
投稿作者介绍：
孟华松 新加坡国立大学，新加坡科研局资讯通信研究院（I2R, A*STAR）
新加坡国立大学四年级博士生，新加坡科研局科研工程师，澳大利亚昆士兰大学访问学者，其研究方向为系统安全，程序分析和可信人工智能。该论文为作者在澳大利亚昆士兰大学TrustLab交流访问时完成。
UQ TrustLab招收软件工程与安全相关方向的博士生和博士后，感兴趣的朋友可以联系A/Prof Bai Guangdong （https://baigd.github.io/）。昆士兰大学（UQ）位列世界前50（ARWU排名47，台大排名33），坐落于澳大利亚东海岸的布里斯班，这里是昆士兰州的首府，毗邻旅游圣地阳光海岸和举世闻名的大堡礁。布里斯班风景如画，坐拥阳光沙滩，同时也是2032年奥运会的主办地。
原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2023-01-05 U2I2
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论