2 ポイント 投稿者 GN⁺ 2024-07-29 | 1件のコメント | WhatsAppで共有
  • Metaの反トラスト集団訴訟における公開文書と、アーカイブされた Onavo Protect Android APK のリバースエンジニアリングにより、Facebookが競合アプリのHTTPSトラフィックを中間者方式で復号できた仕組みが明らかになった
  • 重要なのは、端末に Facebook Research CA証明書 をインストールさせたうえで、Onavo VPNのトラフィックをFacebookインフラ上のSquid透過プロキシ ssl bump に接続する方式だった
  • Onavo ProtectはAndroidで1,000万回以上インストールされ、2016年の配布版にはCA証明書がアプリ資産として含まれており、そのうち1つは2027年まで有効だった
  • Android 7以降、ユーザー追加CAの信頼と証明書インストールのフローが制限されたことで効果は低下したが、当時Snapchatの sc-analytics.appspot.com には 証明書ピンニング がなく、MITMが可能だった事例として確認された
  • Androidのセキュリティ強化とピンニングの普及後、Facebookは Accessibility API の利用まで検討しており、Onavoの権限構成にはIMSIのような機密情報へアクセスできる可能性も残っていた

公開文書とAPKリバースエンジニアリングで確認されたOnavoの構造

  • Metaを相手取った現在の集団訴訟の公開文書には、Facebookが Wiretap Act に違反した可能性のある資料が含まれている
    • HNユーザーの説明によると、この事件自体はwiretapping訴訟ではなくSherman Act違反を扱う反トラスト訴訟であり、原告側の弁護団が証拠開示の過程でWiretap Act関連の可能性を偶然発見した形だという
  • 分析の根拠は、公開された裁判所文書と、アーカイブされた Onavo Protect Androidアプリパッケージ のリバースエンジニアリングである
  • 公開情報は限られており断片的なため、一部の事実は不正確または不完全である可能性がある
    • すべてのアプリ利用者のトラフィックが傍受されたのか、一部の利用者だけが対象だったのかは、まだ不明である

ssl bumpで特定のHTTPSトラフィックを復号した方法

  • Facebookはこの手法を ssl bump と呼んでおり、その名前はSquid caching proxyの透過プロキシ機能に由来する
  • 動作フローは次の構成に近い
    • 端末にFacebook Researchが発行した信頼証明書をインストール
    • Onavo VPN経由で端末トラフィックをFacebookが管理するインフラへ送信
    • トラフィックをSquid透過プロキシへリダイレクト
    • ssl bump 設定で特定ドメインのTLSトラフィックを復号
  • 裁判所文書上、関心対象のドメインはSnapchat、Amazon、YouTube関連ドメインとして示されている
  • アーカイブされたOnavoアプリだけでは、他のユーザーのトラフィックが実際に傍受されたのか、単にプロキシを経由しただけなのかを確認するのは難しい

Onavo Protectアプリの権限と収集機能

  • Onavo Protect Androidアプリは1,000万回以上インストールされており、ユーザーが端末のユーザー信頼ストアに CA証明書 をインストールするよう誘導するコードを含んでいた
  • アプリは「保護」とデータ使用量の表示を名目に、複数の権限を要求していた
    • Display over other apps
    • Access past and deleted app usage
  • Android manifestには android.permission.PACKAGE_USAGE_STATS が含まれており、これにより他アプリの使用統計とネットワーク使用量を収集できた
  • ローカルデータベースのスキーマには、アプリ使用統計やアプリ別ネットワークトラフィック使用量のような、比較的高レベルのデータが保存されていたとみられる
  • 公開文書内のメールには、Snapchatに関する「reliable analytics」の必要性と、「特定サブドメインのトラフィックを傍受するiOSおよびAndroid向けkit」の構想が含まれている

