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確認が成功した後、SRTPマスターキーを確立するためにDTLSセッションが開始され、メディアストリームのためにSRTPに切り替わります。
悪用メカニズム
レースコンディションの悪用： 攻撃者は、正当なユーザーの前にDTLS ClientHelloメッセージを送信することでレースコンディションを悪用できます。無効な暗号スイート（例：
TLS_NULL_WITH_NULL_NULL）を使用する可能性があります。これにより、サーバーでDTLSエラーが発生し、SRTPセッションの確立が妨げられます。
攻撃プロセス
ポートスキャン： 攻撃者は、どのUDPポートが受信メディアセッションを処理しているかを推測し、これらのポートにnull暗号スイートを使用したClientHelloメッセージを送信して脆弱性を引き起こします。
攻撃の図： シーケンスは、攻撃者がサーバーに送信する複数のClientHelloメッセージが正当なシグナリングおよびDTLSメッセージと交互に送信され、誤った暗号スイートのためにハンドシェイクが失敗することを含みます。
テストと緩和策
安全なテスト： Scapyのようなツールを使用して、攻撃者は特定のメディアポートをターゲットにしたDTLS ClientHelloメッセージを再生します。倫理的なテストのために、Chromiumの修正（例：
JsepTransport::AddRemoteCandidates）を使用して、被害者の行動を安全に模倣しました。緩和策： 解決策には、未確認のアドレスからのパケットをドロップすることが含まれ、新しいバージョンのlibniceのようなライブラリで実装されています。主な解決策は、ICE確認プロセスを信頼し、検証されたIPおよびポートの組み合わせからのパケットのみを処理することを強調しています。
脆弱でないシナリオ
DTLSサーバー構成： ブラウザがDTLSサーバーとして機能する場合や、メディアサーバーがメディアセッションにエフェメラルポートを使用しない場合は、この脆弱性に対して影響を受けません。
結論
この脆弱性は、メディアセッション初期化プロセスにおける微妙なバランスと、悪用を防ぐための正確なタイミングおよび確認メカニズムの必要性を強調しています。開発者は、推奨されるセキュリティ修正を実装し、こうした脆弱性を緩和するために堅牢な確認プロセスを確保することが推奨されます。
Last updated
