WebRTC DoS
此问题在以下博客文章中发现： https://www.rtcsec.com/article/novel-dos-vulnerability-affecting-webrtc-media-servers/
在 WebRTC 媒体服务器中描述的漏洞源于媒体会话初始化期间的 竞争条件，具体是在 ICE 媒体同意验证 和 DTLS 流量初始化 之间。以下是详细的分解：
漏洞来源
UDP 端口分配： 当用户发起 WebRTC 通话时，媒体服务器为处理媒体流分配 UDP 端口，IP 和端口通过信令进行通信。
ICE 和 STUN 过程： 用户的浏览器使用 ICE 进行媒体同意验证，利用 STUN 确定到媒体服务器的连接路径。
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 服务器的实例或媒体服务器未使用临时端口进行媒体会话的情况不易受此漏洞影响。
结论
此漏洞突显了媒体会话初始化过程中的微妙平衡，以及需要精确的时序和验证机制以防止利用。建议开发者实施推荐的安全修复，并确保强大的验证过程以缓解此类漏洞。
Last updated
