IPAにアンドロイドアプリの脆弱性報告をした話

IPAにアンドロイドアプリの脆弱性報告をした話

A+ a-

昨日(2016/5/30)日、IPAより「DMM.com証券製の複数の Android アプリにおける SSL サーバ証明書の検証不備の脆弱性」が公開されました。


https://jvn.jp/jp/JVN40898764/

今回この脆弱性は、リスクファインダー株式会社から報告させて頂きましたので、この件につきまして経緯や脆弱性報告手順について記載したいと思います。

SSLサーバ証明書の検証不備の脆弱性は、前から定期的に報告されていますが、なかなか減りません。アンドロイドアプリの脆弱性検査ツールを販売していていつも思うのは、自分の会社のソフトは大丈夫と思い込んでいる人が多い事です。
特に銀行や証券会社等は、お金を取り扱う会社ですので、セキュリティホールが見つかると顧客の資産に影響を与えます。
今回はDMM.com証券での脆弱性でしたが、過去には

まだまだありますが、スマホによるプライバシー情報の流出どころの話ではありません、ログインIDとパスワードが流出すると金銭を取られてしまうような業界のアプリで脆弱性が見つかっております。

既に上記のような事例が出ていますし、IPAから「プレス発表　【注意喚起】HTTPSで通信するAndroidアプリの開発者はSSLサーバー証明書の検証処理の実装を」といった形で注意喚起まで出ているので、てっきりこれらの金銭を取り扱う業界は、きちんとセキュリティ会社によるチェックをしており、まれに、このような脆弱性が出てくると思っていましたが、今年の５月頃に偶然上記リストにはない銀行のアプリのSSLサーバ証明書検知不備の脆弱性を見つけました。(報告修正済）同じ会社の別のアプリを調べるとこれもSSLサーバ証明書検知不備の脆弱性…。
SSLサーバー証明書不備の脆弱性は、検知するのが非常に簡単で、セキュリティ会社にチェックを依頼すれば必ず見つけ出させる種類の物です。まったくセキュリティチェックをしてないと思われます。

流石にIDとパスワードが、中間者攻撃により第三者に漏れる可能性があるというのは、世の中的にまずいだろうと思い、三井住友銀行や東京UFJ等大手のアプリを調べてみたりしました。大手だけにこの２社はSSLサーバ証明書検知不備の問題はありませんでした。もう少し範囲を広げて、銀行、証券等に広げてざっくりと検査をした結果、今回のDMM証券のアプリの脆弱性も発見しました。
今回DMM証券以外の物も発見し、IPAや開発者に報告はしておりますが、脆弱性かそうでないか微妙な物もあり時間がかかってしまったり、そもそも、利益が発生しないこの作業を、仕事の時間を使って行う事はどうかという疑問があります。また、脆弱性をアプリ開発者に連絡しても（Google Play上のメールアドレス）返事が無かったり、「あなたのアプリにセキュリティホールがあります」というメールを出したとしても怪しまれるだけだろなぁと、もやもやします。
１カ月程、なんやかんやと時間を見つけて脆弱性報告を行いましたが、この作業、特にインセンティブがあるわけでもありません。逆に法律違反の疑いがかけられる可能性もあります。従来から脆弱性を報告している方を見ては、えらいなぁと思っていましたが、今回実際に自分でやってみて改めて実感しました。このあたりの脆弱性を届ける事によるインセンティブが何かあれば、アプリやサイトの脆弱性が減り、世の中少しだけ平和になるのになぁと思っています。

ちょっとまとめてみると...

脆弱性報告メリット
  • 知的好奇心が満たされる（きっと）
  • 人のあらさがしは楽しい（必死になってバグ探しをするのって結構熱中したりしません？）
  • 脆弱性報告に名前が載る（載せないことも可、多分こんな事やるひとは名前載るのはどうでもいいと思ってる）

脆弱性報告デメリット
  • 名前が載るが、自慢になりそうでならない（普通の人には脆弱性、何それ？おいしいの？）
  • もちろんお金はもらえない（海外では賞金がもらえたりもしますが…）
  • 感謝もされない。（逆に余計な事しやがって的な事も言われそうと弱気になる）
  • 逆に法律違反と言われる可能性も（特にWeb系の脆弱性報告）
さて、見も蓋もない事を書いてしまいましたが、世の中にはそれでも、脆弱性報告をしたい人がいるはずという楽観的な前提に立ち、脆弱性を報告する時の参考になれば良いと思い記事を書いていきたいと思います。
今回はじめてIPAに脆弱性報告をしたのですが、「脆弱性報告の仕方」等でググってもそれほど沢山の記事が見つかるわけではありません。それでも過去に脆弱性を報告した方の記事が見つかり大変参考になりました。

参考リンク

まぁIPAのHPに脆弱性の報告の仕方もろもろ書いてあって、公式サイトを見れば情報量等十分なんですが、はじめての時って、失敗しちゃうんじゃないかとか、色々心配になるので、体験談とか探しますよね。そんな方に参考になったり、簡単そうだからちょっと１回やってみるかな？という気分になる人が少しでも増えれば良いと思っております。

脆弱性報告の流れ

IPAに届け出受付業務における取り扱いプロセスという図が公開されていますので参考にしてください。


2016/4/11 IPAに脆弱性報告メールを出す。


脆弱性の発見の仕方については、また記事にしたいと思っておりますが、報告したのはSSL証明書の検知不備についてであり、以下のようなメールをIPAに送りました。
何回も送ることが考えられるので、アプリ名と脆弱性の具体的な部分だけ変更すれば良いように少し工夫をしてあります。同じように報告したい方は使っていただけたらと思います。


  2016年 4月 11日
0. 取扱い方針
■ 脆弱性関連情報の取扱いプロセスに則り、脆弱性関連情報を取扱うことへの
   了解
     ※ こちらにチェックがない場合はお取扱いいたしかねます。
1. 届出者情報
  1) 届出者情報
    住所（都道府県）：東京都台東区東上野２－１－１フリーアネックスビル８F
    所属：リスクファインダー株式会社 代表取締役
    氏名*：谷口 岳
    電子メールアドレス*：info@riskfinder.co.jp
    TEL：080-8873-8243
    FAX：03-6802-8347
    ・届出者情報については、* があるものは必須項目です。
    ・電子メールアドレスがない場合、TEL、FAX のどちらかで必ず連絡が取
      れる情報を記入してください。
  2) 届出者情報の取り扱いについて
     ■ 届出者情報を製品開発者に知らせても良い（調整機関経由になります）
     □ 届出者情報を製品開発者には知らせず、すべてのやりとりを IPAとのみ
        行う（調整機関にも伝わりません）
     ※ 「IPAとのみ」を希望する場合、「2. 脆弱性関連情報」等に届出者情報
        は記入しないでください。また、ファイルのプロパティ等に個人情報が
        含まれる場合がありますので、ファイルを添付する場合は個人情報を
        削除してください。
  3) 対策情報公表時の謝辞への届出者名の記載について
      3-1) JVNでの記載
        ■ 記載しても良い        □ 記載して欲しくない
      3-2) 製品開発者サイトでの記載
        ■ 記載しても良い        □ 記載して欲しくない
  記載しても良い場合は、記載する情報を記入してください（日本語、英語）
    所属：リスクファインダー株式会社、RiskFinder,inc.
    氏名：谷口 岳、Gaku Taniguchi
  ※ 謝辞を希望する場合は、必ず日本語表記、英語表記をそれぞれ記載して
     ください。JVN 日本語版の謝辞についても英語表記を希望する場合は、
     お手数ですが、英語表記を 2 つ句読点で区切って記入してください。
  ※ 謝辞に所属の記載を希望しない場合、「記載なし」と記入してください。
  ※ JPCERT/CC から製品開発者に対し、発見者への謝辞を掲載するよう
     推奨いたしますが、掲載されるかどうかは製品開発者の判断となります。