CA証明書のインストールとAndroidのセキュリティ変化

  • OnavoアプリにはAndroidの KeyChain.createInstallIntent() を呼び出して証明書をインストールする機能があり、ユーザーには Facebook Research 名義のインストールポップアップが表示される構造だった
  • KeyChain.createInstallIntent() はAndroid 7 Nougatで、それまでと同じ方式では動作しなくなった
  • Androidのセキュリティポリシーもその後大きく変わった
    • Android 6.0 API level 23以下を対象とするアプリは、デフォルトでユーザー追加CAストアを信頼する
    • Android 7以降は、アプリが別途セキュリティ設定をしない限り、ユーザー追加CAをデフォルトでは信頼しない
    • Android 7では、root化なしにシステムストアへ証明書をインストールできなくなった
  • Android 11は、アプリがユーザーを証明書インストールへ誘導していた仕組みを完全に遮断し、どのアプリもデフォルトではユーザーストアの証明書を信頼しないようになった
  • 2016〜2019年当時に可能だった方式は、現在のAndroid環境では技術的にそのまま実行することは難しい

アプリに含まれていたFacebook Research証明書

  • 2017年9月版のOnavo APKには、assets フォルダ配下に old_ca.cernew_ca.cer が含まれていた
  • 関連コードは ResearchCertificateManager クラスで確認された
  • 2つの証明書の違いは有効期間である
    • 1つ目の証明書は2016年9月8日から有効で、1年ものだった
    • 2つ目の証明書は2017年6月8日から2027年6月8日まで有効である
  • 裁判所文書には、SSL bumpに使われる証明書が「サーバーで生成され、端末へ送信される」という文言がある
  • 入手できたアプリでは、2017年以降に証明書がサーバーから追加される具体的な機能はまだ確認されておらず、追加調査が必要な状態である

Snapchatの分析ドメインと証明書ピンニング

  • 証明書ピンニングを完全に適用しているアプリであれば、このMITM方式は動作しなかったはずである
  • 公開文書の証拠物には、Snapchat関連ドメインとして sc-analytics.appspot.com が含まれている
  • 古いSnapchatアプリをデコンパイルした結果、この分析ドメインのトラフィックには証明書ピンニングが適用されていなかった
  • Facebookは、Androidのセキュリティ強化と証明書ピンニングの普及が ssl bump の長期的な適用可能性を下げることを認識していた

Accessibility APIの検討と機密情報へのアクセス

  • Androidのセキュリティ強化と証明書ピンニング導入が広がると、Facebookは代替策として Accessibility API の利用を検討した
  • Googleは、アクセシビリティ機能は障害のある人が端末を使ったり、障害による困難を克服したりするのを支援するサービスに限って、アクセシビリティツールとして宣言できるとしている
  • Androidのアクセシビリティ機能の悪用は、一般にbanking malwareのような悪性アプリの事例と結び付けられる
  • Onavoアプリには READ_PHONE_STATE 権限がmanifestに含まれており、当時はこれにより subscriber IMSI のような機密情報を取得できた
  • IMSIへアクセスできた可能性は、Onavoアプリが収集していた可能性のある他のデータについても追加確認が必要であることを示している

過去のOnavo論争と今回の分析の違い

  • 今回のMITM関連情報は、2019年に知られるようになったFacebook Project AtlasおよびOnavo論争とは別の事案である
  • 2019年には、Facebookが若者に金銭を支払ってアプリを使わせ、利用習慣データを収集していたとの調査の後、Onavoアプリがアプリストアから削除された
  • 2023年には、Facebookの子会社2社がオーストラリア消費者法に違反する可能性のある誤解を招く行為により、オーストラリア連邦裁判所から合計2,000万豪ドルの罰金を命じられた
  • 今回の分析の焦点は、アプリが削除された後も、アーカイブされたAPKを通じて当時の技術的実装を確認できた点にある

