City-Forum行动：攻击者仅靠访客权限从Salesforce和ServiceNow窃取数据长达17个月

至少17个月以来，一名身份不明的攻击者一直在从全球的Salesforce Experience Cloud站点和ServiceNow Service Portal中悄悄拉取记录——期间没有利用任何一个软件漏洞，没有窃取任何凭据，甚至没有绕过认证。攻击者所做的，仅仅是使用了各组织通过平台内置的**访客用户（匿名访问）**原本就已向公众开放的内容。

安全公司Reco将这场持续进行的行动命名为City-Forum，名称来源于攻击者基础设施关联的域名city-forum.com。至少从2025年3月起，一台租用自德国托管服务商Contabo的单一服务器，就一直在系统性地从电信运营商、银行、金融服务机构、企业软件供应商以及公共部门门户中收割数据。

攻击原理：无需漏洞，无需凭证

Salesforce和ServiceNow都有一个不可删除的永久性访客用户账户，用于接待未认证的浏览者。每个组织都可以配置该访客用户的权限——即它能读取哪些记录和对象。如果访客配置文件中保留了某个记录的读取权限，那么互联网上的任何人都能通过完全合法的API端点获取该记录。

在Salesforce Aura框架上：

• 攻击工具向/aura或/s/sfsites/aura端点发送POST请求。
• 首先调用HostConfigController.getConfigData，枚举出访客用户可访问的对象列表（如Account、Contact、Case、Lead、User、ContentDocument等）。
• 然后使用SelectableListDataProviderController.getItems，对每个可访问对象的所有记录进行翻页读取。
• 单个最繁忙的目标曾从攻击者IP收到超过560,000个事件，几乎全部是访客Aura枚举行为。

在Salesforce LWR（Lightning Web Runtime）框架上：

• 这是业界首次在野观察到对Salesforce LWR站点的UI-API访客面进行利用。
• 工具瞄准GraphQL端点

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

  ，先通过EntityDefinition枚举模式，然后使用游标分页读取记录。
• 它会针对每个发现的LWR站点，依次扫描API版本v56.0到v66.0。

在ServiceNow上：

• 攻击工具瞄准/api/now/sp/search端点——这是一个Service Portal的原生搜索API，几乎没有任何公开文档，也几乎没有开源工具引用过它。
• 该端点默认就是公用的。其返回的数据内容完全取决于管理员将哪些搜索源（search sources）挂载到了面向访客的门户上，以及这些搜索源是否强制执行了访问控制。

自我注册探测（针对Salesforce）：

• 工具会在每一个发现的Experience站点路径后追加/SiteRegister和/CommunitiesSelfReg，以测试是否开启了自我注册功能。如果开启了，访客用户就可以将自己提升为已认证的外部用户，从而获得更多数据。

自定义工具集与基础设施

• 来源IP： 158.220.87.79，托管在Contabo VPS（德国托管商）上，解析到域名city-forum.com（该域名注册于2002年，后被弃用，现被重新利用）。
• 同一个IP从2025年3月起就一直承载同一个域名，没有任何更换——至少17个月没有更换过IP地址。
• 自定义Go二进制文件： 一个单一编译的Go工具，能同时攻击Salesforce的Aura和LWR框架以及ServiceNow——全部来自同一台服务器。这是一套自定义的多平台工具集，并不是AuraInspector这样的现成工具。
• 该工具使用了Go默认的Go-http-client用户代理字符串，因此很容易在日志中识别出来。

攻击目标

Reco报告显示，主要攻击目标包括：

• 电信运营商
• 银行及金融服务机构
• 企业软件供应商（包括安全及数据隐私公司）
• 公共部门门户

为何标准审计日志无法揭示被窃取的数据内容

对于ServiceNow： 该平台的交易日志（syslog_transaction）不记录/api/now/sp/search请求的POST请求体。防御方可以看到发生了自动化搜索以及返回了多少数据（通过输出长度列），但无法确定具体的搜索关键词或检索了哪些记录。

对于Salesforce： 访客枚举流量是合法的、符合协议规范的API调用，看起来就像正常的网站流量。虽然事件监控可以显示访客用户产生的AuraRequest和Sites事件的数量，但日志只能显示数据被请求了，而无法显示GraphQL或Aura响应中返回的具体内容。

换句话说，你能看到攻击者来过并拉走了多少数据，但无法还原出他们到底提取了哪些记录或字段。

推荐的修复步骤

针对Salesforce（Reco建议）：

1. 收紧访客共享规则——这是影响最大的控制项。删除所有向访客用户共享超出站点实际公开需求的记录的共享规则。
2. 从访客配置文件中移除对象级和字段级权限。 删除站点在匿名浏览场景中不需要的对象的读取权限。
3. 从访客配置文件中移除“访问活动（Access Activities）”权限（否则会暴露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（不遵守）。
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请求。按输出长度排序——那些返回数据量远大于小型空结果基线的行，代表搜索返回了内容。