TopicBase
AIに指示してアプリを作る「Grok Build」で、企業の機密情報や個人情報を含むアプリが、ログインせずに閲覧できる状態になっていました。セキュリティ企業Clarocは11月8日の調査で、提供元のSpaceXSI自身の機密扱いの営業資料も発見しました。共有リンクのランダムな文字列がDNSの記録から見つかる構造と、リンクを知る人ならアクセスできる公開設定が重なっていました。
営業計画や医療情報が共有リンクから閲覧可能に
Clarocの調査では、稼働していた3万7571件のアプリのうち、94.7％に当たる3万5578件がログインなしで開けました。多くはゲームや計算機などでしたが、Clarocは約1割に機微な情報、社内業務データ、個人情報が含まれていたとしています。
SpaceXSIとXのスタッフが作った公開アプリは24件あり、機密扱いの新入社員向け受け入れ計画、594顧客の営業担当区域と商談状況、広告提案などが含まれていました。受け入れ計画には、社内システムのアドレスや営業ツール、社内チャットのチャンネルなども記載されていました。
ほかにも、集中治療中の患者の検査結果や人工呼吸器の状態、病院グループの職員名簿、クルーズ船の乗組員の氏名と従業員IDなどが露出していました。ある請負業者の勤務時間管理アプリでは、閲覧者のブラウザーに送られるコードに、管理者を含む18アカウントのパスワードが平文で含まれていました。
Clarocは、SpaceXSIとX以外に、内部データの所属先を特定できた組織が30あったとしています。このうち26組織は従業員が1000人を超え、6社は米大企業のランキング「Fortune 500」に含まれていました。
SpaceXSIは11月8日に問題の通知を受けました。その後、Ars Technicaが問い合わせてから数時間以内に自社関連のリンクの削除を始め、24件すべてが「app not found」と表示されるようになりました。一方、その時点でほかの利用者のデータのほとんどは閲覧できる状態が続いていました。Clarocは影響を受けた組織への通知を進めており、連絡を受けたクルーズ会社はセキュリティチームによる対応を始めています。
推測しにくい名前でもDNSの記録から見つかる
Grok Buildは、公開したアプリごとに「名前.grok.me」という形式の専用アドレスを割り当てます。名前にはランダムな単語の組み合わせが使われますが、その部分はホスト名、つまり接続先のコンピューターを識別する名前に含まれています。
アプリを開く際には、ホスト名から接続先のIPアドレスを調べるDNSへの問い合わせが発生します。「パッシブDNS」は、こうした問い合わせの記録を収集し、検索できるようにするサービスです。共有相手がアプリを利用すると、そのホスト名が検索可能な記録に入ることがあるため、第三者はランダムな名前を推測せずにアドレスを発見できます。
URLを持っていること自体をアクセス権として扱う方式は「ケイパビリティURL」と呼ばれます。Grok Buildでは、発見したアドレスの多くがログインを要求せず、そのままアプリと保存データへの入口になっていました。
ホスト名の発見経路には、TLS証明書の発行を公開記録に残す「証明書透明性」もあります。証明書に含まれるホスト名は公開ログから収集でき、DNSの記録と同様にサブドメインの一覧化に使えます。このため、Grok Buildのようにアプリごとにホスト名を持つ構成では、個別のホスト名が公開証明書に記載されれば、そこからも名前を発見できます。ワイルドカード証明書の場合は、個々のサブドメイン名までは記録に含まれません。
公開時の初期設定と、生成された認証処理にも問題
Clarocが自分たちのアカウントで試したところ、アプリは「Publish」を押すまで公開されませんでした。ただし、公開時の設定画面では「Anyone with the link」があらかじめ選択されており、アクセスを制限するには「Invited users」または「Only you」へ変更する必要がありました。
SpaceXSIが買収したAIコーディングサービスCursorの担当者は、Grok Buildのアプリは初期状態では非公開で、作成者が共有を選ぶまで公開されないと述べています。
Clarocは架空のデータを使う2つのアプリを作り、閲覧以外の操作も検証しました。社内営業チーム4人向けの顧客管理アプリでは、GrokがGoogleやXのアカウントでログインする機能を追加したものの、生成コードはログインした人を先にチームへ登録してから所属を確認していました。
その結果、所有者とは別の、招待されていないGoogleアカウントでも顧客情報を閲覧し、変更や削除ができました。この操作検証はClaroc自身のアプリで行われています。一方、別の検証用アプリを「Only you」に切り替えると、第三者による画面とデータ機能へのアクセスは拒否され、公開停止の操作では数秒以内にアドレスが無効になりました。
URLのランダム性と、パスへ移す対策の範囲
共有リンクの推測しにくさは、文字列の長さだけでなく、実際のランダム性によって決まります。例として、適切に生成した3つのランダムな単語の組み合わせには約38ビットのランダム性があります。ただし、トークンの強度は1つの値の見た目では判断できず、生成された複数の値を分析すると、想定より偏りが大きい場合もあります。
OWASPが示す識別子の推測にかかる時間の考え方では、ランダム性に加え、有効な識別子の数と、攻撃者が1秒に試せる回数が影響します。有効な対象が多いほど、また試行速度が高いほど、いずれかに当たるまでの時間は短くなります。Grok BuildでClarocが使ったのは、名前を総当たりする方法ではなく、DNSの記録からアドレスを探す方法でした。
Claudeの公開アーティファクト、ChatGPTの共有会話、Geminiの共有リンクは、秘密の文字列をホスト名ではなく、ドメインの後ろに続く「パス」に置いています。この部分はDNSへの問い合わせに含まれないため、同じ方法で秘密の文字列を収集できません。
パスに置く方式でも、URLを渡せばアクセス権も相手へ渡るという性質は残ります。ケイパビリティURLを使う共同作業の設計には、共有先や閲覧・編集などの操作ごとにリンクを分け、必要に応じてそのリンクの権限を取り消す方法があります。
また、ブラウザーが送る「Referer」は、リンク元のURLなどを伝える情報です。設定によってはパスを含む完全なURLが別のサイトへ送られるため、URL自体が鍵となる共有方式にも関係します。「Referrer-Policy」で送信範囲を制御でき、「strict-origin-when-cross-origin」では別のオリジンへの送信を接続元の情報に絞り、「no-referrer」ではRefererを送りません。
