Почему важно не откладывать установку и конфигурацию 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 дней то удалять файлы. Но как отписались выше эта ответственность лежит на хозяевах сайта, а не вендоре.

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

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