原文链接: https://www.checkmarx.com/blog/nfc-false-tag-vulnerability[https://www.checkmarx.com/blog/nfc-false-tag-vulnerability]

翻译: 看雪翻译小组 - Nxe

校对: 看雪翻译小组 - 一壶葱茜

Android 是一个权限分离 (privilege-separated) 的操作系统, 每一个应用程序运行时都会有一个不同的系统身份标识 (Linux 的 user ID 和 group ID). 系统的各个部分也被分成了不同的身份. 从而 Linux 可以将应用与应用以及应用与系统之间相互隔离. 此外, "permission" 机制提供了细粒度 (finer-grained) 安全特性, 强制限制了部分进程能够执行的特定操作, 同时 per-URI permissions 授予对特定数据块的 ad-hoc 方式访问的权限.

Android 安全架构的一个中心设计宗旨是, 默认情况下任何应用都没有权限执行对其他应用, 操作系统和用户产生不利影响的操作。其中包括读写用户的私有数据 (例如联系人或者邮件), 读写其他应用的文件, 连接网络、保持设备唤醒状态等等.

由于 Android 会将应用程序彼此沙箱化, 因此应用程序必须显式共享资源和数据. 它们需通过声明权限来获取基本沙盒无法提供的额外的能力. 应用静态地声明他们所需的权限, Android 系统会在安装应用程序时提示使用者同意。

应用沙盒并不依赖构建应用程序的技术. 安全系统并不仅限于 Dalvik VM, 任何应用都能运行 native 代码 (见 the Android NDK). 所有类型的应用 - Java 的，native 的以及混合的 - 都是以同样的方式在沙盒中运行的, 并且彼此之间有同样的安全级别.

该报告详细介绍了一个向谷歌提交的有关 Tags 应用的漏洞, 该应用是 Android OS 自带的, 负责读取 NFC (Near Field Communication) 标签, 解析标签, 并根据其内容转发结果到相关的程序.

该漏洞的编号为 CVE-2019-9295, 该漏洞允许恶意程序欺骗 Tags 应用, 使其认为一个新的 NFC 标签是刚刚读取过的. 然后它会向用户显示它们可以使用标签执行的操作列表, 所以用户必须始终与该应用交互, 从攻击者的角度来看, 这不是一个理想的方式. 不过在一些情况下, 用户交互不是问题, 实际上它能达到如期的攻击效果, 在稍后的攻击场景部分会进行解释.

尽管这不是一个严重的漏洞, 但仍然是 Android OS 用户 - 特别是未使用 Android 10 版本的 - 应当注意的问题, 因为会无法预测不同标签的不同行为, 这可能会导致一些严重的错误.

Google 表示, "作为一个严重性的问题, 该漏洞只在 Android 10 中得到了解决; 补丁没有移植到之前版本的 Android 上."

这种类型的研究是 Checkmarx 安全研究团队 正在进行的工作中的一部分, 旨在推动开发基于消费者的产品的组织在软件安全实践方面进行必要的改进, 同时提高使用它们的消费者的安全意识. 在联通越来越顺畅的当代, 保护消费者的隐私必须成为我们所有人的优先考虑事项.

在本节中, 针对发现的不同漏洞给出了实际用例. 有时不能只看 CVSS 评分, 在某些情况下, 漏洞使用的方式以及能否构成漏洞利用链影响了其在现实世界中的实际价值和用途.

利用该漏洞, 恶意应用可以模拟对 NFC 标签的接收, 就像受害者的手机刚刚读取了标签一样. 它可以模拟任何类型的标签 (更确切的说是 NDEF 记录), 例如电话号码的 URI - tel:123456789.

从攻击者的角度来看的缺点是, 用户必须进行交互并点击显示的标签才会执行对应的动作. 对于先前的URI, 用户必须在屏幕上点击才能发出呼叫.

突然显示 "扫描到新的标签" 的弹出窗口非常奇怪, 可能会引起绝大多数用户的注意. 如上图所示, 我们看到一个带有 URL 的欺骗标签. Android Tag 应用会询问用户是否要使用 Chrome (或是设备上任何其他已注册的浏览器) 打开该链接.

为了显得不像是 "钓鱼攻击", 可以设计一个应用只欺骗 读取过 的标签. 该应用注册后会通过意图过滤器 (intent filter) 监听特定的操作, 比如 android.nfc.action.NDEF_DISCOVERED. 当用户 实际 尝试读取 NFC 标签时, 恶意程序会读取该标签, 修改其内容, 然后调用默认的 Android 标签查看器 (Android Tag viewer). 在这种情况下, 用户实际上在读取卡片后 预料 到会发生操作, 所以他们没有理由会怀疑遭到欺骗.

默认行为:

安装了恶意应用后::

在上面的例子中, 使用了带有电话号码的 NFC 标签. NFC 标签上的实际电话号码是 "555-111-12222". 如果未安装恶意应用, 则会显示实际数字. 但是如果安装了恶意应用程序, 它将抓取 NFC 标签内容, 对其进行更改, 并在调用 Android 标签查看器时变成欺骗的虚假标签. 用户只能看到新的数字 "666-666-666", 就不会怀疑它是假的.

