Уязвимость unserialize в решениях Аспро: как проверить сайт и закрыть дыру

Небезопасный вызов unserialize в шаблонах решений Аспро — самая частая причина, по которой сайт на 1С-Битрикс заражают повторно после каждой чистки. Разбираем, как работает атака, как за десять минут проверить свой сайт и что делать, если шеллы уже загружены.

Проблема выглядит так: сайт чистят от вирусов, через два-три дня malware возвращается. Меняют пароль FTP — не помогает. Отключают крон панели хостинга — не помогает. Причина в том, что заражение приходит не через доступы, а через обычный HTTP-запрос к легитимному файлу самого решения.

Что такое уязвимость unserialize и чем она опасна

Функция PHP unserialize() превращает строку обратно в данные. Если строка описывает объект, PHP создаёт этот объект и при определённых условиях вызывает его магические методы — __wakeup(), __destruct(), __toString(). Это называется PHP Object Injection.

Опасность не в самой функции, а в том, что в строке данные приходят от пользователя. В ряде файлов решений Аспро в unserialize() передавалось содержимое POST-параметра без ограничений:

// уязвимый вариант: в строку попадает всё, что прислал пользователь
$arGlobalFilter = unserialize(urldecode($_POST["GLOBAL_FILTER"]));

Дальше атакующий подбирает цепочку классов, которые уже есть в ядре 1С-Битрикс или в решении (gadget chain), и собирает такой объект, чтобы при его уничтожении PHP записал файл на диск. Итог — веб-шелл в корне сайта, дальше по нему заливают дорвеи, спам-редиректы и скрипты рассылки.

Какие файлы проверять

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

Отдельно проверьте сайты, которые переносили с другого решения Аспро: старые файлы предыдущего шаблона часто остаются в структуре, отвечают по HTTP и остаются уязвимыми, хотя формально «решение другое».

Как за 10 минут проверить свой сайт

Проверка делается по SSH одной командой. Она ищет вызовы unserialize без второго аргумента:

grep -rn --include=*.php "unserialize(" /путь/к/сайту/ajax /путь/к/сайту/include /путь/к/сайту/form /путь/к/сайту/bitrix/components/aspro | grep -v "allowed_classes"

Разбор того, что вы увидите в выводе:

• строка вида unserialize($_POST[...]) или unserialize(urldecode($_REQUEST[...])) — уязвимость, требует правки;
• строка вида Solution::unserialize(...), CMax::unserialize(...), CAllcorp3::unserialize(...) — правка уже есть, защита внутри метода решения, трогать не нужно;
• unserialize($arResult[...]) или unserialize(Option::get(...)) — данные не пользовательские, риск ниже, но второй аргумент лучше добавить и здесь: это ничего не ломает.

Если SSH нет, тот же поиск можно сделать через файловый менеджер хостинга или скачав папки по FTP и выполнив поиск по содержимому локально.

Как закрыть уязвимость

Правильный способ один: запретить десериализацию объектов вторым аргументом.

// было
$arComponentParams = unserialize(urldecode($_POST["AJAX_PARAMS"]));

// стало
$arComponentParams = unserialize(urldecode($_POST["AJAX_PARAMS"]), ['allowed_classes' => false]);

С параметром allowed_classes => false PHP превращает любой объект в __PHP_Incomplete_Class. Магические методы у такого объекта не вызываются, цепочка эксплойта обрывается. Массивы, строки и числа — а именно они и приходят в параметрах фильтра каталога и корзины — восстанавливаются как раньше, поэтому функциональность сайта не меняется.

Порядок работ:

1. Снимите резервную копию сайта и базы. Не в корень сайта — архив в вебруте скачает кто угодно.
2. Разверните тестовую копию, если правок в шаблоне много. На небольшом сайте достаточно копий правленных файлов рядом, вида file.php.bak-2026-08-24.
3. Пройдите по всем найденным в поиске строкам и добавьте второй аргумент. Меняется только вызов, логика остаётся.
4. Проверьте синтаксис каждого файла: php -l путь/к/файлу.php. Ответ No syntax errors detected — можно продолжать.
5. Отдельно проверьте копии файлов в мастере установки решения: bitrix/wizards/aspro/<решение>/site/public/ru/.... Их пропускают чаще всего, а при повторном запуске мастера правки затираются исходными файлами.
6. Откройте сайт и пройдите сценарии, которые задействуют исправленные файлы: фильтр в каталоге, добавление в корзину, всплывающая корзина, быстрый заказ, отправка формы.
7. Сбросьте кэш сайта: *Настройки → Настройки продукта → Автокэширование*, кнопка очистки кэша.

Как понять, что сайт уже заражён

Патч закрывает вход, но не удаляет то, что успели загрузить. Проверьте по порядку:

• Свежие PHP-файлы. find /путь/к/сайту -name "*.php" -mtime -30 -newer /путь/к/сайту/bitrix/modules/main/include.php — покажет файлы, изменённые позже ядра. Обратите внимание на имена из случайных hex-символов и на файлы в /upload/, где PHP быть не должно.
• Короткие «однострочники». Веб-шеллы часто весят 300–800 байт и содержат eval($_REQUEST[...]), assert(, base64_decode( в одной строке. Ищите: grep -rl --include=*.php -E "eval\(\\\$_(REQUEST|POST|GET)" /путь/к/сайту.
• Подмена входных файлов. Сравните index.php и .htaccess в корне с эталонной копией из бэкапа. Частый признак заражения — редирект на сторонний домен только для мобильных или только для поискового бота.
• Логи веб-сервера. Серия POST-запросов к одному ajax-файлу с разных IP, часто с поддельным Referer под поддомен вашего же сайта. Если access-логи выключены — включите: без них расследование строится на догадках.
• Администраторы Битрикса. *Настройки → Пользователи → Список пользователей*, фильтр по группе «Администраторы». Любая незнакомая учётка — тревога.

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

Что сделать после чистки, чтобы не повторилось

• Обновить решение и ядро 1С-Битрикс до актуальных версий — ручной патч закрывает один вектор, обновление закрывает известные остальные.
• Запретить исполнение PHP в /upload/ на уровне веб-сервера.
• Убрать из вебрута архивы, дампы БД и папки-бэкапы деплоя: .zip, .tar.gz, .sql, *.bak, deploy-bak-*. Их скачивают ботами по прямой ссылке.
• Включить и хранить access-логи минимум 30 дней.
• Поставить ежедневную сверку контрольных сумм PHP-файлов с эталоном и оповещение в мессенджер. Важно: сторож не должен автоматически принимать текущее состояние за эталон — иначе первая же малварь попадёт в эталон и проверка замолчит.
• Проверять список администраторов раз в неделю.

Мы разбирали такие заражения на сайтах клиентов: в типичном случае вектор находится не с первого раза, потому что логи веб-сервера отключены, а внимание уходит на FTP и пароли. Если сайт чистят второй раз подряд — почти всегда дело в веб-векторе вроде описанного выше.