华为Share背后的Wi-Fi Direct应用层风险

基础介绍

近期华为Share跨设备文件共享又玩出了新花样，作为一个技术安全研究爱好者，不禁在想此类功能其究竟是如何实现，是否存在安全风险呢？

华为 Share 基于 Wi-Fi Direct 技术实现高速点对点数据传输，通过动态加密和设备验证提升文件共享的安全性和可靠性，自 Android 4.0 以来， 这项 802.11 扩展已通过专用 API 提供，该 API 与设备的内置硬件交互，这些硬件通过 Wi-Fi 直接相互连接，无需中间接入点。多家移动供应商和这项技术的早期采用者迅速利用该标准为其产品提供快速可靠的文件传输解决方案。

在过往的研究中，研究了三种安卓手机厂商流行的 P2P 文件传输实现（即 Huawei Share 、 LG SmartShare Beam 、 Xiaomi Mi Share ）， 发现它们都因不安全的共享设计而存在漏洞。 关于Wifi Direct的研究， 2018 年欧洲 Black Hat 大会期间，Andrés Blanco 已经展示了一些针对协议层的开创性研究工作（链接：https://www.blackhat.com/docs/eu-17/materials/eu-17-Blanco-WI-FI-Direct-To-Hell-Attacking-WI-FI-Direct-Protocol-Implementations.pdf） ，本文专注于此类自定义 UPnP 服务的应用层风险。

WiFI Direct 循环设计模式

在大多数主流 OEM 解决方案中，移动文件传输应用程序将产生两个服务端：

• 文件传输控制客户端( FTC) ，将管理大部分配对和传输控制流

• 文件传输服务器( FTS) ，用于检查会话的有效性并提供所需的共享文件

这两个服务用于设备发现、配对和会话、授权请求和文件传输功能。通常，它们作为共享父应用程序的类来实现，这些类负责协调整个传输。这些组件负责：

1. 创建 Wi-Fi Direct 网络

2. 使用标准 UPnP 阶段 声明设备、文件服务描述（ /description.xml ）和事件订阅

3. 发出 UPnP 远程过程调用来创建与另一个对等方（即设备）的传输请求

4. 接收方接受后，通过 HTTP POST/PUT 请求将目标文件上传到指定位置

在建立 P2P Wi-Fi 连接后，其网络接口 ( p2p-wlan0-0 ) 可供 用户设备上运行的每个拥有android.permission.INTERNET权限的应用程序使用。因此， 本地应用程序可以与本地或远程设备客户端上的文件共享应用程序生成的FTS和FTC服务进行交互，从而为多种攻击打开大门。

漏洞案例

LGSmartShare风险

Smartshare 是 LG 的一项常用解决方案，可使用 Wi-Fi（DLNA、Miracast）或蓝牙（ A2DP 、OPP）将手机连接到其他设备。Beam 功能用于 LG 设备之间的文件传输。

就像其他类似的应用程序一样， 会生成一个 FTS（ FileTransferTransmitter 在 com.lge.wfds.service.send.tx中）和一个 FTC（ FileTransferReceiver 在 com.lge.wfds.service.send.rx中），并分别在端口 54003 和 55003上进行监听 。

举例来说，以下 HTTP 请求演示了当请求双方之间的文件传输会话时 FTC 和 FTS 的运行情况。

首先，FTS 执行 CreateSendSession SOAP 操作：

该 SessionInformation 节点嵌入了实体转义的标准 Wi-Fi 联盟架构，用于传输 CuteCat.jpg 图片。文件名 ( MetaInfo/Item/Name ) 显示在文件传输提示中，以向最终接收者显示所传输文件的名称。根据设计，在接收者确认后， CreateSendSessionResponse 将返回 SOAP 响应：

这将包含 TransportInfo 用于最终传输的目标端口：

很明显这种设计存在许多问题，例如：

无需有效的会话 ID 即可完成传输一旦 CreateSendSessionResponse 发出，无需身份验证即可将文件推送到打开的 RX 端口。由于接收方的 DEFAULT_HTTPSERVER_PORT 被硬编码为 55432 ，因此发送方或接收方设备上运行的任何应用程序都可以劫持传输并将任意文件推送到受害者的存储，只需发出有效 PUT 请求即可。最重要的是，当前的会话 ID 很容易被猜到，因为它们是从一个小范围中随机选择的（ WfdsUtil.randInt(1, 100) ）；

发送方可以任意更改文件名和类型，因为从未检查传输的文件名是否反映最初提示给用户的文件名，所以攻击者只需将请求路径更改为任意值，就可以指定与最初显示的文件名或类型不同的文件名或类型 PUT 。

