What is tested by pre-launch (security) reports?

DroidKaigi20172017/3/9aki_sh_7

自己紹介

aki_sh_7(塩田 明弘)

株式会社NTTデータセキュリティ技術部 所属

社内のモバイルアプリ開発者向けのセキュリティガイドライン作成やサポート)に従事

注意事項本セッションの内容は所属会社の見解を表すものではありません。

pre-launch reportsの調査結果は、2017/3/5時点のものとなります。過去や将来の検出結果と異なる可能性があることをご了承ください。

目次1. Androidアプリと脆弱性

2. pre-launch reportsの登場

3. What is tested by pre-launch (security) reports?

4. まとめ

1. Androidアプリと脆弱性

増え続けるAndroidアプリ

050

100150200250300

Jan-13 Jan-14 Jan-15 Jan-16

Google Playのアプリ数[1]

130%123%

163%

[1] Statista, Number of available applications in the Google Play Store from December 2009 to December 2016,https://www.statista.com/statistics/266210/number-of-available-applications-in-the-google-play-store/

[単位：万本]

スマホアプリを狙った攻撃も増加？

2017 脅威(個人) 20161位 インターネットバンキングやクレジットカード情報の不正利用 1位2位 ランサムウェアによる被害 2位3位 スマートフォンやスマートフォンアプリを狙った攻撃 3位4位 ウェブサービスへの不正ログイン 5位5位 ワンクリック請求などの不当請求 4位6位 ウェブサービスからの個人情報の窃取 7位7位 匿名によるネット上の誹謗・中傷 6位8位 情報モラル不足に伴う犯罪の低年齢化 8位9位 インターネット上のサービスを悪用した攻撃 10位10位 IoT機器の不適切管理 圏外

2016年版は「審査をすり抜け公式マーケットに紛れ込んだスマートフォンアプリ」という文言

[2] IPA, 情報セキュリティ10大脅威 2017, https://www.ipa.go.jp/security/vuln/10threats2017.html

IPAのセキュリティ10大脅威でもランクイン

なくならない脆弱性指摘の多いのがSSL証明書検証不備→中間者攻撃が行われる可能性

2014年にIPAが注意喚起[3](米国CERT/CCが本脆弱性を多数検出)

一方、この脆弱性のあるアプリの割合が2015年に43%となり、2013年の39%より悪化したとのレポートもある。[4]

[3] IPA,プレス発表 【注意喚起】HTTPSで通信するAndroidアプリの開発者はSSLサーバー証明書の検証処理の実装をhttps://www.ipa.go.jp/about/press/20140919_1.html[4] Sony Digital Network Applications, Inc, Android脆弱性レポート2015, https://www.sonydna.com/sdna/solution/report02.html

なくならない脆弱性

この証明書変だな

攻撃者は通信を盗聴しようと、接続要求に割り込み、サーバの証明書の代わりに自分の証明書を送りつける

ユーザ

攻撃者

~~~~~~~~~

~~~~~~~~~

本来の想定~~~~~~~~~

サーバ

証明書検証やエラーのハンドリングに不備が無ければこのまま接続を開始してしまうことはない

なくならない脆弱性情報GET!

ユーザは自分に送られた証明書が攻撃者のものと気付いていない。

ユーザ サーバ

攻撃者~~~~~~~~~

~~~~~~~~~

ユーザは途中経路で見られないように送ったつもり実際は攻撃者が盗聴している

ID・パスワード個人情報etc･･･

脆弱性があると･･･

実際に被害が出てしまうと

[5] ソフトウェア情報センター, SOFTIC 判例ゼミ 2014-5, http://www.softic.or.jp/semi/2014/5_141113/op.pdf

お客様(ユーザ)が被害にあってしまう

受託開発の場合、委託元からの訴訟等セキュリティ対策が要件になくても敗訴した[5] SQLインジェクションで情報漏洩した事例で、経産省やIPAが注意喚起していたため、専門家として対応必須と判断

今後のビジネスへの影響サービス継続への影響(ユーザを失う)、損害賠償、評判・信用の失墜、改修やその他対策費用、等々

脆弱性対策しよう！

検査ツールや診断サービスで、脆弱性が作りこまれてないか確認しよう!

セキュアコーディングガイド等を定めて、則った開発

をしよう!

The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.

脆弱性対策しよう！(現実)

ツールも診断サービスも結構いいお値段するよね

ガイドは広範囲に渡り、開発者が把握するのが大変

そもそもガイドに気付いてもら

えない

The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.

でも中々乗り越える壁が多いです

