«Битрикс24» сменил секретные ключи после взлома FirstVDS: что поменялось для бизнеса

Компания «Битрикс24» провела срочную замену секретных OAuth-ключей у ряда сторонних приложений из своего Маркета после атаки на хостинг-провайдера FirstVDS. С 18 октября обновление затронуло минимум десять сторонних разработчиков, а дальнейшие меры возможны в зависимости от хода расследования и появления новой информации о безопасности.

Что поменялось в работе приложений после инцидента

• С 18 октября «Битрикс24» автоматически переоформил секретные OAuth-ключи для сторонних приложений, включая минимум 10 затронутых разработчиков.
• Мера касается приложений, размещавших серверную часть на инфраструктуре FirstVDS или других провайдеров с опасной версией VMmanager 6.
• Замена ключей не распространяется на локальные приложения и входящие вебхуки — их владельцы должны действовать вручную.
• Разработчики будут уведомлены дополнительно, если потребуется отзыв или повторная генерация ключей.
• Ограничения могут временно повлиять на доступность некоторых приложений и интеграций.
• FirstVDS отправлял точечные уведомления пострадавшим, рекомендуя считать все данные на указанных машинах скомпрометированными.

На мой взгляд, скорость и масштаб замены ключей говорят о зрелой реакции «Битрикс24» на форс-мажоры. Но если приложению или проекту критична непрерывная интеграция и есть зависимость от сторонних сервисов — любые неожиданные блокировки могут стать головной болью для бизнеса.

Автоматизируем рутину. Опишите процесс, который отнимает время, — предложим, как его упростить.

Обсудить задачу

Кого затрагивает и чем грозят последствия невнимания

В первую очередь, ситуация касается компаний и индивидуальных пользователей, которые подключали к «Битрикс24» сторонние приложения через OAuth-ключи, а также тех, кто использовал локальные решения или вебхуки, размещённые на инфраструктуре FirstVDS либо других провайдеров, задействовавших VMmanager 6.

Если игнорировать предупреждения, последствия могут быть весьма серьёзными:

• Вредоносная программа при атаке на FirstVDS копировала не только ключи, но и всю найденную конфиденциальную информацию (SSH и API-ключи, истории команд, пользовательские файлы и даже криптокошельки).
• Отзыв или перемена OAuth-ключей никак не защищают те данные, что уже оказались на внешних серверах злоумышленников — если приложение ранее сохранило что-то критичное, вред наносится вне зависимости от последующих действий.
• Вас могли адресно предупредить через личный кабинет FirstVDS или почту: если получили письмо — считайте все данные на этих серверах потенциально скопированными.
• Даже если атака не оставила прямых следов на гостевой системе, это ещё не значит, что ваши данные не были скомпрометированы.

Я уверен, главная ловушка тут — ложное чувство безопасности. Проблема не только в уходящих токенах, но и в незакрытых каналах, где остались другие «кусочки» доступа: ssh-ключи, приватные конфиги и «секреты» бэкендов. Для компаний, которым важно доверие и репутация, пренебрегать такими инцидентами — настоящий риск для бизнеса и ваших клиентов.

Что делать пользователям и администраторам приложений

1. Проверьте уведомления: Если вы получили сообщение от FirstVDS о возможной компрометации — начните с этого списка. Все данные на перечисленных серверах лучше считать утраченными для внешних лиц.
2. Изолируйте и отключите рисковые приложения: Переведите серверы, на которых размещается локальное приложение или обработчик вебхука, в режим полной изоляции; временно отключите подозрительные интеграции, удалите лишние приложения для аннулирования связанных токенов.
3. Обновите все секреты и ключи: После переноса на безопасную площадку необходимо перевыпустить OAuth-ключи, токены API, webhooks и другие механизмы доступа. Не используйте старые ключи, даже если сложности с приложением не видны сразу.
4. Проверьте или перенесите инфраструктуру: Если сервер размещён на площадке с устаревшей версией VMmanager 6 или у провайдера из группы риска — перенесите рабочую нагрузку на другой, проверенный ресурс. Уточните у провайдера результаты его внутренней проверки хостинга.
5. Сравните статистику запросов: В панели «Битрикс24» проверьте активность REST-запросов с 17 октября. Если вы замечаете аномально высокий объём — реагируйте незамедлительно.
6. Обновите все безопасные связи: После всех изменений передайте новые адреса webhooks или свежие токены только в доверенную среду. Лучше перестраховаться, чем допустить повторную утечку.

Жёстко, но факт: как бы ни был продвинут ваш бизнес-процесс, к ключам доступа теперь стоит относиться с паранойей. Я бы обязательно советовал после подобных событий не просто менять пароли — разбирать, что, где и у кого было в прямом доступе, и учитывать этот опыт при проектировании новых интеграций.

Нужна помощь с автоматизацией бизнеса?
Оставьте заявку, и наши специалисты свяжутся с вами в течение 15 минут — разберем вашу задачу и предложим решение.

Получить консультацию бесплатно