Smoozサービス終了に寄せて

前置き

この文章と、それに含まれる考察や各サービスへの脆弱性報告などはmala個人の活動であり、所属している企業とは関係ありません。
一方で私は、企業が閲覧履歴を収集して何をしたいのか、所属してる企業や他社事例について、ある程度詳しい当事者でもあります。
一般論として書けることは書けるが、(業務上知り得た知識で開示されてないものなど)個別具体的なことは書けないこともあり、また観測範囲に偏りがある可能性もあります。

Smoozに報告した脆弱性2件

最近、Smoozというスマホ向けのブラウザアプリに2件脆弱性の報告をした。
この記事を書いている時点で、Smoozの配布が停止されていて、修正バージョンの入手が出来ない。
2件目についてはまだ返事が来ていない。

脆弱性情報の開示にあたって特段の許可は得ていないが、開発元からも利用停止するように注意喚起している状況なので、特に隠す必要性もないだろうと判断してこの記事を書いている。また、最初の脆弱性の報告のやりとりの際に、注意喚起のほうが適切だと判断した場合には、修正状況に関わらず、ある程度具体的に言及する可能性があることを開発元には伝えている。

配布再開の目処が経っているのかどうか分からないが、少なくとも2020年12月23日時点で、Smoozの利用を推奨しない。

Smoozの機能を網羅的に把握しているわけではないし、そこまで真面目に調べているわけでもないので(プロなのでタダ働きをしたくない)、他に脆弱性が無いことを保証するものではないし、他にもありそうだという予測もしない(それが出来る程度の深追いをしていない)。

1. Webサイト側から、ユーザーインタラクションなしで、利用者の住所氏名メールアドレス電話番号を盗み出すことが出来る

フォームの入力サポート機能の候補表示が、入力対象となるWebページ上のDOMとして挿入される仕組みになっている
JavaScriptを使って、フィルインの対象となるフォームをクリックして、挿入されたDOMノードを読み取るという動作を繰り返すことで、悪意のあるWebサイト側から、住所氏名メールアドレス電話番号を盗み取ることが出来る。

デモ動画 https://twitter.com/bulkneets/status/1341101682734743552

分かりやすいように、動作過程をゆっくり見せているが、実際には一瞬で完了するし利用者に気付かれないように行うことも出来る。

この脆弱性は12月18日の5:37に報告した。

https://twitter.com/bulkneets/status/1339692484377464832
脆弱性自体はSmoozのインストール後、20~30分程度で発見していて、報告までは2時間半ぐらいで行っている。
フィルインが発動する条件を細かく調べたり、クレジットカード番号を盗む方法が無いか探したり、実証コードとレポートを作成するために時間をかけている。

入力サポート機能は、iOS版の2019年12月19日のブログで言及されている。これ以降のバージョンで脆弱性があったと考えられる。

https://smoozapp.com/blog/2019/12/19/smooz%E3%81%A7%E3%81%AE%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A0%E5%85%A5%E5%8A%9B%E3%81%8C%E8%B6%85%E6%A5%BD%E3%83%81%E3%83%B3%E3%81%AB%E3%81%AA%E3%82%8A%E3%81%BE%E3%81%97%E3%81%9F%EF%BC%81/
入力候補の表示がHTMLっぽいので、見る人が見れば、この実装が危険であることが分かる。

2. 設定次第でネットワーク上の中間者から、訪問URLがバレる

いくつか設定をいじっていて、追加で問題を報告している。

Smoozにはページ読み込みの際に、はてなブックマークのコメントを自動で取得する機能があるが、はてなブックマークのAPI呼び出しがHTTPで行われている。
そのため、コメント機能を有効にしていて、かつ、MITM攻撃を受けている場合(信頼できない、危険なWiFiを使っている等)、悪意のある第三者に訪問URLが漏れる。

