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

Разведка. Сканирование портов

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

И запус­каем ска­ниро­вание пор­тов.

Мы наш­ли три откры­тых пор­та: 22 (служ­ба OpenSSH 7.9p1), 2222 (служ­ба OpenSSH 7.6p1) и 8080 (веб‑сер­вер Apache 2.4.38). Нач­нем с веба.

В резуль­татах ска­на отме­чено, что в кор­невом катало­ге сер­вера есть файл 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. Но перед исполь­зовани­ем ее нуж­но соб­рать из исходни­ков.

Пос­ле исправ­ления архи­ва мы его рас­паковы­ваем и чита­ем дамп базы дан­ных. В дам­пе мы най­дем учет­ные дан­ные для авто­риза­ции: логин, хеш пароля и зачем‑то 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:

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

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

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