BeyondTrust、Oktaサポート部門への侵害を発見する

“BeyondTrust Discovers Breach of Okta Support Unit” October 20, 2023 by Marc Maiffret より

サマリー

2023年10月2日、BeyondTrustのセキュリティチームは、社内のOktaの管理者アカウントで、IDを中心とした攻撃を検出しました。我々は自社のIDセキュリティツールを使って、攻撃をただちに検出して是正したため、BeyondTrustのインフラストラクチャにも顧客にも影響はなく、漏洩も発生していません。このインシデントは、Oktaのサポートシステムが侵入を受けた結果、Oktaのカスタマーがアップロードした重要ファイルに攻撃者がアクセスできるようになったことが原因でした。

このインシデントは、攻撃者がOktaのサポートシステムから盗んだ有効なセッションのクッキーを使って社内のOktaの管理者アカウントにアクセスしようとしたことを、BeyondTrustのセキュリティチームが検知したことが発覚のはじまりでした。当社固有のポリシ制御によって、攻撃者の最初の行為はブロックされましたが、Oktaのセキュリティモデルには限界があったため、若干の限られた動作を実行することは許してしまいました。BeyondTrust自身のIndentity Security Insightsツールがチームに対して攻撃を警告し、すべてのアクセスをブロックして、この攻撃者がどのシステムにもアクセスできないことを確認できました。

当初のインシデントレスポンスでは、Oktaのサポートチームの誰か、あるいはカスタマーサポート関連のデータにアクセスできる立場にいる人物の不正によるものだという可能性を示唆していました。我々は、10月2日にこの不正の懸念をOktaに知らせました。Okta社より「侵入の可能性を認識した」という回答が得られなかったため、Okta内への通知の範囲を広げて問い合わせを続けると、10月19日になってOktaのセキュリティ責任者より、実際に侵入があったこと、我々も影響を受けたカスタマーのひとつだったことが知らされました。

Oktaはその後、我々が3週間近く前に検出した侵入を認める声明を出しています。繰り返しますが、BeyondTrustや当社の顧客に関しての漏洩被害はありませんでした。とはいえ、我々はOktaのほかのユーザや情報セキュリティの専門家たちへの教訓として、攻撃についての詳細をお伝えしようと思います。Identity Security Insights製品をお使いのBeyondTrustのお客様に対しては、こうしたタイプの攻撃について、そして、攻撃面の制御を強化し、今回のようなOktaを狙った攻撃の可能性とその影響を最小限にとどめるための推奨事項についての警告となるよう、検出されたさまざまな結果についてお知らせします。

時系列でのオーバービュー

2023年10月2日－　社内のOkta管理者アカウントへのIDに特化した攻撃を検出・是正し、Oktaに警告した

2023年10月3日－　Oktaサポートの組織内での侵入を示唆する最初の調査結果を受けて、Oktaのセキュリティチームに報告するようOktaサポートに依頼する

2023年10月11日および2023年10月13日ー　OktaのセキュリティチームとZoomでミーティングを開き、彼らが侵入を受けていると考える理由を説明する

2023年10月19日ー　Oktaのセキュリティ責任者が、社内の侵入を受けたこと、BeyondTrustもこれに巻き込まれたうちの1社だったことを認める

攻撃の詳細

2023年10月2日、Oktaのサポートを名乗る人物がBeyondTrustのOktaの管理者に対し、この管理者が作業中だった問題のサポートを支援するためにHARファイルを生成するよう依頼しました。HARファイルは、ウェブブラウザで生成できるHTTPアーカイブで、ウェブサイトとのやりとり、この場合はサイトに関する問題のバグ修正のために使われました。管理者は依頼に従って、APIリクエストとセッションクッキーを含むHARファイルを生成し、これがOktaサポートポータルにアップロードされました。

Oktaの管理者アカウントはFIDO2人称で保護されており、BeyondTrustのOktaのポリシでは、Okta Verifyがインストールされている管理デバイスからしか管理者コンソールにアクセスできないことになっていました。

