HTB Laboratory. Взламываем GitLab и учимся перехватывать пути в Linux

Разведка

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

IP-адрес машины — 10.10.10.216, я при помощи строч­ки в /etc/hosts дам ей имя laboratory.htb.

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

Наш­лось три откры­тых пор­та:

• порт 22 (TCP) — служ­ба SSH;
• порт 80 (HTTP) — веб‑сер­вер Apache 2.4.41;
• порт 443 (HTTPS) — веб‑сер­вер Apache 2.4.41.

Ска­ниро­вание пор­та 443 пре­под­носит нам при­ятный сюр­приз. Пос­коль­ку он отве­чает за обще­ние по зашиф­рован­ному про­токо­лу, в отче­те о ска­ниро­вании мож­но най­ти сер­тификат, а в сер­тифика­те еще один домен — git.laboratory.htb. Я тоже добав­лю его в /etc/hosts:

При обра­щении по домену laboratory.htb мы ничего инте­рес­ного не получа­ем, а вот на най­ден­ном git.laboratory.htb нас встре­чает GitLab.

Сканирование веба

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

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

Мы узна­ем вер­сию GitLab CE — 12.8.1.

Точка входа

В реаль­ных усло­виях луч­ше все­го искать экс­пло­иты при помощи Google, пос­коль­ку этот поис­ковик заг­лядыва­ет и в лич­ные бло­ги, и в самые раз­ные отче­ты. Но для уско­рения мож­но поль­зовать­ся спе­циали­зиро­ван­ными базами вро­де Exploit-DB — ско­рее все­го, там най­дут­ся под­ходящие вари­анты. Если ты исполь­зуешь Kali Linux, то эта база у тебя уже есть и для поис­ка мож­но исполь­зовать ути­литу searchsploit.

Как видишь, мы наш­ли сра­зу нес­коль­ко экс­пло­итов, хотя для нуж­ной вер­сии GitLab ничего нет. Зато есть для более новой (номер 48431), а зна­чит, ско­рее все­го, подой­дет и к нашей.

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

Для это­го нам нуж­но изна­чаль­ное иссле­дова­ние, доказа­тель­ство работос­пособ­ности (proof of concept) этой уяз­вимос­ти. Что­бы най­ти его, обра­щаем­ся в Google. Нам повез­ло, на HackerOne (самая извес­тная плат­форма для bug bounty) нашел­ся це­лый отчет. В нем рас­ска­зано, как не толь­ко читать фай­лы, но и получить уда­лен­ное выпол­нение кода (RCE)!

Для получе­ния RCE нам нуж­но иметь кон­соль Ruby on Rails и зна­чение secret_key_base из фай­ла /opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml. Имен­но для получе­ния содер­жимого это­го фай­ла мы будем исполь­зовать пер­вую уяз­вимость, которая поз­воля­ет читать про­изволь­ные фай­лы.

Закрепление

Итак, чита­ем файл. Соз­дадим два про­екта в GitLab, а потом перей­дем к вклад­ке Issues и выберем New Issue. Там ука­зыва­ем сле­дующее зна­чение в качес­тве опи­сания и таким обра­зом вос­поль­зуем­ся уяз­вимостью типа path traversal.

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