Oktaでセキュリティ侵害があったことが、本日（2022年3月22日）03:30 UTC（協定世界時）に判明しました。当社では、従業員の本人確認のため、社内の認証スタックの一環としてOktaを使用しています。今回のセキュリティ侵害について当社で慎重に調査したところ、この侵害の結果として不正アクセスがあったとは考えられません。当社ではお客様のアカウントでOktaを使用していません。そのため、お客様ご自身でOktaを使われていない限り、特にアクションをお取りいただく必要はありません。
調査とアクション
2022年1月中、Okta社外のハッカーが、Oktaのサポートスタッフのアカウントに不正アクセスを試み、そのスタッフになりすまして行動できたというのが当社の理解です。ソーシャルメディアで共有されたスクリーンショットでは、Cloudflareの従業員1名のメールアドレスと、ハッカーがOktaの従業員を騙ってパスワードのリセットを開始した可能性がある旨のポップアップメッセージが確認できました。
当社では、Cloudflare社内のSIRTを通じてこのインシデントを知りました。SIRT（Security Incident Response Team）とは当社のセキュリティインシデント対応チームで、問題の可能性があればCloudflare従業員は誰でもSIRTに警告できることになっています。03:30 UTCに、Cloudflareの従業員がSIRTにメールを送信しました。このメールには、03:22 UTCに送られたツイートへのリンクが貼られていました。ツイートの内容は、Oktaがハッキングにあった可能性があるというものでした。その後２時間にわたり、複数のCloudflare従業員がSIRTに通報しました。
下のタイムラインは、3:30 UTCの時点で、最初のメールがSIRTへ送られてから当社が実行した主なステップを示しています。
タイムライン（UTC時間）
03:30 - SIRTがツイートの存在に関する最初の警告を受ける
03:38 - SIRTがツイートにCloudflareに関する情報（ロゴ、ユーザー情報）が含まれていることを確認する
03:41 - SIRTが調査を開始するためにインシデントルームを設置し、必要な人員を招集する
03:50 - SIRTが前述のスクリーンショットに名前があったユーザーに関して監査ログ対象のイベント（パスワード変更など）はなかったと結論づける
04:13 - Oktaに直接連絡をとり、当社の調査に役立つ詳細情報提供を依頼する
04:23 - 当社のセキュリティ情報・イベント管理（SIEM）システムに取り込むOktaのログすべてについてレビューを実施し、不審なアクティビティ（過去3か月間のパスワードリセットなど）がないかを確認する
05:03 - SIRTが影響を受けた可能性のあるユーザーのアカウントを停止する
当社では、ハッカーのスクリーンショットにメールアドレスが含まれていたCloudflare従業員のアクセスを一時停止しました。
05:06 - SIRTが影響を受けたユーザーの有無を確認するため、アクセスログ（IP、ロケーション、多要素認証）の調査を開始
05:38 - Matthew Princeが、初めてツイートでセキュリティ侵害の事実を認める
一連の状況から、Okta顧客アカウントのパスワード強制リセットなどが可能なアクセスを持つOktaサポートスタッフが不正アクセスを受けていたため、当社では、12月1日から今日までにパスワードをリセットしたか多要素認証（MFA）を何らかの形で変更した従業員すべてについて調べることにしました。2021年12月1日以来、144名のCloudflare従業員がパスワードのリセットまたはMFAの変更を行っていました。144名全員についてパスワードを強制リセットし、変更を本人に連絡しました。
05:44 - 過去3か月間にパスワードを変更したユーザー全員のリスト化が完了。全アカウントでパスワードリセットを実行
06:40 - Matthew Princeから、パスワードリセットについてツイート
07:57 - Oktaから、Cloudflareインスタンスのサポートコンソールには悪意あるアクティビティを示すようなイベントが検出されなかった旨の確認連絡が入る
CloudflareのOkta利用方法
Cloudflareでは社内のIDプロバイダーとしてOkta利用しています。当社のユーザーが安全に社内リソースへアクセスできるようCloudflare Accessと統合しています。前回のブログ記事にて、社内リソースを保護するためのAccessの使用方法と、当社のユーザー認証プロセスの耐障害性を高めるためのハードウェアトークンの強化方法、アカウント乗っ取りに対する防衛方法についてご紹介しました。
Oktaでセキュリティ侵害が生じれば、ユーザーのパスワードを変更するだけでは不十分でしょう。攻撃者も、そのユーザー用に設定されたハードウェア（FIDO）トークンを変更する必要があります。そのため、関係するハードウェアキーをもとに侵害されたアカウントを見つけるのはさほど困難ではありません。
ログはOktaのコンソールで見ることができますが、当社では独自にシステム上でも保存しています。これは、セキュリティレイヤーをさらに1つ追加することになります。Cloudflareでは、Oktaのコンソールよりも長期間ログを保存できるからです。別途保存することで、Oktaプラットフォームのセキュリティが侵害されても、当社で先に収集、保存した証拠は改ざんを免れます。
Oktaは、当社システムでの顧客認証には使われておらず、顧客データをOktaに保存することは一切ありません。Oktaはあくまで、当社従業員のアカウントの管理にのみ使用されています。
このインシデント中に当社がとった主なアクションは次のとおりです。
- Oktaに連絡し、攻撃に関する詳細な情報を収集。
- スクリーンショットで見えていたCloudflareアカウント1件を停止。
- 不正アクセスによるセキュリティ侵害の痕跡（パスワード変更、ハードウェアトークンの変更など）がないか、Oktaのシステムログを調査。CloudflareではOktaのシステムログを5分毎に読み、自社のSIEMに保存します。そうすることで、今回のようなインシデントが当社に起きた場合に、Oktaのダッシュボードで閲覧可能な90日分より前に遡ってログ記録を検証できます。当社がOkta内で探したイベントのタイプは、
user.account.reset_password、user.mfa.factor.update、system.mfa.factor.deactivate、user.mfa.attempt_bypass、user.session.impersonation.initiateなどです。これまでにOktaから受け取った情報を見る限り、Oktaのサポートスタッフのセキュリティ侵害で、当社の推定するシステムログアクターに該当するものは不明です。 - Google Workplaceのメールログでパスワードリセットを検索。Oktaに不正アクセスがあったと考えられること、また、Oktaのログがどの程度信頼できるか確信が持てなかったことから、別のソースを使ってパスワードリセットがOktaのシステムログと一致することを確認しました。
- 過去3か月にパスワードを変更したCloudflare従業員のアカウントをリスト化し、該当者全員に新しいパスワードへのリセットを義務づけ。アカウント復元の一環として、各ユーザーはCloudflare ITチームとのビデオ通話を通じて本人確認を行ったのち、アカウントを再有効化しました。
Oktaの利用者がすべきこと
お客様ご自身もOktaを利用されている場合は、Oktaに連絡して、詳細情報を入手する必要があります。当社では、次のアクションをお勧めします。
- すべてのユーザーアカウントでMFAを有効化。パスワードだけでは、攻撃を退けるために必要なレベルの保護はできません。ハードキーの使用を強くお勧めします。MFAの他の方法では、フィッシング攻撃に対し脆弱になる可能性があるためです。
- 調査と対応：
a. お客様のOktaインスタンスについて、すべてのパスワード変更とMFA変更を確認
b. サポートから開始されたイベントについて特に注視
c. すべてのパスワードリセットが有効であることを確認、あるいは、とにかくすべてを不審と想定して新しいパスワードへのリセットを強制
d. 不審なMFA関連イベントに気づいたら、ユーザーアカウント設定にあるのは有効なMFAキーだけであることを確認 - セキュリティ対策のいずれかが破られた場合に備え、他のセキュリティレイヤーを設けてセキュリティを強化
まとめ
CloudflareのセキュリティチームとITチームは、今後も引き続き今回のセキュリティ侵害を調べます。1月の該当期間以外に生じたセキュリティ侵害を示す新情報が入りましたら、判明した事実と対応アクションを詳説した記事を公開します。
Oktaとも連絡をとり合い、ログや情報の追加提供を何度も依頼しています。当社の状況評価を変えるような事実が判明しましたら、このブログを更新するか、別途記事を投稿します。