管理者がこのファイルをOktaのサポートポータルにアップロードしてから30分以内に、攻撃者はこのサポートチケットからのセッションクッキーを使って、BeyondTrustのOkta環境で動作を行なおうとしました。管理者コンソールアクセスに関するBeyondTrust社内ポリシで、最初はこれをブロックしましたが、攻撃者は手法を変え、盗んだセッションクッキーで認証を受けた管理者APIアクションを利用しました。APIアクションは、実際の管理者コンソールアクセスと同じようにポリシによって保護することはできません。攻撃者はAPIを使って、既存のサービスアカウントのように命名規則を用いて不正なユーザアカウントを作成しました。

BeyondTrust社製品のIdentity Security Insightsのインスタンスと、当社のセキュリティチームによる独自の検出によって、複数の面から侵入の警告がありました。当社はただちに不正なユーザアカウントを無効にし、攻撃者のアクセスをブロックして、このアカウントを使ってさらに何らかの行動が行なわれるのを防ぎました。当社のIdentity Security Insightsによれば、ほかの特権を持つOktaの全ユーザで、別の不正な動作の形跡はなく、別の疑わしいOktaアカウントが作成された痕跡もなく、このインシデント以前に標的となったユーザのアカウントでの異常な動作も検出されませんでした。

詳細な攻撃の流れ

以降、このできごとの流れを詳しく記します。

2023年10月2日

BeyondTrustのOkta管理者が、セキュリティに関係ない現在進行中のサポート問題の解決に関して、Oktaサポートからの要請に応え、ブラウザ記録（HARファイル）をアップロードしました
サポートファイルのアップロードから30分も経たないうちに、匿名のプロキシ／VPNサービスに関連づけられたマレーシアのIPアドレスを使って、BeyondTrustのOkta管理者として、BeyondTrustのOkta管理者コンソールにアクセスしようとする試みがありました
Oktaのイベントは、このマレーシアのIPからであると記録されていますが、この場所のこのユーザからは、通常行われるはずの認証手続きや何らかの動作は事前にありませんでした
攻撃者は認証を受けていましたが、Oktaコンソールへのアクセスは、BeyondTrustのセキュリティチームが強制実施しているデフォルト外の以下のようなOktaセキュリティポリシ構成がされていたため拒否されました
- アクセスはデフォルトで拒否し、特定の基準を満たしたアクセスのみを許可
- 管理されたデバイス上ではOkta Verifyが要求されるポリシ要件のおかげで、攻撃者はコンソールへのアクセスを拒否
攻撃者は、Oktaの管理者コンソールの基盤となっているAPIを使って、パスワード健全性レポートを生成しようとしました
攻撃者は、Oktaのメインのダッシュボードにアクセスしようとしましたが、ポリシに身元証明を求められました
- 参考：Oktaの顧客は、サインインするたびに管理者ユーザにMFAを求めるなどの設定を使って、セキュリティポリシを強化することが大切です。これは攻撃者がハイジャックした既存のセッションの中でしたが、Oktaにはダッシュボードへのアクセスが新規のサインインとして見え、MFAが求められるのです。
攻撃者はOktaの公式のAPIを使って、既存のサービスアカウントに似せて「svc_network_backup」という偽のサービスアカウントを作りました
- 参考：公式のOkta APIを認証するためにセッションのクッキーが使われることもあり、多くの場合、双方向の管理者コンソールに適用されるポリシの規制はありません。
攻撃者の行動は速かったのですが、我々も検出と応答をただちに行ったため、アカウントを無効にして漏洩の危険を軽減できました
BeyondTrustはインシデントレスポンスの手順に着手し、管理者に関連したすべてのシステムとアカウントに対し、ただちに隔離と調査を行ないました
調査では、侵入を示す兆候は見つかりませんでしたが、サポートケースのためにHARファイルが生成されていることがわかりました。これは、例外的な状況（この場合はサポートケース問題解決のため）でのみ作成されるものなので、目を引きました
BeyondTrustはOktaのサポートに連絡して懸念を伝える一方で、独自に調査を続けました

2023年10月3日

