Почему важно не откладывать установку и конфигурацию CMS Битрикс на базе «1C-Битрикс: Виртуальная машина»

Кто обронил перчатку?


Выполняя один из проектов по тестированию на проникновение, мы наткнулись на виртуалку на публичном IP-адресе Заказчика. Из набора открытых на хосте портов у нас появилось ощущение, что это Битрикс. По ссылке обсуждается назначение портов. Ниже список портов, которые открыты на ВМ «из коробки»:

  • 22/tcp
  • 80/tcp
  • 443/tcp
  • 5223/tcp
  • 8893/tcp
  • 8894/tcp

При переходе по URL ip_addr:80 открылась страница первичной настройки сайта 1C-Битрикс, и ссылка «Восстановить копию», которая выполняет переход к модулю restore.php. При нажатии открывается инструкция по созданию резервной копии существующего сайта 1С-Битрикс, ссылки на документацию и кнопка «Далее». И вот далее начинается интересное, можно выполнить следующее:



Понятно, что когда-то администратор не завершил процедуру настройки сайта и ВМ 1С-Битрикс. Тут можно было бы вписать этот косяк в отчет (чтобы потом попытаться продать Заказчику систему мониторинга инфраструктуры, SIEM или что-то подобное) и пойти дальше. Но мы не из таких.

Человеческий фактор это или отсутствие контроля Заказчика за инфраструктурой – не так важно. Важно то, как эта ошибка может стать причиной взлома.

Привет дальним сайтам


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

И тут Битрикс дал течь. Мы ожидали, что сработает проверка файлов на стадии загрузки или пост-проверка содержимого файла. Не сработала…переданный файл оказался в домашней папке веб-приложения!

Стали разбираться что «под капотом» и почему скрипт загружает всё подряд? Для удовлетворения любопытства и для отчетности перед Заказчиком развернули в своей лабе «1С-Битрикс: Виртуальная машина» версии 7.2.

Первичная конфигурация сервера при подключении по SSH выполняется в два шага:

  1. Сменить пароль пользователя root
  2. Сменить пароль пользователя bitrix

Далее станет доступен выход в локальный интерпретатор команд. Пробуем загрузить файлы с расширением .php на «подопытный» сервер – никаких проблем, они записались в домашнюю директорию ‘/home/bitrix/www’:



Стали дальше копать в restore.php. Следующей была функция «Скачать резервную копию с дальнего сайта» («дальний сайт» — весьма своеобразный термин, но ладно). Этот скрипт не дает загрузить ничего кроме резервных копий. Мы заглянули в исходный код restore.php и нашли условие проверки загружаемого файла:

$f = fopen($_SERVER['DOCUMENT_ROOT'].'/'.$arc_name, 'rb');
$id = fread($f, 2);
fclose($f);
if ($id != chr(31).chr(139)) // not gzip
{
$s = filesize($_SERVER['DOCUMENT_ROOT'].'/'.$arc_name);
if ($s%512 > 0) // not tar
{
unlink($_SERVER['DOCUMENT_ROOT'].'/'.$arc_name);
$res = false;
}
}

Первое условие: если в начале файла не содержатся символы с кодом 0x1f и 0x8b таблицы ASCII+extended, то загружаемый файл не архив .gz.

Второе условие проверяет размер загружаемого файла: если значение не делится на 512 без остатка значит файл — это не tar-архив. На этом проверка заканчивается.

Выходит, что нужно обойти только первое условие. Ок! Взяли для тестов простой скрипт cmd.php (есть готовый от «The Dark Raver»). В cli системы передали символы-идентификаторов с содержимым файла cmd.php в новый файл под именем cmd_boom.php:

echo -e "\x1f\x8b\n$(cat cmd.php)" > cmd_boom.php

С помощью утилиты xxd можно увидеть содержимое файла в виде hex-таблицы:

cat cmd_boom.php | xxd

Вывод:



Всё, файл готов к загрузке на «дальний сервер». Загружаем cmd_boom.php на свой GitHub-репозиторий и вставляем URL скрипта на форме восстановления 1С-Битрикс. В результате после короткого созерцания прогресс-бара загрузки мы получили сообщение об ошибке:



Ну может файл удалился из домашней папки из-за ошибки? Какой смысл его хранить, если файл поломался в пути или неконсистентен? Но авторы скрипта restore.php, видимо, посчитали излишним очистку домашней директории сайта от мусора. Так, а что на счет загруженного шелла? Так вот же он, родной!



Теперь самое интересное. Нажав кнопку «Пропустить» и «Попробовать снова» на форме с сообщением об ошибке мы получили страницу с кнопкой «Удалить локальную резервную копию и служебные скрипты». Нажали – файлы удалились!

В результате домашняя директория будет очищена от скриптов restore.php, bitrixsetup.php и загруженного файла cmd_boom.php. После этого, сделать с сайтом решительного ничего нельзя — и резервная копия не восстановлена и к установке нового сайта не перейти.

Конечно же, можно было бы спрятать скрипт cmd.php в поддиректории или переименовать его в index.php. Мы остановились на достигнутом.

Есть отставить!


Мы доложили службе технической поддержки 1С-Битрикс о проблеме со скриптом restore.php, на что получили следующий ответ:

«Говорить об уязвимостях в restore.php не имеет смысла, этот скрипт предназначен для разворачивания системы управления сайтом. Он по своему смыслу нужен для того, чтобы загрузить на сайт php-скрипты.»

Ну в общем все верно, мы успешно загрузили скрипты на «покинутый» сайт заказчика и получили локальный шелл.

Позиция технической поддержки ясна: «Не закончили конфигурацию сайта – вы сам себе злобный Буратина». Тикет был закрыт технической поддержкой без ответа от непосредственно разработчиков.

Выяснять, какое количество «брошенных» ВМ 1С-Битрикс, опубликованы в Интернет мы не стали, достаточно пары найденных по запросу «intitle:«Welcome!» intext:«Welcome to Bitrix Virtual Appliance»» в Google.

Эпилог


Не публикуйте ВМ 1С-Битрикс до того, как будет развернут сайт. Следите за ресурсами своей компании, опубликованных в Интернет. Заброшенные сайты — это почти всегда плохо.
Поделиться публикацией
Комментарии 6
    +2
    ТП ответила логично. Служебные скрипты на то и служебные. В Битриксе есть даже проверка, которая говорит, что на сайте сохранились служебные скрипты и их надо удалить.

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

    Так что такие пользователи сами себе буратины
    Не зря же там есть курсы для администраторов по настройке как ВМ, так и самого Битрикса. Перед использованием любого инструмента надо читать документацию и рекомендации.
      +1

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

        –1
        Тогда для самсебезлобныхбуратин, во время установки можно добавить галочку «Служебные скрипты автоматически удалятся через 10 дней», которая по дефолту будет включена.
          0
          Мы же понимаем, что если на сайт не будет ни одного захода и если задание на это удаление не пропишется в кроне, то такое удаление не произойдёт?
            0

            При первом заходе на сайт со стороны злоумышленника или просто пытливого юноши удаление таки произойдет

              0
              На самом деле можно и без крона обойтись, создавать локальный файл с timestamp времени создания ВМ и если какой-то буратино зайдет через N дней то удалять файлы. Но как отписались выше эта ответственность лежит на хозяевах сайта, а не вендоре.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое