HTB Attended. Инжектим команды в Vim и раскручиваем бинарную уязвимость с помощью ROP-цепочек

Разведка

Ад­рес машины — 10.10.10.221, сра­зу добав­ляем его в /etc/hosts, что­бы мож­но было обра­щать­ся по име­ни.

Тра­дици­онно перехо­дим к ска­ниро­ванию пор­тов:

По резуль­татам ска­ниро­вания име­ем два откры­тых пор­та: 22 (служ­ба SSH) и 25 (SMTP-сер­вер). На SSH нам ловить нечего (брут уче­ток — пос­леднее дело!). Оста­ется толь­ко порт 25, а в слу­чае с SMTP глав­ный век­тор — это фишинг.

В резуль­татах ска­ниро­вания упо­мина­ется имя поль­зовате­ля guly, это уже что‑то. Мы будем отправ­лять сооб­щение, содер­жащее наш локаль­ный адрес, и прос­матри­вать тра­фик на наличие сетево­го вза­имо­дей­ствия. В тек­сте сооб­щения мож­но написать что угод­но, к при­меру «Hi, guly! See 10.10.14.121». Для сбо­ра тра­фика акти­виру­ем tcpdump и с помощью филь­тра отоб­разим толь­ко те пакеты, адрес наз­начения которых наш локаль­ный.

Для отправ­ки сооб­щения будем исполь­зовать удоб­ный скрипт swaks. Для ука­зания получа­теля и отпра­вите­ля исполь­зуют­ся парамет­ры --to и --from соот­ветс­твен­но, текст сооб­щения ука­зыва­ется в фай­ле, путь к которо­му переда­ется в парамет­ре --body, адрес сер­вера — в парамет­ре -s.

Сна­чала в окне tcpdump будут толь­ко отве­ты сер­вера, но через нес­коль­ко секунд мы уже уви­дим зап­рос, при­чем к пор­ту 25.

Точка входа

Ка­жет­ся, нам пыта­ются отве­тить! Что­бы при­нять ответ, раз­вернем прос­той сер­вер SMTP на локаль­ном хос­те. Для это­го уста­новим и запус­тим Postfix.

Все при­нятые сооб­щения будут рас­положе­ны в фай­ле, наз­вание которо­го сов­пада­ет с име­нем локаль­ного поль­зовате­ля (у меня — zralf). А рас­положен этот файл в дирек­тории /var/mail/. Для отсле­жива­ния вхо­дящих писем в пос­тоян­ном режиме мож­но запус­тить про­вер­ку в watch.

Пов­торим отправ­ку сооб­щения и получим ответ в кон­соли watch.

Из тек­ста сооб­щения отме­чаем еще одно­го поль­зовате­ля — freshness, а так­же упо­мина­ние опе­раци­онной сис­темы OpenBSD (это мы зна­ли) и тек­сто­вого редак­тора Vim.

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

Для поис­ка экс­пло­итов удоб­на база Exploit-DB, встро­енная в Kali Linux и дос­тупная через ути­литу searchsploit, но в реаль­ных усло­виях луч­ше исполь­зовать Google, что­бы искать по всем дос­тупным иссле­дова­ниям и отче­там, вклю­чая самые новые.

Вер­сию исполь­зуемо­го тек­сто­вого редак­тора мы не зна­ем, поэто­му возь­мем экс­пло­ит для самой све­жей — 8.1.1365. CVE-2019-12735 поз­воля­ет выпол­нить коман­ды в опе­раци­онной сис­теме при откры­тии фай­лов со спе­циаль­ным содер­жимым (да, это воз­можно! Vim — слож­ный инс­тру­мент, а это зна­чит, что такие вот сюр­при­зы иног­да встре­чают­ся).

Как ука­зано в опи­сании экс­пло­ита, мы переда­ем коман­ду, которую нуж­но выпол­нить, меж­ду сим­волами :! и ||. При­мер выпол­нения коман­ды uname -a:

Поп­робу­ем про­верить экс­пло­ит на прак­тике, но дело осложня­ется тем, что мы не видим резуль­тата выпол­нения коман­ды. Поэто­му нуж­но выпол­нить обра­щение с уда­лен­ного хос­та на наш локаль­ный. Поп­робу­ем выз­вать кон­нект по про­токо­лу TCP. Сиг­нализи­ровать об обра­щении нам будет ути­лита netcat:

Для соз­дания кон­некта с уда­лен­ного хос­та тоже можем прос­то исполь­зовать netcat, ука­зав свой IP и прос­лушива­емый порт (nc [ip] 4321). Как ука­зано в экс­пло­ите, соз­дадим файл‑вло­жение со сле­дующим содер­жимым:

И пов­торим отправ­ку сооб­щения, ука­зав этот файл в парамет­ре --attach.

Нем­ного ждем и, не получив никако­го откли­ка, дела­ем два пред­положе­ния: либо экс­пло­ит не работа­ет, либо на сер­вере нет netcat. Давай поп­робу­ем сде­лать то же самое, но уже исполь­зуя curl и по про­токо­лу HTTP. Изме­ним коман­ду в при­лага­емом фай­ле expl.txt.

Сно­ва ждем, ничего не получа­ем и зак­рыва­ем лис­тенер netcat. Есть еще два вари­анта выпол­нить бэк­коннект — DNS и ICMP. Давай поп­робу­ем вари­ант с пин­гом. Прос­матри­вать тра­фик будем с помощью tcpdump, ука­зав в филь­тре толь­ко пакет ICMP:

А теперь отправ­ляем файл (коман­ду swaks не при­вожу, она оста­ется преж­ней), который в этот раз содер­жит коман­ду с пин­гом. И спус­тя некото­рое вре­мя получа­ем отклик!

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

• COMMAND && ping [IP] — если пинг при­шел, то коман­да COMMAND выпол­нилась успешно, ина­че нет;
• COMMAND || ping [IP] — если пинг при­шел, то коман­да COMMAND не выпол­нилась.

Закрепление

Мы можем лишь узнать, выпол­нилась коман­да или нет, но не зна­ем ее резуль­тат. Что­бы про­извести эксфиль­тра­цию резуль­тата выпол­ненных команд, нам нуж­но най­ти спо­соб обра­щать­ся по HTTP. Нуж­но най­ти коман­ду, с помощью которой это мож­но было бы делать. Как искать? Будем зап­рашивать help у каж­дой прог­раммы. Нач­нем с curl, меня­ем содер­жимое отправ­ляемо­го фай­ла:

Пинг не при­шел, при этом если исполь­зовать дру­гой тип кон­вей­ера (curl -h || ping -c 4 [ip]), то пакеты идут. Дела­ем вывод: curl на хос­те отсутс­тву­ет. Теперь про­верим таким же спо­собом wget:

Пин­га нет, но есть при обратном кон­вей­ере ||, то есть wget тоже отсутс­тву­ет. Про­буем Python 2:

И получа­ем пинг, а зна­чит, Python 2 есть на хос­те! Про­веря­ем, можем ли мы пос­тучать­ся на свой хост по HTTP. Для начала запус­тим прос­той HTTP-сер­вер на Python 3:

А на хос­те нуж­но выпол­нить такой скрипт: