Skip to content

Instantly share code, notes, and snippets.

@mala

mala/2021_browser_mitm_vuln.md

Last active February 15, 2021 00:58
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mala/bd4ff6aa4384f4266e518527bcf618c9 to your computer and use it in GitHub Desktop.
Save mala/bd4ff6aa4384f4266e518527bcf618c9 to your computer and use it in GitHub Desktop.
Download ZIP
LunascapeとSleipnirに報告した脆弱性の話(スマホアプリではとにかくHTTPSを使え2021)
Raw
2021_browser_mitm_vuln.md

LunascapeとSleipnirに報告した脆弱性の話(スマホアプリではとにかくHTTPSを使え2021)

前置き

  • この文章と、それに含まれる考察や各サービスへの脆弱性報告などはmala個人の活動であり、所属している企業とは関係ありません。
  • 執筆時点で未修正の不具合や、過去に修正済みで運営元が開示していない脆弱性情報なども含みますが、公益を意図しています。

概要

2020年の年末に、スマホ向けのLunascapeとSleipnirに対して、以下の問題を脆弱性として報告した。

  • 入力途中も含む検索キーワードが、平文で開発元または検索サービスのサーバーに送られる。
  • 利用者が閲覧しようとしたURLが、平文で開発元または検索サービスのサーバーに送られる経路がある。(閲覧URL全部送られたりするわけではない)

2021年の1月に修正されて、修正内容がリリースノートに記載されている。Lunascapeについては記事執筆時点(2/13)で、報告した問題の一部は未修正になっている。

タイムライン

Lunascape

  • 2020-12-27 Lunascapeに対して報告(問い合わせフォームがうまく動かず、届いていなかったらしい)
  • 2020-12-28 自動返信の類が来ないのでTwitterで催促する https://twitter.com/bulkneets/status/1343388399705628673
  • 2021-01-06 Lunascapeの近藤社長に直接連絡する、翌日返信あり。
  • 2021-01-10 修正リリース Android 1月10日リリース、iOSは1月13日リリース (一部問題は未修正)

新機能

  • ニュースの不具合の修正
  • プライバシーへの配慮のため検索サジェストと検索用URLをhttpsに変更

Sleipnir

  • 2020-12-27 Sleipnirに対して報告(その後、自動応答)
  • 2021-01-04 Sleipnirから返事
  • 2021-01-18 修正リリース Android 1月18リリース、iOSは1月25日リリース

Version 3.5.24

  • 検索エンジンと検索サジェストのリクエスト URL を HTTPS に変更
  • その他軽微な修正

解説と参考画像

Lunascapeの場合

lunascape_google

video: https://user-images.githubusercontent.com/51196/107842024-5f6f0280-6e03-11eb-85e6-3968dacd92ae.mp4

lunascape_redirect

  • サジェストのためのAPIは、 google.com が使われる。(旧バージョンではこの通信がHTTPだった)
  • Lunascapeのスタートページには「検索ワードかURLを入力」と書かれた入力フォームがある
  • このプレースホルダでの説明から、omniboxと呼ばれるような検索とアドレスバーを統合したものだと思いきや、URLを入力して遷移しようとすると、入力したURLはlunascapeの管理するサーバーに送信された上でリダイレクトされ、Google検索される。
  • 検索語句またはURLは、ja.msearch.luna.tv に送られる。(旧バージョンではこの通信がHTTPだった) このホストは、選択した検索エンジンにリダイレクトするためのものである。

google.com は当然に、HTTPSに対応しているのだけれど、なぜか HTTP でサジェストを呼び出しているので、MITM攻撃を受けている場合には検索語句が通信経路上の第三者に漏洩する。

そもそも「検索ワードかURLを入力」と書かれている入力欄にURLを入れているのに、検索されてしまう動作が異常で、これは近藤社長いわく「そもそも不具合」とのことだった。

Sleipnirの場合

sleipnir suggest

  • サジェストのためのAPIは、 api.sleipnirstart.com が使われる。(旧バージョンはこの通信がHTTPだった)
  • アドレスバーにURLを貼り付けようとすると、それが検索語句であってもURLであっても、問答無用で送信される。
  • そのため、Sleipnirで「アドレスバーにURLをペーストして開く」という操作をしようとすると、通信経路上の第三者、及び、Sleipnirのサーバーに開こうとしていたURLが漏洩する。

ブラウザ開発に関わる人向けの参考情報

URLを入れているのにサジェストのAPIに投げたり、検索エンジンにクエリとして飛ばしたりしてしまう問題

  • 自分の調べた and 知っている範囲だと、Google ChromeやFirefoxなどは、URLのような文字列をアドレスバーに入れた場合に、補完するのはドメイン名までにとどめており、Path以降はサジェストのためのAPIに送信しないようになっている。
  • このような配慮が行われていないブラウザを利用すると、URLを「アドレスバー」に入れた際に、サジェストのためのAPIにフルのURLが送られてしまう

サジェストのための入力語句の送信に対する同意取得

