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

What is tested by pre-launch
(security) reports?
DroidKaigi2017
2017/3/9
aki_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アプリ
0
50
100
150
200
250
300
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 脅威(個人) 2016
1位インターネットバンキングやクレジットカード情報の不正利用 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

調査結果
Fragment Injection
暗号の解読危殆化暗号アルゴリズムの使用(DES)

調査結果
Fragment Injection
暗号の解読危殆化暗号アルゴリズムの使用(DES)
想定していた脆弱性は
ほとんど検出されなかった

ヘルプセンター
検出された項目中で、具体的な修正方法は
ヘルプセンターにリンクされていた。
ヘルプセンター内に
情報があるのではないか？

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

脆弱な実装に関する検索結果
Fragment Injection
・APIレベル18以下でPreferenceActivityを
継承したクラスを使用。
・APIレベル19以上で適切でない
isValidFragmentを設定。
危険な課金トランザクション
(アプリ内課金の脆弱性)
InAppBillingServiceへのBINDでターゲット
のパッケージを指定しない
 再調査したが「ホスト名検証無視」と「WebViewでのSSL
エラーハンドリング不備」しか検出されない。
 「アプリ内課金の脆弱性」以外は公開停止する旨の警告あり。
実際オレオレ証明書でも受け入れ、Fragmentも呼び出せた。

実装による検出/未検出
危険なHostnameVerifierを設定するAPIの内、
setDefaultHostnameVerifierで設定した場
合しか検出してくれない。
 setHostnameVerifierでの設定では検出されない
 ヘルプページの内容には沿っている
 同種の危険な実装でも、全てのパターンを網羅してはなさそう
今回の調査についても全てのパターンを網羅して実装しているわけでは
ないため、検出されなかった脆弱性も実装次第では検出される可能性。
ただし、逆に言えばチェックに通ったからといって安心できない？

「WebViewでのエラーハンドリング不備」で
は、脆弱性の原因となるコードが実際に呼び
出されなくても検出された
一方、「ホスト名検証無視」は
onCreateやonResume等の中から呼び出され
ないと検出されなかった。

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

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

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

pre-launch reportだけに頼るのは困難。現時点で
検出された部分の最終チェックくらいの認識で。
まとめ
それでは脆弱性を作りこまないためにどう
対応するべきか
そもそもセキュアコーディングの知識だけで対策す
るのは現実的ではない。要件定義や設計など、開発
の各工程で必要な対策を検討し、盛り込んでいく。
出来上がったものをツールや診断でチェックする
(開発中からチェックも有効、対象をちゃんと見て)

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

サードパーティー製
ライブラリのチェック
 ライブラリは今回の調査対象外だが、一部チェッ
クしてみた
 バージョン2.5未満のOkHttpには
HTTPヘッダインジェクション脆弱性がある。
 上記のOkHttpから取り込んだコードを使っていた
Androidにも、同様の脆弱性がある。
検出されず
 Cordova4.1.1以前には複数の脆弱性が存在する。
 こちらはGoogleヘルプでの掲載有り
検出！

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

More Related Content

What's hot

Viewers also liked

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