У Jet CSIRT есть свой лендинг — мини-сайт, на котором мы рассказываем о наших продуктах и услугах. В нашем коммерческом сервисе SOC он никак не задействован, а поэтому лежит в отдельной инфраструктуре и администрируется подрядчиком через локальные учетные записи. 28 июня специалисты нашей внутренней службы информационной безопасности обнаружили инцидент — подмену главной страницы сайта на другую. В этом посте рассказываем о том, что мы делали, и о предварительных результатах расследования.

Обо всем по порядку

1. Инцидент был зафиксирован 28.06.2024 в 11:42 по Москве. Тут же для реагирования и киберкриминалистического расследования была подключена команда специалистов Jet CSIRT.

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

3. Сразу выполнили базовые действия:

• Собрали для анализа журналы событий веб-серверов и операционной системы.

• Провели проверку подключений к административной панели хостинг-провайдера и удаленных подключений к виртуальной машине.

• Провели проверку учеток и их действий — в операционной системе виртуальной машины и в административной панели самого «1С-Битрикс».

• Проверили планировщик задач (cron) на наличие нелегитимных задач.

• Выгрузили образ диска виртуальной машины сайта для детального анализа.

4. Подключили сетевиков, чтобы еще раз перепроверить, что между инфраструктурами взломанного сайта и «Инфосистемы Джет» или Jet CSIRT не было какой-то связности.

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

6. Примерно через 12 часов после дефейса злоумышленники выложили публикацию дампа базы данных нашего сайта, которую наш сервис мониторинга защиты от внешних цифровых угроз Jet Nautilus оперативно обнаружил.

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

7. 29.06.2024 в 00:35 безопасно восстановили работу сайта. Об этом — ниже.

Как мы восстанавливали работу сайта

1. Настроили новую виртуальную машину на том же хостинге для публикации сайта только для пользователей внутренней сети.

2. Провели харденинг ОС.

3. Установили актуальные версии компонентов «1С-Битрикс» и удалили неиспользуемые модули.

4. Провели полную проверку на вредоносное ПО с использованием средств антивирусной защиты.

5. Очистили директории сайта от обнаруженных вредоносных файлов.

6. Сбросили и поменяли пароли для всех учеток к БД и админке «1С-Битрикс».

7. Провели анализ защищенности.

8. Опубликовали сайт вовне через Web Application Firewall в блокирующем режиме.

Гипотеза и расследование

При первичном анализе собранных логов мы сразу увидели, что загрузка подложной страницы осуществлялась через веб-шелл, в связи с чем сформировалась первая гипотеза: сайт был скомпрометирован через уязвимость «1С-Битрикс». Команда разделилась: одна часть команды начала охоту на веб-шелл, вторая часть команды искала следы эксплуатации нашумевших уязвимостей «1С-Битрикс».

В первые часы расследования вторая команда обнаружила подозрительные POST-запросы к модулю Vote в близкой окрестности к инциденту, при этом все компоненты «1С-Битрикс» на момент инцидента были актуальных версий. Мы привлекли нашу команду пентестеров, чтобы на 100% отсеять данную гипотезу. Попытки эксплуатации уязвимости не увенчались успехом.

Но все изменилось, когда наши «охотники на веб-шелл» обнаружили, что загрузка осуществлялась через загруженный еще в ноябре 2023 года веб-шелл. Мы оперативно подняли историю технологических работ на сайте и обнаружили, что в этот промежуток времени проводились работы по миграции на выделенную виртуальную машину в инфраструктуре хостинг-провайдера. Администратор развернул актуальную на тот момент виртуальную машину «1С-Битрикс: Виртуальная машина (VMBitrix)», обновил все компоненты операционной системы и передал разработчикам для развертывания сайта. На момент проведения технических работ фильтрация обращений к сайту не осуществлялась.

Мы проанализировали логи во временной окрестности, изучили все широко известные и мало известные уязвимости и, учитывая историю технологических работ, сформулировали ключевую гипотезу компрометации веб-сайта: эксплуатация уязвимости класса RCE (удаленного выполнения произвольного кода) в «1С-Битрикс: Виртуальная машина (VMBitrix)». Описание данной уязвимости для версии «1С-Битрикс: Виртуальная машина (VMBitrix)» 7.5.0 приведено здесь и здесь. Уязвимость позволяет внедрить вредоносный PHP-скрипт в корневую директорию веб-сайта через форму «Загрузка резервной копии» на веб-странице первоначальной настройки CMS «1С-Битрикс». На текущий момент данная уязвимость присутствует в базе уязвимостей NVD с идентификатором CVE-2022-29268 в статусе «отклонена», в БДУ ФСТЭК данная уязвимость не выявлена. Наша виртуальная машина была доступна в сети Интернет без сконфигурированного «1С-Битрикс: Управление сайтом» не менее трех дней. До момента завершения настройки веб-страница «1С-Битрикс: Виртуальная машина», в случае публикации в сети Интернет, легко находится в любом поисковике.

