Webサイトを訪問しなくてもArcブラウザにアクセスできた脆弱性

 (kibty.town)
2 ポイント 投稿者 GN⁺ 2024-09-20 | 1件のコメント | WhatsAppで共有
  • Arcブラウザの Boosts とFirestoreルールの問題が重なり、攻撃者が被害者アカウントに任意のJavaScriptを含むBoostを紐付けられる状態だった
  • Firebase認証とFirestoreの利用有無は Fridaフック で確認され、preferences、users、user_referrals、boosts コレクションへのアクセスフローが明らかになった
  • 脆弱性は、Boostの適用対象を creatorID で判断している一方で、攻撃者が自分のBoostドキュメントの creatorID を別ユーザーのIDに変更できた点 に起因していた
  • 被害者IDは user_referrals、公開Boostの boostSnapshots、共有Easelsなどから取得でき、被害者が対象サイトを訪問すると悪意あるBoostが実行され得た
  • The Browser Companyはパッチとともに $2,000 の報奨金を支払い、CVE-2024-45489の割り当て後、Firebaseの縮小、セキュリティ監査、バグバウンティプログラムを進めることにした

Arcのクラウド機能とFirestoreの利用

  • Arcは利用に アカウント が必要で、登録プロセスでFirebase認証を使っていることが確認された
  • 初期のネットワーク観察では他のリクエストは見えなかったが、Easelsの共有機能を調べる中でFirestoreを使っている可能性が明らかになった
  • Easels はホワイトボード型のインターフェースで、他の人と共有するとWebで閲覧できる
  • Firestoreは、別途バックエンドを用意せずにデータベースのセキュリティルールとクライアントからの直接アクセスで機能を作れるdatabase-as-a-backendサービスである
  • Firestoreのセキュリティルールが不十分だった過去の事例として Firewreck が関連している

Firebase呼び出しを確認した方法

  • FirebaseのSwift SDKはシステムのプロキシ設定に従わない傾向があるため、mitmproxyの代わりに Fridaスクリプト で関連呼び出しをダンプした
  • スクリプトはObjective-CクラスのFirestore呼び出しをフックした
    • FIRCollectionReference["- documentWithPath:"]
    • FIRQuery["- queryWhereField:isEqualTo:"]
    • FIRFirestore["- collectionWithPath:"]
    • getDocuments、addSnapshotListener:、getDocument などの実行メソッド
    • updateData、setData 系のドキュメント書き込みメソッド
  • Arc実行中、次の種類のFirestoreパスとクエリが観察された
    • preferences/{userID}
    • preferences/{userID}/stringValues/...
    • users/{userID}
    • user_referrals で inviter_id == {userID} を検索
    • boosts で creatorID == {userID} を検索
  • この構造から、Arcは一部の環境設定、基本的なユーザーオブジェクト、紹介情報、BoostsをFirestoreに保存していた

Boostsが攻撃経路になった理由

  • Arc Boosts は、ユーザーがWebサイトをカスタマイズするための機能である
    • 要素のブロック
    • フォント変更
    • 色の変更
    • カスタムCSS
    • カスタムJavaScript
  • BoostsはFirestoreに保存され、ArcブラウザはどのBoostを適用するかを creatorID フィールドで検索する
  • 攻撃者は自分のアカウントでGoogle.com向けのBoostを作成したあと、Firestoreドキュメントの一部パラメータを変更してテストした
  • creatorID 基準のクエリにより他ユーザーのBoostを直接検索することはできなかったが、自分のBoostドキュメントの creatorID を別アカウントのユーザーIDに変更 できた
  • 別アカウントでテストした結果、被害者のコンピュータでGoogle.comにアクセスした際、攻撃者が作成したBoostが適用された

攻撃チェーンとユーザーIDの取得

  • 最終的な攻撃フローは次のとおり
    • 被害者のユーザーIDを取得する
    • 攻撃者アカウントで目的のpayloadを含む悪意あるBoostを作成する
    • Boostドキュメントの creatorID フィールド を被害者IDに変更する
    • 被害者が対象Webサイトを訪問すると悪意あるBoostが実行される
  • この脆弱性は、Arc Boostsが任意のJavaScriptを含められ、Firestoreに保存され、適用対象が creatorID フィールドで決まるため成立する
  • 被害者のユーザーIDを得る経路は複数あった
    • user_referrals: 誰かをArcに招待したり紹介を受けたりすると、user_referrals テーブルから相手のユーザーIDを取得できる
    • 公開Boosts: JavaScriptを含まないBoostは共有可能で、Arc Boosts公開サイト の boostSnapshots には作成者のユーザーIDが含まれる
    • Easels: 共有可能なホワイトボード機能からもユーザーIDを取得できる

