Уязвимость модуля «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 всех редакций, кроме Старт.

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

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

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

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

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

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

  

• 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»:

  

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

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

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

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

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

• 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(), которую агенты содержать не должны:

    

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

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

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

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

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

  

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

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

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