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. 发起请求的节点（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作为一个可信信道来传输证书指纹，从而实现认证。 


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 

解决方法是增加一个可信第三方，或者让用户自行选择是否相信证书

探测内网

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的条件下，测试另外两个参数的变化对流量的影响 
 
作者最大的流量打到0.8Mbit/s,如果有上千个节点也能带来一定的压力。victim只需要访问attacker设置的网页就被利用了。

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