Кампанія City-Forum: як один сервер викрадав дані з Salesforce та ServiceNow впродовж 17 місяців без жодної вразливості

Щонайменше 17 місяців невідомий зловмисник тихо викачував записи з сайтів Salesforce Experience Cloud та ServiceNow Service Portals по всьому світу — без експлуатації жодної вразливості ПЗ, крадіжки облікових даних чи обходу автентифікації. Атакуючий просто використовував те, що організації вже зробили доступним для публіки через вбудований гостьовий (анонімний) доступ платформ.

Компанія з кібербезпеки Reco назвала цю кампанію City-Forum — за доменом city-forum.com, зареєстрованим на інфраструктуру зловмисника. Починаючи щонайменше з березня 2025 року, один орендований сервер у Німеччині систематично збирав дані з телекомунікаційних провайдерів, банків, фінансових компаній, постачальників корпоративного ПЗ та державних порталів.

Як працює експлуатація: вразливість не потрібна

І 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 endpoint

  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 Cloud, щоб перевірити, чи ввімкнено самореєстрацію. Якщо так, гість може підвищити себе до автентифікованого зовнішнього користувача, отримавши доступ до набагато більшого обсягу даних.

Спеціальний інструментарій та інфраструктура

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

Цільові організації

Reco повідомляє, що основні цілі включають:

• Телеком-оператори
• Банки та фінансові компанії
• Постачальники корпоративного ПЗ (включно з компаніями з кібербезпеки та захисту даних)
• Державні портали

Чому стандартні журнали аудиту не можуть показати, які дані були викрадені

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

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

Іншими словами, ви можете побачити, що зловмисник був там і скільки даних він витягнув, але не можете точно відтворити, які саме записи або поля він витягнув.

Рекомендовані кроки з виправлення

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

1. Обмежте правила надання спільного доступу для гостей (Guest Sharing Rules) — це єдиний найважливіший контроль. Видаліть будь-які правила надання спільного доступу, які надають гостьовому користувачеві доступ до записів понад те, що сайт дійсно потребує для публічного обслуговування.
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 та UI-API REST endpoints одним рухом.

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

1. Зіставте гостьові портали з їхніми джерелами пошуку. Перевірте таблиці sp_portal, m2m_sp_portal_search_source та sp_search_source. Від'єднайте будь-які джерела пошуку, які не потрібні публічному порталу.
2. Перевірте логіку кожного джерела пошуку — особливо is_scripted_source, data_fetch_script та те, чи використовує воно GlideRecordSecure (що забезпечує контроль доступу) або звичайний 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, виконані від імені гостя. Сортуйте за довжиною виводу — рядки, які повертають значно більше, ніж невеликий базовий рівень порожнього результату, вказують на пошуки, які повернули вміст.