先月、セキュリティ研究者がSalesloft Driftの問題について警告を発した際、2つの著名なサイバーセキュリティ企業が同じ脅威に直面しましたが、彼らの物語は異なる展開を見せました。
アイデンティティ管理分野の大手であるOktaとZscalerは、今年最大級のサプライチェーン攻撃の1つで標的となった700社以上のDrift顧客の中に含まれていました。Googleのセキュリティ研究者がSalesforce顧客データの大規模な窃盗を狙ったこの事件について警告を発してから1週間以内に、両社は被害の深刻さを把握するための対応を開始しました。
両社の経験は大きく異なりました。Oktaのセキュリティ対策は被害の拡大を阻止しましたが、Zscalerは運悪く顧客および社内データへの不正アクセスに対処しなければなりませんでした。同じ攻撃者、同じタイムライン、しかし結果は正反対でした。
このようなインシデントと対応の違いは、サイバーセキュリティ戦略が実際にどのように機能するかを理解する貴重な機会となります。CyberScoopは両社のセキュリティリーダーにインタビューし、攻撃の経緯や今後自社や他社の防御を強化するための教訓について話を聞きました。
警告からインシデント発生まで
Salesloftは攻撃の包括的な根本原因分析を公表していませんが、調査の初期結果によると、脅威グループが3月にはすでに同社のGitHubアカウントにアクセスしていたことが判明しています。GoogleがUNC6395として追跡しているこのグループは、Salesloftアプリケーション環境内でラテラルムーブメントを実現し、ワークフローを設定した後、DriftのAmazon Web Services環境にアクセスし、Drift顧客が使用するOAuthトークンを取得しました。
これらのトークンにより、脅威グループはDriftと統合された別のプラットフォームからデータにアクセスし、窃取することができました。Driftは主に営業チームが利用するAIチャットエージェントです。Googleによれば、この「大規模なデータ窃盗キャンペーン」は8月中旬の10日間にわたって行われました。20社以上のサイバーセキュリティベンダーを含む約40社が、この攻撃の影響を受けたことを公表しています。
Zscalerはデータ窃盗が終了してから1週間後、Salesforceから最初のセキュリティアラートを受け取りました。そこでは、認可されていないIPアドレスがDriftのOAuthトークン用APIを使用していると警告されていました。Zscalerは直ちにトークンを無効化しましたが、「その時点ではもう意味がなかった」と同社の最高情報セキュリティ責任者であるSam Curry氏は語っています。
被害はすでに発生していました。Zscalerの多くの顧客データが流出し、氏名、業務用メールアドレス、役職、電話番号、所在地の詳細、Zscaler製品のライセンスや商業情報、一部サポートケースの平文内容などが含まれていました。
防御のためのIP制限
OktaはDriftを利用しているため、脅威インテリジェンスの専門家がサービスの問題を警告し始めた際、積極的に侵害の兆候を調査しました。同社の最高セキュリティ責任者であるDavid Bradbury氏はCyberScoopに対し、セキュリティ目的で手動設定したIP範囲外からDriftトークンを使おうとする「短期間の試行」があったと語りました。
この制御により攻撃は阻止され、OktaのDrift統合は安全に保たれました。しかし、多くの企業はこのアプローチを取っていません。APIコールのIP制限は手動かつ多大な労力を要し、サプライチェーン内のすべてのベンダーの協力が必要だからです。
「このような問題に真剣に取り組めば、数日や数週間の継続的なテストや調査、発見を要するのではなく、数クリックでIP制限を実装できるような解決策を考案できるはずです」とBradbury氏は述べています。
Oktaの調査では、ほぼ自動化された脅威キャンペーンであることが判明しました。「彼らは持続的ではありませんでした」とBradbury氏。「現時点での仮説は、すべてを一度に攻撃し、一連のイベントで情報を一気に引き出すよう設計された単一の重要なスクリプトが使われたというものです。」
Zscalerの侵害が特に悔やまれるのはタイミングの問題でした。同社は7月にすでにDriftの利用を停止しており、その決定はセキュリティとは全く関係なく、攻撃キャンペーンの兆候が明らかになる前に下されていました。
「[Drift]で使われていたOAuthトークンはまだ有効でした」とCurry氏。「8月末には廃止予定でしたが、それはトークンが完全に切断され、もはや使用されていないことを確認するための意図的な遅延でした」と述べています。
トークン窃盗の原因は依然不明
Salesloftは、脅威グループがどのようにしてGitHubアカウントにアクセスしたのか、またどのようにDriftのAWS環境にアクセスし最終的に顧客のOAuthトークンを取得したのかについて説明していません。
「実際にどうやってトークンを持ち出したのかは分かりません。ただ、持ち出されたことは確かです」とCurry氏。「内部でどう保管していたのかも分かりませんが、当社のセキュリティ質問票や、恐らく何百、何千という他社のサードパーティリスク管理にも合格していたのでしょう」と付け加えています。
Oktaもまた、脅威グループがどのように自社のSalesloft Drift OAuthトークンにアクセスしたのか分かっていません。その情報はSalesloftから提供される必要があるとBradbury氏は述べています。
「インターネットは非常にもろくて小さな情報の断片、つまり私たちが常に話題にするこれらのトークン、最終的に私たちが使うすべてのアプリケーションへのアクセスを提供する文字と数字の組み合わせによってつながっています」と彼は語ります。
「これらのトークンはどこかに保管される必要があり、残念ながら現状ではこれらのトークンを何かに直接紐付けて再利用を防ぐ仕組みが必ずしも存在しません」とBradbury氏は付け加えました。
ほとんどのSaaSアプリケーションは、トークンや認証をかなり初歩的な方法で実装しています。「彼らは簡単で機能する方法を選んでいます。実際に機能するのは、一度アクセスを許可したらどこかにトークンを保管しておくことです」と彼は述べています。
集団防衛のための教訓
Salesloft Drift攻撃後の経験は大きく異なりましたが、Bradbury氏とCurry氏は、数百社に影響を与えたサードパーティ侵害から多くの共通した教訓を得たと語ります。
「APIは新たなアクセス経路となりつつあり、より多くの制御が必要ですし、私たち全体でより良い制御が必要です」とCurry氏。「APIはできることの幅が広がっており、それらを監視し、行動変化を検知する予防的な制御を施す能力が必要です。」
Zscalerはもう一つ重要な教訓を痛感しました。それは、APIクエリのIPアドレス範囲を制限し、トークンをより頻繁にローテーションする重要性です。
「私にとって今回の警鐘は、APIが新たな攻撃・制御プレーンとなっており、単なるリスク評価から想像する以上に露出しているということです」とCurry氏は述べています。
「APIでつながった世界には“小さなベンダー”など存在しません。国境警備を考えてみれば分かりますが、“小さくて取るに足らない入国港”などないのです」と彼は付け加えました。「すべて同じ高速道路システムを使っているのです。」
今回の悪質なキャンペーンでOktaが被害を免れたことに満足しているBradbury氏ですが、未承認トークン利用を防ぐためには、より良く安全な方法があると考えているため、やや苛立ちも感じています。このサプライチェーン攻撃の中心的な問題は、Demonstrating Proof of Possession（DPoP）という、トークンの利用を特定クライアントに限定し盗難トークンの利用を防ぐ仕組みで回避できたはずだと彼は述べています。
一度攻撃者が制限なく再利用できるトークンを盗むと、すべての関係者に壊滅的な結果が待っていますとBradbury氏は付け加えました。
「より多くのSaaSベンダーが、顧客の成長や収益につながる機能だけでなく、セキュリティ機能をロードマップ上で優先する必要があります」と彼は述べています。
セキュリティリーダーは、ベンダーにこれらの変更を要求する重要な役割を担っています。「私たちの集団的な意志を使って、セキュリティの基準を引き上げ、ベンダーに責任を持たせる時が来ています」とBradbury氏は語ります。
Curry氏も同様に前向きな姿勢を示しています。「互いに学び合い、傷ついた者を責めるのはやめましょう」と彼は述べています。
「事後、冷静になってから皆で何が起きたかを見直すことになるでしょう」とCurry氏は付け加えました。「今は責任追及には興味がありません。より良いセキュリティに関心があります。」
翻訳元: https://cyberscoop.com/okta-zscaler-security-leaders-salesloft-drift-attacks/
