Техподдержка уязвимостей: CMS. Часть 111.04.2017 10:34

5a981068bf494bdab829b3e81347fa24.jpg

1С-Битрикс — одна их самых популярных систем CMS. Включает в себя много интересных решений, начиная от сайта визитки, заканчивая высоконагруженными системами. Мы часто встречаем во время пентестов данный продукт и отмечаем, что большинство обнаруживаемых проблем безопасности можно увидеть в самописных модулях, а не в самом ядре Битрикса. Однажды, анализируя защищенность одной системы, построенной на основе коробочного решения, мы задетектили ряд любопытных уязвимостей. Жаль, но про все рассказывать нельзя, а вот про удаленное выполнение кода и повышение привилегий на сервере — уже можно.

Кстати, разработчики RCE исправлять отказались.

Вредоносный кот


Если вы знакомы с интеграцией Битрикса и 1С Бухгалтерией, то наверняка встречали скрипт под названием »1c_bx_import.php». Если коротко: это отладочный скрипт для диагностики, подробнее с его возможностями можно ознакомиться по ссылке от разработчиков. Помимо ряда специфичных действий, он реализует возможность скачивать и загружать файлы на сервер, распаковывать архивы, удалять произвольные файлы.

Ситуация с данным скриптом неоднозначная: со слов разработчиков, он не является официальной частью CMS, однако расположен на ресурсах компании и иногда используется технической поддержкой для решения проблем клиентов. В конечном счете это означает, что его вполне можно встретить на различных ресурсах, порой прямо в корне сайта. Разработчик честно указал, что пользоваться данным изделием следует только на свой страх и риск, но юзеры наверняка считают, что все безопасно и хорошо, ведь в скрипте присутствует аутентификация и авторизация. К сожалению, это не совсем так.

Давайте посмотрим, как в скрипте реализована аутентификация: 

if ((@$_REQUEST['mode']!='query' &&  @$_REQUEST['mode']!='exchange')) 
define('NEED_AUTH',true);
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");

Скорее всего, изначально задумывалось, что если в URI параметр «mode» равен «query» или «exchange», то пользователю отдается форма логина, и работа скрипта завершается. Однако, если присмотреться внимательно, то можно заметить, что в логические операторы вкралась ошибка. Получилось ровным счетом наоборот: аутентификация будет запрошена только если «mode» не равен «query» или «exchange»!

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


if ((!$USER->IsAdmin())&&(@($_GET['mode']!='query'))) 
{
	echo 'Доступ запрещён. Вы не администратор сайта. До свидания.';
	localredirect("/404.php");
}

Если не будут выполнены оба условия, выполнение скрипта закончится. Давайте посмотрим еще раз внимательно:
Если пользователь не администратор, и если mode не равен query, то вывести «Доступ запрещен».

Получается, можно не быть администратором, первое условие не будет истинным, в секцию «Доступ запрещен» мы не попадаем, а скрипт успешно продолжит работу. Выходит, что если анонимный пользователь укажет в качестве параметра «mode» значение «query», ему станут доступны все действия внутри скрипта (за выбор типа функции отвечает параметр «action»). Учитывая, что функциональность файла позволяет скачивать файлы с сервера и загружать их в произвольную директорию, публичный доступ к данному скрипту является весьма большой угрозой для безопасности.

Полный список команд, доступных для выполнения:

  • createfile — создание файла с текстом «success» по заданному пути
  • setsession — добавление произвольной Cookie в текущую сессию пользователя
  • createiblocktypeform — создание типа инфоблока
  • download — скачивание произвольного файла с сервера
  • xmlgetinfo — скачивание произвольного файла с сервера
  • deletefile — удаление произвольного файла с сервера
  • getfile — получение списка файлов на сервере
  • unzip — распаковка архива
  • upload — загрузка файла в произвольную директорию
  • search — поиск файла на сервере
  • show_bxmltree — вывод структуры директории в виде xml-файла

Вот, например, запрос, позволяющий скачать конфигурационный файл, содержащий учетную запись для доступа к базе данных:
4d78501d50f34832a2706f3731cc7d68.jpg

А таким запросом злоумышленник может получить листинг файлов на сервере:
40e54bf5ceb44420bc2324c9db23fea3.jpg

Можно, наконец, и произвольный код загрузить:
beffe4213ed440a6bf2c13d2f8a77bc7.jpg

Про уязвимость мы сообщили как клиенту, так и разработчикам CMS. К сожалению, разработчики Битрикса исправлять ошибку отказались, поскольку данный скрипт не является официальным компонентом CMS, как уже было отмечено выше.

Локальное повышение привилегий


Разработчики 1C-Битрикс Веб-кластера допустили ошибку, которая позволяет получить привилегии суперпользователя (root) на всех серверах кластера, обладая доступом к системному пользователю bitrix на одном из серверов кластера.

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

Установщик кластерной системы добавляет следующую строку в файл конфигурации команды sudo /etc/sudoers: 

bitrix ALL=NOPASSWD: /usr/bin/ansible * -m setup

Вместо символа звездочки скрипты системы подставляют имя сервера в кластере.
Утилита sudo ищет вхождения подстроки в строку, а не разделяет аргументы, как это было бы в случае системных команд класса execv. Символ звездочки в строке выше позволяет вставить произвольное количество символов, которые будут разделены на отдельные аргументы. Поэтому повысить свои привилегии можно легко одной командой: 

$ sudo /usr/bin/ansible 127.0.0.1 -m shell -a 'whoami; echo -m setup'

127.0.0.1 | success | rc=0 »
root
-m setup

bitrix@test: ~

Для самого sudo аргументы выглядят следующим образом: 
["sudo", "/usr/bin/ansible", "127.0.0.1", "-m", "shell", "-a", "whoami; echo -m setup"]

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

Вывод


Что мы получаем в итоге? Уязвимости достаточно просты и не требуют специфических условий для эксплуатации.
Перечислим наши действия при поиске возможностей для получения контроля над тестируемым сайтом:
  1. Определяем хост, запускаем процедуру подбора файлов и директорий (dirbuster).
  2. Встретился «bx_1c_import.php». Скачиваем исходники с сайта разработчика для анализа.
  3. Найдена возможность скачивать произвольные файлы с сервера.
  4. Первостепенно скачиваем конфигурационный файл для доступа к БД — dbcon.php. Увы, MySQL ждет подключений только с «localhost». Анализируем исходники дальше.
  5. Найдена возможность загружать собственный код. Получаем бэкконнект на наш сервер, однако, текущий пользователь, под которым запущен веб-сервер и от имени которого мы работаем, имеет ограниченный набор прав.
  6. В результате анализа тестируемого хоста становится ясно — это целый кластер. Да и не стали бы делать интеграцию с 1С у сайта-визитки.
  7. Изучаем возможность взаимодействия с «Ansible».
  8. Повышаем привилегии до root уже на всем кластере.
  9. …
  10. Ищем новые уязвимости.

Комментарии (2)

  • 11 апреля 2017 в 09:07

    0

    ↑

    ↓

    Надо заголовок изменить на: Техподдержка уязвимостей: Битрикс. Часть 1

    Нельзя сравнивать франкинштейна созданного маркетологами с современным CMS.

  • 11 апреля 2017 в 10:05

    0

    ↑

    ↓

    Если Битрикс франкинштейн, то что вы считаете «Современными CMS»?

© Habrahabr.ru