「City-Forum」キャンペーン：脆弱性ゼロで17ヶ月間、SalesforceとServiceNowからデータを盗み続けた手口

脆弱性は不要：攻撃の仕組み

SalesforceとServiceNowの両プラットフォームには、認証されていない訪問者用の永続的なゲストユーザーアカウントが標準で備わっています。このゲストユーザーは削除できません。各組織がその権限—どのレコードやオブジェクトを読み取り可能にするか—を設定する仕組みです。ゲストプロファイルが特定のレコードへの読み取りアクセスを持っている場合、インターネット上の誰もが、完全に正当なAPIエンドポイントを通じてそのデータを取得できてしまいます。

Salesforce（Auraフレームワーク）の場合：

• ツールは /aura または /s/sfsites/aura エンドポイントにPOSTリクエストを送信します。
• まず HostConfigController.getConfigData を呼び出し、ゲストがアクセス可能なオブジェクト（Account, Contact, Case, Lead, User, ContentDocumentなど）を列挙します。
• 次に SelectableListDataProviderController.getItems を使用し、アクセス可能な各オブジェクトの全レコードをページングしながら取得します。
• 最も多く標的となったサイトでは、攻撃元IPから56万件以上のイベントが記録されており、そのほとんどがゲストによるAuraの列挙でした。

Salesforce（LWRフレームワーク：Lightning Web Runtime）の場合：

• これは、SalesforceのLWRサイトにおけるUI-APIゲスト面が実際の攻撃で悪用された初めての事例です。
• ツールは

  POST /webruntime/api/services/data/{version}/graphql?asGuest=true

  のGraphQLエンドポイントを標的にします。まず EntityDefinition でスキーマを列挙し、その後カーソルベースのページネーションでレコードを読み取ります。
• 発見したLWRサイトごとに、APIバージョンv56.0からv66.0までを順にスキャンします。

ServiceNowの場合：

• ツールは /api/now/sp/search エンドポイントを標的にします。これはService Portalの標準検索APIですが、ほとんど文書化されておらず、オンライン上のドキュメントや関連するオープンソースツールもほとんど存在しません。
• このエンドポイントは設計上公開されています。どのようなデータが返されるかは、ゲスト向けポータルにどの検索ソースがアタッチされ、それらのソースがアクセス制御を適用しているかどうかに完全に依存します。

セルフ登録のプローブ（Salesforce）：

• ツールは、発見したすべてのエクスペリエンスサイトのパスに /SiteRegister と /CommunitiesSelfReg を付加し、セルフ登録が有効かどうかをテストします。有効な場合、ゲストは認証済みの外部ユーザーに昇格でき、はるかに多くのデータにアクセスできるようになります。

カスタムツールとインフラ

• 攻撃元IP： 158.220.87.79（ドイツのホスティングプロバイダContaboのVPS）。ドメイン city-forum.com（2002年に登録され、その後放棄され、再利用されたドメイン）に解決されます。
• このIPは2025年3月以降、同一のドメインを保持したまま、少なくとも17ヶ月間ローテーションされていません。
• カスタムGoバイナリ： 1つのGoでコンパイルされたツールが、同一サーバーからSalesforceのAuraとLWRの両フレームワーク、およびServiceNowを標的にします。これはAuraInspectorのような既製のツールではなく、カスタムのマルチプラットフォームツールセットです。
• このツールはGoのデフォルトの Go-http-client User-Agent文字列を使用するため、ログでの識別が容易です。

標的となった組織

Recoの報告によると、主な標的は以下の通りです。

• 通信事業者
• 銀行および金融サービス企業
• エンタープライズソフトウェアベンダー（セキュリティ企業やデータプライバシー企業を含む）
• 公共部門のポータル

標準の監査ログでは、どのデータが盗まれたかがわからない理由

ServiceNowの場合： プラットフォームのトランザクションログ（syslog_transaction）は、/api/now/sp/search リクエストのPOSTボディを記録しません。防御側は、自動化された検索が発生したことと、返されたデータのおおよその量（出力長列で確認）を知ることはできますが、正確な検索語や、どの特定のレコードが取得されたかは特定できません。

Salesforceの場合： ゲストの列挙トラフィックは、通常のサイトトラフィックと見分けがつかない、正当でプロトコルに準拠したAPI呼び出しです。イベントモニタリングは、ゲストユーザーからの AuraRequest や Sites イベントの量を示すことはできますが、GraphQLやAuraのレスポンスで返された具体的な内容までは記録しません。

つまり、攻撃者がいたことと、どれだけのデータを取得したかはわかっても、どのレコードやフィールドが抽出されたのかを正確に再構築することはできないのです。

推奨される対策

Salesforce向け（Reco推奨）

1. ゲスト共有ルールを厳格化する — 最も効果的な対策です。サイトが公開目的で本当に必要とする以上のレコードをゲストユーザーと共有するルールを削除します。
2. ゲストプロファイルからオブジェクト・フィールドレベルの権限を剥奪する。匿名訪問者に不要なオブジェクトへの読み取りアクセスを削除します。
3. ゲストプロファイルから「アクセス権（Access Activities）」権限を削除する（これによりTaskやEventが露出します）。
4. ゲストユーザーの「API有効（API Enabled）」を無効にする。
5. サイトで本当に必要でない限り、セルフ登録を無効にする。
6. ゲストによるファイルアクセスとメンバー表示を無効にする。これにより、ゲストがContentDocumentファイルを取得したり、他のサイトメンバーを列挙したりすることを防ぎます。
7. LWRサイトのみ： Experience Builder → ワークスペース → 管理 → 環境設定で、「ゲストユーザーによるパブリックAPIへのアクセスを許可」のチェックを外す。これにより、GraphQLとUI-API RESTエンドポイントが一度に閉じられます。

ServiceNow向け（Reco推奨）

1. ゲスト向けポータルとその検索ソースをマッピングする。sp_portal、m2m_sp_portal_search_source、sp_search_source テーブルを確認し、公開ポータルに不要な検索ソースをデタッチします。
2. 各検索ソースのロジックをレビューする — 特に is_scripted_source、data_fetch_script、そしてACLを適用する GlideRecordSecure と適用しない GlideRecord のどちらを使用しているかを確認します。
3. ナレッジベースの「読み取り可能（Can Read）」ユーザー条件をレビューする — 制約のない「すべてのユーザー（Any User）」アクセスが設定され、ゲスト検索で機密KBが露出していないか確認します。
4. 盲目的に共有ルールを編集するのではなく、問題のある kb_uc_can_read_mtom リンクをデタッチする。

検出の手引き

• Salesforceイベントモニタリング：

  USER_TYPE = 'Guest'

  からの getItems や getConfigData の高頻度な発生、/webruntime/.../vNN.0/graphql のバージョンスイープ、/SiteRegister や /CommunitiesSelfReg へのアクセスを監視します。
• ServiceNow syslog_transaction： ゲストとして行われた /api/now/sp/search リクエストを監視します。出力長でソートし、小さな空の結果ベースラインよりも著しく大きな行は、データが返された検索を示しています。