呢個行動之所以叫 City-Forum，係因為駭客用嘅基礎設施連接到一個叫 city-forum.com 嘅 domain。呢個 domain 原本喺 2002 年註冊，之後被棄用，然後俾人攞返嚟用。由 2025 年 3 月開始，一部喺德國租用嘅 Contabo VPS server，就一直用緊同一個 IP 地址（158.220.87.79）嚟進行攻擊。

攻擊手法：唔使漏洞，齋靠設定唔小心

Salesforce 同 ServiceNow 呢啲平台本身就有 Guest User（訪客用戶） 嘅設計，用嚟俾未登入嘅訪客睇某啲公開內容。呢個訪客賬戶係冇得刪除嘅，佢哋睇到啲咩嘢，完全取決於管理員點樣設定佢哋嘅權限。如果個 Guest profile 有權限讀取某個紀錄，咁全世界任何一個人，都可以透過合法嘅 API 將啲資料拎走。

針對 Salesforce（Aura 框架）：

• 工具會向 /aura 或 /s/sfsites/aura 呢啲端點發送 POST 請求。
• 首先用 HostConfigController.getConfigData 去列舉 Guest User 可以存取到嘅物件，例如 Account、Contact、Case、User、ContentDocument 等等。
• 然後用 SelectableListDataProviderController.getItems 逐一讀取每個物件入面嘅所有紀錄。
• 攻擊最活躍嘅一個目標網站，單係一個 IP 就錄得超過 560,000 個事件，幾乎全部都係呢啲 Aura 嘅列舉活動。

針對 Salesforce（LWR 框架 — Lightning Web Runtime）：

• 呢個係 首次喺真實世界見到 有人利用 Salesforce 嘅 UI-API Guest 介面嚟攻擊 LWR 網站。
• 工具會針對一個 GraphQL 端點 POST /webruntime/api/services/data/{version}/graphql?asGuest=true，先用 EntityDefinition 拎取 schema，然後用 cursor 分頁嘅方式去讀紀錄。
• 佢會好有系統咁對每個 LWR 網站，由 API v56.0 一路試到 v66.0。

針對 ServiceNow：

• 工具會向 /api/now/sp/search 呢個端點發送請求。呢個係 Service Portal 嘅原生搜尋 API，幾乎冇乜公開文件，亦都好少見有開源工具提到佢。
• 呢個端點本身係公開嘅，佢返咩資料出嚟，完全取決於管理員將啲咩搜尋來源（search sources）綁定到個訪客 portal 上面，同埋啲來源有冇執行權限控制。

自我註冊探測（Salesforce）：

• 工具仲會喺每個搵到嘅 Experience Cloud 網站路徑後面，加上 /SiteRegister 同 /CommunitiesSelfReg 去測試係咪開咗自我註冊功能。如果開咗，訪客就可以自己升級做已驗證嘅外部用戶，從而讀取更多數據。

自訂工具同基礎設施

• 來源 IP： 158.220.87.79，由德國 Contabo 托管，對應 domain city-forum.com。
• 呢個 IP 自 2025 年 3 月起就冇轉過，一直用足超過 17 個月。
• 自訂 Go 工具： 一個用 Go 語言編寫嘅二進制檔案，可以同時針對 Salesforce（Aura 同 LWR）同 ServiceNow 進行攻擊。呢個係一個自訂嘅跨平台工具，唔係好似 AuraInspector 嗰啲現成工具。
• 工具用嘅係 Go 語言預設嘅 Go-http-client User-Agent，所以喺 log 入面好容易認得出。

邊啲行業俾人盯上？

Reco 指出，主要目標包括：

• 電訊營運商
• 銀行同金融服務公司
• 企業軟件供應商（包括網絡安全同數據私隱公司）
• 公共部門嘅網站（政府 portal）

點解標準 Audit Log 睇唔到偷咗咩？

對 ServiceNow 嚟講： 平台嘅交易紀錄（syslog_transaction）唔會記錄 /api/now/sp/search 請求嘅 POST body。管理員只係睇到有自動化搜尋發生過，同埋大約拎咗幾多數據（透過 output length column），但係 冇辦法知道 實際嘅搜尋字詞或者邊啲紀錄俾人拎走咗。

對 Salesforce 嚟講： Guest 嘅列舉流量其實係合法、符合協議嘅 API 請求，睇落同正常網站流量冇分別。即使 Event Monitoring 可以睇到來自 Guest User 嘅 AuraRequest 同 Sites 事件有幾多，但 log 只係記錄咗有人 request 數據，而 唔會記錄 GraphQL 或者 Aura 回應入面嘅具體內容係乜。

簡單嚟講，你可以知道有人嚟過、大約拎咗幾多嘢走，但係冇辦法重組返佢哋實際偷咗邊啲紀錄或者欄位。

Reco 建議嘅補救措施

