スマートフォンのセキュリティについて

ma.la

http://ma.la

https://twitter.com/bulkneets

LINE株式会社

livedoor方面の人です

• JavaScript, Perl
• 元々の専門領域はUI, フロントエンド
• Webアプリ全般
• 認証認可周り

• 自社サービスのリリース前にチェックしたりとか
• 何か新しい攻撃手法見つかったら調査
• 他社サービスの問題見つけて報告したり
• オープンソースプロダクトのバグ報告したり

そもそも何でJavaScriptを書いてた人間が

セキュリティに関することをやっているのか

• あらゆるデバイスでHTML + JavaScriptが使われている
• どこまで悪用できるのか、どうやって修正すべきなのか
• 社内でもっとも詳しい

• 基本的にはWebの人
• iOS / Android アプリ開発あまり詳しくない
• セキュリティチェックやる関係で覚えている

• livedoor, NAVERのWebサービス
• 最近はLINEに関するあれこれも

--

• サービスリリース前にやること
• QA / セキュリティQA
• 社内ベータリリース

--

• リリース前のレビュー
• 機械的な検査で見つからないような問題を見つける
• ポリシー制定や事故が起きた時の相談に乗ったり

• 個人的に報告を受けたものの調整
• 担当者に伝える or 自分で直す
• livedoorのものは大体直せる
• 修正方法の指示から修正完了の確認まで。

--

• 一個見つけたら複数ある
• 一つの脆弱性について全サービス網羅的に調査

• Google, Facebook, Twitter, Yahoo, Amazon, Evernote, etc
• hatena, mixi, Doorkeeper, 任天堂, etc
• 表立って書いたりするのはXSSが多い
• 個人の活動です。
• たまたま業務時間中に見つけることもありますが個人の活動です

• 単に自分の使ってるサービスが安全か気になる

--

• 自社で見つけた問題は他社にもある
• 他社で見つけた問題が自社にもある
• 持ちつ持たれつ

なんかXSSばっかり探してるみたいに思われたりすることがあるのですが

もっとクリティカルなバグとか色々報告してたりします

• 公開しているのは公開しても良さそうなもの
• 公開しているものより遥かに多く報告している
• アプリの脆弱性 → バージョンアップが浸透するまで話しにくいことがある

• スマホアプリ、モバイルアプリケーションにおけるセキュリティ

LINEの話じゃないですよ！

一般論です

• Webベースの技術が多く使われている
• 今までブラウザ上で起きていたようなことがスマホアプリ内で起きている

• 個人的に色々と発見してきた経験から
• 発見手法や修正方法について
• 安全なアプリを作るためにはどうすればいいのか？

• 通常のWebアプリケーションでの事例をざっくりと

クロスサイトスクリプティング

説明必要？

• 自動エスケープしてれば大体大丈夫です
• テンプレートエンジン側で安全側のポリシー
• それでカバー出来ていない事例に気を使えば良い

• scriptタグ内やonclick属性内にテンプレート変数を埋めこんでいるケース
• 安全にするのが非常に難しいのでやらないで!

• a hrefへの指定 → クリック時にscript実行
• iframe srcへの指定 → ロード時にscript実行
• img srcほか → 昔は実行されたが今は実行されない

• ここらへんは普通のXSS
• 世の中にはまだまだたくさん
• 自社サービスではあまり見かけなくなりました

• jQueryを使っているケース
• 外部ドメインをXHRで読み込めてしまうケース

• 複数のXSS脆弱性の存在
• 旧バージョン使ってるサイトほぼ全部XSS可能
• 公式サイトの利用事例から飛べるページほぼ全部

• location.hashに指定されたパスを読み込んでHTMLの部分書き換え
• jQuery Mobileの基本機能
• 任意のURLをロード可能になっていた → 表示中のドメインの権限で評価される

• 読みこむ前に現在表示中のドメインと一致するかどうか検査するように
• 未だに潜在的な問題はある
• 「同一ドメイン」のリソースはHTMLとして読み込んでも安全だ、という暗黙の前提

