AIが弱点ではなかったとき：McHire応募者データ漏洩事件

何が起こったのか

2025年6月、セキュリティ研究者のイアン・キャロルとサム・カリーは、Paradox.aiが構築し、マクドナルドのフランチャイズの大部分で使用されている採用プラットフォームであるMcHireの脆弱性チェーンを公開しました。WiredとBleepingComputerの公開レポートによると、約6,400万人の求職者のデータが流出し、氏名、メールアドレス、電話番号、チャット履歴が、研究者たちと同じ経路をたどった人なら誰でもアクセスできる状態でした。

最も急速に広まった見出しは、これをチャットボット「Olivia」に対するプロンプトインジェクション攻撃として報じました。この見出しは誤りです。研究者たちは最初にプロンプトインジェクションを試みましたが、失敗したと述べています。ボットは定型応答に厳しく制限されており、漏洩を誘発できるようなバックエンドデータを持っていませんでした。この侵害は言語モデルとは何の関係もありませんでした。

実際の侵入経路は、McHire上のParadox.aiの管理ログインページであり、これは公開インターネットからアクセス可能でした。研究者たちは、公開レポートによると2019年からアクティブなままだったテストアカウントに「123456」/「123456」という認証情報を試しました。彼らはログインに成功しました。

ログイン後、応募者APIに対する古典的な不適切なオブジェクト参照（IDOR）により、数値IDをインクリメントして任意の応募者の記録を取得できました。モデルの悪用も、新しい技術も、ゼロデイもありませんでした。デフォルトの認証情報と認証されていないオブジェクト参照です。

なぜこのパターンが繰り返されるのか

ここでの興味深い失敗は技術的なものではなく、組織的なものです。チャットボットは目に見える「AI」コンポーネントであったため、セキュリティの注目を集めました。その背後にある退屈なウェブ管理が実際の爆発半径であり、ほとんど誰もそのように見ていませんでした。

これは、購入者がAIベンダーを、たまたまモデルを含むSaaSアプリケーションとしてではなく、AI製品として扱う場合に常に起こります。モデルはレッドチームレビューを受けます。管理コンソール、応募者API、ストレージバケット、監査ログ、資格情報ローテーションポリシーなど、何十年も前から既知の失敗モードがあるものは、配管として扱われます。

サプライヤーのインセンティブ構造がそれを強化します。AIベンダーは、成熟したセキュリティプログラムを持つ前に迅速に製品を出荷することが多く、顧客の調達チームは、周辺アプリケーションについてではなく、モデルの動作について尋ねます。パスワード「123456」を持つ2019年からのテストアカウントは、誰もレビューの範囲をそれを発見するように設定しなかったため、何年もの間そのギャップを生き延びます。

今後2年間で最も高価なAI侵害は、モデルの悪用ではありません。それらは、モデルを包むアプリケーションにおける1990年代のウェブ脆弱性でしょう。

攻撃者のプレイブックのステップバイステップ

公開されたシーケンスは短く、それが不快な部分です。熟練した攻撃者は、新しいプリミティブの連鎖を必要としませんでした。

ステップ1：AIベンダーの表面を列挙する

目に見えるチャットボットの背後にあるサードパーティベンダーを特定します。この場合、ボットはParadox.aiによって構築されたと自己識別し、同じMcHireドメイン上のログインページという別の管理インターフェースを指していました。

ステップ2：明白な認証情報を試す

デフォルトおよび脆弱な認証情報は、ベンダーの管理パネルに対する最も高い収益をもたらす攻撃であり続けています。レポートによると、「123456」/「123456」という単一のテストアカウントで十分でした。

ステップ3：管理者からデータへピボットする

管理者ロールは内部応募者APIを公開していました。APIはシーケンシャルな数値識別子を使用しており、呼び出し元のアカウントが特定の応募者を読み取る権限があるかどうかを確認していませんでした。IDを反復することで任意のレコードが返されました。

ステップ4：範囲を確認し、開示する

研究者たちは影響の証拠で停止し、データセットのサイズを検証し、Paradox.aiとマクドナルドに報告しました。Paradox.aiはテストアカウントを無効にし、開示から数時間以内にIDORを修正したと報じられています。