さらに調査を進めた結果、BeyondTrustのシステムに起因する侵入の可能性が除外されたため、我々はOktaのサポートシステムに侵入があったのではないかと結論づけました
Oktaに侵入の兆候があり、ほかのOktaの顧客も漏洩にさらされているのではという我々の懸念を伝え、情報セキュリティチームにこの問題を上げてくれるようOktaのサポートに要請しました。侵入や現在進行中のセキュリティインシデントについては、Oktaから知らされませんでした

2023年10月11日

Oktaのサポートが、我々の情報セキュリティチームのメンバーとZoomで会議を開き、そこで我々が発見したことを伝えて、サポートケースのデータアクセスに関連するほかのログデータをOktaに要求しました
Oktaは我々が要求したログデータの提供と協力を約束してくれました。侵入や現在進行中のセキュリティインシデントについては、Oktaから知らされませんでした

2023年10月13日

Oktaのサポートのログ記録を受け取りましたが、そこにはいくつか矛盾点がありました。我々はその矛盾点に関連する詳細なログ記録を求め、Oktaのサポート内で侵入があった可能性が高いという懸念と、影響を受けたカスタマーは我々だけではないのでは、ということを重ねて伝えました。侵入や現在進行中のセキュリティインシデントについては、Oktaから知らされませんでした

2023年10月19日

Oktaのセキュリティ責任者と電話会談し、Oktaで侵入があったこと、当社もこの侵入で漏洩があったうちの一社だということを知らされました

2023年10月20日

Oktaの公式発表に合わせて、我々は、セキュリティ関連の人々に情報を提供し、互いの顧客を守るために、侵入の形跡を含め詳細な情報を記したこのブログを発行することにしました

BeyondTrustはOktaに対し、互いの顧客を守るために協力してくれたことに感謝したいと思います。包み隠さずにこの侵入を報告し、影響を受ける顧客に通知し、さらに進んだ段階の調査について取り上げてくれたことに感謝しています。

この発見における具体的なIdentity Security Insightsの検出

ここからは、BeyondTrustのIdentity Security Insightsソリューションの顧客が、もしOktaの攻撃で使われた手法の標的になった場合、このソリューション内で可能となる検出と推奨事項を記載します。

Oktaセッションのハイジャック：攻撃者はOktaのセッションのクッキーを盗み、それを使って自分たちが制御するインフラストラクチャからOktaにアクセスし、MFAと認証に関連したセキュリティ制御の大半を回避することができます。この検出機能は、セッションのハイジャックと連動する認証イベントなしで発生する疑わしいセッションを探します

Oktaのユーザがプロキシを使って管理者行為を行なった：この攻撃者、およびScattered Spiderなど、その他のOktaを狙った攻撃者は、特権ユーザとしてログインし、極秘の管理者行為を行なうのにプロキシを使うことが多いのですが、正規のユーザはめったにそういうことはしません

Oktaの管理者特権が、ユーザに許諾された：攻撃者は特権を昇格させようとするか、不正なアカウントに対して特権を許諾しようとすることがよくあります。この情報レベルの検出では、Oktaの管理者割り当てをすべて強調表示します。こうした割り当ては通常は珍しく、ふつうは確立された手順の中で行なわれます

Oktaのパスワード健全性レポートが生成された：このレポートは、我々が監視している大半の環境ではめったに生成されません。この情報レベルの検出では、疑わしい動作があった場合に強調表示します

管理者アクセス権があるレベルのOktaのユーザが、SIM交換に脆弱なMFAを使う：当社のインシデントレスポンスの手順が非常に迅速に行われたのは、管理者ユーザがMFAにFIDO2を使っていたために、トークン窃取のメカニズムとして中間者攻撃のフィッシングを除外できたからです。特権ユーザに対して推奨事項を伝えることで、IDセキュリティの専門家に差分の変更を知らせ、こうした重要なアカウントを安全に保護できるようにします。

現在Insightsをお使いの場合、下記の詳細に基づいて当てはまる検出がないか結果を見直してください。また、お客様の環境にOktaの侵入による漏洩の危険がないか調べたい場合、BeyondTrustのサポートにご連絡ください。現在はInsightsのお客様でなく、ご自身の環境を評価するために無料のトライアルをご希望の場合は、当社にご連絡ください。

侵入の兆候

プロキシ（isproxy：Okutaのログイベントの際に該当）を介したOktaの管理者機能へのアクセス
202[.]59.10.100または23[.].105.182.19のIPからOktaへのアクセス
VPS／ホストプロバイダからのOkta、特にOkta管理者機能へのアクセス（特に、VPS Malaysia、LeaseWeb）
次のようなMacOs向けの旧式版のChromeのユーザエージェントによるOktaへのアクセス：Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko)
svc_network_backupその他、既存の正式なアカウントをまねた名前を持ち、REST APIを介して作成されたOktaアカウント
/reports/password-health/async_csv_download_schedule?のようなエンドポイントに対する動作。これは通常、対応する管理者コンソールのログインなしに、Okta Admin Console UIからのみ使われます
認証を受けたことがはっきりわかる証明（例：同じ地域からの「a user.session.start」イベントなど）のないユーザに関するOktaの動作
ポリシが拒否し、同じユーザから管理者コンソールへのログインに成功することなく、その後1時間以内に管理者コンソールにログインが試みられること

その他の注意事項

Oktaは最近、HARファイルの作成と無害化に関する情報記事を更新しているので、これをご覧になることをお勧めします
盗まれたセッションを有効期限後に使おうとする試みが失敗したという例は今のところありませんが、これは、有効期限切れのセッションを伴う動作試行がOktaのログにないからかもしれません

セキュリティ態勢向上のための推奨事項

Oktaのポリシ制御を追加して、アクセスを管理者コンソールに限定する
サインオンごとにMFAの確認を発行するようOktaのグローバルセッションポリシを調整し、攻撃者が盗んだクッキーを使ってメインのダッシュボードにアクセスするのを防ぐことを考える
Oktaセッションの長さを制限したり別の手段を講じたりして、盗んだクッキーを利用できる範囲を減らす
セッションのクッキーを通じて認証された管理者APIの動作には、Global Session Policyしか適用されず、ほかのポリシより規制範囲が少ない場合が多いことをわきまえておく
セッションのハイジャックによって攻撃者はMFAを回避できるということを知っておく
すべてのOktaの管理者にとって、中間者攻撃のフィッシングを介したトークンのハイジャックを防ぐには強力なMFAが必要である

終わりに

昨今のIDベースの攻撃は複雑なことが多く、この攻撃でわかるように、自身の環境の外に由来することもあります。HARファイルの共有のしかたなどを制限するには、具体的できちんとしたポリシと内部統制が必要です。ただし、重要なのは徹底的な防御です。制御や手順を一つ間違えただけで、侵入につながるようなことがあってはなりません。そう、複数の制御の層ー例えば、サインオンの制御、IDセキュリティの監視などーによって侵入は防げるのです。

その他のIDセキュリティの資料と参照

IDの攻撃と防御：Oktaのセキュリティに学ぶこと
当社は最近、Oktaのセキュリティと最新の脅威の実行者の行為について、より一般向けのブログを公開しました。
https://www.beyondtrust.com/blog/entry/lessons-in-okta-security

Marc Maiffret、BeyondTrust社最高技術責任者

Marc Maiffretは、eEye Digital Security、FireEye、SpaceX、BeyondTrustといった組織で、20年以上にわたってセキュリティを主導した経験を持つ起業家であり、経営幹部です。Marcは17歳のときにFBIから引き抜かれた直後に自分の会社を立ち上げました。セキュリティ調査員として、Microsoftの脆弱性調査の草分けであり、最初のMicrosoftのコンピュータのバグ、Code Redを共同で発見し、名づけました。Marcは数多くのセキュリティカンファレンスに出席し、国家のセキュリティに関して議会の前で証言してきました。事業家としては、Vulnerability Management（脆弱性管理）、Web Application Firewalling（ウェブアプリケーションのファイアウォール化）、Endpoint Security（エンドポイントのセキュリティ）、Malware Detonation（マルウェアの破壊）などの最初の製品の設計と生産に関わりました。さまざまな媒体に寄稿しており、定期的にメディアに呼ばれて複雑なセキュリティの話題についてわかりやすく語っています。