Большинство историй о безопасности начинаются с какой-то проблемы. Эта история начинается с того, что всё функционирует в соответствии с замыслом.

Специалисты компании Reco отслеживают кампанию, получившую название City-Forum в честь домена, зарегистрированного в 2002 году, заброшенного, а теперь указывающего на арендованный сервер немецкого хостинг-провайдера. С этого сервера неизвестный участник извлекал записи из портали Salesforce и ServiceNow по всему миру.

Деятельность не прекратилась и усилила интенсивность. Каждый запрос с этого адреса осуществлялся как анонимный гость. Обнаруженные цели включают телекоммуникационные операторов, банки и финансовые организации, разработчиков корпоративного программного обеспечения, включая компании в сфере безопасности и защиты данных, а также государственные порталы.

Пассивный анализ DNS показывает, что домен указывает на этот адрес как минимум с марта 2025 года, следовательно, инфраструктура существует уже длительное время. Вопрос о том, когда началось сканирование, остаётся открытым.

Наиболее важный момент: ни одно программное обеспечение не было использовано. Учетные данные не требовались. Здесь нет уязвимости, которую можно было бы исправить. Атакующий открывал публичные портали клиентов как анонимный посетитель и вежливо, но настойчиво запрашивал их содержимое. Порталы отвечали.

Гостевой пользователь в системе

Salesforce предоставляет каждому сайту Experience Cloud выделенный встроенный аккаунт гостевого пользователя, как и ServiceNow. Это полноценный пользователь с профилем и разрешениями, как и любой другой. Когда неавторизованный посетитель заходит на ваш портал поддержки или базу знаний, именно от его имени осуществляется просмотр. Гостевой пользователь является обязательным, не может быть удален и поступает с разрешениями, которые кто-то когда-то настроил.

Из этих портали не было извлечено ничего, что они не были настроены предоставлять.

Нитай Бахрах, исследователь безопасности в Reco, описывает основную проблему: "Главная суть в том, что 'что является публичным' и 'что должно быть публичным' - это два разных понятия, и именно это и использовал атакующий".

Почему эта кампания выделяется

Нарушители уже давно злоупотребляют чрезмерно привилегированными гостевыми пользователями Salesforce, и для этого существуют готовые инструменты. Этот оператор их не использовал.

Вместо этого он создал собственные. Большая часть трафика продолжала идти по уже известному пути: на старую архитектуру Aura компании Salesforce, гостевой пользователь которой является документированной мишенью уже достаточно долго, чтобы Reco написала отчет о предыдущей кампании, работающей аналогичным образом. Именно здесь сосредоточились основные усилия этого оператора на Salesforce. Наиболее активная цель, которую наблюдала Reco, зафиксировала более 560 000 событий с этого адреса за весь период кампании, практически все из них были попытками перечисления Aura.

Кампания примечательна своим дополнительным набором инструментов, направленным на два места, на которые никто раньше не обращал внимания. Первое - это слой данных позади более новой фреймворка сайтов Salesforce, который существующие инструменты атаки полностью игнорируют. Reco называет это наступательной слепой зоной. Второе - это конечная точка поиска портала ServiceNow, настолько малодокументированная, что ServiceNow вообще не публикует по ней справочную информацию. Reco выяснила, как она работает, прочитав код позади поля поиска на стандартном портале. Скрытность - это не то, что делает её опасной. Конечная точка является публичной по замыслу, и то, что она возвращает, полностью зависит от того, как настроены источники позади неё.

Два наиболее распространённых источника, которые поставляются с платформой, проверяют, авторизованы ли вы, прежде чем обращаться к данным. Другой такой проверки не имеет. Он целиком опирается на то, кому предоставлен доступ на чтение для каждой базы знаний, что является вопросом конфигурации, без каких-либо предупреждений в коде в обоих случаях.

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

Кто это, Reco не раскрывает. Деятельность напоминает кампанию ShinyHunters Experience Cloud, перечисление гостей Salesforce через Aura и GraphQL, и позиция Reco заключается в том, что кампания, не совпадающая с последним известным отпечатком группы, сама по себе ничего не говорит, поскольку участники переписывают инструменты и арендуют новые серверы постоянно. Одно отличается от этих кампаний и предлагается как слабый сигнал, а не вывод: этот оператор использует один адрес как минимум семнадцать месяцев без каких-либо изменений.

Неудобный момент: вы не можете увидеть, что было извлечено

