Служебный скрипт restore.php в CMS 1С-Битрикс предназначен для восстановления сайта из резервной копии. При ошибках конфигурации и проверке загружаемых файлов он превращается в точку удаленного выполнения кода RCE и может дать злоумышленнику полное управление веб приложением.
На виртуальных серверах VMBitrix и тестовых стендах мастер восстановления нередко доступен анонимным пользователям. Исследователи показали что через функцию загрузки бэкапа можно поместить на сервер произвольный PHP файл и выполнить его что отражено в описании уязвимости CVE-2022-29268.
Механика уязвимости restore.php
Сценарий использования restore.php: администратор кладет архив бэкапа в корень сайта или указывает внешний URL затем открывает https://site.example/restore.php и запускает мастер который распаковывает архив и восстанавливает файлы. Для удобства предусмотрена функция загрузки с локального диска Upload from local disk описанная в публикациях об уязвимости.
Уязвимость проявляется когда выполняются три условия одновременно. Скрипт доступен без авторизации разрешена загрузка архива с локального диска или по ссылке а проверка расширения и содержимого недостаточно строгая и позволяет сохранить файл который не является резервной копией например веб шелл на PHP. В таком случае атакующий загружает свой скрипт в корневой каталог после чего обращается к нему напрямую и получает RCE.
В официальном блоге по информационной безопасности 1С-Битрикс restore.php отнесен к опасным служебным файлам которые нужно удалять после установки и восстановления что подчеркивает критичность его присутствия в корне сайта.
Практические сценарии эксплуатации
Показательный пример это образ VMBitrix опубликованный на публичном IP. При первом заходе пользователь видит страницу начальной настройки с кнопкой Восстановить копию переход по ней открывает мастер restore.php который предлагает загрузить файл бэкапа или указать ссылку. Если проверка файлов реализована некорректно вместо архива можно загрузить веб шелл после чего он становится доступен по прямому URL и дает злоумышленнику удаленное выполнение кода что подтверждают разборы инцидентов и обзоры уязвимостей VMBitrix.
Инструменты и практическая проверка
Проверка сервера начинается с поиска скрипта. Все проверки должны выполняться только для ресурсов владельцем которых вы являетесь или на которые получено явное разрешение
find /var/www -type f -name "restore.php"
Если файл найден в корне веб сервера к примеру: /var/www/html/restore.php. Наличие данного файла это явный признак уязвимости, и требует незамедлительного вмешательства, особенно на продуктивных системах.
Снаружи доступность мастера восстановления можно проверять простым HTTP запросом
curl -k -I "https://target.example/restore.php"
curl -k "https://target.example/restore.php?lang=ru"
Код ответа 200 и текст страницы "восстановление сайта из резервной копии" указывают на открытую точку администрирования которую нужно дополнительно исследовать и ограничить по доступу.
Для автоматизированного поиска проблем 1С-Битрикс удобно применять сканер nuclei с набором шаблонов под эту CMS куда входит и проверка restore.php. Установка и запуск выглядят так
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest
git clone https://github.com/jhonnybonny/nuclei-templates-bitrix.git
cd nuclei-templates-bitrix
nuclei -t . -u https://target.example
Набор bitrix шаблонов для nuclei позволяет быстро выявить наличие открытого мастера восстановления и попытки загрузки подозрительных файлов.
Методы закрытия уязвимости
Базовое правило безопасности здесь максимально простое. После завершения установки или восстановления сайта скрипт restore.php должен быть удален из корня веб приложения. На сервере достаточно определить его местоположение командой find и удалить штатными средствами администратора оставив копию только в закрытом резервном хранилище или вне директории опубликованной через веб сервер. Такой подход рекомендуется и в официальных материалах по безопасности 1С-Битрикс.
Если мастер восстановления нужен в рабочем окружении доступ к нему должен быть жестко ограничен. На уровне веб сервера Nginx или Apache имеет смысл разрешать открывать restore.php только с внутренних адресов администраторов или через дополнительную базовую авторизацию а все обращения из внешней сети логировать с повышенным уровнем детализации и рассматривать как потенциальный инцидент.
Дополнительный уровень защиты дает специализированный веб экран приложений WAF. Современные решения распознают подозрительные запросы к служебным скриптам в том числе к restore.php и блокируют попытки загрузки и исполнения опасных файлов. Развертывание решения класса Check Risk WAF предоставляет облачный WAF сервис который по сигнатурам и поведенческому анализу отслеживает атаки на веб приложения и заметно снижает риски компрометации сайта в том числе при попытках эксплуатации уязвимостей восстановления бэкапа.
