blank

Уязвимость модуля «vote» в CMS 1С-Битрикс

картинка

Информация об уязвимости

03.03.2022 НКЦКИ (Национальный Координационный Центр по Компьютерным Инцидентам) выпустил бюллетень ALRT-20220303.2, в котором сообщалось о найденной 0-day уязвимости в модуле «vote» CMS 1С-Битрикс — системе опросов и голосований посетителей сайта. Уязвимость актуальна до версии 22.0.400 всех редакций, кроме Старт.

17.03.2022 уязвимости был присвоен номер CVE-2022-27228.

23.05.2022 в публичном доступе появился документ «attacking_bitrix.pdf», где разбирались новые уязвимости в CMS 1С-Битрикс и методы их эксплуатации, включая вышеупомянутую.

30.06.2022 в сети появились первые RCE-эксплойты на php, использующие методы, описанные в документе «attacking_bitrix.pdf».

12.07.2022 НКЦКИ обновил бюллетень до версии 2, появилось подробное описание и рекомендации для борьбы с злоумышленниками.

03.03.2022 НКЦКИ (Национальный Координационный Центр по Компьютерным Инцидентам) выпустил бюллетень ALRT-20220303.2, в котором сообщалось о найденной 0-day уязвимости в модуле «vote» CMS 1С-Битрикс — системе опросов и голосований посетителей сайта.Уязвимость актуальна до версии 22.0.400 всех редакций, кроме Старт.

Что случится, если сайт взломают?

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

ukr-pic

Как была произведена атака?

  • 1. Злоумышленники сформировали запрос, позволяющий запустить на сайте произвольный код.

    Был сформирован POST-запрос к скрипту «uf.php» модуля «vote».

    Полный запрос на скриншоте:

    post query
  • 2. Внесены изменения в ядро 1С-Битрикс (модифицирован агент).

    Модификация затронула первого агента в системе (ID = 1), добавляя ему нехарактерную функцию «eval()», отвечающую за исполнение кода.

  • 3. Модифицированный агент создает дополнительный файл с вредоносным кодом.

    Зачем?

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

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

    В нашем случае, модифицированный агент создавал файл «putin_h****.php» в котором был предусмотрен вариант восстановления скрипта в случае ручного удаления файла. Важно отметить, что название файла может быть любым.

  • 4. Запускается вредоносный код из файла, происходит уничтожение данных и дефейс сайта.

    Код в файле запускал функции «chr()» и «ord()»:

    «chr()» генерирует односимвольную строку по заданному числу;

    «ord()» конвертирует первый байт строки в число от 0 до 255.

    Код выглядит так:

    chr(ord($c[$i])^42)

    $c=base64_decode($_COOKIE["6a9d4c231d03dbc5454b74fd1c5d15c1"])

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

    Важно отметить, что на этом этапе попасть в админку вы уже не сможете, получив ошибку «.settings.php»:

    script php

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

Проверить сайт на наличие уязвимости в модуле «vote»

  • Введите корректный домен
Уязвимость не найдена
Уязвимость найдена

Важно: осуществляет лишь проверку уязвимого модуля и не гарантирует отсутствие других уязвимостей.

Как проверить сайт на наличие следов взлома?

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

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

  • 1. Изучаем логи веб-сервера на наличие POST-запросов к файлу /bitrix/tools/vote/uf.php.

    В нашем случае искомый запрос выглядел следующим образом:

    185.220.*.* - - [14/Sep/2022:11:28:59 +0300] "POST /bitrix/tools/vote/uf.php?attachId[ENTITY_TYPE]=CFileUploader&attachId[ENTITY_ID][events][onFileIsStarted][]=CAllAgent&attachId[ENTITY_ID][events][onFileIsStarted][]=Update&attachId[MODULE_ID]=vote&action=vote HTTP/1.0" 200 59 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0"

    Если запросы найдены к файлу найдены, стоит дополнительно проверить все обращения к серверу с указанных IP-адресов.

    Важно: убедиться, что на вашем сервере включено логирование POST-запросов.

  • 2. Ищем несанкционированные изменения файлов:

    Файлы ядра системы можно проверить внутренними средствами 1С-Битрикс:
    Настройки → Проактивная защита → Сканер безопасности → Запустить сканирование.

    На наличие несанкционированных следует проверить и файлы вне ядра, например:

    • /bitrix/modules/main/include/prolog.php;

      в нашем случае при взломе в него добавляется строка:

      «https://techmestore[.]pw/jquery- ui.js.», вызывающая сторонний JS-скрипт

    • /bitrix/js/main/core/core.js;
    • /bitrix/components/bitrix/main.file.input/main.php;
    • наличие файла access.php в папке upload/tmp/.

      Если известна дата вредоносного POST-запроса, командой «find» найти файлы с более поздней датой модификации.

      Например, если ищем измененные файлы за прошедшие 30 дней, команда выглядит так:

      find /path -type f -mtime -30 ! -mtime -1

      Если модифицированные файлы найдены, рекомендуется:

    • Восстановить хронологию событий, которая привела к их изменению, чтобы выявить всю цепочку действий злоумышленника;
    • Обновить CMS 1С-Битрикс, это устранит модификации в ядре.
  • 3. Проверить наличие модифицированных агентов в 1С-Битрикс:
    Настройки → Настройки продукта → Агенты

    Модифицированный агент сразу бросается в глаза из-за названия, например:

    • «CSearchStatistic::CleanUpAgent();» — штатный агент;
    • «$arAgent[“NAME”];eval(urldecode(strrev(‘b3%…96%66%’)))» — модифицированный.

      Название агента может быть любым, но визуальное отличие очевидно. Также видно наличие функции eval(), которую агенты содержать не должны:

      vote-bitrix
  • 4. Установить из каталога готовых решений 1С-Битрикс «Поиск троянов» и запустить сканирование:
    Настройки → bitrix.xscan → Поиск и Поиск (бета).

  • 5. Запустить встроенный «Мониторинг качества»:
    Настройки → Инструменты → Мониторинг качества → Тестировать проект.

    По завершению тестирования обращаем внимание на параметры:

    • Безопасность → Проверена безопасность кода (статический анализ уязвимостей)
    • Сдача проекта → Ядро проекта не модифицировалось

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

    vote-report

    Важно: чтобы предпринять дополнительные действия необходимо ознакомиться с публикациями: Уязвимости и атаки на CMS Bitrix и бюллетенем ALRT-20220303.2.

Даже если признаков взлома нет, мы рекомендуем:

  • Обновить веб-сервер (PHP 7.4 и MySQL 5.7) и CMS 1С-Битрикс, включить проактивную защиту;
  • Проверить целостность файлов ядра;
  • Желательно отключить неиспользуемые модули 1С-Битрикс для уменьшения векторов атаки на ресурс;
  • Проверить настройки инструментов по обеспечению безопасности — наличия SSL сертификата на сайте, проактивной защиты, резервного копирования c достаточной глубиной хранения копий.

Итог

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

Другие кейсы

case
Почему мы заменили fail2ban на CrowdSec и как это поможет при DDoS-атаках
Подробнее
case
Почему не пускает в админку 1С-Битрикс?
Подробнее
Задавайте вопросы и заказывайте техническую поддержку сайта
Телеграмм ITSOFT