1つのTwitchチャットメッセージがストリーマーのPCでコード実行に変わった方法

脆弱なチャットオーバーレイ、サンドボックス化されていないChromiumレンダラー、そして既に悪用されていたV8のバグがあれば、ビューワーが制御するテキストをネイティブコード実行に変えることができ、OBS自体はデフォルト設定のままでした。 私は、OBSのブラウザソース内でビューワーメッセージを生のHTMLとしてレンダリングするTwitchチャットオーバーレイを見つけました。これにより、ビューワーはOBSに組み込まれたChromiumブラウザ内でJavaScriptを実行できるようになります。 記事執筆時点でのOBSの最新リリースには、サンドボックスなしで動作するChromiumビルドが含まれており、そのV8バージョンは既に悪用されていたCVE-2024-7971に対して脆弱でした。 これらが組み合わさることで、メッセージはTwitchチャットで始まり、ストリーマーのマシン全体を制御することに終わりました。 PoC: OBS 32.2.2におけるリモートコード実行 スクリーンショットから始まった 友人がOBS用の小さなTwitchチャットオーバーレイをvibecodeで作成し、そのスクリーンショットを投稿しました。 ストリーミングセットアップに触れたことがない方のために説明すると、チャットオーバーレイは基本的に、OBSがブラウザソースを通じてストリームの上にレンダリングする小さなウェブページです。ライブチャットメッセージ、アラート、寄付、またはビューワーに画面で見せたいものをプルしてくることができます。 そのスクリーンショットにはコードの一部も写っており、1行がすぐに私の注意を引きました。チャットメッセージが、サニタイズなしでそのままHTMLとしてページにドロップされていたのです。 この調査全体を開始したツイート これは典型的なXSSです。おそらくこの全く同じセットアップを見たことがあるでしょう。ビューワーがメッセージを制御し、オーバーレイがそれをテキストではなくHTMLとして扱います。そして、攻撃者が制御するコンテンツがページ内で実行される可能性があります。 私は、すでに首を横に振っている人もいると思いますが、それにはもっともな理由があります。 これは、MicodeによるOBSのWebSocketインターフェースを介した攻撃に関する古いビデオを思い出させました。アイデアは、チャットXSSを入力ポイントとして使用し、次にOBSのローカルWebSocketサーバーと通信して、シーンの切り替えやストリームの停止などのアクションをトリガーすることでした。 しかし、そのルートは今日ではあまり面白くありません。OBS WebSocketサーバーはデフォルトで無効になっており、有効にしてもパスワードが必要です（自動生成されます）。 私はもっと強力なものを求めていました。1つのTwitchメッセージ、最新のOBS、標準構成、ストリーマーからの操作なし、そしてマシン自体のコード実行です。 WebSocketではそこまで到達できませんでした。ブラウザなら可能かもしれません。 OBSにはフルブラウザがあります OBSブラウザソースは、CEF（Chromium Embedded Framework）を介してChromiumによって駆動されています。これらは、チャットボックス、アラート、寄付ウィジェット、アニメーション、カスタムオーバーレイに使用されます。 同じブラウザコンポーネントは、ブラウザドックやサービス統合もサポートしています。 したがって、この小さなチャットレイアウトは、実際にはOBSに組み込まれたフルChromiumブラウザ内で実行されていました。 XSSが確立されたことで、ビューワーが制御するJavaScriptが、ストリーマーのマシン上のChromium内で実行されるようになりました。 それだけでは、Windows上のコード実行にはなりません。ブラウザには、ウェブコンテンツがホストの制御に変わるのを防ぐためのセキュリティ境界があります。 しかし、OBSのブラウザには重要な境界が欠けていました。 Chromiumサンドボックスは無効になっています Chromeは通常、サンドボックスを使用してレンダラープロセスを分離します。攻撃者がメモリ破損バグを悪用してレンダラー内でネイティブコード実行を達成した場合でも、通常はホストに到達する前にそのサンドボックスを越える必要があります。 OBSは、以下の設定で組み込みCEFブラウザを初期化します。 CefString(&settings.log_file) = log_path_abs; settings.windowless_rendering_enabled = true; settings.no_sandbox = true; uint32_t obs_ver = obs_get_version(); uint32_t obs_maj = obs_ver >> 24; この設定は、現在のobs-browserソースに直接存在します。 XSSは依然としてJavaScriptしか提供しません。しかし、そのJavaScriptがV8を悪用してレンダラー内でネイティブコード実行に変わることができれば、脱出するためのChromiumサンドボックスはもう残っていません。 そこで、OBSがどのChromiumバージョンを出荷しているかを確認しました。 言っておきますが、その答えは私が期待していたものではありませんでした。 そしてCVE-2024-7971がチャットに入ってきた この記事の執筆時点でのOBSの最新リリース、私がテストしたバージョンは、Chromium 127.0.6533.120とV8 12.7.224.18を使用していました。 これは興味深いことでした。なぜなら、V8における型混乱のCVE-2024-7971は、128.0.6613.84より前のChromiumバージョンに影響を与えるからです。Googleは2024年8月21日にChrome 128でこれをパッチしました。 これは理論的なブラウザバグではありませんでした。Microsoftは、これを追跡している北朝鮮の脅威アクターであるCitrine Sleetによって悪用されていると文書化しており、CISAはそれを既知の悪用脆弱性カタログに追加しました。 Microsoftが観察した攻撃では、V8の悪用はChromeのサンドボックス化されたレンダラー内でコード実行を可能にしました。攻撃者は依然としてサンドボックスを脱出するために別の脆弱性を必要としていました。 OBS内では、その特定の障壁は既に無効になっていました。 ピースが揃った。 攻撃チェーン 構築されたチェーン 私がテストした正確なCEFビルドを標的とした公開Proof of Conceptはなかったので、自分で作成しました。 開発中、Chromiumリモートデバッグを有効にし、DevToolsプロトコルを使用してレンダラーを検査し、エクスプロイトをデバッグしました。 大まかに言うと、V8バグはページに本来アクセスできないはずのメモリへのアクセスを許可します。そこから、エクスプロイトはそれをより広範なプロセスメモリへのアクセスに発展させ、最終的にはネイティブコード実行に至ります。 エクスプロイトの内部については、この投稿では意図的に省略します。 最終的な結果ははるかに説明しやすいです。 ビューワーが悪意のあるTwitchチャットメッセージを1つ送信し、脆弱なオーバーレイがそれをJavaScript実行に変換し、V8エクスプロイトがそれをネイティブコード実行に変換し、攻撃者はストリーマーのマシン上で任意のコードを実行できるようになります。 「デフォルト構成」で私が意味すること これは、Fresh OBSのインストールがTwitchチャットの誰にでもリモートで悪用可能であることを意味するわけではありません。 私のデモンストレーションにおけるゼロクリックのエントリーポイントは、脆弱なオーバーレイです。ストリーマーは、ビューワーが制御するコンテンツを適切にサニタイズせずにレンダリングするブラウザソースを使用している必要があります。 しかし、そのページがロードされると、残りのチェーンを機能させるためにOBSを弱めることはしませんでした。WebSocketの設定なし、管理者権限なし、ユーザーが変更したサンドボックスオプションなし、ストリーマーからのクリックなし。 Twitchオーバーレイは、ブラウザに到達するための唯一の方法でもありません。 より一般的には、OBSブラウザソースまたはブラウザドックにロードされた攻撃者が制御するページは、ブラウザエクスプロイトの段階から直接開始できる可能性があります。 チャットXSSは、この特定のチェーンをビューワーの観点からリモートでゼロクリックにするものです。 したがって、興味深いのはXSS自体ではありません。 それは、攻撃者が制御するウェブコンテンツがどこで実行されているかということです。 なぜこれが重要なのか ストリーミングセットアップはウェブコンテンツでいっぱいです。 チャットボックス、寄付アラート、フォロワー通知、カスタムウィジェットはすべてウェブページであり、そのデータの多くはインターネット上の見知らぬ人から来ています。 チャットメッセージがテキストであれば、テキストとしてレンダリングしてください。本当にHTMLが必要な場合は、適切にサニタイズしてください。 OBSは何をしているのか OBSチームは、両方の修正が既に進行中であることを確認しました。 最初の修正は、組み込みブラウザのアップグレードです。 主なブロッカーは新しいChrome Runtimeでした。これは、ごく最近までOBSが依存しているオフスクリーンレンダリングをサポートしていませんでした。 Chromium 127は2024年7月に安定版に達しました。これは、OBS 32.2.2のエンジンが現在約2年遅れていることを意味します。 このアップグレードは既に進行中です。obs-browserをCEF 128以上に移行するプルリクエストが現在レビュー中であり、OBS Studio 33.0マイルストーン（obs-browser PR #523、obs-studio discussion #3853）を対象としています。 マージされると、この投稿で使用された特定のV8バグが修正されます。 しかし、OBSは主にボランティアによって維持されているオープンソースプロジェクトであり、このアップグレードをこの段階まで進めるには、数ヶ月のテストと互換性作業が必要です。 2番目の修正は、CEFサンドボックスの有効化です。これも同じアップデートの一部としてテストされています。 当初は、一部のサービス統合の認証を壊したため無効にされていましたが、チームはこれらの問題が現在解決されている可能性があると推測しています。 サンドボックスを再度有効にできれば、ブラウザの悪用だけでは十分ではなくなります。攻撃者はサンドボックスを脱出するために2番目の脆弱性も必要とするでしょう。 その仕事のすべてがレンダリングであるコンポーネントにとって