CVE-2019-9295：Android NFC False Tag 漏洞的分析

0x01  Android安全性介绍

Android是特权分离的操作系统，其中每个应用程序都以不同的系统身份（Linux用户ID和组ID）运行，系统的各个部分也分为不同的身份。Linux将应用程序彼此隔离，并与系统隔离，通过“权限”机制提供了其他更细粒度的安全功能，该机制对特定进程可以执行的特定操作实施限制，并为允许对特定数据片段进行临时访问的每个URI权限。

Android安全体系结构的中心设计要点是，默认情况下，没有应用程序有权执行任何会对其他应用程序，操作系统或用户产生不利影响的操作。这包括读取或写入用户的私人数据（例如联系人或电子邮件），读取或写入其他应用程序的文件，执行网络访问，使设备保持唤醒状态等。

由于Android会将应用程序彼此沙盒化，因此应用程序必须明确共享资源和数据。他们通过声明基本沙箱未提供的其他功能所需的权限来做到这一点。应用程序会静态声明其所需的权限，并且Android系统会在安装应用程序时提示用户同意。

应用程序沙箱不依赖于用于构建应用程序的技术。特别是Dalvik VM不是安全边界，任何应用程序都可以运行本机代码（请参阅Android NDK）。所有类型的应用程序（Java，本机和混合应用程序）都以相同的方式在沙盒中使用，并且彼此之间具有相同的安全级别。

0x02  漏洞分析

本文详细介绍了与Android一起向Google提交的有关“标记”应用程序的漏洞，该漏洞负责读取NFC（近场通信）标记，对其进行解析并将结果根据其内容转发到相关应用程序。

此漏洞分配了CVE-2019-9295，此漏洞允许恶意应用程序欺骗Tags应用程序，使其认为刚刚读取了新的NFC标签。然后，它向用户显示了可以使用标签执行的动作的列表，因此用户必须始终与应用程序进行交互，这从攻击者的角度来看并不理想。在某些情况下，用户交互并不是问题，实际上是可以预期的，就像在攻击场景中所说明的那样。

尽管这不是一个严重漏洞，但仍然是Android OS用户（尤其是尚未更新到Android 10的用户）应注意的问题，因为将来无法预测不同标签的不同行为，这可能会引入更严重的错误。

0x03  攻击场景

在本节中，针对发现的不同漏洞给出了一个实际的测试例子。有时，这不仅与CVSS分数有关，在某些情况下，漏洞的使用方式会增加其在真实世界中的价值和使用率。

虚假标签

利用此漏洞，恶意应用可以模拟NFC标签的接收，就像受害者的手机刚刚读取了标签一样。它可以模拟任何类型的标签（更确切地说是NDEF记录），例如带有电话号码的URI ，电话：123456789。

从攻击者的角度来看，缺点是用户必须进行交互并单击显示的标签才能采取相应的措施。对于先前的URI，用户将必须在屏幕上单击才能发出呼叫。

显示随机的“扫描新标签”弹出窗口非常奇怪，可能会引起大多数用户的注意。在右侧，我们看到带有URL的欺骗标记。Android Tag应用会询问用户是否要使用Chrome（或设备上任何其他已注册的浏览器）打开它。

欺骗标记

为了变得不像是“网络钓鱼”，开发一个应用程序可以读取标签。该应用程序注册后会通过过滤器监听特定的操作，例如android.nfc.action.NDEF_DISCOVERED。当用户实际尝试读取NFC标签时，恶意应用会读取该标签，更改其内容，然后调用默认的Android Tag查看器。在这种情况下，用户实际上希望在读取卡后采取措施，因此他们没有理由怀疑是恶意行为。

默认行为：安装了恶意应用程序：

在以上示例中，使用了带有电话号码的NFC标签。NFC标签上的真实电话号码是“ 555-111-12222”。如果未安装恶意应用，则会显示真实数字。但是，如果安装了恶意应用程序，它将抓取NFC标签内容，对其进行更改，并欺骗Android标签查看器的错误标签。用户仅能看到新的数字“ 666-666-666”，没有理由怀疑它不是NFC标签上的数字。

重要的是，恶意应用程序不需要任何特定的权限，因为它只是注册NFC而未使用实际的NFC硬件。

注意事项

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

这是因为Chrome浏览器也已注册以处理NFC URL类型标签。因此，用户必须选择恶意应用程序才能完成操作，以便其访问和更改其内容。这不是不可能的情况，但是同样需要用户交互。

在某些情况下，流氓应用可以在默认操作系统应用处理该标签之前拦截并更改标签的内容。示例：用户扫描的标签是名片，其中包含电话号码，流氓应用程序可以即时将电话号码更改为另一个电话号码，用户无法知道该电话号码已被更改。

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

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

有3个意图：

· ACTION_NDEF_DISCOVERED

· ACTION_TECH_DISCOVERED

· ACTION_TAG_DISCOVERED

如果有一个应用程序针对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标签。

0x04  研究成果

com.android.apps.tag

处理android操作系统中新的NFC标签的默认应用是com.android.apps.tags包中的Tag Viewer 。

android标记查看器处理NFC标记读取（不是全部，而是许多类型的标记，负责处理标签的类是：…/ packages / apps / Tag / src / com / android / apps / tag / TagViewer.java

通过对源代码的分析，可以得出结论，可以“欺骗”该活动以显示用户想要的任何标签，因为该活动是导出的，不受任何权限的保护，并且所使用的操作不受操作系统的保护。

TagViewer.java

为了利用这种情况，恶意应用程序仅需使用操作NfcAdapter.ACTION_TAG_DISCOVERED或NfcAdapter.ACTION_TECH_DISCOVERED构建一个Intent 并提供适当的额外可打包NfcAdapter.EXTRA_NDEF_MESSAGES。

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

它将以HTTP标签启动TagViewer，但是需要用户确认才能调用关联的应用程序，这限制了这种攻击。

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

NdefMessageParser.java

0x05  分析结论

总之，有两种主要的攻击方案：

1. 可能会随机出现的弹出窗口，警告用户已扫描了NFC标签（由流氓应用程序生成），用户必须与之交互才能选择一个应用程序来处理。

2. 用户扫描真实的流氓应用程序，可以在默认操作系统应用程序处理该标签之前拦截并更改标签的内容。示例：用户扫描包含电话号码的公司的标签。流氓应用程序可以即时将电话号码更改为另一个电话号码，并且用户无法知道电话号码已更改（除非通过扫描“未感染”电话中的标签）。

在方案1或2中，最终可能会诱骗用户单击链接，将其引导至恶意登陆页面，给错误的号码打电话/发短信，或者使用NFC标签采取任何其他措施。

尽管该缺陷本身允许对任何标签进行欺骗，但它需要用户交互才能真正启动应用程序。我认为，这一要求降低了漏洞的严重性。话虽如此，并且正如我所展示的，在某些攻击场景中，实际上用户交互是肯定发生的。