2. pre-launch reportsの登場

pre-launch reportsの登場2016年のGoogle I/Oで発表された、アプリ開発をサポートしてくれる機能

オプトインしておくと、α版、β版のAPKをコンソールにアップロードした際に、自動的にチェックしてくれる。チェック対象は以下の3つ

• クラッシュ• スクリーンショット• セキュリティ

pre-launch reportsの登場2016年のGoogle I/Oで発表された、アプリ開発をサポートしてくれる機能

オプトインしておくと、α版、β版のAPKをコンソールにアップロードした際に、自動的にチェックしてくれる。チェック対象は以下の3つ

• クラッシュ• スクリーンショット• セキュリティ

!!

pre-launch reportsの利点ストアへのアプリアップロードと同じ環境(コンソール)でチェックしてくれる

なにより無料

ストア掲載するアプリであれば漏れずに受けさせやすい

チェックにかかる追加コストが抑えられる

pre-launch reportsの疑問点何をチェックしてくれるのか

[6] Google Play デベロッパー ヘルプ,リリース前レポートを使って問題を特定する, https://support.google.com/googleplay/android-developer/answer/7002270[7] Google Developer Japan, I/O 2016 で発表した Google Play の新機能, https://developers-jp.googleblog.com/2016/05/io-2016-google-play-play-console.html

発表時点では、侵入される恐れがある、セキュリティ上の既知の脆弱性(サードパーティー製のライブラリ含む)とのこと[7]

3. What is tested by pre-launch (security) reports?

既存の調査済みチェック項目shibuya.apk#8 GoogleI/O報告会[8]くらい?○WebViewでのSSLエラーハンドラ実装×不要なコンポーネントの公開(exported=true)×LogCatへの出力×脆弱なアルゴリズムによる暗号化(DES等)×SSL3.0によるHTTPS接続×証明書検証の無効化×ホスト名検証無視×不要なsetJavascriptEnabled(true)×addJavascriptInterface()に起因する脆弱性×不要なパーミッション

[8] Kengo Suzuki, Intro to Pre-Report “The Security”, https://speakerdeck.com/ken5scal/intro-to-pre-report-the-security

既存の調査済みチェック項目shibuya.apk#8 GoogleI/O報告会[8]くらい?○WebViewでのSSLエラーハンドラ実装×不要なコンポーネントの公開(exported=true)×LogCatへの出力×脆弱なアルゴリズムによる暗号化(DES等)×SSL3.0によるHTTPS接続×証明書検証の無効化×ホスト名検証無視×不要なsetJavascriptEnabled(true)×addJavascriptInterface()に起因する脆弱性×不要なパーミッション

[8] Kengo Suzuki, Intro to Pre-Report “The Security”, https://speakerdeck.com/ken5scal/intro-to-pre-report-the-security

全然検出されてないけど、他の脆弱性なら検出してくれるよね？

新たな調査対象の選出Google I/O 2016では、うっかり作りこんだアンチパターンも見ているという話。

日本スマートフォンセキュリティ協会の「セキュアコーディングガイド」[9]から対象を以下の条件で選出することとした。

[9]日本スマートフォンセキュリティ協会, 『Androidアプリのセキュア設計・セキュアコーディングガイド』2017年2月1日版, https://www.jssec.org/dl/android_securecoding.pdf

アプリ要件によらず脆弱なもの

セキュリティ上の問題で非推奨・廃止になったもの

調査対象脅威 脆弱性・原因PreferenceActivityのFragment Injection

・APIレベル18以下でPreferenceActivityを継承したクラスを使用。・APIレベル19以上で適切でないisValidFragmentを設定。

不審なアプリによるBroadcast受信 Sticky Broadcastの使用アプリ固有領域にあるディレクトリ・ファイルへ他アプリからアクセス可能

MODE_WORLD_READABLE/MODE_WORLD_WRITABLE設定

SQLインジェクション 入力値を直接連結したSQL文の生成HTTPヘッダインジェクション URLconnectionで入力値からHTTPヘッダ作成(Android2.2～6.0)暗号の解読 危殆化暗号アルゴリズムの使用(DESとか)WebViewによる危険なファイル読込 WebViewのURIへのファイルスキーマ設定WebViewによるスクリプト実行 アクセス先を限定できない状況でのsetJavascriptEnabled(true)WebViewによる任意のコード実行 addJavascriptInterface()に起因する脆弱性中間者攻撃 証明書検証の無効化、ホスト名検証無視