要注意的是, 恶意应用程序 不需要任何特殊权限, 因为它只是注册 NFC 意图, 并不使用实际的 NFC 硬件.

这种欺骗方法并非没有警告. 有一种原因会导致显示电话号码标签, 而不是一个 URL 标签. 例如在三星 S8 上, 如果我们注册了一个应用程序以接收包含 URL 的标签, 并且用户扫描了包含 URL 的 NFC 卡, 则会出现以下画面:

那是因为 Chrome 也已注册为可以处理 NFC URL 类型标签的程序. 因此, 用户将不得不选择恶意应用来完成操作, 以便实现其访问和更改其内容的攻击. 这种可能的情况同样需要用户交互.

在某些情况下, 恶意应用可以在系统默认应用处理该标签之前拦截并更改标签的内容. 举个例子: 用户扫描的标签是名片, 其中包含电话号码. 恶意应用程序可以立刻将电话号码更改为另一个电话号码, 而用户无法知道该电话号码已被更改。

在其他情况下, 恶意应用无法直接拦截标签. 用户会主动选择处理标签的应用程序. 在前面的示例中, 系统为用户提供了一个菜单, 供用户选择该标签的处理程序, 该处理程序为 Chrome 和恶意应用. 如果用户选择了恶意应用程序, 则可以修改 URL 以将用户定向到恶意站点. 这种情况不太可能发生, 但恶意应用程序可能类似于 Chrome, 诱骗用户选择它作为处理程序.

发生这种情况是因为标签分派系统在 Android 中工作的方式. 标签分派系统使用 "类型 名称 格式" 记录和类型字段来尝试将 MIME 类型或 URI 映射到 NDEF 消息. 当标签分派系统完成创建一个封装 NFC 标签及其标识信息的意图时, 它将意图发送给过滤该意图的应用程序. 如果一个以上的应用程序可以处理该意图, 则会显示"活动选择器(Activity Chooser)", 以便用户可以选择"活动".

有3种意图:

如果有一个应用程序针对 ACTION_NDEF_DISCOVERED 进行过滤, 则系统会尝试在其他任何意图之前启动它. 否则它将搜索过滤ACTION_TECH_DISCOVERED 的应用, 最后是过滤 ACTION_TAG_DISCOVERED 的应用.

我们的恶意应用始终会过滤 ACTION_NDEF_DISCOVERED. 如果默认应用不会过滤这个高优先级意图, 我们的恶意应用可以暗地里有效地抓取标签来修改它, 并使用 tagviewer 来调用默认电话应用.

相比之下, Chrome也会过滤 ACTION_NDEF_DISCOVERED. 这意味着, 当扫描 URL 标签时, 系统会看到两个不同的应用程序可以处理该意图并显示弹出消息. 因此, 取决于应用程序, 其行为可能有所不同. 话虽这么说, 可能存在许多类型的 NFC 标签均未由任何特定应用处理, 或者处理程序应用未针对 ACTION_NDEF_DISCOVERED 进行过滤. 每当发生这种情况时, 标签欺骗都是完全透明的, 就像电话号码示例中一样.

对于不同的 NFC 标签类型, 不同的智能手机可能也有不同的处理程序, 要想创建一个详尽的列表列出各种 NFC 标签类型, 到哪个 App, 在哪个模型中, 可以说是一项艰巨的任务.

可以从 NFC Tools Android 应用入手搜索标签类型：

这些只是一些示例, 它支持更多类型的NFC标签.

在 Android 系统中处理新 NFC 标签的默认应用是 Tag Viewer, 位于com.android.apps.tags 包中.

Android 标签查看器处理读取的 NFC 标签 (并非所有类型). 负责处理标签的 class 文件位于 …/packages/apps/Tag/src/com/android/apps/tag/TagViewer.java 中.

通过对源文件进行分析, 可以得出结论, 可以'欺骗'该活动以展示用户想要的任何标签, 因为这个活动 (activity) 是导出的, 且不受任何权限的保护, 并且使用的动作 (action) 不受系统保护.

为了利用这种情况进行攻击, 恶意应用只需使用动作NfcAdapter.ACTION_TAG_DISCOVERED 或 NfcAdapter.ACTION_TECH_DISCOVERED 构建一个意图 (intent), 并提供适当的额外封装的 NfcAdapter.EXTRA_NDEF_MESSAGES.

可以使用以下方法完成此操作:

它将以 HTTP 标签启动 TagViewer. 若干种 URI 格式都是可行的, 例如 tel: 或 sms: , 但是需要用户确认才能调用关联的应用程序, 在实际攻击中受到了限制.

NdefRecord 实际上可以是许多不同的对象, 而不仅仅是URI. 实际上, 消息解析器检查以下类型:

总之, 有两种主要的攻击方案:

可能会随机出现一个弹出窗口, 警告用户已扫描了 NFC 标签 (由恶意应用生成). 用户必须与之交互才能选择一个应用程序来处理.

用户扫描真正的标签后, 恶意应用可以在默认系统应用程序处理该标签之前拦截并更改标签的内容. 示例: 用户扫描包含电话号码的公司的标签. 恶意应用可以立刻将电话号码更改为另一个电话号码, 并且用户无法知道电话号码已更改 (除非通过'未中毒'的手机扫描标签).

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课