17兆件のMicrosoft記録にアクセスできた可能性

17兆件のMicrosoft記録にアクセスできた可能性 9月25日、2026年 Microsoftの様々なデータセットに格納されている推定17.3兆件の行が、単一の内部分析サービスを通じてアクセス可能でした。これは、ログイン・トークンの署名を一切チェックしていなかったためです。この欠陥により、私は管理者権限を偽装し、実際の認証情報なしに不正なSQLクエリを送信することができました。私はテーブルの説明、メタデータ、および限定的なサンプル行のみを使用して、潜在的な範囲を理解しました。 まず、2つの簡単な注釈があります。私が説明する影響は仮説的なものです。これは攻撃者がこのアクセスで何ができたかということですが、幸いにも私はバグを発見し、報告し、顧客データやPII（個人識別情報）には一切触れませんでした。そして透明性のために：Microsoftはこの投稿について編集上のコントロールを行っており、公開前にセクションや図をカットし、影響の説明方法を整形しました。Microsoftはこの発見について次のように述べています：「Faavによって報告された発見を調査する機会を得られたことに感謝します。彼らの提出と協調的な脆弱性開示は、サービスを強化することで顧客をより良く保護するのに役立ちました。Microsoft Bug Bounty Programの条件の下での安全なセキュリティ研究を高く評価しており、今後もFaavと協力していくことを楽しみにしています。」 こんにちは！私はFaavです。1年少し前、私が15歳の時に、私の最初のMicrosoftに関する記事「Break into any Microsoft building: Leaking PII in Microsoft Guest Check-In」を公開しました。私は今16歳で、これはもう少し大きなものです。それ以来、私はバグバウンティにすべてを捧げてきました。学校の合間にMicrosoftをハッキングし、Amazon、Google、Adobe、その他多くの企業でバグを見つけてきました。また、AIをハントに取り入れ始め、私の個人的なAIハックボットであるAntaresを開発しました。これは、Antaresが完了できなかった自動化されたリードから始まりました。10日後、金曜日の学校の課題と深夜のひらめきを経て、それは私がこれまでに見つけたMicrosoftの最大のバグとなりました。 Titan APIの発見 2026年8月25日、AntaresはTitanと呼ばれるMicrosoftの内部サービスを特定しました。そのWebインターフェースはMicrosoft従業員向けのVPN必須ページの後ろにあり、フロントエンドはアクセスできませんでした。しかし、鍵のかかった正面玄関が誰かを止めたことはいつありましたか？ Titanのフロントエンドを訪問した非従業員に表示される「VPN必須」ページ。 APIはフロントエンドのどこにもリンクされていませんでした。そのため、AntaresはMicrosoftのサブドメインを検索し、Azure Cloud Servicesホストに解決される別のエンドポイントを見つけました。その公開されたSwaggerファイルには4つのルートがリストされていました：/GetConfiguration /GetOnboardedTables /v2/Query /v2/Insert Swaggerドキュメントは、4つのルートのうち3つに対してAzure ADベアラー認証を指定していました。例外は/v2/Queryで、これは生のSQLを受け入れるものでもありました。ですから、当然、私はそこから調査を始めました。クエリにはtableNameが必要でしたが、Swaggerには例の値がありませんでした。私はTitanのログインページとプライバシーページの2023年のスナップショットをWayback Machineから取得し、アーカイブされたSupersetの設定を読み取ることで、TestDataというルーティング値を含む56個のテーブル定義を回収しました。 現在のVPN制限前のアーカイブされたTitanインターフェース。 私はその値をライブAPIに対して試しました：POST /v2/Query HTTP/1.1 Host: [redacted] Content-Type: application/json {"query":"SELECT 1","tableName":"TestData","rowLimit":1} 認証ヘッダーなしでは401 Unauthorizedが返されたため、AntaresはJWTの検証方法をプローブし始めました。 JWTの解析 次の10日間、私は何百もの他のリードを処理する間、AntaresはTitanに戻り、エラーを1つずつ解消しながらJWTチェックを chipping away していきました。それは数ヶ月前に作成され、テストに定期的に使用されていた私の外部Entraテストテナントからのトークンから始まりました。Titanはテナントエラーを返しました。テナントをMicrosoftのものに変更すると、オーディエンスエラーに達しました。オーディエンスを変更すると、アプリケーション許可リストエラーに達しました。アプリケーションIDを変更すると、最終的にユーザー検索に達しました。ペイロードは変更され続けましたが、署名はまったく同じままでした。Titanは、まるでボクサーがIDの氏名を確認するが、写真を見ないかのように、新しいクレームを受け入れ続けました。それが署名を検証していない最初の大きな手がかりでした。AIを使用する前に、署名されていないJWTバイパスを自分で悪用したことがあったので、そのパターンをすぐに認識しました。 次に、このヘッダーを使用してトークン全体を合成JWTに置き換えました：{"alg":"none","typ":"JWT"} 通常の署名付きJWTには3つのセクションがあります：header.payload.signature。私のものは、3番目のセクションが空だったため、末尾にベアピリオドがありました：base64url(header).base64url(payload). Titanは署名をまったく検証していませんでした。ペイロードはTitanが期待する値を使用していましたが、私が制御するupnを含んでいました：{ "aud": "[redacted]", "tid": "[redacted]", "appid": "[redacted]", "upn": "[email protected]", "oid": "00000000-0000-0000-0000-000000000000" } これにより、テナント、オーディエンス、アプリケーションのチェックはクリアされ、次の結果が返されました：User '[email protected]' not found Antaresは、このリードに対してCodexとClaudeを実行していました。UPNは通常、メール形式のEntra IDであるため、両方のモデルはプレースホルダー、公開されているサービスエイリアス、およびMicrosoft従業員スタイルのアドレスをテストし続けました。署名されていないトークンはすでにTitanのローカルユーザー検索に到達していましたが、AntaresはTitanが認識するUPNを見つけられなかったため、動作するクエリがなく、影響を示すこともできず、この発見はリードのままでした。 管理者の試行 私は金曜日を学校の課題に費やしていました。Titanのリードが再び現れ、土曜日の午前1時過ぎの9月5日に、自分でもう一度調べることにしました。有効に見えるUPNをいくつか試しましたが、それらも失敗しました。そこで、推測をやめ、バックエンドが実際にクレームをどのように扱っているかを考え始めました。もしUPNをローカルアプリケーションのユーザー名検索に使用していたらどうなるだろうか？私は署名されていないトークンのupnをメール形式のIDからadminに変更しました。結果は単に数字の1でしたが、10日間の認証エラーの後では非常に興味深い1でした。私はついにTitanの管理者としてSQLを実行していました。 Titanは署名されていない管理者IDを受け入れ、SQLクエリを実行しました。面白いのは、adminは明白ですが、明らかに有効なUPNではないことです。まさにAntaresがそれを推測しなかった理由です。私はフィールド名を額面通りに受け取るのをやめ、開発者がバックエンドで何をした可能性があるかを考えたから試しました。Titanは署名されていないupnクレームをローカルユーザー名として使用しました。adminはローカルユーザーID 1に解決され、そのIDはAdminロールを持っており、SQLが実行されました。時には答えは本当にadminなのです。 データベース内部 私はまずTestDataを試しました。テストデータベース内のテストケースだけが含まれていると想定していましたが、その通りでした。しかし、SHOW DATABASESは、Titanのプラットフォームメタデータデータベースを含む残りのデータベースを明らかにしました。そこから、アプリケーションテーブルを直接クエリすることができました。メタデータデータベースには実際のデータが含まれていました。 最初に見つけたのは、名前、メールアドレス、ログイン履歴を持つアクティブなアプリケーションユーザーアカウントのテーブルでした。プラットフォームメタデータ全体で：約25,000件のアカウントとメールレコード。17,990件の従業員メールレコード。15,001件の従業員組織レコード。355件のデータベース構成。20,979件の仮想データセットSQL定義。24,569件のダッシュボード、425,891件のチャート、および27,347件のデータセット定義。 識別情報とログインアクティビティを持つアプリケーションユーザーレコード。 パスワードフィールドには、実際のMicrosoft認証情報ではなく、Supersetのローカルユーザーモデルからのプレースホルダーハッシュが含まれていました。機密値は赤塗りされています。 Titanのユーザーおよび使用状況ディレクトリは、Titanに関連するスタッフの役職、部署、管理階層などの従業員の詳細を公開していました。このデータはMicrosoft従業員のごく一部をカバーしており、全従業員ディレクトリではありませんでした。攻撃者が標的型ソーシャルエンジニアリングの試みを仕掛けるのに役立ったかもしれませんが、私はそれをテストしたり実証したりしませんでした。 その時点で、従業員データが主な発見のように見えました。次に、別のBing分析ソースに気づきました。限定的なBing分析サンプルの検証 最新の利用可能なBingの1行を要求しました。