WebViewでのSSLエラーハンドリング不備独自定義パーミッションの実質無効化 Normal、Dangerousレベルの独自パーミッション定義タスク履歴からのIntent情報読取り ルートActivityへのIntent送信(Android5.0未満)

再

再

再

再

再

具体例：MODE_WORLD_WRITEABLE

データ保存系APIで設定できる公開モードのうち、MODE_WORLD_WRITABLE/READABLEはファイルパーミッションを662、664に設定する。

APIレベル17で非推奨、24でSecurityException “Creating world-writable files is very dangerous,

and likely to cause security holes in applications”とのことなのでこれは検出されそう

具体例：MODE_WORLD_WRITEABLE

検出されず･･･

具体例：中間者攻撃中間者攻撃の原因として、以下の3つが対象 WebViewでのSSLエラーハンドリング不備 証明書検証の無効化 ホスト名検証無視

既存調査結果がある内容だが、更新があるか確認

WebViewでのSSLエラーハンドリング不備

エラーが起きてもそのまま処理

具体例：中間者攻撃証明書検証の無効化ホスト名検証無視

ホスト名の検証しない

証明書チェーンの検証しない

具体例：中間者攻撃過去事例と比べて、ホスト名検証無視が検出されるようになっている

具体例：中間者攻撃具体的な修正方法はリンク先から確認可能

[10] Google ヘルプ, HostnameVerifier の脆弱性の問題を回避する方法, https://support.google.com/faqs/answer/7188426?hl=ja[11] Google ヘルプ,アプリで WebView SSL エラーハンドラの通知を処理する方法, https://support.google.com/faqs/answer/7071387?hl=ja

調査結果脅威 脆弱性・原因PreferenceActivityのFragment Injection

・APIレベル18以下でPreferenceActivityを継承したクラスを使用。・APIレベル19以上で適切でないisValidFragmentを設定。

不審なアプリによるBroadcast受信 Sticky Broadcastの使用アプリ固有領域にあるディレクトリ・ファイルへ他アプリからアクセス可能

MODE_WORLD_READABLE/MODE_WORLD_WRITABLE設定

SQLインジェクション 入力値を直接連結したSQL文の生成HTTPヘッダインジェクション URLconnectionで入力値からHTTPヘッダ作成(Android2.2～6.0)暗号の解読 危殆化暗号アルゴリズムの使用(DES)WebViewによる危険なファイル読込 WebViewのURIへのファイルスキーマ設定WebViewによるスクリプト実行 アクセス先を限定できない状況でのsetJavascriptEnabled(true)WebViewによる任意のコード実行 addJavascriptInterface()に起因する脆弱性中間者攻撃 証明書検証の無効化、ホスト名検証無視

WebViewでのSSLエラーハンドリング不備独自定義パーミッションの実質無効化 Normal、Dangerousレベルの独自パーミッション定義タスク履歴からのIntent情報読取り ルートActivityへのIntent送信(Android5.0未満)

調査結果脅威 脆弱性・原因PreferenceActivityのFragment Injection

・APIレベル18以下でPreferenceActivityを継承したクラスを使用。・APIレベル19以上で適切でないisValidFragmentを設定。

不審なアプリによるBroadcast受信 Sticky Broadcastの使用アプリ固有領域にあるディレクトリ・ファイルへ他アプリからアクセス可能

MODE_WORLD_READABLE/MODE_WORLD_WRITABLE設定

SQLインジェクション 入力値を直接連結したSQL文の生成HTTPヘッダインジェクション URLconnectionで入力値からHTTPヘッダ作成(Android2.2～6.0)暗号の解読 危殆化暗号アルゴリズムの使用(DES)WebViewによる危険なファイル読込 WebViewのURIへのファイルスキーマ設定WebViewによるスクリプト実行 アクセス先を限定できない状況でのsetJavascriptEnabled(true)WebViewによる任意のコード実行 addJavascriptInterface()に起因する脆弱性中間者攻撃 証明書検証の無効化、ホスト名検証無視

WebViewでのSSLエラーハンドリング不備独自定義パーミッションの実質無効化 Normal、Dangerousレベルの独自パーミッション定義タスク履歴からのIntent情報読取り ルートActivityへのIntent送信(Android5.0未満)

調査結果脅威 脆弱性・原因PreferenceActivityのFragment Injection

・APIレベル18以下でPreferenceActivityを継承したクラスを使用。・APIレベル19以上で適切でないisValidFragmentを設定。

不審なアプリによるBroadcast受信 Sticky Broadcastの使用アプリ固有領域にあるディレクトリ・ファイルへ他アプリからアクセス可能

