ベンダーの侵害が自社の問題になるとき：Klueインシデントから学ぶ教訓

どのセキュリティチームもいずれ直面する、受け入れがたい事実があります。最も大きな被害をもたらす侵害は、自社の内部で起きるとは限りません。コードにパッチを適用し、定期的にシークレットをローテーションし、境界防御を強化していても、自社が所有していないシステムが原因でインシデントが起き、目を覚ますことがあるのです。

今回のKlueをめぐるインシデントが、まさにその典型です。Klueは、幅広い企業が競合情報の収集に利用する市場インテリジェンスプラットフォームです。公表されている情報によると、脅威アクターはKlueのバックエンドを侵害し、その足がかりを利用して、Klueの顧客がプラットフォームと連携させていたSalesforce環境など、顧客の接続システムにアクセスしました。また、Recorded Future、Tanium、Huntress、Jamfなど、ほかのセキュリティベンダーも影響を受け、最新情報を公表しています。何が起きたのかを詳しく見てみる価値があります。今回の攻撃の仕組みは、現代のSoftware as a Service（SaaS）エコシステムがどのように侵害されるかを明確に示しているからです。

インシデントの全容

これまでに公表された情報によると、攻撃はおおむね次のように進みました。

Klueへの最初の侵入経路となったのは、古い認証情報でした。報道によれば、これはかつて連携機能のプロトタイプ用に作成されたものの、プロジェクトが中止された後も無効化されずに残っていました。アクセス権は、それが作られたプロジェクトの終了後も有効なままでした。脅威アクターがそれを見つけ、しかもまだ使えたのです。

そこから攻撃者は、Klueのプラットフォームと顧客のツールを接続するインフラにアクセスしました。これらの連携にはOAuthトークンが使われています。KlueがSalesforceなどのシステムに顧客に代わってデータを読み書きできるよう、継続的にアクセスを許可するものです。攻撃者は、こうしたトークンを窃取するコードを仕込みました。トークンを手に入れた攻撃者は、顧客ごとに侵入する必要がなくなりました。連携機能のシークレットを使い、発見したサービスアカウントになりすまして認証し、各顧客の顧客関係管理（CRM）データを直接照会して、外部に持ち出すことができたのです。その後、恐喝の試みが行われました。

詳細を取り除くと、見えてくるのはおなじみの構図です。ひとつの弱点、預けられた複数の鍵、そして接続先すべてに及ぶ被害範囲。ひとつの侵害は一社だけにとどまらず、連鎖していきました。

Snykについて

あらゆるベンダーに期待する透明性を大切にし、率直にお伝えします。SnykもKlueのインシデントの影響を受けた組織のひとつです。現時点での調査では、影響は主にSalesforce環境内の業務データ項目に限られていたと認識しています。対象には、顧客の業務用連絡先情報と、限られた一部のカスタマーサポート案件のタイトルおよび説明のみが含まれます。サポート案件の本文や内容は含まれておらず、Snykの製品にも影響はありませんでした。お客様へのサービス提供にも支障はありません。

通知を受けて、Salesforce内のKlue連携を無効化し、独自の調査を開始するとともに、関係者と連携しました。現在の状況と最新情報については、status.snyk.ioまたはSnyk Trust Centerをご覧ください。調査の進展に合わせて、両方のページを更新していきます。

今回の件に限らず、皆さんにぜひ実践していただきたいことがひとつあります。付与した認証情報と、作成したことさえ忘れていた認証情報を確認してください。