WebRTC DoS

Reading time: 6 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確認が成功した後、SRTPマスターキーを確立するためにDTLSセッションが開始され、メディアストリームのために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サーバーとして機能する場合や、メディアサーバーがメディアセッションにエフェメラルポートを使用しない場合は、この脆弱性に対して影響を受けません。

結論

この脆弱性は、メディアセッション初期化プロセスにおける微妙なバランスと、悪用を防ぐための正確なタイミングおよび確認メカニズムの必要性を浮き彫りにしています。開発者は、推奨されるセキュリティ修正を実装し、こうした脆弱性を緩和するために堅牢な確認プロセスを確保することが推奨されます。