1件のコメント

 
GN⁺ 2024-07-29
Hacker News の意見
  • 具体的に何が問題視されているのかを整理すると、いくつかの記事で抜け落ちているように見える細部がある。私には、FB が SC ユーザーに市場調査への参加報酬を支払い、プロキシをインストールさせたように見える
    ほとんどの記事はハッキングのように聞こえる書き方をしているが、実際にはそうは見えない。参加者が何の対価としてお金を受け取ると説明されていたのかはもっと知りたいが、自分の行動が監視されることを知らなかったとは思えない
    通信当事者の一方が、第三者の提供したツールで暗号化を破っているなら、それを盗聴だとする主張は少し弱く見える。法律家ではないが、これが盗聴なら、私がローカル SSL プロキシであるサービスの API トラフィックを復号して分析するのも盗聴なのだろうか?

    • Neilson もテレビで似たようなことをしている。パネル家庭にキャプチャボックスを設置して、何を見ているかを把握する: https://www.nytimes.com/athletic/3194414/2022/03/22/the-ulti...
      何を収集するのかを正直に知らせていたことを望む。記事には、プロキシをインストールする前の同意画面がどのようなものだったかは出ていなかった
    • 記事によると、これは TechCrunch が取り上げた、Facebook が10代にお金を払って利用習慣データを集めさせていた件とは別の新しい件
      その件では Onavo アプリがアプリストアから削除され、罰金につながった
    • 「ハッキングのように聞こえるが、そうではないようだ」という話について言えば、最も優れた効果的なハッキングはたいてい、誰かに受け取るべきでないものをダウンロードさせてセキュリティを迂回するやり方だ
    • 記事が何かを抜かしているのではなく、別々の事件を混同している。この話は、お金を払っていなかった Onavo Protect、「Free VPN + Data Manager」に関するものだ
      別に、Facebook が10代にお金を払い、エンタープライズ配布チャネル経由で Facebook Research VPN をインストールさせて App Store と規則を迂回したプログラムがあり、その有料版はより侵襲的だった
      だから、この Onavo の件はまったく擁護できない
      https://apkpure.com/onavo-protect-from-facebook/com.onavo.sp...
      https://techcrunch.com/2019/01/29/facebook-project-atlas/?re...
    • 「FB が SC ユーザーに市場調査参加の対価を払ってプロキシをインストールさせた」という部分は、以前の件と混同しているようだ。このアプリは Google Play と Apple App Store で誰でも入手できた
      ブログ記事も、2023年にオーストラリア連邦裁判所が Facebook 子会社2社に対し、オーストラリア消費者法違反の可能性がある誤解を招く行為として合計2,000万ドルの支払いを命じた以前の論争と、今回の盗聴の主張を区別している
      「自分のローカル SSL プロキシで自分のトラフィックを復号して分析するのも盗聴なのか」については、自分のネットワークや機器上で自分のトラフィックを見ているなら、当然そうではない
  • メールの一部はいろいろな意味で印象的だが、特に FB の人たちがどれほど愚か、あるいは傲慢だったかが表れている。MITM を公然と話し、他の複数の企業の製品にもこのキットを入れさせたことを文章に残したのは本当に愚かだ
    「Zuck、ご提案の件についてアイデアがあるので会って話しましょう」程度でも怪しくはあるが、少なくとも有罪の証拠ではない。まるで映画や、摘発された他社についてのニュース記事を一度も見たことがない人たちのようだ

    • 何かを文章で送るたびに、同じことを法廷で繰り返さなければならなくなったり、そのメッセージがニュースに載ったりしたらどう感じるかを考えろ、という助言を肝に銘じている。あそこまでひどいことを書いたことはないが、それでも役に立つ
    • むしろ、もっと賢くて悪意ある行動の痕跡を隠せる人たちであってほしいのか?
      本当の問題は倫理の完全な欠如だ。倫理を障害物と見なせば会議室で笑いものにされるか、解雇されかねない場所のように聞こえる。企業文化は何より利益を追う方向で、ソフトウェア業界では自分の行動の倫理的含意をまったく考えない人があまりに多いので、特に悪い
    • 億万長者のボスたちは日和見主義者とおべっか使いに囲まれている。時間がたつと、巨大なゴミ地帯のようにその集団が手に負えないほど大きくなり、少しでもまともに振る舞う人は、彼らの幻想、支配、操作、贅沢、余暇生活に対する存在論的脅威として扱われ、排除される
    • Meta について知るべきことは、ミャンマーのジェノサイドに寄与した事実だけで十分だ。防衛産業関連企業で働くと軽蔑されることが多い一方で、Meta で働くことは概して中立的に見なされるのは悲劇だ。前者の悪影響より後者のほうが圧倒的に大きい可能性があるにもかかわらずだ
      Instagram には触れてすらいない
      結局、あまりにも高い給料を払い、業界の人をあまりにも多く雇っているため、批判が減るのだろう。私たちは皆、Meta で働いた友人がいるか、少なくとも一度は応募したことがあるかもしれない。一方、Anduril のようなところにいた人は周囲にあまりいない
    • こういう人の誰かが新しい職を探すなら、あなたの働いている場所も列に並んで面接ループに入れようとするだろう
  • 過小評価するつもりではないが、これは少なくともユーザーが Onavo アプリをダウンロードする必要があったので、そこまで一般的なことではない
    私がもっとよく考えるのは、iOSで使える、廃止されていない2種類のWebView、WKWebViewとSFSafariViewControllerのことだ。この2つは想定用途が大きく異なる
    Facebookアプリでリンクをタップしたら、SFSafariViewControllerを使うべきだ。アプリのコードは内部を見られないのでプライベートで、SafariとCookieを共有し、文字どおり「このアプリの文脈の中で外部のWebコンテンツを読み込む」ために作られたものだ
    ところがFBはいまだにWKWebViewを使っている。これを使うと、好きなページに任意のJSを注入でき、遷移や読み込まれたリソースなどをすべて追跡できる。今回の記事や他の暴露を見ると、FBがその機能で何をしているのか想像するのが怖い。外部サイトでユーザーがどのピクセルをタップしているかまで追跡している可能性は高い。アプリ内WebViewに入力されたすべてのユーザー名とパスワードを追跡しているかもしれないと考えるのは狂気じみて見えるが、技術的には可能だ。そして本当に彼らがやらないと信じられるだろうか?

    • 実際にJSを注入している。以前、決済の自動入力で特定の JS呼び出しを壊す問題があった
      https://x.com/jameshartig/status/1534886418266431488
    • WKWebViewがアプリにそこまで大きな権限を与えるとは知らなかった。ユーザーがWebページを開いたとき、それがWKWebViewなのかSFSafariViewControllerなのかを見分ける方法はあるのだろうか?FBは使っていないが、他のアプリのWebViewは使っているので、そのアプリたちにもこういうことはできないでほしい
    • Onavoアプリを入れる必要があるので珍しいという話については、AndroidRankによるとAndroidで 1,000万インストールがあった
      まだ分からないのは、そのインストールのうち何パーセントでFB競合のトラフィックがMITM処理されたのかという点だ
      https://www.androidrank.org/application/onavo_protect_from_f...
    • この記事を見ればよい: https://krausefx.com/blog/ios-privacy-instagram-and-facebook...
    • Instagramは入れておらずFacebookは使っているのだが、人がMessengerでInstagram動画のリンクを送ってくると、ログインしない限り、実質的にはアカウントを作らない限り、アプリ内では見られない。Safariで外部から開いて初めて見られる
  • なぜかは分からないが、Facebookはどうしても好意的に見られない唯一のテック企業だ。Google、Microsoft、Apple、Nvidia、AMD、Intelなどは、それぞれ好きなところも嫌いなところもあるが、Facebookはただ嫌いだ
    10〜11年ほど前にFacebookアカウントを閉じ、検索結果からFacebookを除外するフィルターをかけたが、効果はある。GoogleニュースフィードでもFacebook関連の内容はほとんど見ない。ただしWhatsAppはまだ使っている。中国以外のアジアでは最大の メッセンジャーアプリだからだ

    • 理由はいくつかが混ざっているのだと思う。この記事のようなことから、トラッキングピクセル、いわゆるシャドーアカウント、追跡を妨げるあらゆるものに対抗する姿勢まで、利益を増やすために プライバシーを弱体化させてきた長い歴史がある。挙げた企業の中ではGoogleだけが少し重なるが、そこまでではない
      さらに、アルゴリズムがヘイトスピーチを増幅する効果に無責任だ。他の企業にはこの規模の問題はない
      マーケティングも不誠実だ。ほぼすべてのQuest広告や機能発表で、できることをごまかすためにコンセプト映像を使っている。Markも問題を扱う際に二重語法をよく使う。二重語法はMetaだけのものではないが、挙げた他の企業に比べて 欺瞞的な広告を限界まで押し進めている
      今回のAIサイクルでは、オープンウェイトで、オープンソースではないモデルのおかげでMetaの人気が再び上がっており、Markも最近の広報攻勢でイメージを作り直そうとしている
      それでも、挙げた企業の中で仕事に道徳的な核がないのは、文化的にはMetaだけだと思う。文化は上から降りてくるもので、ZuckerbergとThielがMetaの運営方法に「成功がすべて」という文化を植え付けた
      他の企業も確かに資本主義的だが、自分たちの成果物に対する責任感はある程度持っている
    • WhatsAppを使い続けることは、Metaの 独占に加担することだ。WhatsAppの独占は大きくなっており、競合であるTelegramを露骨に真似し始めてもいる
      自分が先に相手を強化しているなら、公然と反対しても何の効果もない
    • 会社名が今はMetaなので、Facebookのニュースをあまり見ない理由もそのせいかもしれない
  • 「Metaを相手取った現在の集団訴訟で、裁判所文書に同社がWiretap Actに違反したという主張が含まれている」という表現は不正確だ
    これは 盗聴訴訟ではない。請求はすべてSherman Act違反、つまり反トラスト関連だ。原告側の弁護士が証拠開示の過程で、偶然FacebookがWiretap Actに違反した可能性のある証拠を見つけただけだ。盗聴に関する請求はなく、反トラスト事件である

    • これはDMCAにも違反しないのだろうか?暗号化されたシステムを迂回しているからだ
      この規模のことにDMCAが十分強くないのか、原告適格や立証可能な損害の問題なのか、原告たちが忘れたのか、気になって混乱している
  • 親戚の一人が以前、これと本質的によく似た市場調査にほぼ登録しかけたことがある。携帯電話のすべてのインターネットトラフィックを、市場調査会社が管理する VPNとプロキシに迂回させ、証明書もインストールする方式だった
    少額の報酬を受け取るはずで、インストールにも同意していたはずだ。その会社が具体的に何かを欺いていた記憶はない
    ただ、過度に温情主義的なポリシーは全般的にはあまり好きではないものの、技術知識が比較的少ない人がこういうことに同意することにどれほど意味があるのかは疑問だ。騙したわけではないが、何が起きるのかを知らない人にも直感的に分かるよう説明していたわけでもなかった

    • ある市場調査会社が 十分な告知をしているからといって、Onavoもそうだったという意味にはまったくならない。Onavoはユーザーに自分たちを「市場調査会社」として宣伝しておらず、インターネットのデータ使用量を分類してくれる無料の便利アプリのように見えていた
  • この記事を読むと、Facebook には今や単なる NSA のフロント組織のような部門があるのではないかと思えてくる

    • Google になった研究も、当初は NSA と CIA の資金提供を受けていたという事実を人々は忘れているようだ
      https://qz.com/1145669/googles-true-origin-partly-lies-in-ci...
      今や自動車には Google サービスと Android がインフォテインメントシステムに組み込まれて出荷され、取り外す方法もない。広告会社があなたがどこへ行くのか、車に誰が乗っているのかをすべて見られる状況で、何が問題になり得るというのか?
    • Prism の流出時には、ほぼすべての大手テック企業が協力していた
    • あるいは 8200部隊のフロント組織かもしれない。Facebook Israel の話だから
  • おおお、SSLbump
    顧客側でネットワークトラフィックをスニッフィングすることを犯罪と見なした判例がありそうだ
    銀行情報の盗聴に関する複数の事件の一つだったのだろう

    • Computer Fraud and Abuse Act がこれを扱うのでは?
  • 有害な情報をインターネットに送る前に、サーバーとクライアントの双方が証明書を交換する 相互 TLS を行うべき理由がこれだ。でも現実は、いやあああああ

    • ここで相互 TLS はどう役に立ったのだろう?
    • 証明書ピンニングはできる
  • 残念だが驚きはない。Meta のような悪意あるアクターは、すでに多くの ダークパターンを仕込んでいる可能性が高い
    例えば、加速度計やジャイロスコープのようなセンサーデータを監視して音声情報を推測する、といったセンサーデータ漏えいのセキュリティリスクは想像できる。収集したデータをひそかに外部へ中継して処理すれば、デバイスのマイクに直接アクセスせずとも機微情報を再構成できる
    彼らがこうしたことをやってのけても不思議ではない
    Meta や他の有害な企業、政府機関は、現実環境でははるかに多く、より悪質で、より単純な 盗聴手法を使っている可能性が高い