パッチと公開スケジュール

  • The Browser Companyは通常バグバウンティを実施していなかったが、この脆弱性について $2,000 USD を支払った
  • 脆弱性のタイムラインは次のとおり
    • 8月25日 5:48pm: Arc共同創業者のHurshにSignalで最初に連絡
    • 8月25日 6:02pm: HurshのArcアカウントで脆弱性PoCを実行
    • 8月25日 6:13pm: 暗号化された形式で詳細を共有した後、Slackチャンネルに追加される
    • 8月26日 9:41pm: 脆弱性をパッチし、報奨金を支払い
    • 9月6日 7:49pm: CVE-2024-45489 が割り当てられる
  • その後Arcは、関連する問題を扱った自社記事 CVE-2024-45489 incident response を公開した

権限のあるページでの実行とプライバシーの衝突

  • Boostsはクライアントで作成できなくても、別のプロトコルで実行される可能性があった
  • settings ページを対象にBoostを作ると chrome://settings で実行され、権限昇格 につながる可能性があった
  • サイト訪問時には次のFirestoreクエリが発生する
    • boosts コレクションで creatorID == {userID} と hostPattern == "www.google.com"; の条件で検索する
  • ここで hostPattern は訪問したサイトを意味し、Arcがどのサイトを訪問しているかを把握しないと明記している Arcプライバシーポリシー と衝突する

Arcのその後の対応

  • Arcは脆弱性と新機能導入をきっかけに、Firebaseから離れる方向 へ転換した
  • Arcの自社要約には次の対応が含まれる
    • 問題修正の確認
    • クライアントでBoostsを無効化する機能の追加
    • 現在のFirebase ACLルールに対する内部監査
    • セキュリティ問題対応プロトコルの策定
  • Arc内部の議論として共有された追加対応は次のとおり
    • v1.61.1アップデートでプライバシー問題を修正
    • 新機能と製品でFirebaseの使用を中止
    • 該当バージョンに対する外部セキュリティ監査
    • 今後の脆弱性に向けたバグバウンティプログラムを開始

関連記事

1件のコメント

 
GN⁺ 2024-09-20
Hacker Newsのコメント

  • Arcを作っているThe Browser Companyの共同創業者兼CTO、Hurshです。実際に被害を受けたユーザーはいませんでしたし、すぐにパッチを当てましたが、この脆弱性の潜在的な深刻度は受け入れがたいものだと考えています。
    技術的な詳細と今後の改善計画、Firebaseから離れること、正式なバグバウンティプログラムを用意することについては、こちらにまとめました: https://arc.net/blog/CVE-2024-45489-incident-response
    脆弱性そのものと、コミュニケーションが遅れたことの両方について本当に申し訳ありません。失望・怒り・励ましを含むフィードバックのおかげで、より良くしていく責任を強く感じています。

    • この記事はHNユーザーだけに向けて書かれたものなのか疑問です。ブログ一覧（https://arc.net/blog）にも見当たらず、Twitterにも投稿されていません。
      対応全体が、十分に騒ぎが大きくなって初めて反応するように見えます。
    • 友人が何人かArcを気に入っていたので、自分でも乗り換えを検討していましたが、今は使わないつもりです。脆弱性そのものというより、全ユーザーを危険な形で乗っ取れるバグに対してたった2,000ドルのバウンティしか支払わなかったからです。
      ユーザーのセキュリティをこれほど軽く見ている会社が作ったブラウザは使いたくありません。確実ではありませんが、この程度の深刻度なら闇市場ではずっと高く売れた可能性が高いでしょう。
    • 下のコメントでは、ページ読み込みのたびにURLと識別可能なユーザーIDをTBCへ送っているのではないかという懸念があります。Chrome以外のブラウザを使う人は、概してプライバシーにも敏感である可能性が高いので、この点に答えたほうがよいと思います。
      脆弱性は起こり得ますが、ブラウジングデータを送るのは意図的な設計上の選択に見えます。
    • これを見た後では、このチームにブラウザを保守する専門性があると説得する方法はなさそうです。修正したという事実とは別に、現在も今後も安全なブラウザを作る能力がないように見えます。
      CTOが辞任すべき事案だと思います。
    • バグバウンティの支払額を引き上げる予定があるのか気になります。2,000ドルはこのバグの価値に比べればごく小さな金額で、発見者に適切な報酬を支払ってほしいです。
      正しい方向へ進むための絶好の機会が与えられたということです。

  • ここのコメントではFirebaseのせいにする声が多いですが、実際にはよく知らないことを受け売りで言っているように見えます。私はFirebaseを使っていませんが、以前使った経験からすると、これはエッジケースでも解決が難しい問題でもなく、基本中の基本です。
    本当の問題は、クライアントが「自分が誰か」を伝える値をAPIが信頼するようにしていたことです。結局はアマチュア的なミスで、おそらく1行の修正で直せた可能性が高いでしょう。ドキュメントを見るだけでも、https://firebase.google.com/docs/rules/rules-and-auth#cloud-...でrequest.authが必要なユーザーID（request.auth.uid）を与えることが分かります。

    • Firebaseで作ったアプリを運用している立場から同意します。投稿者が正しく指摘しているように、設定ミスは非常に起こしやすいものの、こうした基本的なセキュリティ慣行はFirebaseのドキュメントで太字の目立つ警告として強調されています。
      セキュリティルールは真剣に扱うべきで、事実上唯一の防衛線です。
    • ソフトウェアエンジニアたちが自前で認証を作り、次に自前で作らない方向へ進み、今ではこうした露骨なセキュリティ問題さえ見落としているのは興味深いです。
      自前で認証を作るかどうかにかかわらず、要点は一つです: クライアントを絶対に信頼しないこと。
    • 「結局はアマチュア的なミス」なら、むしろまだ良いのですが。私の同僚たちも社内フロントエンドアプリで同じミスを何度もしていました。
    • 誰であれアマチュア的なミスを絶対にしないという前提に依存するセキュリティ計画そのものが、アマチュア的なミスです。
    • 正しく理解しているなら、この問題の修正はfirestore.rulesのmatch文の中に次のルールを入れる程度だったはずです。Firebase Firestoreのセキュリティ入門レベルのドキュメントにそのまま出ている内容です。 
      