2. 脆弱性関連情報
  1) この脆弱性関連情報の入手先
     ■ 自分で発見した    □ 人から入手した
     □ ウェブサイトから入手した（URL：                           ）
  2) 脆弱性を確認したソフトウエア等に関する情報
     名称：DMMFX Trade
     バージョン：Ver.1.5.0(2015年11月7日リリース)
     パッチレベル：
     言語：
     設定情報：標準インストール直後の設定
     ウェブ: https://play.google.com/store/apps/details?id=com.dmm.sec.DMMFX
     ※ パッチレベルについては、マイナーバージョンや適用されたパッチに
        対する情報、あるいはサービスパックやホットフィックス等の情報を
        含みます。
  3) 脆弱性の種類
SSL サーバ証明書の検証不備
  4) 再現手順
Android端末へのルート証明書のインストールを行うことなく、mitmproxy(https://mitmproxy.org/)を使った
中間者攻撃を行うことで、DMMFX Tradeアプリが行うSSL通信の内容を傍受することが可能です。
  5) 再現の状況
     ■ 常に    □ 時々    □ まれに
     補足説明（バージョンによる、言語による、などを記入）
アプリを起動するとすぐに証明書のチェックを行わないSSL通信が発生します。
また、ユーザが入力したログインID、パスワードの情報も証明書のチェックを行わないSSL通信で送信されます。
  6) 脆弱性により発生しうる脅威
