HTB Ready. Эксплуатируем дыру в GitLab и совершаем побег из Docker

Разведка

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

Ад­рес машины — 10.10.10.202, сме­ло кида­ем его в /etc/hosts, что­бы писать вмес­то это­го ready.htb.

И конеч­но, ска­ниру­ем пор­ты в поис­ках инте­рес­ных вещей.

Ви­дим два откры­тых пор­та: 22 (служ­ба SSH) и 5080 (веб‑сер­вер nginx). На SSH мы пой­дем сту­чать­ся, ког­да у нас будут какие‑нибудь учет­ные дан­ные, поэто­му нач­нем с nginx. Скрипт, при­веден­ный выше, любез­но пре­дос­тавил нам информа­цию из поля http-title, бла­года­ря которой мы сра­зу опре­деля­ем исполь­зуемую тех­нологию — GitLab.

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

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

Точка входа

На стра­нице Help находим вер­сию про­дук­та — 11.4.7.

Впол­не веро­ятно, что для такого популяр­ного про­дук­та в Exploit DB най­дут­ся готовые уяз­вимос­ти. Если ты исполь­зуешь Kali Linux или дру­гой хакер­ский дистр, то, ско­рее все­го, можешь прос­то написать коман­ду searchsploit:

Так мы узна­ем об уяз­вимос­ти, которая может пре­дос­тавить уда­лен­ное выпол­нение кода (RCE). Так­же получа­ем ее иден­тифика­тор (2018-19571 и 2018-19585) в базе дан­ных обще­извес­тных уяз­вимос­тей информа­цион­ной безопас­ности (CVE).

Закрепление

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

За­тем экс­плу­ати­рует­ся уяз­вимость SSRF в фун­кции соз­дания нового про­екта при импорте репози­тория по URL. Это поз­воля­ет нам обра­щать­ся к локаль­ному сер­веру Redis, который работа­ет на пор­те 6379. Так как при этом «зап­росы к локаль­ному хос­ту не раз­решены», для обхо­да исполь­зует­ся спе­циаль­ный адрес IPv6: [0:0:0:0:0:ffff:127.0.0.1]:6379.

Redis — резиден­тная сис­тема управле­ния базами дан­ных клас­са NoSQL с откры­тым исходным кодом, работа­ющая со струк­турами дан­ных типа «ключ — зна­чение». Она час­то исполь­зует­ся и в роли СУБД, и для реали­зации кешей и бро­керов сооб­щений. GitLab исполь­зует его по‑раз­ному, нап­ример для хра­нения дан­ных сеан­са, кеширо­вания и даже для хра­нения оче­реди фоновых заданий.

Так как Redis исполь­зует прос­той тек­сто­вый про­токол, мы можем спо­кой­но работать с ним нап­рямую, не соб­людая никаких спе­цифи­каций. Так как есть воз­можность вза­имо­дей­ство­вать с Redis через SSRF, ста­новит­ся воз­можным получе­ние уда­лен­ного выпол­нения кода (RCE).