WebRTC DoS

Reading time: 5 minutes

此问题在以下博客文章中发现： https://www.rtcsec.com/article/novel-dos-vulnerability-affecting-webrtc-media-servers/

在WebRTC媒体服务器中描述的漏洞源于媒体会话初始化期间的竞争条件，具体是在ICE媒体同意验证和DTLS流量初始化之间。以下是详细的分解：

漏洞来源

1. UDP端口分配： 当用户发起WebRTC通话时，媒体服务器为处理媒体流分配UDP端口，IP和端口通过信令进行通信。
2. ICE和STUN过程： 用户的浏览器使用ICE进行媒体同意验证，利用STUN确定到媒体服务器的连接路径。
3. DTLS会话： 在成功的STUN验证后，DTLS会话开始建立SRTP主密钥，切换到SRTP进行媒体流传输。

利用机制

• 竞争条件利用： 攻击者可以通过在合法用户之前发送DTLS ClientHello消息来利用竞争条件，可能使用无效的密码套件如TLS_NULL_WITH_NULL_NULL。这会导致服务器出现DTLS错误，阻止SRTP会话的建立。

攻击过程

• 端口扫描： 攻击者需要猜测哪些UDP端口正在处理传入的媒体会话，向这些端口发送带有空密码套件的ClientHello消息以触发漏洞。
• 攻击示意图： 该序列涉及攻击者向服务器发送多个ClientHello消息，夹杂着合法的信令和DTLS消息，导致由于错误的密码套件而握手失败。

测试和缓解

• 安全测试： 使用像Scapy这样的工具，攻击者重放针对特定媒体端口的DTLS ClientHello消息。为了进行伦理测试，对Chromium进行修改（例如，JsepTransport::AddRemoteCandidates）以安全地模拟受害者行为。
• 缓解措施： 解决方案包括丢弃来自未验证地址的数据包，如在libnice等库的新版本中实现的那样。主要解决方案强调信任ICE验证过程，仅处理来自验证的IP和端口组合的数据包。

非易受攻击场景

• DTLS服务器配置： 浏览器充当DTLS服务器的实例或媒体服务器未使用临时端口进行媒体会话的情况不易受到此漏洞的影响。

结论

此漏洞突显了媒体会话初始化过程中的微妙平衡，以及需要精确的时序和验证机制以防止利用。建议开发人员实施推荐的安全修复，并确保强大的验证过程以缓解此类漏洞。