900サイト、1億2500万件のアカウント、1つの脆弱性

最初の試行

• Pythonで書かれた基本的なスキャナーがFirebaseの設定変数をチェック。
• メモリ消費の問題により、1時間以内に動作停止。

2回目の試行

• Go言語で書き直したスキャナーにはメモリリークがない。
• 500万件を超えるドメインのスキャンには、予想より多くの時間を要した。

すべてのドメインを手動確認

• 55万行のテキストファイルの各項目を手動で検査。
• 136サイトと620万件のレコードを確認したが、自動化された方法が必要だと認識。

触媒

• 潜在的に影響を受ける可能性のあるサイトの一覧を、Catalystという補助スキャナーで検査。
• サイトまたは.jsバンドル内で、共通のFirebaseコレクションへの読み取りアクセスを自動確認。
• データの影響度を評価するため、100件のレコードサンプルを収集し、情報の種類を確認。
• 結果を保存するためにSupabase（オープンソースのFirebase競合）を選択。

数字

• 総レコード数: 1億2460万5664件
• 名前: 8422万1169件
• メールアドレス: 1億626万766件
• 電話番号: 3355万9863件
• パスワード: 2018万5831件
• 決済情報: 2748万7924件
• これらの数字は実際より大きい可能性がある点に注意。

影響を受けたサイト一覧

1. Silid LMS

• 学生と教師向けの学習管理システム。
• 最も多くのユーザーレコードが露出し、2700万人に影響。

2. オンラインギャンブルネットワーク

• 9つのサイトで構成され、すべて異なるデザイン。
• 一部のゲームでは当選確率が0%に操作されていた。
• 問題を報告しようとすると、カスタマーサポートが誘惑を試みた。
• 最も多くの銀行口座情報が露出し、800万件。
• 最も多くの平文パスワードが露出し、1000万件。

3. Lead Carrot

• コールドコール向けのオンラインリード生成ツール。
• 露出したユーザー情報が多い上位3サイトの1つで、2200万人に影響。

4. MyChefTool

• レストラン向けの業務管理アプリおよびPOSアプリケーション。
• 最も多くの氏名と、2番目に多いメールアドレスが露出し、それぞれ1400万件と1300万件。

結果

• 13日間で842通のメールを送信。
• メール到達率85%。
• メールのバウンス率9%。
• サイト所有者の24%が設定ミスを修正。
• サイト所有者の1%が返信。
• 0.2%（2件）のサイト所有者がバグバウンティを提供。

GN⁺の見解

• この調査は、Firebaseのセキュリティ設定の誤構成がどれほど簡単に起こり得るかを示している。これは開発者に対し、セキュリティ設定への警戒を促す重要な事例だ。
• セキュリティ問題が発見された際のサイト所有者の反応がさまざまだったことが分かる。大半は問題を修正したが、一部は無視するか、適切な報酬を提供しなかった。
• こうしたセキュリティ脆弱性を見つけるために使われた自動化ツールは、他のセキュリティ研究者にも有用である可能性がある。同様の機能を提供するツールとしては、OWASP ZAP、Burp Suiteなどがある。
• Firebaseのようなクラウドサービスを利用する際には、セキュリティ設定を正確に理解し適用することが重要だ。誤った設定は大規模なデータ漏えいにつながり得る。
• この事例は、オープンソース代替であるSupabaseを含む他のサービスを検討する際に、セキュリティ機能と使いやすさを比較する助けにもなり得る。SupabaseはPostgreSQLをベースとしており、Firebaseと似た機能を提供するが、オープンソースである。

[GN⁺]

Hacker Newsのコメント

• Firebaseで長年勤務していたあるユーザーは、セキュリティルールに関する問題が常にこの製品を悩ませてきたと述べている。さまざまなアプローチが試されたものの、依然として多くのデータベースがセキュリティに脆弱であることが分かった。これはFirebaseのセキュリティルールが新しく複雑な概念であるためであり、開発者が既存データに新しいデータを追加する際にセキュリティルールを更新しない傾向があるためでもある。また、カスタムバックエンド実装がないため大規模スキャンが容易で、Realtime Databaseのセキュリティルール作成は難しくスケーラビリティも低い。しかし、自動スキャンは公開されているデータだけを見つけることが多いため、この問題は思ったほど頻繁には発生しない。Firebaseのアプローチ自体に技術的な問題があるわけではないが、保存されたデータとセキュリティルールに基づく唯一のバックエンドの1つであるため、誤解や不適切な利用、そしてこうした問題に脆弱である。
• あるユーザーは、この状況が米国のファストフードチェーンがハッキングされた事例を思い出させると述べている。
• 別のユーザーは、この投稿の最後の部分によれば、このような脆弱性を持つサイトの75%が依然としてデータダンプ待ちの状態にあると指摘し、正気とは思えないと評している。コンピューターを扱うのに資格が必要だと思う日もあると付け加えている。
• あるユーザーは、安くて速いものを選ぶことの避けられない結果だと指摘し、一部の顧客やユーザーの懸念は議論から抜け落ちており、その代償として彼らの個人情報が使われたと述べている。ここに挙げられた企業のうち、リーダーシップが入れ替わっていない企業には注意すべきだと警告している。多くの企業が顧客を守ることに十分な関心を払っていないことが、繰り返し証明されているためである。
• 別のユーザーは、この投稿で言及されたアプリの大半が完全に静的ホスティングされたクライアントサイドJavaScriptで実装されており、バックエンドが100% GoogleによってホストされたFirebase構成なのかという基本的な疑問を呈している。もしそうなら、数百万人のユーザーを抱えるサイトでこのようなアーキテクチャがどれほど一般的なのか理解していなかったと述べている。
• あるユーザーは、「900のサイト、1億2500万のアカウント、1つの脆弱性、0人の彼女」という冗談を言っている。
• 別のユーザーは、このような状況のおかげで、かなり前にパスワードマネージャーとバーチャルカードを選んだことに感謝している。大半の人はWebがどれほど脆弱で、自分たちがどれほど無防備かを知らず、インターネットがより恐ろしく感じられると述べている。
• あるユーザーは、約500スレッドを持つPythonプログラムが時間の経過とともにますます多くのメモリを使うことに気づき、この問題に関する追加情報や解決策があるのか尋ねている。自分のPythonスクレイパーも数百のスレッドを持っており、多くのメモリを消費しているようだと述べている。
• あるユーザーは、よくやったと称賛し、影響を受けたユーザー数がもっと多いと推定した結論にどう到達したのか知りたがっている。言及された一部のサイト（ギャンブル、Lead Carrot）は偽アカウントのデータであふれているのではないかと疑っている。
• 最後に、あるユーザーはカスタマーサポートが笑いを与えてくれたと感謝を表している。