中間者攻撃 (man-in-the-middle attack) による暗号通信の盗聴などが行なわれる可能性があります。
  7) 回避策
  8) 検証コード
mitmproxy 0.16
  9) その他
3. 当該ソフトウエアの海外での利用状況について
     □ 海外で開発されたソフトウエアである
     □ 国内で開発されたソフトウエアであるが、他のソフトウエアに組み
        込まれ、海外で配布/販売されている
     □ 国内で開発されたソフトウエアであるが、海外で配布/販売されて
        いる
     □ 国内で開発されたソフトウエアであり、海外で配布/販売されてい
        るかどうかは不明である。
     ■ その他（提供元は「DMM.com Securities Co.,Ltd.」ですが、それ以上の情報は不明です。     ）
4. IPA 以外の組織への届出について
     □ あり            ■ なし
     届出年月日：
     届出番号：
     届出先、窓口担当者：
     窓口メールアドレス：
     窓口電話番号：
5. 今後の連絡について
  1) IPA からの連絡における暗号化
     □ 希望する        ■ 希望しない
     ※ 希望する場合は、公開鍵を添付してください。
6. その他
レポートに不備や、さらに詳細の情報等必要な場合はご連絡ください。
----------------------------------------
IPAからダウンロードできる、サンプルをそのまま使用していますが、注意事項等も社内で別の人が記載する可能性があるので、そのままにして社内テンプレートとしました。

脆弱性内容はかなり手抜きです。有名な脆弱性なので内容よりはちゃんと確認しましたよとわかるように記載をしています。

ちなみに、「当該ソフトウェアの海外での利用状況について」は、この届け出では、その他にしていますが、この後から、GooglePlay上で海外URLでアクセス可能であれば、「国内で開発されたソフトウェアであるが海外で配布・販売されている」にチェックをつけ、日本だけであれば、「国内で開発されたソフトウェアであり、海外で配布・販売されているかは不明である」にチェックを付けています。

IPAからの連絡における暗号化については、単に手間を省くために暗号化せずにそのままでやり取りをおこないました。

2016/4/11 IPAからメール受けとった脆弱性か調べるのでちょっと待ってメール受信


IPAからのこの連絡は非常に速く、通常その日か翌日には返信メールが届きます。
IPA#40898764といったIDが振られ以後、メールタイトルにこのIDを付けるようにします。この段階では、脆弱性にあたるか（取り扱い対象か）調べるのでちょっと待ってねといった感じになります。（基本だまって待ちます）

