warning

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

Разведка

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

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

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

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

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

На­ибо­лее извес­тный инс­тру­мент для ска­ниро­вания — это Nmap. Улуч­шить резуль­таты его работы ты можешь при помощи сле­дующе­го скрип­та:

Он дей­ству­ет в два эта­па. На пер­вом про­изво­дит­ся обыч­ное быс­трое ска­ниро­вание, на вто­ром — более тща­тель­ное ска­ниро­вание, с исполь­зовани­ем име­ющих­ся скрип­тов (опция -A).

Мы наш­ли все­го два откры­тых пор­та: 22 — служ­ба OpenSSH 8.2p1 и 80 — веб‑сер­вер Nginx 1.21.6. С SSH ничего не сде­лать, поэто­му сра­зу перехо­дим к вебу.

На сай­те находим упо­мина­ние домена www.response.htb, поэто­му обновля­ем запись в фай­ле /etc/hosts:

Что­бы рас­ширить область тес­тирова­ния, сос­тавим кар­ту сай­та с помощью Burp Discovery. Для это­го в Burp History выбира­ем целевой адрес и в кон­текс­тном меню Engagement tools → Discover content.

Так находим нес­тандар­тный файл /status/main.js.php.

Точка входа

Ко­пиру­ем содер­жимое фай­ла /status/main.js.php на локаль­ную машину и изу­чаем. Этот файл содер­жит дан­ные для обра­щения к домену api.response.htb через сайт на домене proxy.response.htb.

Так как обра­щение про­исхо­дит к под­домену proxy, добав­ляем в /etc/hosts толь­ко его.

За­тем копиру­ем дан­ные для обра­щения и пов­торя­ем зап­рос.

От­вет от сер­вера закоди­рован в Base64, декоди­ровать мож­но пря­мо в Burp Inspector.

Так как даль­ше дан­ные пред­став­лены в фор­мате JSON, мож­но кра­сиво отоб­разить их при помощи ути­литы jq.

Прос­мотрим так­же стра­ницы /get_chat_status и /get_servers.

Рас­кры­ваем еще один сер­вис — chat.response.htb. Добав­ляем его в файл /etc/hosts и прос­матри­ваем ответ сер­вера.

Сайт ока­зал­ся недос­тупен. Но мож­но обра­тить­ся к нему через сайт proxy. Прав­да, для это­го нам нуж­но под­твер­дить параметр url под­писью в парамет­ре url_digest, который сами вычис­лить мы не можем. Но параметр session, где переда­ется иден­тифика­тор веб‑сес­сии, тоже под­твержда­ется под­писью session_digest.

Тог­да про­буем вмес­то иден­тифика­тора сес­сии отпра­вить ссыл­ку, что­бы получить под­пись для нее.

Как видишь, мы узна­ем дей­стви­тель­ную под­пись URL, отправ­ленно­го вмес­то иден­тифика­тора сес­сии.

Точка опоры

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

С под­писью мож­но выпол­нить зап­рос к прок­си‑сай­ту.

Спо­соб получе­ния под­писи ока­зал­ся рабочим. Но как бы я ни пытал­ся эксфиль­тро­вать дан­ные, все рав­но при­шел к тому, что нуж­но писать свой прок­сиру­ющий веб‑сер­вер. Работать он будет так:

1. Че­рез свой бра­узер обра­щаем­ся к внут­ренне­му сай­ту, ука­зывая IP-адрес написан­ного нами веб‑сер­вера.
   


2. Наш сер­вер будет кодиро­вать при­нятый зап­рос и отправ­лять на прок­си‑сайт.
   


3. Пос­ле получе­ния отве­та от прок­си‑сай­та наш самопис­ный сер­вер будет декоди­ровать при­нятые дан­ные и отправ­лять в качес­тве отве­та бра­узе­ру.
   

Так как работать будем с сай­том http://chat.response.htb, сде­лаем запись в файл /etc/hosts:

Сна­чала напишем оснас­тку веб‑сер­вера без вся­ких фун­кций. В клас­се сер­вера ProxyServer реали­зуем обра­бот­чики do_GET и do_POST, которые будут вызывать еди­ный метод do_Multi. Спер­ва прос­то будем выводить URL, к которо­му обра­тит­ся бра­узер.

За­пус­каем сер­вер и обра­щаем­ся к http://chat.response.htb/.

Теги: CSS