Wi-Fi Direct移动文件传输的新型滥用攻击分析

Wi-Fi Direct移动文件传输的新型滥用攻击

Wi-Fi Direct规范（又称“点对点”或“P2P”Wi-Fi）于2020年4月迎来了10周年纪念。这项802.11扩展自Android 4.0起通过专用API提供，利用设备内置硬件直接通过Wi-Fi相互连接，无需中间接入点。
多家移动厂商和该技术的早期采用者迅速利用该标准为其产品提供快速可靠的文件传输解决方案。
近十年后，绝大多数移动OEM仍然依赖定制的封闭实现进行文件传输，尽管大型跨厂商联盟（如“点对点传输联盟”）和谷歌等巨头（通过最近的“Nearby Share”功能）正在推动改变这一现状。

研究背景

在我们的研究中，分析了三种流行的P2P文件传输实现（即华为Share、LG SmartShare Beam、小米Mi Share），发现它们均因不安全的共享设计而存在漏洞。尽管Andrés Blanco在Black Hat EU 2018上已经提出了攻击协议层的突破性研究工作，我们决定专注于这类定制UPnP服务的应用层。

复现的设计模式

在大多数OEM解决方案中，移动文件传输应用程序会启动两个服务器：

文件传输控制器或客户端（FTC）：管理大部分配对和传输控制流。
文件传输服务器（FTS）：检查会话有效性并提供目标共享文件。

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

创建Wi-Fi Direct网络。
使用标准UPnP阶段宣布设备、文件服务描述（/description.xml）和事件订阅。
发出UPnP远程过程调用以创建与另一个对等体的传输请求。
在接收方接受后，通过HTTP POST/PUT请求将目标文件上传到指定位置。

一个重要考虑是，P2P Wi-Fi连接建立后，其网络接口（p2p-wlan0-0）对设备上具有android.permission.INTERNET权限的任何应用程序可用。因此，本地应用程序可以与文件共享应用程序启动的FTS和FTC服务交互，为多种攻击打开大门。

LG SmartShare Beam

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操作：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


POST /FileTransfer/control.xml HTTP/1.1
Connection: Keep-Alive
HOST: 192.168.49.1:55003
Content-Type: text/xml; charset="utf-8"
Content-Length: 1025
SOAPACTION: "urn:schemas-wifialliance-org:service:FileTransfer:1#CreateSendSession"

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope
    xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <s:Body>
        <u:CreateSendSession
            xmlns:u="urn:schemas-wifialliance-org:service:FileTransfer:1">
            <Transmitter>Doyensec LG G6 Phone</Transmitter>
            <SessionInformation>&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;&lt;MetaInfo
                xmlns=&quot;urn:wfa:filetransfer&quot;
                xmlns:xsd=&quot;http://www.w3.org/2001/XMLSchema&quot;
                xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot; xsi:schemaLocation=&quot;urn:wfa:filetransfer http://www.wi-fi.org/specifications/wifidirectservices/filetransfer.xsd&quot;&gt;&lt;Note&gt;1 and 4292012bytes File Transfer&lt;/Note&gt;&lt;Size&gt;4292012&lt;/Size&gt;&lt;NoofItems&gt;1&lt;/NoofItems&gt;&lt;Item&gt;&lt;Name&gt;CuteCat.jpg&lt;/Name&gt;&lt;Size&gt;4292012&lt;/Size&gt;&lt;Type&gt;image/jpeg&lt;/Type&gt;&lt;/Item&gt;&lt;/MetaInfo&gt;
            </SessionInformation>
        </u:CreateSendSession>
    </s:Body>
</s:Envelope>

SessionInformation节点嵌入了一个实体转义的标准Wi-Fi Alliance模式urn:wfa:filetransfer，传输CuteCat.jpg图片。
文件名（MetaInfo/Item/Name）显示在文件传输提示中，向最终接收方展示传输文件的名称。设计上，接收方确认后，将返回CreateSendSessionResponse SOAP响应：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


HTTP/1.1 200 OK
Date: Sun, 01 Jun 2020 12:00:00 GMT
Connection: Keep-Alive
Content-Type: text/xml; charset="utf-8"
Content-Length: 404
EXT: 
SERVER: UPnPServer/1.0 UPnP/1.0 Mobile/1.0

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope
    xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <s:Body>
        <u:CreateSendSessionResponse
            xmlns:u="urn:schemas-wifialliance-org:service:FileTransfer:1">
            <SendSessionID>33</SendSessionID>
            <TransportInfo>tcp:55432</TransportInfo>
        </u:CreateSendSessionResponse>
    </s:Body>
</s:Envelope>

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

1
2
3
4
5
6
7
8


PUT /CuteCat.jpeg HTTP/1.1
User-Agent: LGMobile
Host: 192.168.49.1:55432
Content-Length: 4292012
Connection: Keep-Alive
Content-Type: image/jpeg

.... .Exif..MM ...<redacted>

可能出错的地方？

不幸的是，这种设计存在许多问题，例如：

不需要有效的会话ID来完成传输：一旦发出CreateSendSessionResponse，推送到打开的RX端口不需要身份验证。由于接收方的DEFAULT_HTTPSERVER_PORT硬编码为55432，发送方或接收方设备上运行的任何应用程序都可以通过发出有效的PUT请求来劫持传输并将任意文件推送到受害者存储中。此外，当前会话ID易于猜测，因为它们是从小池中随机选择的（WfdsUtil.randInt(1, 100)）。
文件名和类型可以由发送方任意更改：由于传输的文件名从未检查以反映最初提示用户的名称，攻击者可以通过将PUT请求路径更改为任意值来指定不同的文件名或类型。
可以在没有用户确认的情况下一次发送多个文件：一旦RX端口（DEFAULT_HTTPSERVER_PORT）打开，攻击者可以在单个事务中发送多个文件，而不会向接收方提示任何通知。

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

华为Share

华为Share是华为EMUI操作系统中包含的另一种文件共享解决方案，支持华为终端及其第二品牌Honor。

在华为Share中，FTS（FTSService在com.huawei.android.wfdft.fts中）和FTC（FTCService在com.huawei.android.wfdft.ftc中）启动并监听端口8058和33003。
在高层，Share协议类似于LG SmartShare Beam机制，但没有相同的设计缺陷。
不幸的是，华为Share的绊脚石是服务的稳定性：识别了多个可分别崩溃FTCService或FTSService的HTTP请求。由于崩溃可以由用户设备上安装的任何第三方应用程序触发，并且由于UPnP通用事件通知架构（GENA）设计本身，攻击者仍然可以接管由合法华为Share应用程序发起的任何通信，窃取会话ID并劫持文件传输。

滥用FTS/FTC崩溃

在复制的攻击场景中，Alice和Bob的设备通过Direct Wi-Fi连接连接和配对。Bob还在其设备上无意中运行了一个具有很少或没有权限的恶意应用程序。
在此场景中，Bob通过华为Share 1启动文件共享。因此，他的合法应用程序将通过POST请求向Alice的FTCService发送CreateSession SOAP操作以获取有效的SessionID，该ID将用作其余事务的授权令牌。在标准交换期间，Alice在其设备上接受传输后，文件共享事件通知（NOTIFY /evetSub）将触发到Bob的FTSService。FTSService然后将用于提供目标文件。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


NOTIFY /evetSub HTTP/1.1
Content-Type: text/xml; charset="utf-8"
HOST: 192.168.49.1
NT: upnp:event
NTS: upnp:propchange
SID: uuid:e9400170-a170-15bd-802e-165F9431D43F
SEQ: 1
Content-Length: 218
Connection: close

<?xml version="1.0" encoding="utf-8"?>
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
    <e:property>
        <TransportStatus>1924435235:READY_FOR_TRANSPORT</TransportStatus>
    </e:property>
</e:propertyset>

由于Alice手动接受传输和其开始之间存在固有的时间跨度，恶意应用程序可以执行具有特制负载的请求以触发FTSService 2的崩溃，随后将其自己的FTSService 3绑定到同一端口。由于UPnP事件订阅和通知协议设计，包括SessionID（例如上面的1924435235）的NOTIFY事件现在可以被假冒的FTSService 4拦截，并由恶意应用程序用于提供任意文件。

崩溃对设备用户和文件接收方都是不可检测的。识别了多个使用畸形请求的崩溃向量，使服务系统性地脆弱和可利用。

随着MIUI 11引入，小米的MiShare提供类似AirDrop的文件传输功能，用于Mi和Redmi手机之间。最近，此功能扩展为与“点对点传输联盟”生产的设备兼容（包括拥有超过4亿用户的厂商，如小米、OPPO、Vivo、Realme、Meizu）。

由于这种过渡，MiShare内部具有两组不同的API：

一组使用裸HTTP请求，具有许多RESTful路由。
一组主要使用Websockets Secure（WSS）和仅少数HTTPS请求。

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

通过WSS发送的指定文件属性的JSON编码包裹被信任，其fileSize参数用于检查设备上是否剩余可用空间。由于这是发送方声明的文件大小，可能导致拒绝服务（DoS）耗尽剩余空间。
会话令牌（taskId）为19位长，使用弱熵源（java.util.Random）生成。
与其他提出的厂商解决方案一样，安装在用户设备上的任何第三方应用程序都可以干预MiShare的交换。虽然也有几个崩溃MiShare的DoS负载可用，但对于该厂商，文件传输服务非常快速地重启，使得攻击的机会窗口非常有限。

在更积极的方面，Mi Share协议设计通过在使用WSS和HTTPS通信时使用每会话TLS证书进行了加固，限制了许多安全问题的可利用性。

结论

本文描述的一些攻击可以轻松复制到其他现有的移动文件传输解决方案中。虽然核心技术一直存在，但OEM仍然难以防御其自己的P2P共享风格。过去发现的其他常见漏洞包括类似的不当访问控制问题、路径遍历、XML外部实体（XXE）、不当文件管理以及连接中的猴子在中间（MITM）。
本文简要描述的所有漏洞在2020年4月至6月期间已负责任地披露给各自的OEM安全团队。