HTB Sea
Эксплуатируем уязвимость в WonderCMS
Наша цель — получение прав суперпользователя на машине Sea с учебной площадки Hack The Box. Уровень задания — легкий.
warning
Подключаться к машинам с HTB рекомендуется с применением средств анонимизации и виртуализации. Не делай этого с компьютеров, где есть важные для тебя данные, так как ты окажешься в общей сети с другими участниками.
Разведка
Сканирование портов
Добавляем IP-адрес машины в /
:
10.10.11.28 sea.htb
И запускаем сканирование портов.
Справка: сканирование портов
Сканирование портов — стандартный первый шаг при любой атаке. Он позволяет атакующему узнать, какие службы на хосте принимают соединение. На основе этой информации выбирается следующий шаг к получению точки входа.
Наиболее известный инструмент для сканирования — это Nmap. Улучшить результаты его работы ты можешь при помощи следующего скрипта:
#!/bin/bashports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '' ',' | sed s/,$//)nmap -p$ports -A $1
Он действует в два этапа. На первом производится обычное быстрое сканирование, на втором — более тщательное сканирование, с использованием имеющихся скриптов (опция -A
).

Сканер нашел два открытых порта:
- 22 — служба OpenSSH 8.2p1;
- 80 — веб‑сервер Apache 2.4.41.

Точка входа
Идем смотреть сайт и на странице How to participate находим ссылку на contact.
.


На странице contact.
есть форма связи, где можно отправить ссылку на сайт. Пока оставим форму и попробуем узнать больше о сайте, поискав страницы, на которые нет ссылок.
Справка: сканирование веба c feroxbuster
Одно из первых действий при тестировании безопасности веб‑приложения — это сканирование методом перебора каталогов, чтобы найти скрытую информацию и недоступные обычным посетителям функции. Для этого можно использовать программы вроде dirsearch, DIRB или ffuf. Я предпочитаю feroxbuster.
При запуске указываем следующие параметры:
-
-u
— URL; -
-w
— словарь (я использую словари из набора SecLists); -
-t
— количество потоков; -
-d
— глубина сканирования.
Запускаем feroxbuster:
feroxbuster -u http://10.10.11.28/ -w files_interesting.txt -d 1 -t 128
Но ничего интересного найти не удалось.
Попробуем еще определить, какие используются технологии. Просматривая ответ сервера в Burp History, я нашел ссылку на файл style.
.

Обычно каталог /
расположен в корне сайта, поэтому просканируем файлы и директории в каталоге /
. В нем и находим файл README.
.
feroxbuster -u http://10.10.11.28/themes/bike/ -w files_interesting.txt -d 1 -t 128

Из содержимого README.
узнаём об использовании WonderCMS.

Это опенсорсная система управления контентом, можем сразу же заглянуть в ее репозиторий на GitHub.

Первым делом найдем, где в коде можно посмотреть версию, а затем просмотрим ее в том же файле на сервере. Текущая версия записана в файле version
в корневом каталоге CMS.


Мы имеем дело с довольно старой версией — WonderCMS 3.2.0. Поэтому первым шагом поищем информацию об известных уязвимостях в ней и готовые эксплоиты.

Из Google сразу же узнаём об уязвимости CVE-2023-41425 и получаем для нее готовые эксплоиты.
Точка опоры
Уязвимость позволяет атакующему удаленно выполнить произвольный код с помощью специального сценария, загружаемого в компонент installModule
. Удобно, что весь процесс эксплуатации автоматизирован и собран в одном эксплоите. Скачиваем и запускаем питоновский файл. При запуске указываем URL сайта, а также хост и порт для реверс‑шелла.

В выводе присутствует XSS-нагрузка, которую необходимо отправить в форме связи на сайте. Но предварительно запустим листенер:
pwncat-cs -lvp 4321

В логах веб‑сервера, который запустил наш эксплоит, отображается загрузка с удаленного хоста основной XSS-нагрузки.

Однако больше ничего не произошло, а значит, нужно разбираться в коде эксплоита и дорабатывать его. Первым делом обращаем внимание на адрес репозитория, с которого должен загружаться модуль (строка 20).

Так как в лабораторной среде нет выхода в интернет, скачиваем модуль и кладем рядом с файлом эксплоита. В коде меняем адрес на свой. Поскольку путь, указанный в модуле (строки 29 и 37), может быть занят, меняем его на любой другой.


Еще нужно подкорректировать адрес в переменной urlWithoutLogBase
.

Когда все готово, повторно запускаем эксплоит и отправляем ссылку через форму на сайте. В этот раз, кроме аплоада основной XSS-нагрузки, видим также и загрузку архива.

Спустя несколько секунд в листенере появляется сессия пользователя www-data
.

Продвижение
Первым делом поищем учетные данные в веб‑приложении. Обычно можно найти логин и пароль от базы данных.
Так и есть: в файле /
находим хеш bcrypt.

Если просто запустить hashcat без указания режима, то утилита предложит возможные режимы подбора сама.
hashcat '$2y$10$iOrk210RQSAzNCx6Vyq2X.aJ/D.GuE4jRIikYiWrD3TM/PjDnXm4q' rockyou.txt

Нам нужен самый обычный bcrypt — это режим 3200.
hashcat -m 3200 '$2y$10$iOrk210RQSAzNCx6Vyq2X.aJ/D.GuE4jRIikYiWrD3TM/PjDnXm4q' rockyou.txt

У нас есть пароль, а список возможных пользователей можно посмотреть в файле /
.

Подключаемся от имени пользователя amay и забираем первый флаг.

Локальное повышение привилегий
Теперь нам необходимо собрать информацию. Я буду использовать для этого скрипты PEASS.
Справка: скрипты PEASS
Что делать после того, как мы получили доступ в систему от имени пользователя? Вариантов дальнейшей эксплуатации и повышения привилегий может быть очень много, как в Linux, так и в Windows. Чтобы собрать информацию и наметить цели, можно использовать Privilege Escalation Awesome Scripts SUITE (PEASS) — набор скриптов, которые проверяют систему на автомате и выдают подробный отчет о потенциально интересных файлах, процессах и настройках.
Загрузим на удаленный хост скрипт для Linux, дадим право на выполнение и запустим сканирование. В выводе будет много информации, но из интересного — только сайт на порте 8080.

Так как порт доступен только для локального хоста, нам необходимо сделать туннель.
Вот как это можно сделать:
ssh amay@10.10.11.28 -L 8000:127.0.0.1:8080
Теперь весь трафик, который мы пошлем на локальный порт 8000, будет туннелирован на порт 8080 указанного хоста (в данном случае 127.0.0.1) через SSH-хост.
Смотрим сайт через браузер, где нас встречает HTTP-авторизация.

Используем единственные имеющиеся у нас учетные данные и получаем доступ к системе мониторинга, которая находится в разработке.

Выводим лог и предполагаем, что скорее на сервере читается файл, а затем нам отображается его содержимое.

Перейдем в Burp Repeater и попробуем прочитать файл /
.

Файл выводится не полностью, возможно, что‑то фильтруется. Попробуем выполнить инъекцию команды id
.

Получаем результат выполнения команды, а значит, сервер скомпрометирован. Напоследок просто прочитаем флаг рута.

Машина захвачена!