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

Выполняя один из проектов по тестированию на проникновение, мы наткнулись на виртуалку на публичном 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С-Битрикс до того, как будет развернут сайт. Следите за ресурсами своей компании, опубликованных в Интернет. Заброшенные сайты — это почти всегда плохо.