2016/4/22 IPAから脆弱性として受理したよメール受信

報告した届け出が脆弱性として認められました。
営業日としては、１０日で判断したという事になります。
こうした報告を１件、１件確認するのも中の人は大変です。何人ぐらいでチェック等を行っているのでしょうか？今丁度サイバーセキュリティ関係でIPAに新たな仕事が割り振られたりしており、きっと体制とか変わったり、色々大変だろうなぁと推察します。
今回はSSLサーバー証明書の検知不備という既に他のアプリで脆弱性として届けられている物ですし、確認も比較的楽な部類に入りますので、早かったのだと思います。

ちなみに、この１０日もっと短縮できないかと思い、IPAの方に、「もっと詳しい情報送った方がわかりやすいですか？」という質問を送りましたが、「送ったもので十分です。同様の脆弱性を発見した場合、同様の形式で問題ない」との回答を頂いたので、脆弱性届け出テンプレートをフィックスさせました。

2016/5/16 開発者と連絡とれたよ起算日決定メール受信

前回の脆弱性受理したよメールが２２日ですので、結構時間が空いている気がしますが、ゴールデンウイークを挟んでいます。
１６日に受け取ったメールですが、５月９日が起算日となっていました。２２日からは、営業日６日です。早い方だと思います。
「起算日」とは、IPAからJPCERT/CCに連絡し、製品開発者の連絡先を調査し、製品開発者に連絡を開始した日です。そして、連絡が付き（メールが返ってこないなんて事もよくありますね）
５月１３日に脆弱性のやり取りが開始されましたと記載がありました。

2016/5/02　謝辞の内容確認のメール受信

脆弱性の内容が分かりずらかったり、再現方法が難しい場合は、連絡がくるようですが、有名な脆弱性ですので、前回のメールから何も連絡はありませんでした。

一番最初に送った脆弱性報告届け出に、謝辞の記載内容を書いておいたので、このメールはあれ？と思ったのですが、届け出から公開まで１年以上もかかるケースもありますし、再確認の意味合いもあるのでしょうか？
書いてあるよ？等問い合わせをするよりもサクッと書いて送った方が速いので、最初に出したのと同じく、日本語名と英語名の会社名、自分の名前を記載してメールを送りました。（仕事モード）

2016/5/30 届出情報公表のご連絡

IPAホームページの「メールニュース配信」→「セキュリティ対策情報」に登録すると脆弱性情報についてメールで送られてくるので非常に便利です。本脆弱性が公開されたのは、まずこのメールで知りました。確かに先にこちらにメールを送ると、IPA側での公表前に公表してしまう可能性があるのでこの順序になりますね。

公開先されたJVNのURLと、特に何もなければ、これでメールのやり取りも終わりになるけどいいですか？みたいな事が書いてありました。

最後に

4月11日に脆弱性届け出をだして、5月30日に終了になりました。ゴールデンウイークを挟んでこのスピードは非常に速い例なのではないかと思っています。DMMの担当者様、IPA様、JPCERT/CC様ご苦労様でした。
また、金銭を取り扱っている会社様、弊社の製品使ってなんていいませんので、開発会社にセキュリティ大丈夫だよな的な確認だけでなく、第三者によるセキュリティチェックしてくださいお願いします。


がく

がく

リスクファインダーはAndroidアプリのセキュリティホールを見つけます！

Androidスマートフォンが急速に普及するとともにアプリの脆弱性報告も急増しています。
リスクファインダーは、Androidアプリの脆弱性診断WEBサービスです。
500項目以上のチェックでアプリの脆弱性や問題を検出し、セキュアなアプリ開発をサポートします。

  • ブラウザでファイルをアップロードするだけ
  • アプリの脆弱性を指摘するだけでなく対処方法も提示
  • 頻繁にバージョンアップするAndroidの最新情報に素早く対応

リスクファインダーの詳細はこちら