• HTMLじゃないものがHTMLとして評価される問題
• 以前は IE限定の問題として存在
• X-Content-Type-Options: nosniff

• テキストファイル
• 画像(のコメント部分にHTML)
• JSON、CSV etc
• HTMLじゃないものがHTMLとして評価される
• リダイレクタなどが絡むと話がややこしくなります

• Ajax + history.pushState で高速に画面切り替え
• githubでやってるようなやつ

--

• jQuery Mobileと同様の問題
• ユーザーがサイト内の任意のURLにリンクを貼れるようなケース
• やや特殊だが十分に有り得る(潜在的XSS)
• 対応: htmlのみ受け入れ、リダイレクトを拒否
• Rails プチコミッター

• 最近アツいと話題の
• 振る舞いを記述していい感じにMVCしてくれるやつ
• https://code.google.com/p/mustache-security/wiki/AngularJS
• ユーザーがclass名を自由に書けるようなケース？？？
• 流石になさそうだけど今後問題になるかも
• むしろ Content Security Policy bypass としてのリスク

• リッチテキストエディタのiframe内でのXSS
• TinyMCEや、その派生プロダクト
• 最近多数報告

• livedoor Blog
• NAVERのサービス

• wordpress.com XSS 修正済み
• Movable Type XSS 修正済み
• ほかにも調整中のいくつか

• 解釈にブレが生じるようなHTMLを入力する
• サーバー側やJSのフィルタをすり抜ける。
• 禁止されてるはずのタグが通る!

• 普通のXSSは見つかりにくくなっている
• Flash based XSSがアツい!
• 事例についてまとめてます
• http://subtech.g.hatena.ne.jp/mala/20130604/1370328779

• ExternalInterface.call
• htmlText によるタグ出力
• 外部swfのロード

• 今さらどうしようもない
• 今からFlash書く人はあまりいない
• 必要とされてるケースで適切なライブラリを使う
• メンテされてるライブラリかどうかの選定が大事

• swfupload
• zeroclipboard
• 動画プレイヤーあれこれ

• videoタグのfallbackとしてFlash
• まだ必要とされる状況

• ぶっちゃけ全部ダメだった
• あれもこれも全部XSSがある
• JWPlayer, Video-js, mediaelement, flowplayer, etc
• 古いバージョン使った覚えがあるなら更新を。

• すごくたくさん
• ブログに書いてから気付いたものもあり

• IPA脆弱性報告窓口に届出
• 調整中

• Flash側でのイベントをJavaScriptに通知
• 呼ばれる関数をカスタマイズ出来るようになっているものが多い
• some_swf?debug=function(){alert(/XSS/)}
• そもそもFlash → JSへの引数受け渡しの際の処理がバグってたりする

• Player側で直すべきバグが直らない
• 時として互換性のために不適切な仕様のまま放置
• 多くのswfが古いバージョンのママ放置されている

• だいたいこんな感じ

• 脆弱性の発生しやすいポイントは同じ
• WebView + XSS
• CSRFに似たもの(Cross-Application request forgeries)
• 他言語とのブリッジ機能

• Webベースのもの
• HTML5ベースのもの
• プラットフォーム固有のUIコンポーネント使うもの

• スマホ向けのWebサイト
• あるいはそれを表示するだけのアプリ

• ローカルのHTML5 + JSで作られているもの
• プラットフォームネイティブのUIコンポーネントで作られているもの
• いずれにせよ内部ではhttp/https使ってることが殆ど

• 結局のところ特定サービス向けの専用ブラウザ
• であることが非常に多い
• Webの技術、ノウハウが流用できる
• HTML/JSを調査することで脆弱性を見つけられる
• Webで起きてることはスマホアプリ上でも起きる

• 通信をキャプチャして調べる
• アプリケーションの保存しているデータを調べる
• ソースコードから調べる(自社アプリ)
• リバースエンジニアリング(Android)