无需用户确认即可一次发送多个文件一旦打开 RX 端口（ DEFAULT_HTTPSERVER_PORT ），攻击者就可以在一次交易中发送多个文件，而不会向收件人发出任何通知。

由于上述设计问题，安装在对方设备上的任何恶意第三方应用程序都可能影响或接管合法 LG SmartShare 应用程序发起的任何通信，从而可能劫持合法文件传输。蠕虫恶意应用程序可能会滥用这种不安全的设计来淹没等待文件传输的本地或远程受害者，从而有效地传播其恶意 APK，而无需用户交互。攻击者还可以滥用此设计在受害者的设备上植入任意文件或证据。

Huawei Share风险

Huawei Share是华为EMUI操作系统中包含的另一个文件共享解决方案，支持华为各种终端使用，在 Huawei Share 中，会生成一个 FTS ( FTSService 在 com.huawei.android.wfdft.fts 中) 和一个 FTC ( FTCService 在 com.huawei.android.wfdft.ftc 中)，它们会监听端口 8058 和 33003 。从更高层次上看，Share 协议类似于 LG SmartShare Beam 机制，但没有相同的设计缺陷。

不过Huawei Share 的风险是服务的稳定性：已识别出多个可能导致FTC/FTS崩溃的 HTTP 请求 。 FTSService 的崩溃可以通过安装在用户设备上的任何第三方应用程序触发，并且由于 UPnP 通用事件通知架构 (GENA) 本身的设计， 攻击者仍然可以接管合法 Huawei Share 应用程序发起的任何通信，窃取会话 ID 并劫持文件传输。

在复现攻击场景中，张三 和 李四 的设备通过直接 Wi-Fi 连接进行连接和配对。李四还在不知情的情况下在其设备上运行了一个几乎没有权限的恶意应用程序。在此场景中，李四通过 Huawei Share 发起文件共享。因此，他的合法应用程序将通过POST请求向张三的FTCService发送CreateSession SOAP操作，以获取有效的SessionID，该ID将用作文件传输其余部分的授权令牌。在标准交换期间，张三在他的设备上接受传输后，将向李四的FTSService发送文件共享事件通知（NOTIFY /evetSub）。然后FTSService将用于提供预期的文件

由于张三手动接受传输与其开始之间存在固有的时间跨度，恶意应用程序可以执行带有临时有效负载的请求，以触发FTSService崩溃，并随后将其自己的FTSService 绑定到同一端口。由于UPnP事件订阅和通知协议设计，包含SessionID的NOTIFY事件现在可以被假FTSService 拦截，并被恶意应用程序用于提供任意文件。

小米 MiShare风险

小米的 MiShare 随 MIUI 11 推出，可在小米和红米手机之间提供类似 AirDrop 的文件传输功能。最近，此功能已扩展，以兼容“点对点传输联盟”生产的设备（包括小米 、OPPO、Vivo、Realme、魅族等拥有超过 4 亿用户的供应商）。

MiShare 内部具有两组不同的 API：

• 使用纯粹 RESTfulAPI HTTP 请求

• 主要使用 Websockets Secure (WSS) 和少量 HTTPS 请求

目前，小米设备之间的传输默认使用基于 websocket 的 API，我们评估的就是这个 API。与其他 P2P 解决方案一样，我们发现了几个小的设计和实现错误：

1. 通过 WSS 发送的 JSON 编码包裹指定了文件属性，是可信的，其 fileSize 参数用于检查设备上是否还有可用空间。由于这是发送者声明的文件大小，因此可能会发生耗尽剩余空间的拒绝服务 (DoS)。

2. 会话令牌（taskId） 长度为19位数字， 使用弱随机函数java.util.Random来生成它们。

3. 与其他手机供应商解决方案一样，安装在用户设备上的任何第三方应用程序都可以干扰 MiShare 的交换。虽然也有几种使 MiShare 产生崩溃的 DoS 风险，但对于小米手机而言，文件传输服务重新启动非常快，因此攻击的机会窗口非常有限，效果一般。

比较好的是Mi Share 协议设计在通过 WSS 和 HTTPS 通信时使用TLS证书进行了强化，限制了许多安全问题的可利用性。

结论

上述某些攻击很容易在其他现有的移动文件传输解决方案中复制，过去发现的其他常见漏洞包括类似的不当访问控制问题、路径遍历、XML 外部实体 (XXE)、不当文件管理以及连接的中间人攻击 (MITM)，感兴趣的朋友可以继续深入研究，探索炫酷科技背后的心酸安全风险