そもそも、はてなブックマークが全面的にHTTPS化されたのが2019年の話だ。そのため、Smooz側での実装当初にはHTTPSを使うという発想が無かったのだと思われる。(実際にはHTTPSサイトへのwidget埋め込みやスマホアプリの通信などでHTTPS化が必要だったので、はてなブックマークのAPI自体はこれよりも結構前のタイミングでHTTPSに対応していたはず)

はてなブックマークのコメントを取得する機能は、Smoozの初期から実装されている機能のようだ。逐一はてなにURLが送信されることになるが、その点についての説明も十分とは言えないだろう。

https://smoozapp.com/blog/2017/01/13/why-smooz-was-created-2/

この問題は、12月22日11:16に報告している。

コメント一覧機能を有効にした場合の、はてなブックマークのコメント一覧のJSONを取得する際に最初にHTTPのURLでリクエストが行われています。リダイレクトによってHTTPSのURLが使われますが、WiFiが盗聴されている場合など、中間者攻撃を受けている場合には、アスツールやはてな社以外にも、Smooz利用者の訪問URLが分かる状態になります。

HTTPSが利用されている場合、中間者からは接続先のIPアドレスは把握可能で、追加でDNSクエリやTLSコネクション時の平文でのやりとりでホスト名等が把握可能な場合がありますが、 URLはHTTPSで暗号化されるため、本来は中間者攻撃を受けていてもフルのURLが盗聴されることはありません。第三者から攻撃可能という脆弱性ということになるので、これも、アスツール社への情報送信とは無関係に対応が必要です。

発見の経緯について

この記事を読んで、

https://reliphone.jp/post-16247/

広告や関連記事が、大元のWebページに対してDOMを継ぎ足すことで実装されているのが気になったからだ。広告載せないポリシーなのに広告が挿入されて不愉快だとか、あるいは同一性保持権の侵害だとか、そういう観点で問題視する人も当然いるのだろうが、それ以前に、まずもってこの手法はセキュリティ上の問題を引き起こしやすい。

これをやっている時点で、ブラウザがWebページのDOMに干渉するということ自体に「無頓着」である可能性に思い至って、入力サポート機能を見つけて、住所氏名メールアドレス電話番号を盗み出すことが出来ることを発見した。

勝手に広告挿入してけしからんとか月並みな感想しか持たなかった人間は、アプリやWebの開発者に向かない。

しかし、12月20日に聞いた話だと「脆弱性報告」という形の報告を上げたのは自分ひとりだったそうだ。

実際のところ、大半の開発者が同程度に、結局なにか目の前で不味いことが起きていても気付かないだろう。似たような要件で仕様が上がってきたら、多くの開発者が同じようなことをやるだろう。上から目線で評論家気取りでこれは酷いなどとのたまうばかり、火事場を外から眺めて他人事で自分のことは棚に上げ、人のふり見て我が振り直しもしない、お前もお前もお前も、漫然とインターネットをしている醜い卑しい下賤の生き物ばかり。なんとかしてくれ。

Smooz開発元のアスツール社の対応について

