[关闭]
@1qaz 2017-06-20T13:06:09.000000Z 字数 2162 阅读 1736

WebRTC: Your Privacy is at Risk

webrtc


Andreas Reiter, Alexander Marsalek IAIK TU Graz, SAC'17

Web-based Real-Time Communication实现了浏览器到浏览器的通讯。这篇文章提出了4种针对WebRTC协议本身的攻击,不可信的sigal server、探测内网、Fingerprint和拒绝服务攻击。对于每种攻击,都提出了相应的解决方法。

Introduction & Background

经典的web应用是server-client模型,client之间不能互相访问。WebRTC作为一个实时音视频通讯技术,使得两个应用,例如两个浏览器,在不需要中间服务器的情况下,可以直接互相通讯。这使得浏览器本身也要起到部分服务器的功能,这些功能带来了潜在的安全问题。

webrtc的整体架构和流程
1
1. 发起请求的节点(offerer)创建一个offer,包含自己的连接信息
2. offer通过signal channel发送到 另一方节点
3. 另一方节点(answerer)基于offer创建一个answer,发送回offerer
4. offerer和answerer可能需要用ICE协议来联系STUN server 或者 TURN server,获得自己的外网地址
5. 双方节点都获知了对方的连接信息,建立点对点的通信

Session Description Protocol(SDP)用来描述offer/answer,Interactive Connectivity Establishment (ICE)用来实现NAT穿越。signal channel是双方在连接建立前唯一的通道,需要实现安全通信。问题的关键在于webrtc标准里并没有明确指定signal channel如何实现

Security Analysis

分析WebRTC中已有的安全机制

WebRTC规范中不允许明文发送数据,目前的实现默认使用DTLS-SRTP进行媒体传输,DTLS进行数据传输。 DTLS-SRTP中,双方为每次连接生成一个新的自签名的证书,signal channel作为一个可信信道来传输证书指纹,从而实现认证。
2
3
ice字段用来发现remote candidate,避免其他节点参与本次连接;fingerprint字段就是之后DTLS会使用的自签名证书的哈希。最后点对点通信时通过验证证书指纹是否和signal channel中传输的相符,来防止中间人攻击。

在这个场景中,signal server起到了Identity Provider的作用。Rescorla提出了图3的安全架构,浏览器直接和IdP交流获得身份信息,signal信道传输身份信息

在这种方法下,signal server不需要被完全信任,需要和不同的IdP建立信任。

WebRTC引入了新的需要保护的资源:
1. 外网IP:泄漏用户的位置信息。server-client模型中server获得所有client的ip,WebRTC中任何client都能获得另外一个client的ip
2. 私有IP和内部网络:连接建立的过程中client的私有IP被暴露
3. 带宽:防止DoS (音视频流量大)
4. 节点身份:server-client模型通常只验证服务器身份,WebRTC需要验证双方身份

Attacks & Mitigation

作者提出了针对协议本身,不针对具体实现的4种攻击(需要特定的环境)

不可信的signal server

在没有其他IdP的情况下,节点只能相信signal server
4
解决方法是增加一个可信第三方,或者让用户自行选择是否相信证书

探测内网

JavaScript可以使用WebRTC的接口。为了找到最高效的通讯路径,如在同一个内网中使用私有IP地址,在NAT之后需要NAT穿越,因此所有网络接口的IP是暴露给JavaScript的。
利用这个接口,可以获得VPN后的用户的实际IP地址,也可以用javascript port scanner来探测内网。

inter-protocol attack:让一种协议的内容按照另一种协议来解析。 有些协议忽略错误的输入,直到接收到有效的输入
(HTTPS vs FTPS)

解决方法:更细粒度的权限控制

WebRTC指纹

利用WebRTC获得浏览器的各个IP地址,从而对每个浏览器建立唯一的标识,可以跟踪用户
内网ip,WiFi ip,虚拟机adapter ip,virtual adapter ip to communicate with plugged-in or host devices

Flooding the Web

offer发送后,可以任意数量的IceCandidate,接受方会去测试可否连接。
STUN 测试连接时会发送 bind request,其中用户名最多255个字节,STUN+IP包最大368字节
还有其他参数:
1. 连接请求(offer)的数量
2. 每个offer中candidate的数量
3. 每个连接的等待时间

在等待时间1s的条件下,测试另外两个参数的变化对流量的影响
5
作者最大的流量打到0.8Mbit/s,如果有上千个节点也能带来一定的压力。victim只需要访问attacker设置的网页就被利用了。

解决方法:
限制candidate数量
连接数过大时提醒用户

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注