• 最近はもっぱらmitmproxyというのを使ってます

• http://mitmproxy.org
• pythonで書かれたproxyサーバー
• 端末にルート証明書を入れてHTTPSの通信をキャプチャ

• WiFi立てるの面倒なのでVPN経由で使えるようにしてある
• VPN有効に → 80,443の全ての通信をmitmproxyの透過プロキシ経由に。
• iOSでもAndroidでもVPNの設定はあまり難しくない

• 社内で開発用にWiFiアクセスポイント作る人多すぎ
• 干渉して無線つながりにくくなる
• 野良WiFi禁止令が出た

• 内部で叩いているAPI → これ直接アクセスしたらどうなるんだろ？
• 平文通信 → 改竄された場合の影響はどの程度？
• アクセス解析やトラッキングで送られているデータ

• 端末とUSBケーブルで接続してマウント
• 保存されているファイルを調べたり書き換えたり
• ディレクトリ構成を調べる → 個人情報が保存されてそうなファイルを見つける
• アプリ内の脆弱性でファイルが読めないか調べる

• apkの逆コンパイル
• 自社アプリのソースコードから
• 最も効率がよく網羅的に調べられる

• 大体こんな感じ

• 自分が発見報告してきたもの

Sparrow, Mailbox, Boxcar, LINE, NAVER, Google, etc

• HTMLメール表示機能でscript実行可能な事例が多数
• Sparrow
• Mailbox

• 評判の良いメールクライアント
• Googleに買収された
• その少し前にちょうどバグ報告していた

• とあるサービスの名前の設定にHTMLタグを入れていた
• お知らせメールの件名部分でタグが有効になっていた
• 怪しいと思って検証
• ブラックリストでの制限だった

--

• audioやvideo用の新しいイベントハンドラ
• 既存のブラックリストに書いてない → 通る
• OSXで問題があったのでiOSバージョンも調べる
• 同様にメール表示画面でJavaScript実行可能だった

• JavaScriptからメール本文の入っているsqliteファイルにアクセス可能だった
• 受信した全てのメールを盗み取ることが可能
• iOS5ではアドレス帳のデータベースファイルの読み取りも可能

• 権限の強いUIWebViewでメールを表示している
• BaseURLが無指定 or file://
• そのアプリのDocumentにアクセス可能になる

• Dropboxに買収された
• Gmail用クライアント、OAuth使ってサーバーサイドで受信している
• Mailboxのサーバー側でタグをフィルタ可能
• 海外で問題を指摘されてサーバー側でのフィルタで対応していた

• 2013年9月
• HTMLメール内でのJavaScript実行の問題が指摘される
• http://miki.it/blog/2013/9/24/mailboxapp-javascript-execution/

"As many have noted, the real risks presented by running javascript within Mailbox are extremely limited thanks to how iOS is designed."

多くの人が指摘してるようにMailbox上でのjavascript実行によるリスクは極めて限定的です、iOSの設計に感謝

"extremely limited" "thanks to how iOS is designed."

お前は何を言っているんだ

• 動画とって長文書いてる暇あったら alert(location) を書け
• 影響範囲を適切に把握することが必要

• バグ報告に動画はいらない
• Google: デモ動画より短い実証コード

--

• 公式ブログで「sandboxによって影響は極小」とアナウンス
• 正直この段階では、分からない
• 「あ、こいつ分かってなさそう」→ 調べる

• 元の報告者: 抜けがあって再度修正、という記事
• まだまだ抜け穴あるんじゃないの？
• → ここでHTMLパーサの挙動の違いによるXSS

• 変なタグたくさん作って試す
• 普通のメーラーでは送れないことが多い
• HTMLメール送信script書く or メーラの送信待ちファイルをエディタで編集

    <!--> 
    < script>  your code here < /script>
    -->

    <!--> 
    < script>  your code here < /script>
    -->

• HTMLパーサライブラリの多くはコメントとして解釈
• 実際のブラウザでは一行目でコメント終了と見なす
• 知らないと気付かない