(この文章を書いている間に終了のお知らせが出てしまった https://smoozapp.com/blog/2020/12/23/end_of_service/ )

利用規約やアプリ内での説明が不足しているのはもちろん良いことではない。けれど、批判や炎上にビビって、公開を取りやめてしまったことは、良い対応ではないと思っている。

運営元がサーバーを落とせば、アスツール社への情報送信はいつでも止められるが「悪意のある第三者に個人情報が盗まれる」脆弱性は、アプリをバージョンアップしないことには直せない。
「問題があったので新しい商品と差し替えてください」ではなく「問題が見つかったので新規出荷を停止します」という状況になっている。これでは既存のユーザーは保護されない。

批判を受けている最中に「サービスを継続する」事自体に対する圧力もあるだろうし、修正バージョンの用意のないまま、利用停止を呼びかけたことは、苦渋の選択だっただろう。自分が批判するのはアスツール社の対応だけではなく、そういう対応を選択させてしまう環境も含めた話で、炎上だとか、あるいは投資家からの圧力だとか、そういったものは優先順序を見誤らせることになる。

内情や経緯についても、いくつか聞いているが、アスツール社の主張を代弁する立場ではないので、アスツール社が公式に説明をすべきだと考えている。この部分はこれで終わり。

いくつかの関係ありそうな話

中間者(プロキシ、ブラウザ、拡張機能等)が、Webページのコンテンツに何か加工するときの注意

時間があったら個別にもう少し詳しく書く。取り急ぎ自分が過去に報告したことがある脆弱性をいくつかピックアップした。
https://twitter.com/bulkneets/status/1341087910368407552

Favicon取得のためにGoogleのクローラが秘密のURLに来る話

これはたまたま最近の調べ物と被っていて把握しているのだが、Google Chromeは、Googleのサーバーからfaviconを代理で取得することがある。 faviconがローカルのキャッシュに無い状態で、ブラウザの履歴ページを見るとURLがGoogleのサーバーに送られて、Google FaviconというクローラがWebサイトのHTMLを取得しにくる。

https://www.google.com/chrome/privacy/whitepaper.html

機械翻訳引用

履歴ページを使いやすくするために、ChromeはアクセスしたURLのファビコンを表示します。他のデバイスからのChromeの閲覧履歴の場合、これらのファビコンは、指定されたURLとデバイス表示DPIのみを含むCookieなしのリクエストを介してGoogleサーバーから取得されます。同期パスフレーズを持つユーザーのファビコンはフェッチされません。

クローラの一覧についてはこちらに記載がある

https://developers.google.com/search/docs/advanced/crawling/overview-google-crawlers?hl=ja
Google Favicon（さまざまなサービスのファビコンを取得します）ユーザーが開始したリクエストの場合、robots.txt ルールは無視されます。

そもそもfaviconとは何なのか？なぜクロールが必要になるのか。

伝統的にドメイン直下の /favicon.ico というURLに設置されることが多いが、HTMLのlinkタグの指定で、これ以外のURLを使うことも出来る
そのため、正確にfaviconを表示するためには、HTMLを取得しないといけない。
faviconのキャッシュ、Webページのキャッシュが失われた状態からfaviconを(正確に)表示するためには、HTMLを再取得しないと実現できない。

こういう事例を知っているので「閲覧履歴を収集するためにわざわざfaviconをサーバーサイドで取得している」なんてことを、自分なら絶対に言わない。

Googleの事例でいうと、正確には「同期パスフレーズ」を使っていない場合、Googleにとって、Web訪問履歴は既知のURLであり、代理でクロールしても構わないという思想なのだろう。(同期パスフレーズを利用している場合には、閲覧履歴は厳に秘密なので、Googleからもわからないように設計している) さらについでに言うと、同期パスフレーズを利用しない場合、Googleは原理的に、他社サービスのパスワードをGoogleから復号出来る形で保存している。 (Googleの従業員から気軽に取り出せるような状態になっているなどとは決して思わないが、パスワード管理ツールというのは、サービス運営元にも原理的に復号できないように設計するというのが当然であった、と自分は認識している)

今さらGoogleにそんなことを言っても仕方ないという部分も多いが、結局なし崩し的にいろんなことは変わっていく。

サーバーサイドでDMを読んでいるTwitterクライアントの話

あるサードパーティのTwitterクライアントアプリは、Direct Messageをサーバーサイドで受信している。理由は単純で、そうしないとプッシュ通知が実現出来ないからだ。クライアントサイドだけではなく、サーバー側でもTwitterのトークンを保持していることになる。

利用者に分かりやすく説明されているかと言うと、されていない。自分は「利用者がそのことを知らなかったり、意識しなくなっているのは問題だ」ということは言うが「このアプリはマルウェアだ、スパイウェアだ」であるとか「このTwitterクライアントは社員がDMを盗み見るために、わざわざサーバーサイドで処理している」なんてことは口が裂けても言わない。

同様に、クラウド変換機能を持っているIMEをキーロガーだと言ったりはしない。

この処理はクライアントサイドでやるのが当たり前とか、この処理はサーバーサイドでやるのが当たり前とか、そういう概念はとっくに壊れている。

サーバーサイドでのデータの取扱いが信用ならないといって、マルウェアだのスパイウェアだの運営元が邪悪だのと騒ぐことをしない。単純に失礼だからというのもあるし、仕事でサービスの運営に関わったりあるいはセキュリティの診断をしたりといったことでお金を稼いでいる、プロとしての誇りがある。

マルウェアの境界線はどこにあるのか

事実として、App Store、Google Play、ブラウザの拡張機能ストアにおいて、利用規約がそれらしく書かれていれば、Web閲覧履歴を収集する機能があっても、ストアのポリシーによって取り下げられたりすることは無い。送信された情報が、サーバーサイドでどのように取り扱われているのかは審査しようがなく、運営元が信用できないからマルウェアだスパイウェアだと騒いだところで、そういった理由でリジェクトされたり、証明書失効やマルウェア判定などの厳しい処罰がされるようなことは滅多なことでは起きない。

Webのパネルデータ(年代性別などと訪問サイトの傾向のデータ)を作成している企業が、Web閲覧履歴の収集目的でブラウザ拡張機能を買収するということがある。こういった買収後にスパイウェアとしてストアから取り下げられたにもかかわらず、その後、利用規約を記載して普通に復活しているという事例もある(収集自体はデフォルトで有効のままだったりする)

それでもマルウェアとして判定されてストアから排除されるようなのは、例えば以下のようなケースだ。

リモートから動的にコードを受信して挙動を変えられるようになっている
他社サービスの認証情報など、あからさまに必要以上の情報を取得している
情報収集に関する機能が難読化が行われていたり、特定条件や時間経過などで発動するようになっている(審査迂回しようとしている)

大事なのでもう一度言うが、サーバーサイドでどのように取り扱われているのかは審査しようがないので、利用規約がそれらしく書かれていれば、一見必然性がないように思われるような情報収集が行われていようとも、それだけを理由に各種アプリストアが排除するようなことはしないし、正規の機能を隠れ蓑にして、実態としてはウェブパネルデータの生成が目的であるということもある。

で、結局Smoozってスパイウェアなのか？

ユーザーの閲覧履歴を収集して金に変えるようなビジネスはあるが、自分はSmoozがそうであるかのような主張をしていない。 (「そうではない」とも言っていない、彼らの法務機能が貧弱で、利用規約やプライバシーポリシーでの説明が不十分なので判別がつかない。それはアスツール社が説明すべきことで自分は代弁する立場にない)

収益化の方法として確認できるのは、単純に、Googleのカスタム検索エンジンの収益化 https://support.google.com/programmable-search/answer/4514267?hl=ja 及び、楽天やAmazonのアフィリエイトだ。

favicon取得のためのURL送信や、おすすめ記事表示のためのURLや本文テキスト送信を指して、利用者の個人情報を収集して換金するような目的だと考えているなら、それは論理が飛躍しすぎている。なぜそれが必要になるのかの背景を理解していたり、あるいはクライアントで行うこととサーバーサイドで行うことの境界が曖昧になっていること、自分が発見、報告した脆弱性なども含めて、彼らが「ブラウザが意識すべきセキュリティやプライバシーのセオリー」に無頓着であったことは伺い知れるのだから、そこに悪意を見出すのには無理があると自分は考えている。

おすすめ記事表示のためのWebページ分析はnlpやmlというホスト名に送られていて、これは自然言語処理や機械学習の意味だろう。送信してるのはHTMLソースそのものではなくて本文っぽいコンテンツのテキスト部分で、レスポンスも見れば記事がどういう分類されたのかが入っていた。(今はサーバー落とされているので確認出来なくなっているが、どういう目的でデータを送信しているのかは十分に理解できる状態だった)

まとめ

面の皮が厚い連中は堂々とスパイウェア続けるし、弱小ベンチャーは批判にビビってサービスを畳む。

mala/202012_smooz.md