WebRTC DoS
Last updated
Last updated
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)
この問題はこのブログ記事で見つかりました: 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サーバーとして機能する場合や、メディアサーバーがメディアセッションにエフェメラルポートを使用しない場合は、この脆弱性に対して影響を受けません。
この脆弱性は、メディアセッション初期化プロセスにおける微妙なバランスと、悪用を防ぐための正確なタイミングおよび検証メカニズムの必要性を強調しています。開発者は、推奨されるセキュリティ修正を実装し、こうした脆弱性を緩和するために堅牢な検証プロセスを確保することをお勧めします。
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)
