В рамках данного proof of concept мы будем использовать msfvenom для генерации библиотеки .so, которая будет содержать нашу полезную нагрузку (в нашем случае — reverse shell). Затем мы скопируем этот файл на уязвимую машину и укажем этот путь в переменной wsrep_provider, которая выполнит нашу полезную нагрузку, предоставив нам доступ к целевой машине от имени пользователя с привилегиями суперпользователя (здесь пользователь mysql) благодаря нашему reverse shell.

Сборка и запуск образа уязвимой машины

Для этого эксперимента вам понадобятся установленные на вашей машине пакеты docker, msfvenom, openssh-client и mariadb.

В этой конфигурации целевая машина основана на образе MariaDB 10.4.12 (который уязвим к этой ошибке), на котором запущен openssh-сервер без разрешения входа для root. Поэтому мы создали для вас непривилегированного пользователя myuser с паролем mypassword.

Сборка уязвимого образа:

Запуск целевой машины:

Эксплуатация

Создание полезной нагрузки: reverse shell

Полезная нагрузка — это бинарный файл, который целевая машина должна выполнить после завершения эксплуатации. Здесь мы используем msfvenom для создания reverse shell в виде библиотеки .so, указав в качестве параметров наш IP-адрес (LHOST) и порт (LPORT). В другом терминале выполните:

IP-адрес LHOST — это адрес, указанный в docker-compose.yaml для сетевого шлюза, в нашем случае — атакующий, то есть вы.

Прослушивание reverse shell

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

Порт, который мы прослушиваем, 4444, — это тот, который мы указали как LPORT при создании полезной нагрузки.

Отправка полезной нагрузки на уязвимую машину

Теперь нам нужно скопировать созданную ранее полезную нагрузку (payload-CVE-2021-27928.so) на целевую машину по ssh с помощью команды scp от имени непривилегированного системного пользователя myuser, пароль которого — mypassword:

Поскольку мы не можем напрямую скопировать файл по ssh в /usr/lib, нам нужно подключиться к машине и переместить его в нужное место вручную (напомним, что пароль myuser — mypassword):

Мы могли бы загрузить полезную нагрузку в другой каталог под другим именем, например /tmp/exploit.so, и передать этот путь как путь к полезной нагрузке, но поскольку эта уязвимость уже исправлена во всех пакетах mariadb, её эксплуатация потребовала некоторых корректировок, которые вы увидите в конце этой демонстрации.

Выполнение полезной нагрузки на целевой машине через эксплуатацию уязвимости

Последний шаг — эксплуатация уязвимости MariaDB путём отправки запроса от имени дружелюбного непривилегированного системного пользователя, но компетентного администратора базы данных, которым мы являемся, с запросом на установку глобальной переменной wsrep_provider в путь к нашей полезной нагрузке.

Здесь root означает «администратор» на уровне базы данных, а не системный пользователь root. Поэтому пароль здесь — тот, что указан в файле docker-compose.yaml, MYSQL_ROOT_PASSWORD: myrootpwd.

Наконец, если всё сработало как ожидалось, в терминале, где мы прослушивали входящие подключения, мы увидим, что целевая машина успешно подключилась к нам, и мы можем выполнять shell-команды. Приятного использования :)

Reverse shell не так удобен, как «классическая» оболочка: у вас нет автодополнения, приглашения оболочки и истории, поэтому следить за корректным выполнением команд придётся самостоятельно. Так, например, не стесняйтесь использовать ls -la.

Вы можете выполнить whoami в оболочке netcat, чтобы убедиться, что вы — системный пользователь mysql!

Исправление

Согласно Jira MariaDB, похоже, что практическое применение для изменения этих переменных во время выполнения практически отсутствует (или вовсе отсутствует); они используются только в тестах. После обнаружения этой уязвимости исправление заключалось в том, чтобы сделать их доступными только для чтения — это было простое и безопасное решение, ценой несколько более сложных тестовых скриптов.

Раньше это было не так, но теперь единственное значение пути, которое может принимать wsrep_provider, — это /usr/lib/galera/libgalera_smm.so, именно поэтому данный proof of concept потребовал некоторых корректировок, например предоставления прав на запись в каталог /usr/lib/galera, чтобы можно было загрузить нашу полезную нагрузку. Таким образом, в контексте этой демонстрации такая конфигурация намеренно уязвима, но на большинстве современных систем её больше нельзя использовать подобным образом.

Ссылки

• CVE
• Проблема MariaDB Server в Jira
• Пример эксплойта

Эта работа была выполнена в рамках курса по безопасности информационных систем, читаемого на последнем курсе специализации «Инженерия информационных систем» в Grenoble INP - Ensimag, UGA.