Взлом хостинг-провайдера: что проверить владельцу Битрикс24 и сайта
17 октября злоумышленники вошли в инфраструктуру хостинг-провайдера FirstVDS через уязвимость в панели виртуализации VMmanager 6. Дальше произошло неприятное: вредоносная программа подключала диски клиентских виртуальных серверов в режиме чтения и копировала всё ценное: пароли, SSH- и API-ключи, токены, конфигурационные файлы, историю команд. Внутри гостевых систем она не запускалась.
Последнее и есть главная особенность этой истории. Внутри вашего сервера следов не будет. Диск читали снаружи, как чужую флешку, и обычные признаки взлома тут бесполезны.
Хронология
18 октября провайдер сообщил об инциденте. В тот же день Битрикс24 превентивно перевыпустил client_secret на серверной стороне Маркета для потенциально затронутых сторонних приложений: мера коснулась десяти разработчиков, часть приложений на день-другой перестала работать.
21 октября FirstVDS завершил собственный технический разбор. Уведомления затронутым клиентам отправляли в три этапа, новых пострадавших узлов компания не ожидает. На части узлов нашли следы закрепления: скрытые сервисы, замаскированные под служебные процессы. Доступ к панели виртуализации для клиентов закрыт, управление переносят в личный кабинет, итоговый отчёт обещан после расследования.
Позиция провайдера сформулирована прямо: полный объём выгруженного подтвердить нельзя, поэтому исходить нужно из худшего. Получили уведомление? Считайте скопированным всё, что лежало на сервере. Не получили? Это означает лишь, что следов на вашем узле не нашли.
Почему «у нас всё работает» ничего не значит
При обычном взломе остаются следы: изменённые файлы, новые администраторы, всплеск нагрузки, странные процессы. Здесь ничего этого нет по устройству атаки.
И ценность для злоумышленника представляют не файлы сайта. Рядом с ними лежит куда более интересное: пароль к базе данных в конфиге, ключи SSH, токены платёжных систем и облачных хранилищ, доступы к почте для рассылок, вебхуки и секреты приложений, подключённых к порталу. С такими ключами ломать уже ничего не нужно, можно просто войти.
Что проверить владельцу Битрикс24 и сайта
- Выясните, затронуты ли вы: личный кабинет провайдера и почта, включая спам. Уведомления шли тремя волнами. Если сервер арендует подрядчик, спросите его: письмо ушло ему.
- Откройте в портале раздел «Приложения → Разработчикам → Статистика» и сравните активность с 17 октября с обычным уровнем. С этим не тяните: история хранится 14 дней, и период инцидента скоро станет недоступен. Всплеска может не быть, но посмотреть стоит.
- Перевыпустите входящие вебхуки, если их вызывали с затронутого сервера или сам ключ хранился в его конфигах. Старый удаляется, создаётся новый, адрес передаётся в проверенную среду. Сначала посмотрите, что на них держится: обычно приём заявок с сайта и обмен с учётной системой, и короткий простой лучше спланировать.
- Разберитесь с локальными приложениями. Удаление приложения с портала делает сохранённые токены недействительными, и это основной способ отозвать доступ. Дальше сервер приложения проверяется или переезжает, секреты выпускаются заново.
- Напишите разработчикам приложений Маркета: где размещена серверная часть, был ли это затронутый хостинг, какие данные и ключи там хранились, проверена ли инфраструктура. Превентивный перевыпуск секретов коснулся не всех решений.
- Смените всё, что лежало на сервере: пароли администратора сайта и базы данных, SSH-ключи, пароли SMTP, токены платёжных систем и служб доставки, ключи облачных хранилищ, доступы к репозиторию. Ключи важнее паролей — копировали именно их.
- Поищите закрепление: службы и задания cron от имени веб-сервера, новые ключи в authorized_keys, незнакомые процессы.
- Оцените юридическую сторону. Если на сервере лежала база клиентов или заказы, это персональные данные, и вопрос про уведомление Роскомнадзора лучше задать юристу сейчас, а не когда придёт запрос.
Что в этой истории стоит изменить насовсем
Секреты не должны лежать на сервере в открытом виде. Файлы с ключами выносятся за пределы веб-дерева, права ставятся только своему пользователю. Если каталог отдаётся по HTTP, резервная копия конфига превращается в публичную ссылку.
У вебхуков должны быть минимальные права. Тот, кто создаёт лиды, не обязан уметь читать всю CRM: это ограничивает ущерб, когда ключ утёк.
Ключи и токены полезно менять по расписанию, раз в полгода. Тогда внеплановая смена перестаёт быть авралом с остановкой интеграций: команда уже знает, как это делается и что сломается.
И последнее, самое скучное — список интеграций. Кто имеет доступ к порталу, через что и зачем. В день инцидента именно этот список определяет, займёт проверка час или неделю.
Если проверять некому
Мы делаем такую проверку разовой работой: смотрим портал и сервер, собираем список доступов и интеграций, меняем ключи без остановки процессов, ищем следы закрепления. Это часть поддержки сайта и поддержки Битрикс24. Что видно снаружи, вроде заголовков безопасности и открытых служебных файлов, покажет экспресс-аудит за минуту.
Источники
- FirstVDS завершил технический разбор инцидента: хронология, уведомления, следы закрепления, статус панели.
- Рекомендации Битрикс24 клиентам: перевыпуск секретов Маркета, порядок проверки приложений и вебхуков.
- Сообщение провайдера: что именно копировалось и почему следов внутри системы нет.
Частые вопросы
Мы не получили уведомление. Значит, нас не затронуло?
Не обязательно. Провайдер пишет, что отсутствие уведомления означает лишь отсутствие найденных следов на вашем узле, а полный объём выгруженного подтвердить нельзя. Если на сервере лежали ключи от платежей, почты или портала, смена доступов — недорогая страховка независимо от уведомления.
Сервер чистый, журналы в порядке. Разве этого мало?
Мало. Диски читали снаружи, вредонос внутри гостевой системы не запускался, поэтому следов в ней и не будет. Проверять нужно не файлы сайта, а то, что могло быть скопировано: пароли, ключи, токены и конфигурации.
Нужно ли менять вебхуки Битрикс24?
Если URL вебхука был на затронутом сервере или сам ключ хранился в его конфигах — да. Старый вебхук удаляется, создаётся новый, адрес передаётся в проверенную среду. Сначала посмотрите, что на нём держится: обычно приём заявок с сайта и обмен с 1С, и их простой нужно спланировать.
Битрикс24 перевыпустил секреты. Этого достаточно?
Нет. Превентивный перевыпуск коснулся серверной части приложений Маркета десяти разработчиков. Локальные приложения и входящие вебхуки, созданные вашими администраторами, этой мерой не охвачены — с ними нужно разбираться самостоятельно.
Данные уже скопированы. Есть ли смысл что-то менять сейчас?
Да. Смена ключей не отменяет копирования, но закрывает дальнейший доступ: украденный токен ценен ровно до момента, пока он действует. Отдельно стоит помнить о риске второго рода — данные, которые приложение ранее законно получило из портала и хранило у себя, могли быть скопированы вместе с его сервером, и отзыв секрета этих копий не удаляет.
Стоит ли менять хостинг?
Сама по себе уязвимость была в панели управления виртуализацией, а не в конкретном провайдере — похожий инцидент возможен у любого, кто использует эту систему. Полезнее другое: хранить секреты вне сервера, ограничивать права вебхуков и держать проверенные резервные копии в независимом месте.