検索語句の補完の目的で一字一句が逐一サーバーに送信されるのは、今日では当たり前のことになってしまっているが、特にプライバシーへの配慮を謳うようなブラウザの場合には、初回に確認がある。

Firefox Focusの場合

Braveの場合

個人的には必須とまでは思わないが、Sleipnirのケースに見られるように、入力中の検索語句がブラウザベンダのサーバーに送られるのか検索エンジンに送られるのか、自明ではないので本来説明したほうが良いのだろう。

そもそも検索語句はどこに送られて誰が利用するのか？

そもそもGoogleのサジェストのためのAPIは、公式に提供されているものではなく、むしろアクセス制限すると宣言されている。

多くのブラウザは、検索キーワードの補完のために、Google ChromeやFirefoxの投げているリクエストを真似をして勝手に利用しており、勝手にChromeやFirefoxを名乗っている。 最終的にGoogle検索に誘導するものについては、Googleがわざわざ制限するかというと、そういうことは起こらないとは思うし、オープンソースのソフトウェアのソースコード中に、open searchの定義ファイルとしてパラメータ仕様が公開されていたりもする。

ブラウザの利用者にとっては、ブラウザベンダが提供するAPIよりも、どうせ最終的に検索クエリを投げるGoogleのサジェストAPIを直接利用したほうが安心だと思うかもしれない。 しかし、GoogleのサジェストのAPIの利用は、正式に契約しているもの以外は非公式な利用で、いつ制限されてもおかしくない、ということになっている。 なので、Sleipnirのように、ブラウザベンダーがサジェストのためのAPIを自前で提供しようとするのは、自然なことだと自分は考える。

小まとめ

驚いたことは、かなり長い歴史のあるブラウザであるにも関わらず、2021年1月に改修されるまで、検索キーワードやURLを取り扱う通信でHTTPSが使われていなかったことだ。

このような事態を招いているのは私が所属している組織に配慮して、スマホアプリがHTTPSを使わないのは、それ単体で脆弱性だということを強く主張してこなかったことが原因なので、とにかく全部俺が悪かった。

来世ではこのようなことがないようにしたい。

関連しそうな内容

スマートフォンアプリケーションでSSLを使わないのは脆弱性か

2012年2月6日の記事 「スマートフォンアプリケーションでSSLを使わないのは脆弱性か」

「公開情報のみを通信している場合を除く」という条件付けに対して、当時ツッコミを入れている。

この当時、HTMLからのローカルファイル読み取りや、JSブリッジ機能との組み合わせによる脆弱性を多く報告している(撲滅されたわけではなく、近年でもある)

スマホアプリでは、権限の強いWebViewや、ローカルのHTMLファイルにリモートから受信したデータを流し込んで表示するということがしばしば行われ、その結果、HTTPが使われていると、通信経路で改竄されたJavaScriptから、そのアプリの権限で読み取り可能なローカルファイルを盗み取ることが可能になる。 WebView内に、アプリ固有の機能を呼び出すためのブリッジが設定されることも多く、これによって、そのアプリのユーザー情報を盗み取るようなことが可能である。

2015年8月に報告したメルカリの脆弱性

実例として思い出したのでついでに開示しておく。

  • ヘルプページがHTTPで提供されており、HTTPでアクセスした場合にもjs bridgeが有効になっているため、MITM経由で利用者のメールアドレスや電話番号を盗み出すことが出来た。
  • 個人情報を取り扱うAPIへの通信等でHTTPSが使われないのが問題なのは自明であるが、単にヘルプページの表示(公開コンテンツの表示)であっても、アプリの設計次第では、MITM経由で認証情報を盗み出すことが出来てしまう。
  • 2015年8月23日に報告して、9月3日リリースのバージョンで修正された。(セキュリティfixとしては告知されていない)
メルカリのiOSアプリ、アプリ内で表示されるhttpのURLに対してもjs bridgeが有効になっています。
バージョンは最新版(Mercari_r/393)
http://guide.mercariapp.com/jp/index.html
http://guide.mercariapp.com/common/js/webview.js

通信経路で改ざんされた場合、webview.initAccessToken でアクセストークンを取得でき、api経由で各種情報の取得が可能です。
少なくともget_profileで登録メールアドレス、電話番号が取得できるのを確認しました。
curl -H "X-APP-VERSION: 393" -H "X-PLATFORM: ios" -H "User-Agent: Mercari_r/393 (iPhone OS 8.3; ja; iPhone5,2)" "https://api.mercari.jp/users/get_profile?_access_token=[access_token]&_user_format=profile"

メルカリのAndroid版についても、類似の問題を報告した人もいるようだ。

2020年7月になってJVNで公開されているが、おそらく報告されたのは相当に昔のことだろう。(修正バージョンとされる3.52がリリースされたのも、2017年2月のようだ)

当時のAndroid 4.x 系列では、単にWebViewがロードされただけでも暗黙のうちに追加されるJavaScript Interfaceが存在しており、HTTPでJavaScriptのコードが受信される経路さえあれば任意コード実行が可能という、地獄のような状況だった。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment