Кампания City-Forum: как один сервер 17 месяцев воровал данные из Salesforce и ServiceNow, не взламывая ничего

Как работает эксплуатация: уязвимости не нужны

И Salesforce, и ServiceNow поставляются с постоянными гостевыми учетными записями для неаутентифицированных посетителей. Эти гостевые учетки нельзя удалить. Их разрешения — какие записи и объекты они могут читать — настраиваются каждой организацией. Если гостевой профиль имеет доступ на чтение к какой-либо записи, любой человек в интернете может получить ее через абсолютно легитимные API-эндпоинты.

В Salesforce (фреймворк Aura):

• Инструмент отправляет POST-запросы на endpoint /aura или /s/sfsites/aura.
• Сначала он вызывает HostConfigController.getConfigData, чтобы определить, какие объекты (Account, Contact, Case, Lead, User, ContentDocument и т.д.) доступны гостю.
• Затем он использует SelectableListDataProviderController.getItems для постраничного перебора всех записей каждого доступного объекта.
• Самая активная одиночная цель зафиксировала более 560 000 событий с IP-адреса атакующего — почти все из них были перебором гостевого Aura.

В Salesforce (фреймворк LWR — Lightning Web Runtime):

• Это первая задокументированная эксплуатация гостевой поверхности UI-API Salesforce на сайтах LWR в реальных атаках.
• Инструмент нацелен на GraphQL-эндпоинт

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

  , сначала перечисляя схему через EntityDefinition, затем считывая записи с курсорной пагинацией.
• Он последовательно проверяет версии API от v56.0 до v66.0 для каждого обнаруженного сайта LWR.

В ServiceNow:

• Инструмент атакует endpoint /api/now/sp/search — родной поисковый API Service Portal, который практически не документирован и почти не упоминается в открытых источниках или инструментах.
• Этот endpoint изначально является публичным. Какие данные он возвращает, целиком зависит от того, какие источники поиска привязаны к порталу для гостей и применяют ли эти источники контроль доступа.

Проверка самостоятельной регистрации (Salesforce):

• Инструмент добавляет /SiteRegister и /CommunitiesSelfReg к каждому найденному пути сайта Experience, чтобы проверить, включена ли самостоятельная регистрация. Если да, гость может повысить свои права до аутентифицированного внешнего пользователя, получив доступ к гораздо большему объему данных.

Пользовательский инструментарий и инфраструктура

• IP-адрес источника: 158.220.87.79, размещен на VPS от Contabo (немецкий хостинг-провайдер), резолвится в домен city-forum.com (домен зарегистрирован в 2002 году, затем заброшен и переиспользован).
• Тот же IP-адрес использует тот же домен с марта 2025 года без смены — минимум 17 месяцев на одном адресе.
• Пользовательский Go-бинар: Единый скомпилированный на Go инструмент, который атакует Salesforce как через фреймворк Aura, так и LWR, а также ServiceNow — все с одного сервера. Это собственный многоплатформенный инструментарий, а не готовая утилита вроде AuraInspector.
• Инструмент использует стандартный User-Agent Go-http-client от Go, что позволяет легко идентифицировать его в логах.

Какие организации стали целями

По данным Reco, основные цели включают:

• Телекоммуникационные операторы
• Банки и финансовые организации
• Разработчики корпоративного ПО (включая компании в сфере безопасности и защиты данных)
• Государственные порталы

Почему стандартные журналы аудита не могут показать, какие данные были украдены

Для ServiceNow: Журналы транзакций платформы (syslog_transaction) не записывают тело POST-запроса к /api/now/sp/search. Специалисты по безопасности могут видеть, что выполнялись автоматизированные поиски и какой объем данных был возвращен (по столбцу длины вывода), но не могут определить точные поисковые запросы или какие конкретно записи были извлечены.

Для Salesforce: Трафик перебора гостевых данных состоит из легитимных, соответствующих протоколу API-вызовов, которые выглядят как обычный трафик сайта. Хотя Event Monitoring может показать объем событий AuraRequest и Sites от гостевых пользователей, логи свидетельствуют о том, что данные запрашивались, но не конкретное содержимое того, что было возвращено в ответах GraphQL или Aura.

Иными словами, вы можете видеть, что атакующий был там и какой объем данных он выкачал, но не сможете восстановить, какие именно записи или поля были извлечены.

Рекомендуемые шаги по устранению

Для Salesforce (рекомендации Reco):

1. Ужесточите правила общего доступа для гостей — это наиболее эффективный контроль. Удалите все правила, которые предоставляют доступ к записям гостевому пользователю сверх того, что действительно необходимо для публичной работы сайта.
2. Снимите разрешения на уровне объектов и полей с гостевого профиля. Удалите доступ на чтение для объектов, которые не нужны анонимным посетителям.
3. Удалите разрешение "Access Activities" из гостевого профиля (оно открывает доступ к задачам и событиям).
4. Отключите "API Enabled" у гостевого пользователя.
5. Отключите самостоятельную регистрацию, если сайт в ней действительно не нуждается.
6. Отключите гостевой доступ к файлам и видимость участников, чтобы гости не могли получать файлы ContentDocument или перечислять других участников сайта.
7. Для сайтов LWR: В Experience Builder → Workspaces → Administration → Preferences снимите флажок "Allow guest users to access public APIs." Это одним действием закроет GraphQL и REST-эндпоинты UI-API.

Для ServiceNow (рекомендации Reco):

1. Составьте карту порталов для гостей и их источников поиска. Проверьте таблицы sp_portal, m2m_sp_portal_search_source и sp_search_source. Отсоедините все источники поиска, не нужные публичному порталу.
2. Проверьте логику каждого источника поиска — особенно is_scripted_source, data_fetch_script и то, используется ли GlideRecordSecure (с контролем ACL) или обычный GlideRecord (без контроля).
3. Проверьте критерии пользователя "Can Read" для баз знаний — ищите неограниченный доступ "Any User", который открывает конфиденциальные базы знаний через гостевой поиск.
4. Удалите некорректные связи kb_uc_can_read_mtom вместо слепого редактирования правил общего доступа.

Обнаружение:

• Salesforce Event Monitoring: Обратите внимание на большое количество вызовов getItems и getConfigData от

  USER_TYPE = 'Guest'

  , перебор версий /webruntime/.../vNN.0/graphql, а также обращения к /SiteRegister и /CommunitiesSelfReg.
• ServiceNow syslog_transaction: Ищите запросы к /api/now/sp/search, выполненные от имени гостя. Сортируйте по длине вывода — строки, возвращающие значительно больше, чем небольшой базовый уровень пустого результата, указывают на поиски, которые вернули содержимое.