• ブラックリストは危険です
• パースして、正規化したHTMLを再構成すること

• SparrowもMailboxもUIWebView内でJavaScriptが実行できた
• 実際のところどこまで出来たのか？
• セキュリティ研究者もリスクを正しく認識出来ていない
• 元の報告者は「Jailbreakされてるデバイスで危険」と主張

• iOS関係でよく聞くフレーズ。
• Jailbreakはマジで関係ないです
• WebKitのバグをついたら危険 → それはWebKitのバグです

• BaseURLによる
• UIWebViewのBaseURLです

JS実行出来るだけで危険だったらブラウザが危険

どういう権限、コンテキストで動いてるのかが重要

Mailboxの場合

file:// で動いてる!!

なんかまずそう

1. データを保存してるパスを調べる(iPhone Explorer等)
2. JSからファイル読み取るコードを書く
3. ファイルサイズ取れれば成功
4. リモートにデータ送るコードを書く

• SparrowもMailboxも強い権限のWebViewで動作。
• 「受信済みメールを全て盗み出せることが出来る脆弱性」だった

• Mailbox Appの問題は修正された
• そもそも「WebViewの権限を制限したほうが良い」とアドバイス
• 「ブログ記事を訂正したほうが良い」ともアドバイス

--

Dropboxの容量増えた

10GB

--

今時10GB? と文句言ったら

100GB 増えた

• スマホアプリ中でのXSS
• 自分のブログで解説記事を書く
• しかし自社やグループ会社のアプリで同等の問題
• 同じ説明を繰り返す日々
• oh..

• 強い権限を持つWebViewでのJavaScript実行
• 開発元: sandboxで制限されると主張
• 実際は: メールのデータベース全部読める、iOSのアドレス帳読める
• 開発者がリスクを正しく認識できていない

• どこまで悪用できるか調べることまでセット
• "JavaScriptが実行できるバグ" なのか "個人情報を盗み出せる脆弱性" なのか

--

• 最初は自分も「そんなことできんの？？」だった
• プラットフォーム毎にリスクは異なる
• そのプラットフォーム上のバリバリ現役開発者じゃないと分からない
• そういう人がセキュリティに興味ないと → 情報出まわらない
• laisoさんというひとが調べてくれた
• http://d.hatena.ne.jp/laiso+iphone/20111003/1317651353

• addressbook.sqlitedb
• iOS5: file:// からであれば許可無く読み込めた
• iOS6: アプリが一度アドレス帳を読み込んだ後なら読み込めた
• iOS7: file:// で直接アクセスが不可能になった

• UIWebView上のJavaScriptからローカルファイルが読める
• そのアプリのドキュメントならOK
• OSのアドレス帳のsqliteファイル読める意味がどこに？
• アップルに問い合せてみたり。

--

• 俺「なんでJavaScriptからアドレス張読めちゃうの？」
• ア「それはアプリ側の問題です、こちらのセキュアコーディングに関する講演動画を・・・」

--

• 俺「iOS7 betaでは直ってるみたいなんだけど」
• ア「iOS7 ではSandboxの強化が行われて・・・」

--

• 完全な修正はiOS7以降

• Sandboxが何を保護するものなのか理解すること
• アプリケーションごとのプロセスの分離
• iOSの設計に感謝する前に調べましょう

• 「別プロセス」から干渉できなくすること
• 自分自身の保持しているデータは多くの場合、当然に読める

• addJavascriptInterfaceの問題
• WebViewを使っているアプリの非常に多くが影響を受ける
• 参考: http://ierae.co.jp/uploads/webview.pdf

• JavaScriptからアプリ側の関数を呼び出すためのブリッジ
• 本来開発者の指定したメソッドしか呼び出せないとおもいきや
• Javaのリフレクションを使って任意のメソッド呼び出し可能

--

• 使ってなければ問題ない？

--

