セキュリティの話題は、たいてい何かが壊れたところから始まります。しかし今回のケースは、すべてが設計通りに動作していたところから始まりました。
Recoの研究者たちは、City-Forumと呼ばれるキャンペーンを追跡してきました。この名前は2002年に登録され、その後放棄され、現在はドイツのホスティングプロバイダーが提供する汎用のレンタルサーバーに解決されているドメインに由来します。何者かが、このサーバーを起点に、世界各地のSalesforceおよびServiceNowポータルからレコードを抜き取ってきたのです。
この活動は現在も継続しており、むしろ規模を拡大しています。Recoがこのアドレスから観測したリクエストは、すべてゲストとして到着していました。標的となった組織は、通信事業者、銀行や金融サービス企業、セキュリティやデータプライバシー企業を含むエンタープライズソフトウェアベンダー、そして公共部門のポータルなど多岐にわたります。
パッシブDNSから判明しているのは、このドメインが少なくとも2025年3月以降このアドレスに解決されてきたということです。つまり、このインフラはしばらく前から稼働していたことになります。ただし、スキャンがいつ始まったのかはまた別の問題です。
ここで注目すべき点があります。ソフトウェアの脆弱性は一切悪用されていません。認証情報も必要ありませんでした。パッチを当てるべき脆弱性も存在しません。攻撃者は匿名の訪問者として公開の顧客ポータルにアクセスし、礼儀正しく、そして繰り返し、コンテンツを求めただけです。そしてポータルはそれに応じてしまったのです。
部屋の中にいたゲスト
Salesforceは、Experience Cloudサイトごとに「ゲストユーザー」と呼ばれる常設アカウントを与えており、ServiceNowの各インスタンスにも同様のものが存在します。これは他のユーザーと同じく、プロファイルと権限を持つ実在のユーザーです。認証されていない見知らぬ訪問者がサポートポータルやナレッジベースを読み込むとき、その訪問者はこのゲストユーザーとして閲覧していることになります。ゲストユーザーはオプションではなく、削除することもできません。そして、誰かがある時点で設定した権限を持って存在しています。
これらのポータルから流出したものはすべて、そもそも提供するよう設定されていたものにすぎません。
Recoのセキュリティ研究者であるNitay Bachrach氏は、根本的な問題をこう説明しています。「核心的な問題は、『何が公開されているか』と『何が公開されるべきか』がまったく別のものだということです。そして、まさにそこを攻撃者は突いてきました」
このキャンペーンが際立つ理由
過剰な権限を持つSalesforceのゲストユーザーを悪用する攻撃者はこれまでも存在しており、そのための既製ツールも出回っています。しかし今回の攻撃者は、それらを使いませんでした。
代わりに独自のツールを構築していたのです。とはいえ、結果として生じたトラフィックの大半は、よく知られたルートをたどっていました。すなわち、Salesforceの旧型フレームワークであるAuraです。このフレームワークのゲストユーザーは、長らく標的として知られており、Recoも同様の手口による過去のキャンペーンについてすでにレポートを公開しています。今回の攻撃者のSalesforceに対する取り組みの大部分も、ここに集中していました。Recoが観測した中で最も攻撃を受けたある標的では、このキャンペーン期間中にこの1つのアドレスだけで56万件を超えるイベントが記録されており、そのほぼすべてがAuraの列挙操作でした。
このキャンペーンが読む価値を持つのは、残りのツールキットの部分です。誰も目を向けていなかった2つの箇所を狙っていたのです。1つ目は、Salesforceの新しいサイトフレームワークの背後にあるデータレイヤーで、既存の攻撃ツールはここを完全に無視しています。Recoはこれを「攻撃者側の死角」と表現しています。2つ目は、ServiceNowのポータル検索エンドポイントで、これはServiceNowが公式リファレンスすら公開していないほど文書化されていないものです。Recoは、標準的なポータルの検索ボックスの裏にあるコードを読み解くことで、その挙動を突き止めました。ただし、これが危険なのは文書化されていないからではありません。このエンドポイントは設計上公開されており、何が返されるかは、その背後にあるソースの設定次第で決まるという点が問題なのです。
プラットフォームに標準搭載されている最も一般的な2つのソースのうち、一方はデータにアクセスする前にログイン状態を確認します。しかし、もう一方にはそうしたチェックが一切ありません。各ナレッジベースへの読み取りアクセス権が誰に付与されているかにすべて依存しており、これは設定の問題であって、コード側には注意を促す仕組みが何もありません。
この2つはまったく異なる振る舞いを見せます。Salesforce側では、新しい手法による攻撃はAuraへの大量アクセスに比べると薄く、見つけた各サブサイトの各APIバージョンに対して数件のリクエストを送る程度でした。これは、Auraサイトが依然としてより一般的な標的である状況を踏まえれば、おおむね予想通りの規模です。一方、ServiceNow側ではまったく逆でした。ツールがひとたびポータルを見つけると、そこで行われる操作のほぼすべてがあの検索エンドポイントに集中していたのです。両者はいずれも、攻撃者が入念に下調べを行っていたことを物語っています。これらのプラットフォームに腰を据えて向き合い、きちんと学習した上で、どのスキャナーもチェックしていない「扉」を探し出した人物の姿が浮かび上がります。
それが誰なのかについて、Recoは明言を避けています。この活動は、AuraおよびGraphQLを介したSalesforceのゲスト列挙を特徴とするShinyHuntersのExperience Cloudキャンペーンに似ています。しかしRecoの立場は、あるキャンペーンがあるグループの既知の手口と一致しないからといって、それ自体では何の証明にもならないというものです。攻撃者はツールを頻繁に書き換え、新しいサーバーを次々とレンタルするからです。それでもこれらのキャンペーンと1点だけ異なる部分があり、Recoはこれを断定的な指摘ではなく、あくまで弱い兆候として提示しています。今回の攻撃者は、少なくとも17か月にわたり単一のアドレスを保持し続けており、一度もローテーションしていないのです。
厄介な点:何が流出したのかが見えない
仮に、あなた自身のログの中にこのトラフィックを見つけたとしましょう。しかし、そこから分かることは思ったより少ないはずです。
ServiceNowでは、トランザクションログに検索が行われたことと、返されたおおよそのデータ量は記録されますが、検索語そのものは記録されません。応答サイズこそが、何が返されたのかを示す唯一の手がかりであり、これについては後述の最終セクションで扱います。Salesforceはより多くの情報を提供しますが、それでも疑問を完全に解消するには十分ではありません。Bachrach氏はこう説明しています。「Salesforceは、何が試みられたか(どのAuraアクション、LWR GraphQLのバージョンスイープURI、自己登録の試行など)については比較的よく分かります。しかし、Event Monitoringでは、どのレコードやフィールドが返されたのかまでは分かりません」
つまり、ログから分かるのは「何が試みられたか」であって、「何が持ち去られたか」ではないのです。この当然の疑問について、Bachrach氏はこう述べています。「監査ログだけをもとに、何が漏えいしたかを特定することはできません。組織側で内部的にリクエストを再現し、そのレスポンスを分析する必要があります」
言い換えれば、匿名の訪問者が何を読み取れたのかを知るには、自組織の誰かが実際に匿名訪問者になってみる必要があるということです。
少なくともServiceNowに関しては、これを行う際に一つの落とし穴があります。ポータルの検索エンドポイントは、返すべきデータがあってもなくても、匿名リクエストに対して同じHTTP 201を返します。つまり、情報が漏れているポータルと、しっかり閉じているポータルは、外側から見ると見分けがつきません。両者を分けるのは、返ってきた本文が空かどうかだけです。正常に返ってきたプローブも、その中身を読むまでは何も語ってくれません。攻撃者自身も同じ曖昧さに直面していましたが、それを一つの手法へと転化させました。どの検索語が中身のあるレスポンスを返すかを丹念に調べることで、各ポータルのコンテンツをマッピングしていたのです。
これが顧客への通知が必要な事態に発展するのはどの段階かについて、Bachrach氏はこう述べています。「そのデータに個人識別情報(PII)やその他の非公開データが含まれる場合、顧客に通知すべきです」。これらのレコードは、技術的には誰でもアクセス可能な状態にありました。しかし、それが本来アクセス可能であるべきだったかどうかこそが、事後に誰へ電話をかけるべきかを左右する部分なのです。
両プラットフォームに共通する同じ過ち
最も頻繁に見られた設定ミスは何かと問われ、Bachrach氏は一つを挙げています。「最も頻度の高い設定ミスは、ゲスト/匿名ユーザーへの過剰な権限付与でした。これが両プラットフォームに共通する根本原因でした」
また同氏は、最も効果の高い対策と最も一般的な問題とを区別してこう述べています。「Salesforceのゲスト共有ルールは、最も効果の高い対策ですが、必ずしも最も一般的な設定ミスというわけではありません」。てこの効果が最も大きいのは共有ルールなので、まずそこから着手すべきですが、そこで止まって「対応は完了した」と思い込んではいけません。
これは決して華やかな作業ではなく、ServiceNowにおいては単なる権限設定画面の見直し以上の対応が必要になります。しかし、これは有限の作業であり、一方であのサーバーは少なくとも2025年3月から今も稼働し続けているのです。
このトラフィックを発見した場合、次に何をすべきか
Bachrach氏は、発見直後の1時間で行うべき対応を示しています。まず、このパターンに該当するかどうかを確認してください。
Salesforceでは、Event Monitoringの AuraRequest と Sites のエントリのうち、USER_TYPE = ‘Guest’ のものを確認し、getItems や getConfigData の大量呼び出し、/webruntime/…/vNN.0/graphql に対するバージョンスイープ、そして /SiteRegister や /CommunitiesSelfReg へのアクセスがないか探してください。
ServiceNowでは、syslog_transaction 内で、ゲストとして行われた /api/now/sp/search へのリクエストを確認してください。その上で、これらの行を出力サイズの順に並べ替えます。結果が空の場合、サイズは小さく一定になるため、それを大きく上回るものはレコードを含む結果が返された検索と判断できます。まずはそこから確認を始めてください。
次に、是正措置を行います。Salesforceの場合:
- ゲスト共有ルールを厳格化する。
- ゲストのオブジェクト権限およびフィールド権限を剥奪する。
- ゲストユーザーの「Access Activities」と「API Enabled」を無効化する。
- 不要であれば自己登録機能を無効化する。
- ゲストによるファイルアクセスとメンバー可視性を無効化する。
- LWRサイトでは、不要であれば「Allow guest users to access public APIs」を無効化する。
ServiceNowの場合:
- ゲストポータルとその検索ソース、そしてそれらのソースに紐づくスクリプトの対応関係を洗い出す。
- ナレッジベースの「Can Read」ユーザー基準を見直し、無制限の「Any User」アクセスがないか確認する。
- ポータルで有効化されているスクリプト検索ソース(sp_search_source)を見直す。
- 共有の基準を直接編集するのではなく、不適切な kb_uc_can_read_mtom のリンクを個別に切り離す。
翻訳元: https://www.helpnetsecurity.com/2026/08/12/salesforce-servicenow-guest-user-exposure/