針對 Salesforce：

1. 收緊 Guest Sharing Rules — 呢個係最有效嘅控制。移除任何非必要嘅 sharing rule，確保 Guest User 只可以睇到網站真係需要公開嘅數據。
2. 移除 Guest Profile 嘅非必要物件同欄位權限 — 唔好俾訪客讀取網站唔需要嘅物件。
3. 移除 Guest Profile 嘅「Access Activities」權限 — 呢個權限會暴露 Tasks 同 Events。
4. 關閉 Guest User 嘅「API Enabled」。
5. 關閉自我註冊（Self-Registration） — 除非個網站真係需要。
6. 關閉 Guest 嘅檔案存取同成員可見性 — 咁訪客就冇得拎 ContentDocument 檔案或者列舉其他網站成員。
7. 對 LWR 網站： 喺 Experience Builder → Workspaces → Administration → Preferences，取消揀選「Allow guest users to access public APIs」。呢個動作可以一次過關閉 GraphQL 同 UI-API REST 端點。

針對 ServiceNow：

1. 搞清楚邊啲搜尋來源（search sources）綁咗落訪客 portal — 檢查 sp_portal、m2m_sp_portal_search_source 同 sp_search_source 表格，解除唔需要嘅搜尋來源。
2. 檢視每個搜尋來源嘅邏輯 — 留意 is_scripted_source、data_fetch_script，同埋係用 GlideRecordSecure（會執行 ACL）定係普通 GlideRecord（唔會執行 ACL）。
3. 檢視知識庫（Knowledge Base）嘅「Can Read」用戶條件 — 留意有冇冇限制嘅「Any User」存取權限，令敏感嘅知識庫文章可以俾訪客搜尋到。
4. 直接解除有問題嘅 kb_uc_can_read_mtom 連結，而唔係盲目咁改 sharing rules。

偵測建議：

• Salesforce Event Monitoring： 留意有冇大量 getItems 同 getConfigData 事件，而且 USER_TYPE = 'Guest'；檢查 /webruntime/.../vNN.0/graphql 嘅版本掃描；留意對 /SiteRegister 同 /CommunitiesSelfReg 嘅存取。
• ServiceNow syslog_transaction： 留意以 Guest 身份發出嘅 /api/now/sp/search 請求。將結果按 output length 排序，如果某啲請求返嘅數據量明顯大過 baseline（空結果時嘅大小），就可能代表有內容俾人拎走咗。

呢個行動之所以叫 City-Forum，係因為駭客用嘅基礎設施連接到一個叫 city-forum.com 嘅 domain。呢個 domain 原本喺 2002 年註冊，之後被棄用，然後俾人攞返嚟用。由 2025 年 3 月開始，一部喺德國租用嘅 Contabo VPS server，就一直用緊同一個 IP 地址（158.220.87.79）嚟進行攻擊。

攻擊手法：唔使漏洞，齋靠設定唔小心

Salesforce 同 ServiceNow 呢啲平台本身就有 Guest User（訪客用戶） 嘅設計，用嚟俾未登入嘅訪客睇某啲公開內容。呢個訪客賬戶係冇得刪除嘅，佢哋睇到啲咩嘢，完全取決於管理員點樣設定佢哋嘅權限。如果個 Guest profile 有權限讀取某個紀錄，咁全世界任何一個人，都可以透過合法嘅 API 將啲資料拎走。

針對 Salesforce（Aura 框架）：

• 工具會向 /aura 或 /s/sfsites/aura 呢啲端點發送 POST 請求。
• 首先用 HostConfigController.getConfigData 去列舉 Guest User 可以存取到嘅物件，例如 Account、Contact、Case、User、ContentDocument 等等。
• 然後用 SelectableListDataProviderController.getItems 逐一讀取每個物件入面嘅所有紀錄。
• 攻擊最活躍嘅一個目標網站，單係一個 IP 就錄得超過 560,000 個事件，幾乎全部都係呢啲 Aura 嘅列舉活動。

針對 Salesforce（LWR 框架 — Lightning Web Runtime）：

• 呢個係 首次喺真實世界見到 有人利用 Salesforce 嘅 UI-API Guest 介面嚟攻擊 LWR 網站。
• 工具會針對一個 GraphQL 端點 POST /webruntime/api/services/data/{version}/graphql?asGuest=true，先用 EntityDefinition 拎取 schema，然後用 cursor 分頁嘅方式去讀紀錄。
• 佢會好有系統咁對每個 LWR 網站，由 API v56.0 一路試到 v66.0。

針對 ServiceNow：

• 工具會向 /api/now/sp/search 呢個端點發送請求。呢個係 Service Portal 嘅原生搜尋 API，幾乎冇乜公開文件，亦都好少見有開源工具提到佢。
• 呢個端點本身係公開嘅，佢返咩資料出嚟，完全取決於管理員將啲咩搜尋來源（search sources）綁定到個訪客 portal 上面，同埋啲來源有冇執行權限控制。

自我註冊探測（Salesforce）：

• 工具仲會喺每個搵到嘅 Experience Cloud 網站路徑後面，加上 /SiteRegister 同 /CommunitiesSelfReg 去測試係咪開咗自我註冊功能。如果開咗，訪客就可以自己升級做已驗證嘅外部用戶，從而讀取更多數據。

自訂工具同基礎設施

• 來源 IP： 158.220.87.79，由德國 Contabo 托管，對應 domain city-forum.com。
• 呢個 IP 自 2025 年 3 月起就冇轉過，一直用足超過 17 個月。
• 自訂 Go 工具： 一個用 Go 語言編寫嘅二進制檔案，可以同時針對 Salesforce（Aura 同 LWR）同 ServiceNow 進行攻擊。呢個係一個自訂嘅跨平台工具，唔係好似 AuraInspector 嗰啲現成工具。
• 工具用嘅係 Go 語言預設嘅 Go-http-client User-Agent，所以喺 log 入面好容易認得出。

邊啲行業俾人盯上？

Reco 指出，主要目標包括：

• 電訊營運商
• 銀行同金融服務公司
• 企業軟件供應商（包括網絡安全同數據私隱公司）
• 公共部門嘅網站（政府 portal）

點解標準 Audit Log 睇唔到偷咗咩？

對 ServiceNow 嚟講： 平台嘅交易紀錄（syslog_transaction）唔會記錄 /api/now/sp/search 請求嘅 POST body。管理員只係睇到有自動化搜尋發生過，同埋大約拎咗幾多數據（透過 output length column），但係 冇辦法知道 實際嘅搜尋字詞或者邊啲紀錄俾人拎走咗。

對 Salesforce 嚟講： Guest 嘅列舉流量其實係合法、符合協議嘅 API 請求，睇落同正常網站流量冇分別。即使 Event Monitoring 可以睇到來自 Guest User 嘅 AuraRequest 同 Sites 事件有幾多，但 log 只係記錄咗有人 request 數據，而 唔會記錄 GraphQL 或者 Aura 回應入面嘅具體內容係乜。

簡單嚟講，你可以知道有人嚟過、大約拎咗幾多嘢走，但係冇辦法重組返佢哋實際偷咗邊啲紀錄或者欄位。

Reco 建議嘅補救措施

針對 Salesforce：

1. 收緊 Guest Sharing Rules — 呢個係最有效嘅控制。移除任何非必要嘅 sharing rule，確保 Guest User 只可以睇到網站真係需要公開嘅數據。
2. 移除 Guest Profile 嘅非必要物件同欄位權限 — 唔好俾訪客讀取網站唔需要嘅物件。
3. 移除 Guest Profile 嘅「Access Activities」權限 — 呢個權限會暴露 Tasks 同 Events。
4. 關閉 Guest User 嘅「API Enabled」。
5. 關閉自我註冊（Self-Registration） — 除非個網站真係需要。
6. 關閉 Guest 嘅檔案存取同成員可見性 — 咁訪客就冇得拎 ContentDocument 檔案或者列舉其他網站成員。
7. 對 LWR 網站： 喺 Experience Builder → Workspaces → Administration → Preferences，取消揀選「Allow guest users to access public APIs」。呢個動作可以一次過關閉 GraphQL 同 UI-API REST 端點。

針對 ServiceNow：

1. 搞清楚邊啲搜尋來源（search sources）綁咗落訪客 portal — 檢查 sp_portal、m2m_sp_portal_search_source 同 sp_search_source 表格，解除唔需要嘅搜尋來源。
2. 檢視每個搜尋來源嘅邏輯 — 留意 is_scripted_source、data_fetch_script，同埋係用 GlideRecordSecure（會執行 ACL）定係普通 GlideRecord（唔會執行 ACL）。
3. 檢視知識庫（Knowledge Base）嘅「Can Read」用戶條件 — 留意有冇冇限制嘅「Any User」存取權限，令敏感嘅知識庫文章可以俾訪客搜尋到。
4. 直接解除有問題嘅 kb_uc_can_read_mtom 連結，而唔係盲目咁改 sharing rules。

偵測建議：

• Salesforce Event Monitoring： 留意有冇大量 getItems 同 getConfigData 事件，而且 USER_TYPE = 'Guest'；檢查 /webruntime/.../vNN.0/graphql 嘅版本掃描；留意對 /SiteRegister 同 /CommunitiesSelfReg 嘅存取。
• ServiceNow syslog_transaction： 留意以 Guest 身份發出嘅 /api/now/sp/search 請求。將結果按 output length 排序，如果某啲請求返嘅數據量明顯大過 baseline（空結果時嘅大小），就可能代表有內容俾人拎走咗。