MODE_WORLD_READABLE/MODE_WORLD_WRITABLE設定

SQLインジェクション 入力値を直接連結したSQL文の生成HTTPヘッダインジェクション URLconnectionで入力値からHTTPヘッダ作成(Android2.2～6.0)暗号の解読 危殆化暗号アルゴリズムの使用(DES)WebViewによる危険なファイル読込 WebViewのURIへのファイルスキーマ設定WebViewによるスクリプト実行 アクセス先を限定できない状況でのsetJavascriptEnabled(true)WebViewによる任意のコード実行 addJavascriptInterface()に起因する脆弱性中間者攻撃 証明書検証の無効化、ホスト名検証無視

WebViewでのSSLエラーハンドリング不備独自定義パーミッションの実質無効化 Normal、Dangerousレベルの独自パーミッション定義タスク履歴からのIntent情報読取り ルートActivityへのIntent送信(Android5.0未満)

想定していた脆弱性はほとんど検出されなかった

ヘルプセンター検出された項目中で、具体的な修正方法はヘルプセンターにリンクされていた。

ヘルプセンター内に情報があるのではないか？

ヘルプセンター「脆弱性」で検索して実装に関するものを抽出(ライブラリは今回対象外)

脆弱な実装に関する検索結果脅威 脆弱性・原因PreferenceActivityのFragment Injection

・APIレベル18以下でPreferenceActivityを継承したクラスを使用。・APIレベル19以上で適切でないisValidFragmentを設定。

中間者攻撃 証明書検証の無効化、ホスト名検証無視WebViewでのSSLエラーハンドリング不備

危険な課金トランザクション(アプリ内課金の脆弱性)

InAppBillingServiceへのBINDでターゲットのパッケージを指定しない

再調査したが「ホスト名検証無視」と「WebViewでのSSLエラーハンドリング不備」しか検出されない。

「アプリ内課金の脆弱性」以外は公開停止する旨の警告あり。実際オレオレ証明書でも受け入れ、Fragmentも呼び出せた。

実装による検出/未検出危険なHostnameVerifierを設定するAPIの内、

setDefaultHostnameVerifierで設定した場合しか検出してくれない。 setHostnameVerifierでの設定では検出されないヘルプページの内容には沿っている

同種の危険な実装でも、全てのパターンを網羅してはなさそう今回の調査についても全てのパターンを網羅して実装しているわけではないため、検出されなかった脆弱性も実装次第では検出される可能性。ただし、逆に言えばチェックに通ったからといって安心できない？

実装による検出/未検出「WebViewでのエラーハンドリング不備」では、脆弱性の原因となるコードが実際に呼び出されなくても検出された

一方、「ホスト名検証無視」はonCreateやonResume等の中から呼び出されないと検出されなかった。

実装による検出/未検出ただし、イベントリスナーの中でonClickイベント等から呼び出した場合には検出されない。

検出される 検出されない

onClickの中で呼んだ場合は未検出

4. まとめ

まとめpre-launch reportsのセキュリティ機能は、今回の調査では、中間者攻撃の原因となる脆弱性の一部のみ検出するという結果となった。検出されなかった項目は対応しなくてOK？

まとめpre-launch reportsのセキュリティ機能は、今回の調査では、中間者攻撃の原因となる脆弱性の一部のみ検出するという結果となった。検出されなかった項目は対応しなくてOK？検出されなかったものも、危険という事で非推奨になったり、削除されたりしているものがある。Googleヘルプに掲載されているものも検出されておらず、実装方法によって検出結果にムラがあると思われる。アプリの要件によって検討すべき事項も多い。

(exportedやファイル保存場所等)

pre-launch reportだけに頼るのは困難。現時点で検出された部分の最終チェックくらいの認識で。

まとめそれでは脆弱性を作りこまないためにどう対応するべきか

そもそもセキュアコーディングの知識だけで対策するのは現実的ではない。要件定義や設計など、開発の各工程で必要な対策を検討し、盛り込んでいく。

出来上がったものをツールや診断でチェックする(開発中からチェックも有効、対象をちゃんと見て)

ご清聴ありがとうございました

おまけ

サードパーティー製ライブラリのチェックライブラリは今回の調査対象外だが、一部チェックしてみた

バージョン2.5未満のOkHttpにはHTTPヘッダインジェクション脆弱性がある。

上記のOkHttpから取り込んだコードを使っていたAndroidにも、同様の脆弱性がある。検出されず

Cordova4.1.1以前には複数の脆弱性が存在する。こちらはGoogleヘルプでの掲載有り

検出！