防御側が見落としたもの

3つのこと、おおよそ重大度の降順です。

第一に、ベンダーの管理インターフェースにおける認証情報の衛生管理の欠如。本番展開より前に作成された、6文字の数字パスワードを持つテストアカウントが、作成から5年後も公開インターネットからアクセス可能でした。定期的な認証情報の監査があれば、それを見つけられたでしょう。

第二に、応募者APIにおける認可チェックの欠如。IDORはOWASPカタログで最も古く、最もよく文書化されたウェブ脆弱性の一つです。認証された管理者呼び出しが任意の応募者レコードを返したという事実は、APIが認証を強制したが、認可を強制しなかったことを意味します。

第三に、退屈なインターフェースのセキュリティレビューの欠如。チャットボットはAIであったため注目を集めました。管理ログイン、APIゲートウェイ、および6,400万件の個人識別情報（PII）レコードの保存は、マクドナルド、Paradox.ai、またはMcHireを展開したフランチャイズのいずれにおいても、同じ精査を受けませんでした。

実用的な防御チェックリスト

修正は地味です。しかし、これらがこのインシデントを防いだであろうものです。

• 管理パネル、テスト環境、カスタマーサポートツールを含む、使用するすべてのAIベンダーが公開するすべての認証インターフェースを棚卸しします。それらをモデルの配管としてではなく、王冠の宝石のようなウェブアプリとして扱います。
• ベンダーに、本番環境にデフォルトまたは共有の認証情報が存在しないこと、およびオンボーディング中に作成されたテストアカウントが本番稼働時に削除されることを書面で保証するよう求めます。
• ベンダーが公開するすべてのAPI、特にユーザーごとのレコードを返すAPIに対して、認証されたIDOR/BOLAテストを実行します。OWASP API Security Top 10がこれを1位にランク付けしているのは正当な理由があります。
• すべてのベンダー管理インターフェースに対して、IDプロバイダーとのSSOを強制します。これにより、認証情報が独立して漂流することがなくなり、従業員が退職したときに古いアカウントが機能しなくなります。
• 管理セッションの権限を制限し、単一の侵害された管理者アカウントが応募者または顧客データセット全体を列挙できないようにします。
• ベンダーに、機密APIに対する大量読み取りパターンをログに記録し、アラートを発するように求めます。数千万件の応募者レコードをプルすることは、通常の日とは異なるはずです。

現代の攻撃的テストがこれをどのように捉えられたか

チャットボットではなく、McHireベンダーのインターフェースに対する範囲を定めた承認済みの攻撃的エンゲージメントは、初日の午後にこれを発見したでしょう。関連するチェックはよく知られています。管理ログインに対する認証情報スプレー、すべてのパラメータ化されたAPIに対する認証された水平アクセス制御、およびテストアカウントとリセットワークフローのレビューです。

この話では、モデル自体はレッドチームを必要としません。モデルは正しく動作しました。チャットボットのガードレールは機能しました。教訓は、ラッピング製品の徹底的なアプリケーションセキュリティレビューが、キルチェーンのすべてのステップが稼働する前にフラグを立てていたであろうということです。

次に注目すべきこと

このような事態がさらに増えることを予想してください。AIベンダーは、採用、請求、顧客サービス、スケジューリングなど、より機密性の高いワークフローを吸収しており、これらのワークフローを取り巻くバックエンド管理コンソールは、以前はアクセスしにくいシステムにあった規制対象の個人データの集中を保持するようになりました。

自身のプログラムで注目すべき2つのこと：どのAIベンダーがあなたに代わって最も高濃度の規制対象個人データを保持しているか、そして彼らの管理インターフェースをテストするあなたの契約上の権利がどのようなものか。ベンダーのパネルに対して認証されたアプリケーションセキュリティレビューを実行できない場合、あなたは次のテストアカウントが削除されたこと、次のAPIが認可を強制すること、そして次のデフォルトパスワードがローテーションされたことを信頼していることになります。McHireの開示は、その信頼が誤って置かれたときに何が起こるかを示しています。