Волна взломов сайтов на Битрикс 2025:
уязвимость ASPRO и как ее исправить
Внимание!
С 3 февраля 2025 года наблюдается третья крупная волна взломов сайтов на платформе 1С-Битрикс. По аналогии с предыдущими волнами весной 2023 и 2024 годов, атаки, по всей видимости, нацелены на сайты с необновленными решениями от АСПРО.
Содержание
Суть проблемы и анализ ситуации
Анализ обращений и комментариев пользователей показывает, что основной вектор атаки связан с уязвимостью в компонентах решений АСПРО (преимущественно интернет-магазины: Max, Next, LiteShop и др.). Проблема кроется в небезопасной обработке данных функцией unserialize()
, что позволяет злоумышленникам выполнять произвольный PHP-код на сервере.
Многие пользователи не могут оперативно обновить решения АСПРО из-за истекшей лицензии или других ограничений, что делает их сайты уязвимыми. Важно понимать, что вирус может распространяться по серверу: если на одном аккаунте хостинга (например, /home/bitrix/www/
или /home/bitrix/ext_www/
) размещено несколько сайтов, заражение одного может привести к компрометации всех остальных, даже если они не используют Битрикс или АСПРО.
Хронология атак на Битрикс
Первая волна атак
Первая крупная волна атак на сайты Битрикс. Основной вектор: уязвимости в компонентах АСПРО. Многие сайты были скомпрометированы из-за отсутствия своевременных обновлений.
Вторая волна атак
Повторная масштабная кампания с использованием новых и ранее обнаруженных уязвимостей. Более сложные и комплексные атаки, использование шифрования для сокрытия вредоносного кода.
Текущая волна атак
Начало третьей волны атак зафиксировано 3 февраля 2025 года. Основной вектор — уязвимость в функции unserialize() в компонентах АСПРО. Атаки продолжаются, затрагивая неактуальные версии решений.
Как проявляется взлом (Симптомы)
- Сайт частично или полностью перестает работать: не открываются разделы каталога, блога, новостей и т.д.
- Недоступна административная панель Битрикса (
/bitrix/
), отображается ошибка "403 Forbidden: You don't have permission to access /bitrix/ on this server". - На сервере появляются посторонние файлы и папки (упоминалась папка
75555
в корне). - Вирус активно создает или изменяет файлы
.htaccess
в различных директориях сайта (включая/
,/bitrix/
,/bitrix/admin/
), блокируя доступ к разделам и админке. - Вредоносный код может внедряться в легитимные файлы сайта, часто в начало
index.php
. - Заражение может происходить повторно даже после частичной очистки, если не устранены все бэкдоры и запущенные вредоносные процессы.
Полезный совет
Если у вас возникли подозрения на взлом, первым делом проверьте содержимое файлов .htaccess
на наличие подозрительного кода и посмотрите список недавно измененных файлов на сервере.
Комплексное решение проблемы
Просто закрыть уязвимость (обновить или пропатчить файлы) недостаточно, если сайт уже был скомпрометирован. Необходим комплексный подход:
Шаг 1: Восстановление доступа и первичная очистка
- Восстановите доступ к админке: Подключитесь к серверу по FTP/SSH и удалите файлы
.htaccess
из папок/bitrix/
и/bitrix/admin/
. - Проверьте
.htaccess
файлы: В админке перейдите в "Настройки" -> "Проактивная защита" -> "Сканер безопасности". На вкладке "Контроль целостности" запустите проверку.htaccess
. Удалите все лишние файлы, найденные сканером, и при необходимости восстановите стандартные. Затем вручную проверьте и отредактируйте основной.htaccess
в корне сайта, удалив вредоносный код.
Шаг 2: Полная очистка сайта от вредоносного кода
Это самый важный и сложный этап. Без полной очистки вирус вернется.
Восстановить сайт из чистой резервной копии, сделанной до даты заражения (ориентировочно, до конца января 2025).
- Используйте сканер безопасности Битрикса ("Проактивная защита" -> "Поиск троянов") для поиска вредоносных файлов. Внимание: сканер может пропускать угрозы или давать ложные срабатывания. Не полагайтесь только на него.
- Вручную проанализируйте файлы на сервере. Обратите внимание на файлы, созданные или измененные после даты предполагаемого заражения. Проверьте стандартные файлы (
index.php
,init.php
и др.) на наличие постороннего кода в начале или конце файла. - Удалите все подозрительные и неизвестные файлы/папки.
- Предупреждение: Ручная очистка требует хорошего понимания структуры Битрикса и опыта. Неправильные действия могут повредить сайт. Если не уверены, обратитесь к специалистам или используйте бэкап.
Шаг 3: Закрытие уязвимости
После очистки сайта необходимо закрыть уязвимость, через которую произошло заражение:
Обновить платформу 1С-Битрикс и решение АСПРО до последних актуальных версий.
Вы можете устранить уязвимость самостоятельно. Ниже приведем примеры файлов, где может находиться угроза безопасности.
Внесите исправления вручную в уязвимые файлы шаблона. Внимание: Пути к файлам могут незначительно отличаться в зависимости от вашей версии и настроек.
1. Файлы comp_catalog_ajax.php
(для АСПРО: Max и др.)
Найдите строки:
$arIncludeParams = ($bAjaxMode ? $_POST["AJAX_PARAMS"] : $arParamsTmp);
$arGlobalFilter = ($bAjaxMode ? unserialize(urldecode($_POST["GLOBAL_FILTER"])) : ($_GET['GLOBAL_FILTER'] ? unserialize(urldecode($_GET['GLOBAL_FILTER'])) : array()));
$arComponentParams = unserialize(urldecode($arIncludeParams));
Замените их на:
if ($_POST["AJAX_PARAMS"] && !is_array(unserialize(urldecode($_POST["AJAX_PARAMS"]), ["allowed_classes" => false]))) {
header('HTTP/1.1 403 Forbidden');
$APPLICATION->SetTitle('Error 403: Forbidden');
echo 'Error 403: Forbidden_1';
require_once($_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/epilog_after.php');
die();
}
$arIncludeParams = ($bAjaxMode ? $_POST["AJAX_PARAMS"] : $arParamsTmp);
$arGlobalFilter = ($bAjaxMode ? unserialize(urldecode($_POST["GLOBAL_FILTER"]), ["allowed_classes" => false]) : ($_GET['GLOBAL_FILTER'] ? unserialize(urldecode($_GET['GLOBAL_FILTER']), ["allowed_classes" => false]) : array()));
$arComponentParams = unserialize(urldecode($arIncludeParams), ["allowed_classes" => false]);
Этот вариант добавляет проверку и использует безопасный вызов unserialize
, не ломая функционал (например, табы на главной).
2. Файлы корзины (для АСПРО: Max и др.)
Найдите строку:
$arParams = unserialize(urldecode($_REQUEST["PARAMS"]));
Замените ее на:
if (!is_array(unserialize(urldecode($_REQUEST["PARAMS"]), ["allowed_classes" => false]))) {
header('HTTP/1.1 403 Forbidden');
$APPLICATION->SetTitle('Error 403: Forbidden');
echo 'Error 403: Forbidden';
require_once($_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/epilog_after.php');
die();
}
$arParams = unserialize(urldecode($_REQUEST["PARAMS"]), ["allowed_classes" => false]);
Автоматизированное решение с помощью патчера
Для тех, кто не хочет вручную править файлы, доступен специальный патчер безопасности, который автоматически находит и исправляет небезопасные вызовы unserialize()
.
Важно!
Перед использованием патчера обязательно создайте резервную копию сайта. Патчер вносит изменения в файлы системы, которые могут повлиять на работу сайта.
Версия 1.0.4 от разработчиков ASPRO
Как использовать патчер:
- Скачайте файл
fixit.php
и загрузите его в корневую директорию вашего сайта - Откройте файл в браузере, перейдя по адресу
http://вашсайт.ru/fixit.php
- Настройте параметры сканирования на экране патчера:
- Выберите расширенное сканирование для проверки кода сторонних разработчиков
- Рекомендуется включить создание резервных копий изменяемых файлов
- При желании активируйте опцию самоудаления скрипта после завершения
- Запустите сканирование и дождитесь его завершения
- Проверьте отчет о внесенных изменениях
Технические требования: PHP 7.4 или выше, включенные модули zip
, session
и file system
.
Патчер автоматически находит потенциально опасные вызовы unserialize()
и добавляет к ним параметр ["allowed_classes" => false]
, закрывая уязвимость.
Шаг 4: Перезагрузка сервера
Критически важный шаг!
После полной очистки сайта и закрытия уязвимостей необходимо перезагрузить веб-сервер (Apache/Nginx+PHP-FPM) или весь сервер целиком.
Это нужно для того, чтобы уничтожить все вредоносные процессы, которые вирус мог запустить и которые могут работать в памяти сервера. Без перезагрузки эти процессы могут восстановить вредоносные файлы и заражение начнется снова.
Шаг 5: Финальная проверка и мониторинг
- После перезагрузки сервера еще раз проверьте работоспособность сайта и убедитесь в отсутствии признаков заражения.
- Проверьте права доступа к файлам и папкам. Они должны принадлежать пользователю, от имени которого работает веб-сервер (обычно
bitrix
или аналогичный), а неroot
. Установка правroot
на файлы сайта может нарушить его работу (например, создание бэкапов) и не является правильным решением проблемы безопасности. - Настройте регулярный мониторинг целостности файлов сайта.
Профилактика и защита
Важно!
Предотвратить проблему всегда проще, чем устранять её последствия. Следуйте этим рекомендациям для защиты вашего сайта.
Регулярные обновления
Своевременно обновляйте ядро Битрикса и все установленные решения, особенно АСПРО. Настройте уведомления о выходе критических обновлений.
Резервное копирование
Настройте регулярное резервное копирование сайта (файлы + база данных) с хранением копий на отдельном сервере или облачном хранилище.
Проактивная защита
Используйте все инструменты проактивной защиты Битрикса: WAF, контроль целостности файлов, безопасный режим PHP и регулярные проверки на вирусы.
Мониторинг активности
Настройте мониторинг необычной активности на сервере и подозрительных изменений файлов с помощью внешних сервисов или собственных скриптов.
Чек-лист безопасности Битрикс
Технические детали уязвимости
Механизм атаки
Вектор атаки основан на эксплуатации функции PHP unserialize()
, которая при небезопасном использовании может стать причиной уязвимости десериализации объектов. Злоумышленники могут передать специально сформированные данные, содержащие вредоносный код, который будет выполнен на сервере.
Принцип атаки заключается в том, что при десериализации PHP-объектов без ограничения разрешенных классов, могут вызываться магические методы классов (__wakeup
, __destruct
и др.), что позволяет выполнить произвольный код.
Сравнение безопасного и уязвимого кода
$data = unserialize($input);
$data = unserialize($input, ["allowed_classes" => false]);
Параметр ["allowed_classes" => false]
запрещает десериализацию объектов любых классов, что предотвращает выполнение вредоносного кода через магические методы. В PHP 7.0 и выше этот параметр должен использоваться всегда, когда происходит десериализация данных из ненадежных источников.
Технический совет
Если вы используете PHP версии ниже 7.0, где параметр allowed_classes
недоступен, рекомендуется обновить PHP до актуальной версии. В крайнем случае, используйте дополнительную валидацию входных данных перед их десериализацией.
Официальная позиция 1С-Битрикс
По текущей волне атак компания 1С-Битрикс выпустила официальные рекомендации по безопасности, в которых подчеркивается важность своевременного обновления как платформы, так и сторонних решений.
Основные рекомендации от разработчиков включают:
- Регулярное обновление Битрикс до последней версии
- Обязательное обновление решений партнеров (АСПРО и др.)
- Использование проактивной защиты и WAF
- Регулярное резервное копирование
- Проверку сайта сканером безопасности
Часто задаваемые вопросы
Профессиональная помощь
Если вы столкнулись с заражением сайта и не можете самостоятельно решить проблему, мы предлагаем профессиональную помощь по лечению сайтов на Битрикс:
- Диагностика и выявление уязвимостей
- Полная очистка сайта от вирусов
- Восстановление работоспособности
- Настройка защиты от будущих атак
- Обучение персонала основам безопасности

- Алексей Сидоров
- Основатель агентства Digital Rocket
Отправить запрос
Заключение
Текущая волна взломов подчеркивает важность своевременного обновления Bitrix и применения патчей безопасности. Для успешного лечения сайта от вируса, связанного с уязвимостью АСПРО, требуется комплексный подход: тщательная очистка (или восстановление из бэкапа), закрытие уязвимости (обновлением или ручным патчингом) и обязательная перезагрузка сервера.
Если вы не уверены в своих силах или столкнулись со сложностями, рекомендуется обратиться к опытным специалистам по безопасности Bitrix.