Наши пентестеры смогли успешно воспроизвести эксплуатацию уязвимости для актуальной на данный момент версии «1С-Битрикс: Виртуальная машина (VMBitrix)» v.7.5.5 на специально подготовленном тестовом стенде. Внедрение тестового вредоносного PHP-скрипта (веб-шелл), который позволяет удаленно управлять веб-сервером, осуществлялось через модуль «Загрузка резервной копии».

Проверка успешности внедрения вредоносного PHP-скрипта путем запроса содержимого файла /etc/group операционной системы тестового стенда ниже на картинке. Команда, переданная в запросе к веб-шеллу, успешно выполнена:

Несмотря на ошибку, выданную при попытке загрузки файла, не являющегося резервной копией сайта, вредоносный PHP-скрипт был успешно внедрен в корневую директорию веб-сайта. Так возможность компрометации веб-сайта с использованием описанной уязвимости для актуальной версии «1С-Битрикс: Виртуальная машина» v7.5.5 была подтверждена практически.

Мы выпустили бюллетень с описанием уязвимости и рекомендациями.

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

Как развивался инцидент

1. Еще в 2023 году (21.11.2023 04:23 по Москве) на выделенном сервере сайта jetcsirt.su (виртуальная машина на внешнем хостинге) злоумышленники разместили веб-шелл .500.php (детектируется сигнатурой webshell_php_generic из пака YARA-правил), позволяющий выполнить любой PHP-код при передаче в него определенного HTTP-заголовка. Веб-шелл был размещен в корневой директории /home/bitrix/www.

2. 28.06.2024 11:36 злоумышленники разместили веб-шелл system.php в директорию /home/bitrix/www/bitrix/. Анализ журналов показал, что загрузка веб-шелла system.php осуществлялась через веб-шелл .500.php. Веб-шелл system.php является более функциональным и имеет возможности по ограничению доступа функций по ключу и паролю — по содержимому PHP-файла определили, что это PhpDynamicPayload из общедоступного Godzilla Webshell;

3. 28.06.2024 11:37 зафиксировано, что злоумышленники выполняли подготовительные к дефейсу операции через веб-шелл system.php;

4. 28.06.2024 11:42 заменена оригинальная главная страница index.php на подложную через веб-шелл system.php — это определили по наличию запросов к system.php, которые идентичны по времени со временем появления подложной страницы.

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

Мы также не нашли следов выявленных индикаторов компрометации в инфраструктуре «Инфосистемы Джет» и Jet CSIRT. Это подтверждается и тем фактом, что в сообщениях злоумышленников в социальных сетях не было снимков экранов хостов (рабочих станций, серверов) внутренних инфраструктур. Получается, единственной возможностью злоумышленников было реализовать дефейс на сайте, что они и сделали.

Индикаторы компрометации

Мы делимся с комьюнити собранными индикаторами компрометации при расследовании инцидента.

Файлы:

Вредоносные IP-адреса:

Что делать, если у вас сайты на базе «1С-Битрикс»

1. Проверить отсутствие в инфраструктуре сайтов на базе «1С-Битрикс» выявленных индикаторов компрометации;

2. Проверить отсутствие в корневой директории веб-ресурсов потенциально вредоносных файлов с расширением .php;

3. Обновить компоненты «1С-Битрикс» до актуальных версий;

4. Максимально изолировать машину с сайтом от своей инфраструктуры;

5. Выполнить проверку веб-приложения посредством специализированного сканера «1С-Битрикс: Поиск троянов»;

6. Рассмотреть возможность закрыть доступ к следующим файлам на уровне веб-сервера (например, в .htaccess с учетом настроек инсталляции «1С-Битрикс»):

• /bitrix/tools/upload.php

• /bitrix/tools/mail_entry.php

• /bitrix/modules/main/include/virtual_file_system.php

• /bitrix/components/bitrix/sender.mail.editor/ajax.php

• /bitrix/tools/vote/uf.php

• /bitrix/tools/html_editor_action.php

• /bitrix/admin/site_checker.php

7. Выполнять рекомендации НКЦКИ после каждого обновления модулей «1С-Битрикс»: https://safe-surf.ru/upload/ALRT/ALRT-20220712.1.pdf

8. При развертывании веб-ресурса на базе продуктов «1С-Битрикс» ограничить сетевой доступ к виртуальной машине с «1С-Битрикс: Виртуальная машина (VMBitrix)» из внешних сетей до завершения настроек «1С-Битрикс».

Главный вывод для себя самих

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

Мы на свои грабли уже наступили. Если получится сделать полезные выводы из нашего опыта — будем рады.