長達17個月的沉默竊取：City-Forum 如何利用訪客權限入侵 Salesforce 與 ServiceNow

安全研究機構 Reco 揭露了一起名為 City-Forum 的持續性資料竊取行動。一個身份不明的攻擊者，至少從 2025 年 3 月起，便利用 Salesforce Experience Cloud 網站與 ServiceNow 服務入口網站中「訪客用戶（Guest User）」的預設權限，在不利用任何軟體漏洞、不竊取憑證、也不繞過身份驗證的情況下，從全球多個組織的系統中靜默提取資料。

這起行動以其攻擊基礎設施所使用的網域 city-forum.com 命名。該攻擊者僅透過一臺位於德國託管商 Contabo 的虛擬私有伺服器（VPS），便系統性地從電信業者、銀行、金融服務公司、企業軟體供應商以及政府入口網站中大量擷取資料。

如何運作：無需漏洞的利用方式

Salesforce 和 ServiceNow 都內建了無法刪除的「訪客用戶（Guest User）」帳號，專門提供給未經身份驗證的訪客使用。這些訪客用戶的權限由各組織設定。在 Reco 的調查中，所有來自攻擊來源 IP 的請求都是以訪客身份發出的。

針對 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 的 UI-API 訪客存取面來攻擊 LWR 網站。
• 工具目標是 GraphQL 端點

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

  ，先透過 EntityDefinition 列舉 Schema，再使用基於游標的分頁技術讀取記錄。
• 它會針對每一個發現的 LWR 網站，依序掃描 API 版本 v56.0 到 v66.0。

針對 ServiceNow：

• 工具攻擊的是 /api/now/sp/search 端點。這是一個原生的服務入口網站搜尋 API，幾乎沒有公開的文件，也幾乎沒有開源工具提及它。
• 這個端點設計上即為公開。它所能回傳的資料完全取決於哪些搜尋來源被附加到這個面對訪客的入口網站，以及這些來源是否強制執行了存取控制。

自我註冊探測 (Salesforce)：

• 工具還會在每一個發現的 Experience Cloud 網站路徑後加上 /SiteRegister 和 /CommunitiesSelfReg，以測試是否啟用了自我註冊功能。一旦啟用，訪客就能升級為已驗證的外部用戶，從而取得更多資料。

自製工具組與基礎設施

• 攻擊來源 IP： 158.220.87.79，託管於德國 Contabo 的 VPS，並解析至網域 city-forum.com（該網域註冊於 2002 年，曾遭棄用後被重新利用）。
• 同一 IP 自 2025 年 3 月 起便一直使用同一網域，持續至少 17 個月未更換。
• 自製 Go 語言二進位檔： 這是一個單一的 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. 移除訪客設定檔中的「存取活動」權限（這會暴露 Tasks 和 Events）。
4. 停用訪客用戶的「API 啟用」 功能。
5. 除非網站確實需要，否則停用自我註冊功能。
6. 停用訪客檔案存取與成員可見性，防止訪客擷取 ContentDocument 檔案或列舉其他網站成員。
7. 僅針對 LWR 網站： 在 Experience Builder → Workspaces → Administration → Preferences 中，取消勾選「允許訪客用戶存取公開 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，以及它使用的是 GlideRecordSecure（執行 ACL）還是普通的 GlideRecord（不執行 ACL）。
3. 檢視知識庫的「可讀取」用戶條件——尋找不受限制的「任何用戶」存取，這可能會透過訪客搜尋暴露敏感的知識庫。
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 請求。可以依輸出長度排序——那些回傳資料量遠大於空結果基準值的請求行，便代表搜尋到內容。