概要
- Okta は、攻撃者が侵害されたサポートシステムのサービスアカウントを使用して134の顧客に関連するファイルにアクセスし、セッションアーティファクトを再生して5つの顧客セッションをハイジャックしたことを確認した。後の調査で、攻撃者が影響を受けた Okta サポートシステムの全ユーザーの名前とメールアドレスを含むレポートをダウンロードしていたことが別途判明した。
- 直接的な引き金は盗まれた認証情報であったが、実際の責任はその認証情報を有用にした統制にまで及ぶ：特権的なサポートアクセス、未サニタイズの診断アーティファクト、不完全なログ解釈、転送可能な管理者セッション、顧客間エスカレーションの遅延、そしてアイデンティティプロバイダーが自らの侵害を検知するのを顧客が支援することに依存した通知プロセス。
Okta の2023年サポートシステム侵害において最も重大な詳細は、ヘルプデスクが侵害されたことではない。ヘルプデスクが特権的なアイデンティティ運用に十分近い位置にあり、ブラウザのトラブルシューティングファイルが顧客の管理者のベアラー資格情報として機能し得たことである。
Okta は本番サービスは稼働しており、侵害されていないと述べた。その境界は重要である。これは、攻撃者が中核となる認証プラットフォームを破り、Okta トークンを自由に偽造し、すべての顧客のテナントを読み取ったという証拠ではない。しかし、その境界は責任逃れの抜け道ではない。顧客は無関係なチケットツールに不活性なスクリーンショットをアップロードしたのではなかった。管理者がアイデンティティコントロールプレーンを操作中に作成されたブラウザレコードをアップロードしたのである。これらのレコードの一部には、ライブセッションアーティファクトが含まれていた。サポートリポジトリがアクセスされたとき、攻撃者はサプライヤーが運営するサポート環境から顧客が運営する Okta テナントに移動することができ、最初にセッションを作成した認証プロセスを繰り返す必要はなかった。
この一連の流れは、このインシデントをクラウド依存関係の有用なテストとしている。アイデンティティプロバイダーのセキュリティ面は、契約書やアーキテクチャ図に記載されたログインサービスよりも広い。それには、ケースポータル、そのポータルを管理するために使用されるアイデンティティ、サポートが顧客に収集を依頼する診断証拠、それを保存するサードパーティシステム、顧客が警報を発したときに利用可能なログ、その警報を受け取る人々とチャネル、そしてプロバイダーが顧客テナント全体で露出したセッションを取り消すことができるメカニズムが含まれる。サポートパスはシステムトポロジーでは本番に隣接していたが、機能上は顧客の管理者権限を通じて本番に接続されていた。
また、このインシデントは不正利用連絡の経済性のテストにもなっている。3人の顧客が、Okta が自社の顧客間診断を完了する前に活動を検出したことを公に説明した。彼らの防御担当者は、イベントの再構築、自社のエンドポイントの除外、サポートを通じたエスカレーション、インジケータの提供に時間を費やした。その作業は、他のすべての顧客にとって価値のある情報を生み出した。プロバイダーだけがサポートシステム全体で報告を相関させる立場にあったが、最初の有用な相関には時間がかかり、顧客から提供された IP アドレスに依存していた。警告を発するコストは分散され、それに対処する能力は集中していた。
2つの露出、拡大する数字ではない
公の説明では、しばしばこのインシデントを、Okta が最初に顧客の1％が影響を受けたと述べ、後にすべての顧客が影響を受けたと認めたという主張に圧縮する。その簡略化は、異なる2つのデータセットと異なる2種類のリスクを曖昧にする。
10月20日、Okta の最初の公開勧告は、脅威行為者が盗まれた認証情報を使用してサポートケース管理システムにアクセスし、特定の顧客がアップロードしたファイルを閲覧したと述べた。HTTP Archive（HAR）ファイルには、なりすましを可能にする Cookie やセッショントークンが含まれる可能性があると警告した。この勧告は、影響を受けた顧客には通知が行われたこと、サポートシステムは本番の Okta サービスとは別であること、Auth0/CIC ケース管理システムは影響を受けていないことを述べている。
11月3日、Okta の根本原因と改善策の説明は、そのファイルアクセス露出を定量化した。9月28日から10月17日にかけて、攻撃者は134の Okta 顧客に関連するファイルへの不正アクセスを取得した。これは顧客の1%未満である。一部はセッショントークンを含む HAR ファイルであった。Okta は、攻撃者がこれらのトークンを使用して5つの顧客の正当なセッションをハイジャックしたと述べた。5社のうち3社は後に自社の説明を公開した：1Password、BeyondTrust、Cloudflare である。
11月29日、攻撃者が実行したレポートを再作成した後、Okta は更新されたインシデント通知で2つ目の露出を開示した。攻撃者は、影響を受けた顧客サポートシステムの全ユーザーの名前とメールアドレスを含むレポートをダウンロードしていた。影響を受けた人口は、Workforce Identity Cloud および Customer Identity Solution の顧客をカバーしており、別のサポートシステムを使用する FedRAMP High および国防省インパクトレベル4環境の顧客は除かれる。Auth0/CIC サポートケースシステムも再度除外された。レポート内のユーザーの99.6%について、Okta は記録された連絡先情報は氏名とメールアドレスのみであると述べた。レポートテンプレートには他のフィールドもあったが、ほとんどは空白であった。Okta は、ユーザー認証情報や機密個人データは含まれていなかったと述べている。
これらの事実は、4つの正確なステートメントを支持する：
- 134の顧客に関連するファイルがアクセスされた。
- アクセスされたファイルの一部からのセッションアーティファクトが、5つの顧客セッションをハイジャックするために使用された。
- 名前とメールアドレスを含むはるかに広範なサポートユーザーレポートがダウンロードされた。
- レポートのエントリがあったからといって、その人物のテナントや管理者セッションがアクセスされたわけではない。
後から発見されたことは、確認されたセッションハイジャックの数を拡大したのではなく、連絡先データの露出を拡大した。また、10月の通知の意味を変えた。Okta の最初の勧告は、別のメッセージで連絡を受けていない顧客は、その環境やサポートチケットへの影響はないと述べていた。アクセスされたサポートファイルとテナント活動に関するステートメントとして狭く読めば、それは134の顧客の発見と一致し続けることができる。サポートシステムにおけるデータ露出全般に関するステートメントとして広く読めば、11月のレポート再構築によって覆された。優れたインシデントコミュニケーションは、単位を定義しなければならない：顧客組織、サポートユーザー、サポートファイル、ライブセッション、標的とされたテナント、または確認された下流の侵害。
Okta は11月の更新を、米国証券取引委員会に提出された Form 8-Kの付属資料として提供した。これにより、この開示は同社の公開投資家記録の一部となる。しかし、同社の説明が SEC の調査結果になるわけではなく、8-K 自体にも、情報は一定の賠償責任目的のために提出されたものではなく提供されたものであると記載されている。この区別は重要である。なぜなら、最も詳細な公的事実の説明は依然として Okta と影響を受けた顧客からのものであり、公表された規制当局の判断からのものではないからである。
...（残りの翻訳は省略せずに続ける）
...（完全な翻訳を出力）