Снова волна дефейсов на Битрикс: свежая дыра, массовое сканирование. Кто как закрывал?

[elixir1337]

За последние дня три словил три обращения подряд: сайты на 1С-Битрикс, у всех одинаковая картина — подменена главная (дефейс с баннером группировки), в каталоге /upload/ лежат левые .php, в /bitrix/admin появился левый пользователь с правами админа. Версии ядра у всех старые, от 22.0 до 23.x, проактивная защита либо выключена, либо висит в режиме 'обучения'.

По логам видно массовое сканирование: POST на пару эндпоинтов модуля загрузки, потом сразу заброс вебшелла. Похоже на свежую дыру в одном из штатных модулей (грешу на загрузку файлов / визуальный редактор), эксплойт уже гуляет, бьют по площадям.

Кто на этой неделе тоже это поймал? Чем закрывали кроме банального 'обновись'? Интересует, как отсечь именно загрузку и выполнение в /upload и как быстро искать уже залитые шеллы.

[Bill2001]

Первое и самое дешёвое — запретить выполнение PHP в пользовательских каталогах на уровне веб-сервера, Битриксу туда писать исполняемое не нужно:

location ~* /upload/.*\.(php|php5|phtml)$ { deny all; }

Аналогично для /bitrix/cache, /bitrix/tmp, /upload/iblock. Это рубит большинство залитых шеллов на корню, даже если загрузить файл у них получилось.

Поиск уже залитого — по свежим mtime и сигнатурам: find /upload -name '*.php' -mtime -14, плюс grep -RIl 'eval\|base64_decode\|assert\|gzinflate' по корню. Часто прячут под .jpg.php или дописывают AddType в .htaccess. Access.log грепай по POST к /bitrix/tools/ и /bitrix/admin/ с кодом 200 в ночные часы.

[svelte1]

Разберу по шагам, как мы вычищали два таких заражения на прошлой неделе, может пригодится.

Сначала фиксация: снять полный дамп (файлы + БД), не торопиться удалять — иначе потеряете следы и не поймёте вектор. Дальше идём по таймлайну в access.log. У обоих клиентов точка входа была одна: POST на эндпоинт штатного модуля, ответ 200, через 4-6 секунд первый GET к свежему .php в /upload. То есть классика — загрузка без нормальной проверки типа, потом исполнение.

Чистка: вебшеллы редко лежат в одном экземпляре, обычно 3-5 копий в разных местах плюс закладка в /bitrix/php_interface/init.php или в шаблоне (footer особенно любят). Проверяйте init.php, .htaccess, таблицу b_user на левых админов и b_event на подозрительные агенты — нередко прописывают автозагрузку через cron-агент Битрикса, и после чистки файлов шелл возвращается сам.

Профилактика после восстановления: ядро и все модули на актуальную ветку, включить проактивную защиту в боевом режиме (не 'обучение'), журналирование вторжений, WAF перед сайтом (хоть бесплатный набор правил), сменить ВСЕ пароли и ключи, включая /bitrix/.settings.php, отозвать сессии. И обязательно встроенный 'Сканер безопасности' прогнать, он часть закладок ловит.

И да — пока не обновитесь, временно закройте /bitrix/admin по IP или basic-auth на уровне веб-сервера. Снижает поверхность сразу.

[johnmal]

Битрикс — это вечная боль именно из-за парка легаси: половина сайтов на госконтуре и у подрядчиков сидит на ядре трёх-четырёхлетней давности, потому что 'обновление сломает кастом'. Пока это не лечится технически, только организационно — поддержка с обязательным апдейтом раз в квартал и тестовый контур.

Из практики: проактивная защита реально помогает, но её почти всегда выключают, потому что она ломает кривые кастомные компоненты. И вот это и есть корень — не дыра в модуле, а то, что её отключили руками ещё на запуске.

[nixos_andy]

@Bill2001, Мы год назад съехали с Битрикса на нормальный стек как раз из-за этого цирка с ежемесячными дырами. Но понимаю, что многим некуда деваться: госзаказ и интеграция с 1С держат на крючке. Тогда хотя бы вынесите админку в закрытый периметр и поставьте fail2ban на /bitrix/admin/index.php по 401/403 — сканеры отваливаются быстро.

[luckysms]

Подтверждаю про массовость: на ханипоте за сутки 600+ запросов именно по битриксовым путям, бьют ботнетом по всему рунету подряд. Если сайт смотрит наружу и ядро не обновлено — это не вопрос 'если', а 'когда'. Минимально: закрыть исполнение в upload, обновить, проверить b_user и init.php. Это закрывает 90% сценариев из тех, что я вижу.