• Androidの古いバージョンでは(Android 3 - 4.1)
• 標準のWebViewコンポーネントがデフォルトでaddJavascriptInterfaceを使用
• addJavascriptInterface使った覚えがなくても問題が起きる!!
• WebView組み込んでるだけで問題がある
• こりゃ大変

• アプリが任意のWebページを表示できる = そのアプリの権限で任意コード実行可能
• 通信が改竄されている = そのアプリの権限で任意コード実行可能
• 冗談みたいだけど本当の話

• 昨年末に問題について調査
• 権限の弱いアプリでも: アプリケーション一覧の取得などが可能
• 権限の強いアプリ: アドレス帳読み込み、SMS送信 etc

• 公になってないだけ
• セキュリティ関係者は知ってる
• ちょっと調べれば実証コード手に入る

• WebView使ったブラウザアプリ
• いくつかのアプリで検証
• Android4.1以下で脆弱なもの
• Android4.2以降でも脆弱なもの

• アプリ開発者は殆ど悪くない
• 標準のWebViewをそのまま使ってるだけで危険
• 他の権限昇格系のバグと組み合わせればWebサイト開いただけで完全掌握

• いくつか把握
• ブラウザ独自の機能や拡張機能のために、addJavascriptInterfaceを使用

• Android API Level 17 での変更

• 指定したメソッドしか呼び出せないようにすることが可能に

• http://commonsware.com/blog/2013/02/18/webview-addjavascriptinterface-change.html

• http://android-developers.blogspot.jp/2013/02/security-enhancements-in-jelly-bean.html

• 動作対象デバイスが限られることになってしまう

• されている、はず
• ApplicationのContextオブジェクトを取得することが出来たクラスが無くなってる
• 他にも抜け道があるかもしれない [要調査]

• 広告配信用のSDK(殆どHTMLだよね)
• 回線が信用出来ない状況下でも安全にしたければ、全通信SSL必須に

• 古いAndroidでもなんとか出来ないこともない
• Chrome/Operaは実際に影響受けない(標準WebView使ってないから)
• 独自でWebKit組み込むとか、うまいこと上書きするとか。
• OS側のバグにどこまで対処すべきかという問題

• 影響広範すぎるのでOS側で対処してくれるのが望ましいが・・・
• 現実的にアップデート困難な端末が多数ある
• 「IEの問題だろ！！」と言いつつ対応してきた歴史と似てる

• シングルサインオンとか
• Webサイト間
• アプリケーション間

• 強制的に認可させてしまうようなもの
• 他人に成りすましてログイン出来てしまうもの
• 正規のアプリ以外に強制的に認可できてしまうもの

• ライブラリ使って普通に実装しただけ、で現状防げてない問題がある

• そのユーザー用の「別アプリ」のアクセストークンをアプリに入力
• カスタムURLスキームで受け渡す
• ユーザー情報取得 → ログインに使用
• 悪意のあるアプリ開発者が別アプリに成りすましログイン可能になる

• 「そのアプリ用に発行されたtokenかどうかの確認」
• http://oauth.jp/blog/2012/02/08/ios-sdk/

• アプリケーション間の遷移を調べる
• 呼び出し元のアプリを調べて、検証する
• 概ね安全
• 抜け道がある

• 2013年7月: Android OS においてアプリの署名の検証が不十分な脆弱性
• 古い端末 + 野良アプリを考慮する場合: package signatureが宛にならない
• 正規のアプリに限定したい処理が野良アプリからでも叩けることに

• openURLで他のアプリケーション起動
• 呼び出し元アプリのBundle IDを取れる
• WebView内のリンククリックでも付いちゃうよ
• 任意のWebページを表示するような機能があるなら呼び出し元アプリ情報はアテにならない

• 概ねその通り。

• 不自由なマーケットに依存したセキュリティ

• App Store, Google Playに配布形態が限定

• この考えで行くとアプリ自由に開発/配布できない世の中になってしまう

• 重要な処理は必ずユーザー操作を介在させたほうが良い
• 信用できるアプリ同士に限定したつもりであっても
• 本当に限定できてる？

