ハッカーがOktaのサポート部門からアクセストークンを盗取
(krebsonsecurity.com)- Oktaの顧客サポートシステム侵害により、一部顧客がサポートケースにアップロードしたファイルが露出し、攻撃者は遮断されるまで少なくとも2週間、サポートプラットフォームにアクセスしていたとみられる
- 攻撃者は盗んだ認証情報でサポートケース管理システムに入り、顧客が問題解決のために提出したHARファイルを閲覧できた
- HARファイルにはCookieとセッショントークンが含まれる可能性があり、奪取されると攻撃者が有効なユーザーのようにセッションを再利用するリスクがある
- BeyondTrustは10月2日、自社のOkta環境で管理者アカウント作成の試みを検知しており、その30分前に有効なOktaセッショントークンを含むHARファイルをOktaに共有していた
- Oktaは18,000社以上の顧客のうち約1%にあたる約170社に通知し、1PasswordとCloudflareも自社のOkta認証プラットフォームが侵害されたことを公表したが、顧客情報やシステムへの影響はなかったとしている
サポートケース管理システムで露出した顧客ファイル
- Oktaは多要素認証とシングルサインオンを含むIDツールを数千社の企業に提供する会社であり、今回の事故は顧客サポート部門の侵害から始まった
- 10月19日に一部顧客へ送った通知で、盗まれた認証情報がサポートケース管理システムへのアクセスに使われたと知らせた
- 攻撃者は、最近のサポートケースに一部のOkta顧客がアップロードしたファイルを見ることができた
- 影響範囲は当初「ごく少数」と表現され、その後、顧客基盤の約1%にあたる約170社に通知したことが確認された
HARファイルが危険になった理由
- Oktaは顧客の問題を解決する際、Webブラウザのセッション記録である**HTTP Archive（HAR）**ファイルを求める場合がある
- HARファイルには顧客のCookieとセッショントークンが含まれる可能性があり、機微な情報となる
- 攻撃者はファイル内のCookieやトークンを使い、有効なユーザーになりすますことができる
- Oktaは影響を受けた顧客とともに調査し、埋め込まれたセッショントークンの失効など保護措置を講じた
- HARファイルを共有する前には、すべての認証情報、Cookie、セッショントークンを削除する必要がある
BeyondTrustが捉えた攻撃の流れ
- セキュリティ企業BeyondTrustは、Oktaの10月19日の通知を受け取った顧客の1社だった
- BeyondTrustのCTOであるMarc Maiffretは、その通知がBeyondTrustがOktaに潜在的な問題を知らせてから2週間以上経って届いたと述べた
- BeyondTrustのセキュリティチームは10月2日、何者かが自社エンジニアに割り当てられたOktaアカウントで、自社のOkta環境内に強力な管理者アカウントを作成しようとする試みを検知した
- 当該従業員アカウントの活動を確認したところ、不正活動の30分前に、サポートエンジニアがOktaの依頼に従って、有効なOktaセッショントークンを含むHARファイルをOktaに共有していた
- 攻撃者はブラウザ記録内のCookieを利用してセッションハイジャックを試み、そのユーザーの代わりに行動しようとした
- BeyondTrustは10月3日、Oktaが侵害を受けた可能性が高いと通知し、10月11日と10月13日の通話でも同じ判断を伝えた
- BeyondTrustは攻撃を進行中に検知しており、自社顧客は影響を受けていないと明らかにした
Oktaの対応と残る疑問
- OktaのDeputy CISOであるCharlotte Wylieは、10月2日のBeyondTrustからの通知を当初、自社システム侵害の結果とは見ていなかったと述べた
- 10月17日までにOktaは事故を特定して遮断し、侵害された顧客ケース管理アカウントを無効化し、関連するOktaアクセストークンを失効させた
- Wylieは、潜在的なセキュリティ問題の通知を受けた顧客数を正確には公表しなかったが、18,000社以上の顧客のうち「非常に、非常に小さな一部」と表現した
- 侵入者が同社のケース管理アカウントにどれほど長くアクセスしていたのか、攻撃の背後にいるのが誰なのかは公表されていない
- Wylieは、今回の攻撃者はOktaとOktaの特定顧客を標的にしたことがある既知の脅威アクターだと明らかにした
関連する侵害とその後の公表
- Oktaの公表は、Caesar’s EntertainmentとMGM Resortsのハッキングから数週間後に行われた
- 2つのカジノ企業の事件では、攻撃者が従業員をソーシャルエンジニアリングでだまし、Okta管理者アカウントの多要素認証ログイン要件をリセットさせていた
- 2022年3月、Oktaはソーシャルエンジニアリング攻撃に特化したハッキンググループLAPSUS$に関連する侵害を公表した
- Oktaの事後報告書によると、LAPSUS$はOktaリソースへのアクセス権を持っていたサードパーティのアウトソーシング企業Sitelのサポートエンジニアのワークステーションに、ソーシャルエンジニアリングでアクセスした
- Oktaはその後、事故に関するブログ記事を公開し、顧客が影響の有無を確認できる侵害指標を含めた
- 影響を受けたすべての顧客に通知したと明らかにした
- 個別の連絡を受けていないOkta顧客の環境やサポートチケットには影響がないと強調した
- BeyondTrustも自社の調査結果を公開した
- 10月24日のアップデートで、1PasswordとCloudflareは、Okta侵害の結果として自社のOkta認証プラットフォームが侵害されたと公表した
- 両社とも、調査の結果、顧客情報やシステムは影響を受けていないと明らかにした
- Oktaの広報担当者はTechCrunchに、顧客基盤の約1%、約170社に通知したと述べた
1件のコメント
Hacker News の意見
この記事で面白いのは、Okta がサードパーティから不審なテナント活動の通知を受け、当初は侵害の証拠を見つけられず、BeyondTrust が押し続けた後でようやく再調査して侵害を確認したという点
Okta はここにブログ記事を投稿している: https://sec.okta.com/harfiles
冒頭の文言は「Okta Security has identified adversarial activity」だが、サードパーティからの通知についての言及はない。透明性がすばらしいですね
タイトルがひどく、透明でも直接的でもない。BeyondTrust が 10月2日に、HAR ファイルを Okta Support にアップロードしてから 30分後に知らせていたという事実にすら Okta が触れていないのは本当にお粗末
「Okta の副 CISO である Charlotte Wylie は、Okta が当初、10月2日の BeyondTrust の警告は自社システム侵害の結果ではないと見ていたと述べた。しかし 10月17日までには同社が事案を特定し、遮断したと述べた」
サイバーセキュリティと認証の専門家を名乗る会社に、ハッキングの事実を 30分以内に知らせたのに、その会社はそれは違うと言い、15日間認めないあいだ攻撃者が好き放題していた、という話
Wylie、もっとしっかりしてほしい
元記事にリンクされているこのブログ記事を見ればよい。Okta の顧客の一つだったセキュリティ企業が、Okta と HAR ファイルを共有した直後に自社ネットワークで不審な活動を検知し、Okta に侵害を通知した
https://www.beyondtrust.com/blog/entry/okta-support-unit-bre...
おそらくログイン後に IP が変わったということを回りくどく表現しているのだと思う。もちろん最も簡単な解決策は、アクティブなセッションの HAR ファイルを自発的に共有しないこと
こういうことを言うと人気はなさそうだが、OAuth、SAML、2FA による SSO の中核ゲートウェイは、SaaS の「簡単ボタン」を押すよりオンプレミスで運用すべきではないかと思う
ここには Okta だけでなく Auth0（Okta が買収）、Authy、Duo も含まれる
すべてのソフトウェアにはセキュリティバグがあり、オンプレミスソフトウェアも例外ではない。多くの IT 組織には、ディレクトリを運用し保護する専門性がない。ソフトウェアをインストールしてアカウントをいくつか作り、隅に置いておけばよいという話ではなく、災害復旧、バックアップのテスト、侵害の有無の判断までしなければならない非常に難しい作業
オンプレミスの IT セキュリティがクラウドプロバイダーのセキュリティより優れていると証明した人はいない。実際に見たオンプレミス IT 部門の中には、セキュリティが非常にひどいところもあった。2010〜2020年の間にも MD5 証明書を使う VPN を運用していたところ、認証なしのユーザーが住民番号/税番号・住所・名前・電話番号といった個人情報にアクセスできる Web サービスをデプロイしていたところ、看護師に患者メモ作成用として広告付きテキストエディタを渡していたところ、既知のセキュリティバグがあるサポート終了版の Redcap を更新していないところ、など
Redcap は、医学研究や公衆衛生統計の計算に使われる情報を保存するソフトウェアだと理解しており、機密データが多い
要点は、クラウドからオンプレミスへ移せばセキュリティが良くなることもあれば、そうでないこともある、ということ。個々の IT 組織の能力次第であり、多くの組織には Okta のようなアイデンティティサービスを運用する能力がない。また、クラウドプロバイダーは通常、予算がはるかに大きく、コストを多くの顧客に分散できるため、セキュリティ専門家、システム保護、侵害検知により多く投資できる
そういう管理職や役員には何の質問も飛んでこない
実際、一度も接続されないシステムでソフトウェアを書き、テストすることはできる。驚くが事実
IDプロバイダー、パスワードマネージャー、VPN企業のようなところは、絶対にハッキングされてはいけない。セキュリティ製品で収益を上げている企業であり、侵害されたところは使わないだろう。もっと深い問題がある可能性が高い
基本的な前提はすべて侵害され得るということであり、侵害されないことを立証する責任は彼らにある。繰り返し無能さを示してきた人たちに善意で解釈するよりも、ハッキングされないという例外的な主張を裏づける肯定的な証拠を待つほうが慎重に思える
十分に有能で責任感があれば検知して公表するだろうが、多くはそうしないと思う。まさにあなたのような人たちが利用をやめるからだ。だから少しでも気にする人なら、オフライン、セルフホスト、自作の代替手段を使うべきだ
Oktaが1か月ハッキングされないチャレンジ：難易度インポッシブル
冗談はさておき、Oktaは侵害されるのが好きなように見える。こうした事件で株価が下がり続ければ変化が起きると期待するところだが、そうではないようだ
悪魔は細部に宿る。おそらくゼロトラストで運用していたのだろう
一方では、コア製品の侵害ではなかった。他方で、あらゆるコア製品の侵害には、間接的な非コア部分の侵害が付きまとう
競合のAuth0を買収することを許可されて、本当に良かったですね
いつかカンファレンス発表で、複数の企業のサポート職に人をお金で送り込んだうえで、その人たちに与えられたシステムアクセス権でその企業を侵害する実験をしてみるつもりだ
メールの末尾にはこう書かれていた
「この情報はOktaの機密情報であり、貴組織の外部に共有してはなりません」
正直、かなり笑える