1С‑Битрикс: что делать при компрометации сайта и внедрении web shell

Сайты на «1С Битрикс Управление сайтом» часто становятся целью атак из за популярности платформы. Наиболее опасный сценарий компрометации связан с внедрением web shell скрытого управляющего скрипта на PHP полезной нагрузки который даёт злоумышленнику удалённый доступ к файловой системы и базе данных.

Shell превращает сайт в опорную точку для дальнейших атак и подмены контента. Понимание механики его появления и методик поиска критично для специалистов по информационной безопасности.

Как сайт оказывается скомпрометирован

Исходя из практики компрометация происходит через совокупность уязвимостей приложения и организационных ошибок. Для Bitrix типичны следующие вектора атаки:

• устаревшее ядро или модули с уже известными RCE и обходом авторизации
• уязвимые компоненты и шаблоны где не фильтруются входные данные и допускается произвольное выполнение PHP кода
• некорректные права на файлы и каталоги позволяющие записывать скрипты в веб корень
• компрометация учётных данных FTP хостинга или административной панели

Практически всегда после успешного входа атакующий сохраняет один или несколько shell скриптов маскируя их под системные файлы Bitrix или изображения в каталоге upload.

Признаки компрометации и первичный осмотр

Среди типичных симптомов неожиданные редиректы на сторонние ресурсы, неизвестные администраторские учётные записи, сторонние ссылки на сайте и всплески исходящего трафика. В Bitrix поиск вредоносных активностей необходимо начать с журнала событий модуля безопасности и системных логов сервера Nginx или Apache.

Для поиска индикаторов компрометации на Linux сервере применяют простые команды. Поиск подозрительной активности в административной панели Bitrix:

grep "POST /bitrix/admin" /var/log/nginx/access.log | tail -n 50

Далее оценивают соответствие времени подозрительных запросов моменту изменения файлов на диске, что помогает связать события в логах с конкретными скриптами.

Поиск точки входа и web shell

Задача последующего анализа сводится к поиску файлов и цепочек которые привели к их появлению. Для Bitrix характерна высокая плотность PHP кода поэтому ручной просмотр малоэффективен. Исследование строится вокруг поиска конструкций вредоносного кода например eval base64_decode gzinflate assert удалённого включения через include из внешнего ресурса.

Для массового поиска подозрительных конструкций в каталоге сайта удобно использовать сочетание find и grep:

cd /var/www/site
find . -name "*.php" -type f -print0 | xargs -0 grep -niE "eval\\s*\\(|base64_decode\\s*\\(|gzinflate\\s*\\("

Отдельное внимание уделяется каталогам upload и bitrix cache а также файлам с нетипичными именами и временем изменения совпадающим с моментом компрометации по логам. На практике веб shell нередко маскируется под компонент Bitrix или под файл изображения с двойным расширением например jpg php.

Важно проверить и базу данных поскольку часть вредоносного кода может храниться в опциях и агентах Bitrix. Поиск аномальных записей необходимо начинать с таблиц b_option и b_agent, поскольку закрепление ВПО в данных таблицах позволяет выявить запуск скрытых скриптов по расписанию.

Инструментарий для углублённого анализа

Дополнительно к стандартным утилитам Linux применяются специализированные сканеры вредоносного PHP кода. Пример установки и запуска PHP Malware Finder:

git clone https://github.com/nbs-system/php-malware-finder.git
cd php-malware-finder
python pmf.py /var/www/site

Альтернативой является использование антивируса для файловой системы например ClamAV:

apt update
apt install clamav
freshclam
clamscan -r /var/www/site

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

Ликвидация последствий и закрытие уязвимости

После локализации shell необходимо восстановить целостность приложения. Наиболее надёжный подход полный разворот сайта из проверенной резервной копии с последующим переносом только верифицированного пользовательского контента. Если такой возможности нет проводится точечная очистка файлов и базы данных с последующей проверкой на целостность.

Критически важно устранить исходную уязвимость. Для Bitrix это означает обновление ядра и всех модулей через стандартный механизм обновлений исключение выполнения PHP кода в каталогах upload и контента на уровне конфигурации веб сервера с помощью директив запрета обработки PHP в этих каталогах, а также корректную настройку прав на файлы и каталоги по принципу минимально необходимых привилегий. 

Необходимо защитить веб приложение при помощи веб экрана приложений который фильтрует входящий трафик и блокирует типичные эксплуатационные цепочки до попадания в приложение. Использование WAF Check Risk позволяет исключить вероятность успешной загрузки и активации web shell затрудняет эксплуатацию существующих уязвимостей и обеспечивает раннее выявление подозрительных запросов, что в совокупности существенно уменьшает риски связанные с рассматриваемым типом угроз.

Дополнительные меры защиты включают ограничение доступа к административной части по IP или VPN включение и настройку модуля "Проактивная защита" в Bitrix использование двухфакторной аутентификации для критичных учётных записей и регулярный аудит логов. Такие меры снижают вероятность повторной эксплуатации даже при наличии ещё не выявленных слабых мест.