// Allow create new object if user is authenticated

allow create: if request.auth != null;

// Allow update or delete document if user is owner of document

allow update, delete: if request.auth.uid == resource.data.ownerUID

  • クリックした場所へ駆け寄ってくる小さなピクセルアートの猫が本当に良かったです。最近はなかなか見かけない、楽しくて気の利いた小さな仕掛けで、私たちが望めばインターネットもそんな楽しい場所になり得るのだというリマインダーのようでした。

    • 私の環境では見えませんでしたが、開発者がprefers-reduced-motionを尊重して、その設定なら表示しないようにしているようです。望む人には楽しさを提供し、嫌がる人には煩わしさを避ける、素晴らしい対応です。
    • 35歳の猫にしては、とてもよく動いています。
      https://en.wikipedia.org/wiki/Neko_(software)
    • Debianでは次のようにして猫をインストールして実行できます。
      sudo apt install oneko
      oneko &
      席を外している同僚のPCへのプレゼントにぴったりです。
    • かわいいのですが、マウスを動かしたりスクロールしたりするたびに猫が動くと分かっているので、文章に集中できませんでした。コンソールを開いて消してしまいました。ごめんね、猫。
    • スマホではずっとテキストを覆い隠していたので、消す方法を探していました。Firefoxのリーダーモードで解決しました。

  • この記事によると、Arc はアカウントが必須で、訪問するすべてのページのホスト名とユーザー ID を Google Firebase に送っている。だとすると Arc は、現在使われているブラウザの中で最もプライバシーが弱いブラウザになるのではないかと思う

    • インストール直後にアカウント必須だと分かって、すぐ Arc を削除した。Wi-Fi が必要な歯ブラシみたいに馬鹿げて見えたが、今見るともっと深刻だ
    • その称号は OperaGX が持っていきそう
    • Firebase が落ちたら Arc がどれだけ壊れるのかも気になる
    • 数か月前にダウンロードしたとき、使うにはアカウントが必要だと分かって、そのまま Firefox を使い続けるのがよさそうだと直感した
    • Firebase に送るデータを暗号化していないのか？ センシティブなデータなら、Google もそうするよう推奨するはずだが

  • 本当に見事なバグだ。Firebase のようなバックエンドサービスのセキュリティルールには、説明しにくい奇妙なデフォルトがある。自分で API を作るなら、この事例の boost のようなレコードの userId はリクエストペイロードから受け取らず、セッションのユーザー ID に設定するだろう
    一定以上のレベルの開発者なら、保護された API パスにクライアントが自分の userId だと主張する値を渡させようとは、そもそもあまり考えない。一方でセキュリティルールでは、実際にプログラムされた利用方法とは関係なく、システムを悪用できるあらゆる方法を想像しなければならない

    • そういうアプローチなら、率直に言ってやり方が間違っている。デフォルト拒否から始めれば、正当な利用方法だけを想像すればよい
    • 挿入ではその通りだが、更新ではリクエスト全体を ORM やドキュメントストアにそのまま渡しているケースをよく見た。「所有者はドキュメントを更新できる」と考えがちだが、公式クライアントが設定しない一部のフィールド、たとえば所有者や作成時刻は変更されてはいけない、という点を見落としやすい
      正しい解決策はおそらく、すべてのフィールドに対してデフォルト拒否の権限を置くことだ。そうすれば少なくとも所有者フィールドを書き込み可能として明示する必要があり、このオブジェクトを別のユーザーに移譲する影響についても考えることになる

  • この脆弱性がどれほど呆れるほど愚かなものかに驚く。任意コード実行をするには、文字通り他人のユーザー ID を送るだけでよく、その ID もかなり簡単に入手できる
    FAANG で働いているわけでもなく、実際には必要でもない粗悪な製品を作る会社で働いているが、自分でもこんなバグは作らない。なのにこの人たちはブラウザを作ると言い、それに伴うセキュリティの専門性と倫理的責任まで引き受けるつもりなのかと思う

    • 他人のユーザー ID をどうやって取得できるのか説明してもらえる？ 大きな脆弱性だというのは分かるが、その部分がどう起きるのか理解したい

  • Arc を使っている人や、Arc ユーザーの知り合いがいる人にもっと分かりやすいよう、投稿タイトルに Arc を入れてほしい

    • 完全に同意。昨日初めて見たときは、これが自分に関係あるとは思わず、タイトルが変わってからようやくクリックした
      正直、タイトルは「Arc ブラウザの根本的なバグ（CVE 123-4567）」のようなものにすべきだと強く感じる

  • 世の中には、理解できる経緯で作られてしまった重大なセキュリティ脆弱性も多く、責任ある対応で修正されれば許せる
    だがこれはそういうケースではない。個人的には評判を台無しにするレベルの無能さを示しており、二度と Arc を使わないと決心させるほどだ

    • 一方で対応速度そのものはかなり印象的だ
      aug 25 5:48pm: Signal の暗号化チャンネルで Arc 共同創業者 Hursh と初接触
      aug 25 6:02pm: Hursh の Arc アカウントで脆弱性の概念実証を実行
      aug 25 6:13pm: 暗号化された形式で詳細を開示後、Slack チャンネルに追加される
      aug 26 9:41pm: 脆弱性をパッチ、バウンティ支払い
      sep 6 7:49pm: CVE 割り当て（CVE-2024-45489）
      突然の初接触から修正版の配布まで4時間なら、修正が単純だった可能性を考慮してもかなり良い。修正：日付が変わっていたので実際には28時間だった。それでもまずまずで、初接触から30分で「うちの Slack チャンネルに入って」と反応したのは非常に速い
    • Arc をちょっと試すだけでも必須アカウントが必要だったのは、最初から大きな危険信号で、それでまったく試さなかった。今となっては使わなくてよかった
    • 正直、Arc は特にプライバシー面で、ずっと羊の皮をかぶった狼のように見ていた
      ブラウザのように重要で個人的な製品で、現金5,000万〜6,000万ドルと5億ドルの評価額を得ているのにビジネスモデルがないというのは大きな危険信号だ。慈善事業ではないのだから、誰かが何らかの形でコストを払うことになる
    • ブラウザを配布する会社なら、セキュリティルールにもう少し気を配るだろうと思うものだ
      Firebase もこれをもう少しフールプルーフにできなかったのは残念だ。そして本当に**$2,500**だけなのか？ 文字通り Arc の全ユーザーを乗っ取れたのに、NSA ならゼロをいくつか足していたはずだ
    • しかも Firebase とは、本気なのかと思う。低レベルソフトウェアエンジニアまで雇っている会社が、箱入りの CRUD バックエンドを使っている。コスト効率は良かったのだろうが、自分がこういうものを設計するなら、Firebase はバックエンド候補の長いリストにすら入れなかっただろう
      特に Supabase のような機能上の競合は、一般的な DBMS と認証モデルを包む方式なのだから

  • 共有してくれてありがとう。ベータの最初の週から Arc を使ってきた
    ただ、このバグと修正内容についてソーシャルメディアのどこにも触れていないという事実は、かなり懸念している。Arc を使う時間は楽しかったが、こういう対応を見ると使い続けられる気がしない

    • 問題を認めて28時間以内に直したなら十分ではないのか？ その対応なら Arc を使い続けてもよいと思える

  • こんな大きな脆弱性に**$2,000**は侮辱的な金額だ

    • HN のブログ記事を見ると、こうした脆弱性がまったく報酬を受けられなかったり、ごく少額しか受け取れなかったりするケースが多いように見えた。企業がハッカーにエクスプロイトを売ってくれと懇願しているようにさえ見える
      おそらく侵害事故について規制当局から罰せられないからかもしれない
    • そう、自分も最初の反応はそれだった。ここまでケチるとは本当に驚いた
    • この金額の20〜50倍を出すという悪意ある相手に売らないでいるには、かなり強い良心が必要だ