• 後から方向修正が困難。古いバージョンのアプリが残ると厄介。
• SDKとして配布 → 古いバージョンが市場に残り続ける
• 最初から正しい設計指針を持つことが大事

• バージョンアップ機構と適切なアナウンス
• 処理を完全にアプリ内で完結させると危険
• サーバーサイドで修正できる余地を残しておく

• 古いバージョンが残っているので詳細を公開できない
• security fix なのに bug fix と告知
• 深刻なバグは強制バージョンアップの仕組みを。
• サーバー側で対処できるような仕組みのほうが安全？

• Gmailを一度Mailboxのサーバー経由で受信
• そのためサーバー側でのフィルタでも対応できる
• その気になれば運営者からメールを盗み見ることが出来てしまう
• データがどこに保存しているのか曖昧な世界

サーバーサイドから実行コードすら更新できるようになっていたほうが

迅速にバグ修正できるけれど、

それはそれで安全かどうかの検証も不可能な世界

• 権限の強いWebViewにリモートのHTMLやJSが読み込まれる
• そのアプリケーションが安全か、信用できるか、単体で分からない
• 解析しても動的に受信するソースとセットじゃないと判断できない

--

• 第三者による安全性の担保が困難
• ユーザーから見て安全かどうか判断が難しい

• これまで発見、対処してきた経験から

• JavaScriptフィルタする前にWebViewの権限落とせ

• JavaScriptをフィルタするのが対策
• WebViewの権限を落とすのが保険的対策、フェイルセーフ設計

• バグがあっても安全にするのがフェイルセーフ
• "適切な権限"で動いてないのは、そもそもおかしい

• root権限で何もかも動いてるようなもの
• 適切な権限で動かすのがまず大前提

--

• ファイルパーミッション
• WebであればSame origin policy
• 原始的な保護機構は枯れててバグも少ないことが期待できる

• ユーザーが怪しいWiFi使った
• ユーザーが携帯電話落とした
• 「自己責任でしょ」と言いたいところ

• 回線が信用できなくても安全にするのが目的
• その前提に立たなければ意味が無い

--

• ストレージ上の暗号化
• 解読されるまでの時間稼ぎ
• 物理的に盗まれても大丈夫なようにするのが目的

• Android + WebViewの脆弱性
• 通信が改竄されてる場合にアプリの権限で任意コード実行

• 特定のSSIDで自動接続するような設定の端末が非常に多い
• 罠仕掛けようと思えば簡単

• ケースバイケース
• 判断できなかったらとにかくHTTPS使ったほうがいい

• 画像や動画なら。
• Mozilla の Active/Passive content 判断を参考に
• https://developer.mozilla.org/en-US/docs/Security/MixedContent

--

• あるいは署名やハッシュ値の検証とセットでHTTPを使う
• アプリケーション本体に検証処理を組み込めばいい

• iOS5,6: アプリ内XSSでOSのアドレス帳が読める
• Android: 標準WebView使ってるアプリ全般が危険

• ユーザーは実際に古いバージョンのOSを使ってる
• アップデート困難な端末が多数市場に残っている

Webの場合

• geocitiesでJavaScript書けても「脆弱性だ」とは言わない
• 本来動いちゃいけないscriptが動かせたらXSS

--

スマホの場合

• 保護すべき機密情報を持たないアプリでも
• アドレス帳が読めてしまったりOSの機能を叩けたり
• 通信が改竄された場合の影響が無視できないほど大きかったり

• アプリ入れても入れなくても起こる問題ならOSの問題
• そのうちOS側のバージョンアップで勝手に安全に？？
• あまり期待しないほうがいい
• そのアプリ固有で増加するリスクは対処した方がいい

--

• 影響の大きい問題は個々のアプリが対策してくれないと悪循環になる
• 公表されない → 周知されない → 個人の開発者は全く知らない
• WebViewに起因する問題
• セキュリティ関係者は知ってるけど開発者が殆ど知らないのでは。

以上

質疑応答