HTB Sink. Учимся прятать запросы HTTP и разбираемся с AWS Secrets Manager - «Новости»

warning

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

Разведка

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

Ад­рес машины — 10.10.10.225, добав­ляем его в /etc/hosts как sink.htb.

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

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

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

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

В резуль­тате ска­ниро­вания находим три откры­тых пор­та: 22 (служ­ба SSH), 3000 (Gitea) и 5000 (Gunicorn). Нач­нем с Git.

Мы видим какие‑то име­на поль­зовате­лей (запишем их, могут при­годить­ся!), но боль­ше ничего инте­рес­ного нет. Поэто­му перехо­дим к Gunicorn. На сай­те, который он отда­ет, нуж­но регис­три­ровать­ся. Сде­лаем это, авто­ризу­емся и пос­мотрим, что нам ста­нет дос­тупно.

Ос­мотр сай­тов я рекомен­дую про­водить через Burp, что­бы мож­но было прос­мотреть все отправ­ляемые и получа­емые дан­ные. Так пос­ле отправ­ки ком­мента­рия в отве­те замеча­ем заголо­вок Via. Это заголо­вок для прок­си, в котором ука­зано haproxy.

HAProxy — это сер­верное при­ложе­ние, которое обес­печива­ет высокую дос­тупность сай­та и балан­сиру­ет наг­рузку TCP и HTTP-при­ложе­ний меж­ду нес­коль­кими сер­верами.

Даль­ше я попытал­ся пос­каниро­вать дирек­тории. У меня ничего не выш­ло, зато сооб­щение об ошиб­ке помог­ло выяс­нить исполь­зуемую вер­сию HAProxy — 1.9.10.

По­гуг­лив, узна­ем, что эта вер­сия уяз­вима к ата­ке HTTP Request Smuggling.

Точка входа

HTTP Request Smuggling

HTTP Request Smuggling — это метод вме­шатель­ства в про­цесс обра­бот­ки сай­том HTTP-зап­росов, получен­ных от одно­го или нес­коль­ких поль­зовате­лей. Уяз­вимость час­то име­ет кри­тичес­кий харак­тер и поз­воля­ет зло­умыш­ленни­ку обой­ти меры безопас­ности, получить несан­кци­они­рован­ный дос­туп к кон­фиден­циаль­ным дан­ным и нап­рямую пос­тавить под угро­зу дру­гих поль­зовате­лей при­ложе­ния. Уяз­вимость воз­ника­ет из‑за того, что спе­цифи­кация HTTP пре­дос­тавля­ет два раз­ных спо­соба ука­зать, где закан­чива­ется зап­рос: заголо­вок Content-Length и заголо­вок Transfer-Encoding.

За­голо­вок Content-Length прост: он опре­деля­ет дли­ну тела сооб­щения в бай­тах. Нап­ример:

За­голо­вок Transfer-Encoding может при­менять­ся для ука­зания того, что исполь­зует­ся тело сооб­щения с фраг­менти­рован­ным кодиро­вани­ем. Это зна­чит, что тело сооб­щения содер­жит один или нес­коль­ко бло­ков дан­ных. Бло­ки устро­ены так. Сна­чала идет раз­мер бло­ка в бай­тах (в hex), затем знак новой стро­ки, а даль­ше — содер­жимое бло­ка. Сооб­щение закан­чива­ется бло­ком нулево­го раз­мера. Нап­ример:

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

Прис­тупим к реали­зации. Отпра­вим ком­мента­рий и перех­ватим зап­рос в Burp Proxy.

Его сто­ит пре­обра­зовать сле­дующим обра­зом: ука­жем заголо­вок Transfer-Encodeing:[x0b]chunked и поменя­ем зна­чение Connection на keep-alive. Пос­ле чего дуб­лиру­ем заголов­ки зап­роса в тело зап­роса.

Пос­ле редирек­та видим явно не тот ком­мента­рий, который отправ­ляли.

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

Так как это сер­вис хра­нения заметок, сра­зу прос­мотрим, что может хра­нить админ. Находим три замет­ки.

Каж­дая из них содер­жит учет­ные дан­ные.

Точка опоры

С най­ден­ными учет­ными дан­ными получа­ется авто­ризо­вать­ся в Git от име­ни root. Находим очень мно­го ком­митов, которые сто­ит прос­мотреть. Отту­да мы можем получить еще какие‑нибудь учет­ные дан­ные, сек­реты, токены или прос­то узнать исполь­зуемые тех­нологии.

Я начал прос­мотр с кон­ца. Важ­ные дан­ные наш­лись в ком­мите вот по этой ссыл­ке:

А в этом ком­мите нашел­ся при­ват­ный ключ:

Не­обхо­димо про­верить этот ключ. Для это­го сфор­миру­ем спи­сок поль­зовате­лей и попыта­емся под­клю­чить­ся по SSH. Для авто­мати­зации я исполь­зовал Metasploit Framework.

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