Предположим, вы ищете и обнаруживаете этот трафик в собственных журналах. Вы узнаете меньше, чем хотелось бы.

На ServiceNow журнал транзакций фиксирует, что произошёл поиск и приблизительно сколько было возвращено, но не условия поиска. Размер ответа - это единственное, что здесь говорит о том, что было возвращено, а в последней части ниже указано, что с этим делать. Salesforce предоставляет больше информации, хотя недостаточно, чтобы закрыть вопрос. Как описывает это Бахрах: "Salesforce несколько лучше показывает, что было предпринято (какие действия Aura, версии GraphQL LWR, URI сканирования саморегистрации). Event Monitoring не показывает, какие записи/поля были возвращены".

Итак, журналы показывают, что было попытано, но не что было взято. На очевидный последующий вопрос Бахрах отвечает: "Невозможно определить, что было утечено на основе журналов аудита. Организация должна внутренне смоделировать запросы и проанализировать ответы".

Другими словами, чтобы выяснить, что может прочитать анонимный посетитель, кто-то с вашей стороны должен стать анонимным посетителем.

При этом есть подвох, по крайней мере на ServiceNow. Конечная точка поиска портала отвечает на анонимный запрос одинаковым HTTP 201 независимо от того, есть ли что возвращать или нет. Портал, который протекает, и портал, который закрыт, выглядят идентично снаружи, и единственное различие состоит в том, пуст ли возвращаемый текст. Зонд, который возвращает чистый результат, не сказал вам ничего до тех пор, пока вы не прочитаете то, что он вернул. Оператор столкнулся с той же неоднозначностью и превратил её в метод, отображая содержимое каждого портала, отмечая, какие условия поиска дали ответ с чем-то в нём.

Позиция Бахраха относительно того, когда это пересекает границу того, о чём должны узнать клиенты: "Если данные содержат ЛИД или другие приватные данные, клиенты должны быть уведомлены". Записи были технически доступны каждому. Вопрос о том, должны ли они были быть, определяет звонки, которые вы совершаете впоследствии.

Одна и та же ошибка конфигурации на обеих платформах

На вопрос, какая неправильная конфигурация встречается чаще всего, Бахрах указывает на одну: "Наиболее частая неправильная конфигурация - это чрезмерное разрешение для гостей/анонимных пользователей. Это была корневая причина на обеих платформах".

Он также выделяет наиболее важное исправление из наиболее частой проблемы: "Правила совместного доступа гостей Salesforce - это наиболее влиятельное исправление, но не обязательно наиболее частая неправильная конфигурация". Правила совместного доступа - это где находится рычаг влияния, поэтому начните оттуда, но не останавливайтесь и не думайте, что работа завершена.

Ничего из этого не является привлекательной работой, и на ServiceNow это больше, чем просто экран разрешений. Но это конечная работа, и сервер на другом конце находится там как минимум с марта 2025 года.

Вы обнаружили трафик. Что теперь?

Бахрах предлагает рекомендации для первого часа. Сначала подтвердите эту схему.

В Salesforce проверьте Event Monitoring записи AuraRequest и Sites с USER_TYPE = 'Guest', ищя высокие объёмы getItems и getConfigData, sweeps версий /webruntime/…/vNN.0/graphql и попадания на /SiteRegister и /CommunitiesSelfReg.

На ServiceNow проверьте syslog_transaction для запросов /api/now/sp/search, выполненных как гость. Затем отсортируйте эти строки по длине вывода. Пустое множество результатов имеет небольшой и постоянный размер, поэтому всё, что значительно превышает его, - это поиск, который вернул записи. Начните с них.

Затем исправьте. На Salesforce:

  • Ужесточите правила совместного доступа гостей.
  • Удалите разрешения объектов и полей гостей.
  • Отключите "Доступ к мероприятиям" и "API Enabled" для гостевого пользователя.
  • Отключите саморегистрацию, если она не требуется.
  • Отключите доступ гостей к файлам и видимость участников.
  • На сайтах LWR отключите "Разрешить гостям доступ к публичным API", если это не требуется.

На ServiceNow:

  • Сопоставьте гостевые порталы их источникам поиска и эти источники их скриптам.
  • Проверьте критерии пользователя "Can Read" базы знаний на неограниченный доступ "Any User".
  • Проверьте включенные источники скриптованного поиска (sp_search_source) для портала.
  • Отсоедините плохие ссылки kb_uc_can_read_mtom вместо редактирования общих критериев.