Bitrixsetup.php в 1С‑Битрикс: практический разбор уязвимости XSS + чтение файлов

Установочный скрипт bitrixsetup.php входит в экосистему CMS 1С-Битрикс и используется для развертывания продукта на хостинге. На практике его часто забывают удалить после установки, и он остается доступным из сети, превращаясь в точку атаки. Производитель зафиксировал уязвимость в этом скрипте как сочетание некорректной обработки ошибок и отсутствия проверки входных параметров, что приводит к связке XSS плюс чтение файлов операционной системы OS.

Уязвимость формализована в реестре БДУ ФСТЕК под идентификатором BDU 2024 01501, а в рекомендациях отдельно подчеркивается необходимость удаления bitrixsetup.php из корня сайта после установки CMS. Понимание внутренней логики скрипта позволяет не только корректно оценивать риск, но и строить практические сценарии тестирования в легитимной лабораторной среде.

Модель уязвимости в bitrixsetup.php

Ключевую роль в реализации уязвимости играет параметр filename в запросах к bitrixsetup.php с действием action UNPACK. Пользовательское значение этого параметра без фильтрации передавалось в объект архиватора, а затем попадало в текст ошибки и логов установки, где выводилось без контекстного экранирования. В результате ошибка содержала фрагмент строки filename "как есть", что образует классическую отраженную XSS.

Одновременно тот же параметр filename использовался и как путь до архива на файловой системе. Отсутствие строгой проверки и нормализации пути позволяло сформировать значение, указывающее не на архив tar gz, а на произвольный локальный файл. При попытке распаковать его заголовок интерпретировался как данные архива, а сообщения об ошибке частично раскрывали содержимое файла. Это создает уязвимость типа локальное чтение файлов LFR Local File Read с классом раскрытия информации Information Disclosure.

Исследователи показали, что через такой механизм можно прочитать критичные конфигурационные файлы 1С-Битрикс например стандартный bitrix.php interface_dbconn.php с параметрами подключения к базе данных. В ряде конфигураций дополнительно использовался параметр seek который позволял управлять смещением чтения внутри файла. В сумме это превращает установщик в независимый канал доступа к чувствительным данным.

Практическая проверка в контролируемой среде

Для безопасного изучения уязвимости достаточно развернуть лабораторный стенд с bitrixsetup.php и типовой конфигурацией web сервера. Один из практичных вариантов это контейнер с PHP и Apache, куда кладется скрипт установщика.

docker run -p 8000:80 -v $PWD:/var/www/html php:8.1-apache

После копирования bitrixsetup.php в рабочий каталог контейнера можно переходить к тестированию. Для проверки отраженной XSS удобно использовать параметр filename с заведомо некорректным значением и отслеживать появление этого значения в ответе и HTML DOM. Пример простого запроса через curl к локальному стенду:

curl "http://localhost:8000/bitrixsetup.php?action=UNPACK&filename=%3Cscript%3Ealert(1)%3C/script%3E"

Если скрипт уязвим, фрагмент с тегом script появится в теле ответа без экранирования, а при открытии URL в браузере в контексте страницы выполнится внедренный JavaScript. В реальных атаках вместо демонстрационного alert используется полезная нагрузка для кражи сессионных токенов или подмены интерфейса, но при аудите достаточно безопасных пейлоадов.

Для проверки чтения файлов используется тот же параметр filename, но уже со значением, имитирующим обход каталогов и доступ к конфигурации. В лабораторной среде можно ориентироваться на стандартные файлы 1С-Битрикс, например:

curl "http://localhost:8000/bitrixsetup.php?action=UNPACK&filename=../../bitrix/php_interface/dbconn.php"

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

Инструменты и команды для анализа

Базовый уровень проверки уязвимости возможен прямо в браузере через инструменты разработчика. Вкладки Network и Console позволяют отслеживать запросы к bitrixsetup.php, видеть параметры action, filename, seek и оперативно экспериментировать с безопасными пейлоадами.

Для систематического анализа удобно задействовать прокси сканеры класса OWASP ZAP или Burp Suite. В режиме прокси трафик к установщику перехватывается, а параметры можно фаззить и отправлять за серию тестов на XSS и LFR. Пример запуска контейнерной версии OWASP ZAP для быстрой проверки конкретного URL:

docker run -u zap -p 8080:8080 owasp/zap2-docker-stable \
  zap-baseline.py -t http://target.example/bitrixsetup.php -r zap-report.html

Для перебора вариантов значений параметра filename и проверки обходов путей полезен фаззер ffuf или аналогичные утилиты. Их можно установить в тестовом контейнере и использовать с собственным словарем полезных нагрузок:

apt-get update
apt-get install -y ffuf

ffuf -u "http://target.example/bitrixsetup.php?action=UNPACK&filename=FUZZ" \
     -w payloads-filename.txt -mr "Unable to open"

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

Методы устранения и снижение риска

Наиболее надежная стратегия это исключить сам источник уязвимости. Производитель прямо рекомендует удалять bitrixsetup.php с боевых серверов после завершения установки, а в актуальных версиях скрипта устранены проблемы с экранированием и проверкой входных параметров. Поэтому первым шагом должна быть проверка на наличие установочного скрипта в корне сайта и на нестандартных путях, а затем его удаление или перемещение в изолированную зону вне web корня.

Если по организационным причинам полное удаление невозможно, допустимо ограничить доступ к bitrixsetup.php средствами настройки web сервера. Для Nginx и Apache практикуют запрет прямого обращения к этому файлу из сети или разрешение только с доверенных внутренних адресов. Поверх этого стоит внедрить строгую валидацию параметра filename по белому списку допустимых имен архивов и контекстное экранирование всех сообщений, содержащих пользовательский ввод.

Дополнительный слой защиты дает применение специализированного веб экрана приложений WAF (Web Application Firewall). Решения этого класса позволяют блокировать типичные паттерны отраженной XSS и попытки обхода каталогов по параметру filename еще на границе периметра. Регулярный анализ правил и сигнатур в Check Risk WAF и аналогичных системах позволяет автоматически выявлять подозрительные запросы к bitrixsetup.php и блокировать цепочки эксплуатации до выполнения вредоносного кода в браузере или чтения конфиденциальных файлов. Использование современного WAF такого уровня существенно снижает риски, связанные с уязвимостью установщика 1С-Битрикс, и служит важным компенсирующим контролем даже при временном наличии уязвимых версий на боевых системах.