18 октября хостинг‑провайдер FirstVDS сообщил об обнаружении атаки, произошедшей 17 октября. По данным провайдера, злоумышленники воспользовались уязвимостью в системе управления виртуализацией VMmanager 6, которую использовал хостер, и получили доступ к части его инфраструктуры.
Несмотря на то что уязвимость была обнаружена не в Битрикс24, а в инфраструктуре FirstVDS, для наших клиентов мог возникнуть косвенный риск, если на затронутых внешних серверах работали серверные части сторонних приложений и хранились данные доступа к порталам либо данные, ранее полученные из Битрикс24.
Что сообщает FirstVDS
Провайдер информирует, что вредоносная программа подключала диски некоторых клиентских виртуальных машин в режиме «только чтение» и копировала находившиеся на них файлы, пароли, ключи, токены и конфигурации. По сообщению FirstVDS, программа не запускалась внутри гостевых систем и не изменяла данные на их дисках. Поэтому виртуальная машина могла продолжать работать без явных следов этой активности внутри ее операционной системы.
В сообщении FirstVDS указано, что расследование инцидента продолжается. По состоянию на 19 октября 2 026 года, 17:46 МСК, в этом сообщении не раскрыты технические детали эксплуатации уязвимости и полный перечень затронутых версий.
Почему вопрос не ограничивается FirstVDS
FirstVDS — публично известный пример эксплуатации этой уязвимости. Однако VMmanager 6 может использоваться и другими хостинг‑провайдерами.
Серверная часть стороннего приложения для Битрикс24 может работать во внешней инфраструктуре, выбранной его разработчиком. Само по себе использование VMmanager 6 не доказывает компрометацию. Если серверная часть приложения размещена у провайдера, использующего VMmanager 6, клиенту следует запросить у разработчика результаты проверки конкретной инфраструктуры, на которой работает приложение. Разработчик при необходимости должен получить соответствующую информацию у хостинг‑провайдера.
Что сделал Битрикс24
18 октября после публикации сообщения от FirstVDS Битрикс24 перевыпустил секреты (client_secret) OAuth‑доступа на серверной стороне Маркета для потенциально затронутых сторонних приложений. Эта мера носит проактивный характер и сама по себе не означает, что конкретное приложение или его установка были скомпрометированы. Разработчики этих модулей в настоящее время обновляют данные секреты, что может влиять на их доступность. Текущий охват — 10 разработчиков. Расследование инцидента со стороны FirstVDS продолжается, мы следим за ситуацией, возможны дополнительные отзывы ключей.
Что это означает для клиентов
-
Если приложение из Маркета перестало работать 18–19 октября, одной из возможных причин может быть введенное Битрикс24 ограничение доступа. Уточните у разработчика, затронута ли установка приложения на вашем портале. При этом локальные приложения и входящие вебхуки, созданные администраторами порталов, автоматически этой мерой не охвачены.
-
Сроки и порядок восстановления работы конкретного приложения и необходимые действия уточняйте у его разработчика. Если разработчик не отвечает, обратитесь в техническую поддержку 1 С‑Битрикс.
Два риска, которые нужно проверить
Возможны два разных сценария:
-
Использование похищенных данных доступа для новых обращений к порталу. Отзыв секрета OAuth‑доступа предназначен для снижения этого риска у потенциально затронутых установок приложений из Маркета.
-
Компрометация данных, ранее сохраненных приложением. Стороннее приложение могло законно получить данные из Битрикс24 и сохранить их во внешней инфраструктуре разработчика. Если такие данные находились на затронутом сервере, они могли быть скопированы во время атаки. Отзыв секрета приложения не удаляет ранее сохраненные копии данных с внешнего сервера стороннего модуля, из его резервных копий, журналов или хранилищ. Такой сценарий может не сопровождаться новыми REST‑запросами к Битрикс24.
Что делать клиенту
1. Проверьте установленные приложения
Составьте список сторонних приложений, подключенных к вашему Битрикс24, и определите их разработчиков. Проверьте, к каким данным и инструментам портала у каждого приложения есть доступ.
Как проверить доступы приложения
2. Обратитесь к разработчику приложения
Уточните:
-
Где размещается серверная часть приложения и какой хостинг‑провайдер используется?
-
Использует ли этот провайдер VMmanager 6?
-
Получал ли разработчик или провайдер уведомление о возможной компрометации конкретного сервера или узла?
-
Работало ли приложение для вашего портала на потенциально затронутом сервере?
-
Какие данные, ключи и токены хранились на этом сервере?
-
Какие данные вашего портала приложение ранее сохраняло во внешней инфраструктуре, включая резервные копии, журналы и временные файлы?
-
Проведена ли проверка инфраструктуры и можно ли безопасно продолжать использование приложения?
-
Какие действия уже выполнены и требуются ли дополнительные действия от вас?
Просите ответ по конкретному приложению и обслуживающему ваш портал серверу. Самого утверждения об использовании или неиспользовании определенного хостера недостаточно.
3. Локальное приложение, размещенное у хостера
Если серверная часть какого‑либо вашего локального приложения или его данные доступа находились на потенциально скомпрометированном хостинге:
-
Изолируйте соответствующий сервер и отключите интеграции.
-
Для аннулирования сохраненных токенов удалите локальное приложение с портала: согласно документации Битрикс24, удаление приложения делает все сохраненные токены недействительными. Перед удалением оцените, какие зависимые процессы остановятся и что потребуется для восстановления интеграции.
-
Проверьте инфраструктуру на предмет компрометации, при необходимости перенесите приложение в проверенную среду.
-
Перевыпустите все секреты и токены.
4. Входящий вебхук
Если URL входящего вебхука хранился на потенциально скомпрометированном сервере, удалите прежний вебхук в Битрикс24, проверьте или перенесите серверную среду, затем создайте новый вебхук и передайте его URL в проверенную среду. Предварительно оцените, какие процессы перестанут работать после удаления.
5. Проверьте REST‑активность
Администратор портала может открыть раздел Приложения → Разработчикам → Статистика и проверить число REST‑запросов по приложениям, вебхукам, методам или событиям и датам. Доступна история не более чем за 14 дней. Сравните активность начиная с 17 октября с обычным уровнем за предыдущие дни.
Как проверить статистику REST‑запросов
Статистика подходит только для предварительного поиска аномалий. Она не показывает, кто фактически использовал данные доступа, какие записи были прочитаны и какие сведения могли быть получены.
Отсутствие всплеска запросов не исключает использование доступа небольшим числом запросов, компрометацию ранее сохраненных данных или утечку непосредственно из инфраструктуры разработчика. Необычная активность, в свою очередь, сама по себе не доказывает атаку и требует проверки совместно с разработчиком приложения.
Источник: habr.com