在开始之前,先了解一下什么是NFC中继攻击。
NFC(近场通信,Near Field Communication),又称近距离无线通信,是一种短距离的高频无线通信技术,允许电子设备之间进行非接触式点对点数据传输。
NFC使用更加方便,成本更低,能耗更低,建立连接的速度也更快,只需0.1秒。但是NFC的使用距离比蓝牙要短得多,有的只有10CM,传输速率也比蓝牙低许多。
假设准备1个NFC卡, 1个服务器, 1个读卡终端,2个具备NFC功能的设备①、②。将这2个设备与服务端连接在同一wifi,保持通信。设备①作为读卡器靠近NFC卡,设备②作为仿真卡靠近读卡终端
为了成功实施攻击,安全研究人员对Tesla Model Y,在NFC卡和车辆之间使用的NFC协议进行了逆向分析,创建了自定义固件修改,允许Proxmark RDV4.0设备使用Proxmark的BlueShark模块通过蓝牙/Wi-Fi中继NFC通信。
Proxmark(如下图所示)是一款功能强大的通用 RFID 工具,大小相当于一副卡片,旨在窥探、监听和模拟从低频 (125kHz) 到高频 (13.56MHz) 信号的所有内容
为了更好地了解车辆和NFC卡之间发生了什么,我们必须对协议进行逆向工程。对于这次攻击,使用Proxmark RDV4.0设备来嗅探这些通信。
下图是结果,说明了使用NFC卡打开车辆时发生的NFC通信。蓝色勾勒的数据包是低级NFC通信,红色勾勒的数据包是应用层(APDU):
通信(蓝色)与此过程无关,因为它们是所使用的卡类型的标准协议内容。然而,应用层数据是我们需要关注的地方,因为这是我们找到特斯拉专有协议的地方。
在第1区块,读写器正在向特斯拉卡发送APDU,以选择应用进程类型。这是智能卡选择所谓的AID(应用进程标识符)的常用过程。在这种情况下,车辆正在请求用于智能手机中使用的虚拟车钥匙的标识符。由于我们使用的是物理特斯拉NFC卡进行嗅探,因此该卡将响应6d00(无效)。如果我们使用智能手机作为钥匙进行嗅探,它将响应90 00(有效)。
在第 2 区块中,车辆正在询问 Tesla NFC 卡所使用的虚拟车钥的识别码。由于我们正在使用实体 Tesla NFC卡进行嗅探,因此该卡将以 9000 回应。此时,卡将选择该应用程序并等待读卡器发出的请求。当车辆收到卡的 90 00 回应时,它认为它正在与 Tesla NFC 卡通话。车辆将加密请求发送到卡(第 3 区块),并等待对该请求的有效回应。
此时,特斯拉 NFC 卡(基本上是智能卡)将计算从车辆收到的请求的加密响应。由于这种加密计算需要大量时间(我们可能认为仅仅是几毫秒,但对于它来讲“时间太长”),因此卡实际上会向等待响应的车辆请求回应说:“嘿,不要放弃我,请给我一些时间,让我计算加密响应。
这个”需要更多时间“的消息构成了第4区块 中卡片和车辆之间来回切换的内容。此消息通常称为等待时间扩展 (WTX)。
最后,该卡将发送根据先前收到的请求计算得出的加密响应。如果此响应有效,汽车将打开车门并允许用户驾驶汽车。
在这里有几个问题值得我们思考:
a.车辆和卡之间的中继通信,还是会花费太多时间?
b.我们是否在协议中缺少其他可以防止中继攻击的东西?
c.攻击者必须离受害者的卡有多近?
带着这几个问题我们继续一探究竟:
此中继攻击需要两个攻击者;在这种情况下,其中一名攻击者将在车辆的 NFC 读卡器上使用 Proxmark 设备,而另一名攻击者可以使用靠近受害者的 Tesla NFC 卡或带有 Tesla 虚拟密钥的智能手机的任何支持 NFC 的设备(例如平板电脑、计算机或智能手机)。Proxmark 和第二个攻击者的智能手机可以使用 Proxmark RDV4.0 的 BlueShark 模块通过蓝牙进行通信,甚至可以通过 Wi-Fi,将 Proxmark 连接到带有蓝牙的 Raspberry Pi 等微型计算机或类似计算机,而 Raspberry Pi 则通过 Wi-Fi 连接到第二个攻击者的智能手机。
我们的 Proxmark 固件中的自定义代码必须使设备能够处理车辆和 Proxmark 之间的底层NFC 协议。
工作流程如下:
1. 从车辆收到 Select AID 后,Proxmark 将以正确的值进行响应。
2. 然后,Proxmark 接收请求并将其中继到第二个攻击者的手机,该手机靠近受害者的 Tesla NFC 卡。
3. 第二个攻击者的智能手机将通过 NFC 与受害者的卡进行通信,选择 AID,并发送从 Proxmark 收到的请求。
4. Tesla NFC 卡将响应加密并进行响应,将从第二个攻击者的智能手机中继到 Proxmark。
5. Proxmark 将接收到的加密响应发送给车辆的读卡器
我们可以开始为 Proxmark 编写代码。需要对 Proxmark 进行代码编写以充当模拟器,因为它将模拟 Tesla NFC 卡并尝试解锁车辆时处理上述所有任务。此外,Proxmark的蓝牙接口对于外部通信是有必要的。
Proxmark GitHub 存储库解释了如何为 Proxmark RDV4.0 编写独立模块单机模式 ·RfidResearchGroup/proxmark3 维基 (github.com)的硬件提供了一个 ARM 处理器,代码在其中运行,该代码需要通过 UART 接口促使与蓝牙芯片的交互。我们还需要通过Proxmark的FPGA进行通信,该FPGA处理NFC通信的所有射频调制/解调。
Proxmark 项目提供了某些用于与蓝牙芯片和 FPGA 通信的 API,我们将在编程阶段使用这些 API。像 hf_reblay 这样的第三方独立模块可以帮助更快地了解这种通信的工作原理。
该代码做的第一件事就是设置 Proxmark 来模拟 14443 卡,并执行初始化和 FPGA 设置。
接下来,代码接收从车辆读取器发送的内容,使用GetIso14443aCommandFromReader()。在读取来自无线电的数据后,它会立即检查用于蓝牙芯片的 UART 端口中是否有可用数据,并使用 usarT_rxdata_available()。如果有数据,则它会向读卡器发送最后一个 WTX 并读取来自蓝牙接口的数据。通过蓝牙接收的数据将始终是来自受害者卡的加密响应。
然后,代码处理通过 NFC 接收的数据,首先检查第一个字节并处理在通信的早期阶段接收的底层 NFC 消息的类型。
如果它只是接收应用进程层消息 (APDU),代码也会处理这些消息:
一旦我们收到来自车辆阅读器的请求,我们需要使用蓝牙接口将该数据发送到第二个攻击者的智能手机。我们将复制收到的缓冲区的内容,通过 UART 将其发送到蓝牙芯片,并在第二个攻击者的智能手机应用进程中处理该数据。
此外,一旦我们通过蓝牙收到加密响应,我们就需要通过 NFC 将其发送到车辆的读卡器。
在通过 NFC 发送任何内容之前,我们必须添加 CRC 字节,使用 prepare_tag_modulation() 准备调制,然后使用 EmSendPrecompiledCmd() 通过 NFC 发送数据。
Proxmark 代码或多或少已经准备好了,但我们确实需要创建额外的代码才能在第二个攻击者的智能手机上运行,这将接近受害者的 Tesla NFC 卡。该应用进程将需要 NFC、蓝牙和 Wi-Fi 功能来执行中继攻击。
当第二个攻击者的智能手机上运行的 Android 应用进程通过 Wi-Fi 或蓝牙收到来自 Proxmark 的请求时,它会通过 NFC 将该请求中继到受害者的卡,然后读取加密响应并将其送回 Proxmark。
时间限制似乎非常宽松,攻击者可以从几米之外通过蓝牙进行攻击,也可以通过Wi-Fi在更远的距离内进行攻击。我们认为通过互联网进行攻击也是可能的。
对于刚开始提出的几个问题:
a.车辆和卡之间的中继通信,还是会花费太多时间?
时间限制似乎非常宽松,攻击者可以从几米之外通过蓝牙进行攻击,也可以通过Wi-Fi在更远的距离内进行攻击。我们认为这也可能通过互联网进行攻击。
b.我们是否在协议中缺少其他可以防止中继攻击的东西?
当车辆未启用“PIN to Drive”功能时,只需要一个请求/响应即可打开并驾驶汽车
c.攻击者必须离受害者的卡有多近?
攻击者之一必须非常接近受害者的卡片。这个距离可能会根据多个因素而改变,但在使用智能手机时,4厘米或更短的距离可能是相当精确的。使用更专业、高功率的设备可能会使这个距离变得更大,甚至超过60厘米。