Salesforce Agentforceに存在する複数の脆弱性を、研究者らは総称して「Salesbleed」と名付けました。これらを悪用されると、顧客の社内データが流出するおそれがあります。さらに悪いことに、攻撃者が信頼された社内チャンネルの内側から従業員をフィッシングできてしまいます。
顧客や投資家を熱狂させる強力で相互接続されたAIプラットフォームでは、セキュリティと可視性の確保が依然として難題であり、今回も例外ではありません。Zenityの研究者らによると、Agentforceにある3つの「Salesbleed」の弱点を突くと、ハッカーはWeb-to-leadフォームを通じて被害者のデータを少しずつ抜き取れます。ただ、最も興味深いのは、一見すると軽微なこのWeb-to-leadの脆弱性を通常のAgentforceのワークフローと組み合わせることで、最終的に最も信頼されているSlackチャンネルの内側から従業員をフィッシングできる点です。
SalesforceのWeb-to-leadフォームの問題を発展させた攻撃
1年前、Noma Securityの研究者らは、Salesforceを使って企業データを盗み出す巧妙な手法を明らかにしました。この手口の起点はWeb-to-leadフォームです。インターネット上で、企業が見知らぬ個人から送られるほぼ任意のデータを自ら受け入れる、数少ない場面の1つです。基本的な流れは、見込み客が何かにアクセスするために登録フォームへ記入し、そのリードデータがSalesforceに取り込まれるというものです。従来、攻撃者はWeb-to-leadフォームを使って悪意のあるコードを送り込むことがありました。エージェントの時代になった今、研究者らは悪意のあるプロンプトを送れると考えました。
攻撃者が標的企業でAgentforceのAIエージェントが稼働していると見込んだ場合、巧妙に細工したAIへの指示をWeb-to-leadフォームに仕込めることが判明しました。たとえば、攻撃者が管理するURLへデータを送出させる指示です。やり取りの受け手側にいるエージェントはこの指示を取り込んで処理し、被害企業の環境内でその要求を実行します。Noma側の発見に対し、Salesforceは攻撃者が悪用しうるURLに関するルールを速やかに整備して対応しました。ただ、Dark Readingは当時、「AIが指示を処理する仕組みそのものの構造的な修正は、今のところ見通しが立っていない」と指摘していました。
この応急処置は根本的な感染を治療できていませんでした。1年後の今、Zenityの新たな研究者チームは、昨年の発見を受けてSalesforceが導入したURLフィルタリングのルールを単純な回避策でかいくぐり、ほぼ同じ攻撃を実行できることを突き止めました。
研究者らは、この攻撃がいかに手軽かを強調しています。まず、Web-to-leadフォームを使う通りすがりのインターネット上の悪党を特定したり、アカウントを停止したり、その他の方法で処罰したりする手段はありません。さらに、攻撃者はAIエージェントに自分の代わりに作業させることで、Salesforceの顧客が自社のボットに与えている、たいていは十分に広い権限に苦もなく便乗できます。
Salesforceエージェント経由でSlackを悪用
Zenityのエクスプロイトには、1つだけ欠点がありました。1回のプロンプトで攻撃者が流出させられるデータは、1つのサブドメイン文字列に収まる量に限られていました。よほど的を絞ったデータを狙うか、数百から数千回の悪意ある要求を自動化しない限り、大きな被害を与えるには不十分です。
しかし、データの読み取りと送信は、Agentforceのエージェントに与えられた数ある権限のうちの2つにすぎません。エージェントが正規のユーザーのために何でもこなせるのなら、攻撃者のためにも同じことをしてしまうのではないでしょうか。
たとえば、ユーザーはSalesforceのエージェントをSlackに直接展開できます。Slackのエージェントには、データの読み取りや書き込みを可能にする「サブエージェント」という形で、さまざまな権限を割り当てられます。望ましくない動作を防ぐため、エージェントは事前にユーザーの確認を必須とするよう設定できます。また、エージェントの動作の責任者である人間のユーザーを特定する帰属情報の機能も、標準で備わっています。
ところが、エージェントがSlackのスレッドに返信する機能では、これらの制御が欠けていました。Zenityの研究者らはこう推論しました。外部の攻撃者が悪意のあるプロンプトをWeb-to-leadフォームに注入できるなら、データを流出させるだけでなく、Salesforceのボットに社内のSlackスレッドへ返信させる指示も出せるはずです。しかも、それを止める仕組みはありません。メッセージにはソーシャルエンジニアリングを盛り込めます。フィッシングリンクには、先述したSalesforceの信頼済みURL保護の抜け穴を利用します。帰属情報がないため、メッセージは実在の従業員やITヘルプデスクから送られたように見えかねません。信頼された社内コミュニケーションチャンネルでは、誰も悪意を疑わない可能性が高いでしょう。
Salesforce、フィッシング対策でAgentforceを強化
SalesforceはDark Readingへの声明で、これらの脆弱性にCVE番号は付与されていないと説明したうえで、脆弱性の存在を認めました。また、実際の攻撃者が悪用した証拠はないとしています。同社はSlack内の特定のAgentforceアクションについて、「メッセージ送信前にユーザーの確認を必須とするようデフォルト設定を更新しました。あわせて、顧客に直接連絡を取り、設定の見直しと推奨される変更の実施を支援しています」と、広報担当者は書面で回答しました。
同社は、昨年のWeb-to-lead脆弱性への対応が包括的なものではなく、その場しのぎの修正だったことも認めました。今回は、より堅牢だと考える解決策を導入したとしています。
従来、SalesforceのURLリダクション（伏せ字化）制御は、正規表現（regex）によるマッチングでAIエージェントの出力に含まれる信頼できないURLを識別していました。つまり、テキストの文字列がURLのように見えるかどうかを確認していただけです。そのため、巧妙な研究者は想定外の形式でドメインを隠せました。同社によると、現在は仕様に準拠したURLパースを採用しています。これにより、URLの可能性がある文字列がどこに通じるのかを、より的確に分解して解釈できるようになります。
Salesforceは、URLパースの仕組みを刷新したほか、URLの検査プロセスも一本化しています。従来は、エージェント型ワークフローの各部分がそれぞれURLを処理していた可能性があります。現在は、URLに関わるAIのトラフィックがすべて単一のゲートウェイを通過し、より一貫した検査とセキュリティルールが適用されます。
エージェント型技術を悩ませる、より根深い問題
研究者らがSalesforceの修正を再び破るかどうかは、時間がたたないとわかりません。Zenityのアナリストが指摘するように、エージェント型プラットフォームには、URLポリシーでは対処できる範囲を超えた構造的な弱点がさらに存在します。
Zenityのセキュリティ研究ディレクターであるTamir Ishay Sharbat氏は、次のように述べます。「私たちは何年も前から言い続けています。エージェントに与える権限が大きいほど、危険性も高まります。たとえば、エージェントが自らの判断で複数のチャンネルにメッセージを送る権限を持った時点で、悪用の対象になります。さらに、機密情報（買掛金、リード、契約など）と外部チャンネル（Web-to-leadフォームなど）の両方へのアクセスを与えると、この組み合わせは極めて有害です」
この有害な組み合わせに加えて、エージェントには可視性の問題もあります。
Zenityの最高技術責任者（CTO）であるMichael Bargury氏は、こう指摘します。「企業向けソフトウェアを購入するときは、ログが備わっていて、誰が何をなぜ行ったのかがはっきりわかると想定します。ところがエージェントの場合、誰もが急いで開発しているため、市場全体がブラックボックスを作り上げています。そのせいで、信頼しにくくなっているのです」
Bargury氏は「推論の過程も、裏で何をしているかも確認できず、得られるのは要約だけです」と嘆きます。「これはSalesforceだけの問題ではありません。業界全体に広がっています」
