Меня зовут Дмитрий Прохоров, я пентестер из команды CyberOK. Часто на проектах по пентесту, а также в программах Bug Bounty встречаются Gitlab-ы. И встречаются они не только специалистам по ИБ, но и злобным хакерам, которые не прочь завладеть секретами репозиториев и даже исполнить код на сервере! Все представленные материалы несут образовательный характер J
Сегодня я бы хотел посвятить свой монолог тем, кто любит приоткрывать завесу тайн своего Gitlab через функционал Explore и показывать интересные кейсы из Bug Bounty и пентестов, где небольшая мисконфигурация приводит к тяжелым последствиям.
Explore – не баг, а фича!
Холивар на тему функционала исследования Gitlab для анонимных пользователей тянулся несколько лет с 2017 года. И закрытие данной фичи до 2020 года являлось скорее костылем. Но на проблему обратили внимание и все-таки закрыли Explore и Help для неаутентифицированных пользователей через настройки видимости репозитория (Covid сыграл в этом некую роль).

Рис.1
Поэтому речь, по большому счету, пойдет о тех организациях, где уровень видимости настроен некорректно и дает злобным хакерам больше информации, чем нужно.
В поисках тайн
Введение прошло, переходим к исследованию. Самое очевидное, что стоит поискать в Gitlab — это токены, API-ключи и информацию о внутренней сети.
В проектах встречалось разное J:

Рис. 2 Раскрытие логина и пароля Gitlab (https://login:pass@gitlab.example.com)

Рис. 3 Раскрытие логина и пароля БД в файле .sh

Рис. 4 Раскрытие ключей API в файле .sh

Рис. 5 Раскрытие окружения Shared Runner в файле. yml – Ansible
И если, рассматривая первые три скриншота, все вполне очевидно (и ничего нового я не показал), то окружение Shared Runner-а представляет наибольший интерес для эксплуатации связки уязвимостей и выполнения удаленного кода на сервере. При наличии раскрытия токена Shared Runner-а мы можем обратиться напрямую к Gitlab и перехватить сессию задач процесса CI/CD. Это может помочь получить первоначальный доступ к репозиторию от имени пользователя проекта.
Расшаренные бегуны
Что ж, если на различные токены и секреты репозиторий пуст, то идем в раздел CI/CD проекта и смотрим, что там в Jobs’ах:

Рис. 6 Еще одно место для утечек переменных окружения
Наличие процессов CI/CD — это уже хорошо и здесь можно выстроить интересный вектор, о котором очень подробно рассказали ребята из Pulse Security.
И именно этот вектор позволил мне попасть в шорт-лист Pentest Award, а также забрать хорошую баунти в одной из программ VK.
Главной проблемой был доступ к данному репозиторию. К сожалению, утечки токена Shared Runner-а не было, но мы как хитрые багхантеры знаем, что при возможности приобретения легального доступа (да-да, не Try Harder) не жалко вложить собственные средства, которые с большей вероятностью окупятся. И это был именно такой случай. Немного заморочившись с вводом данных своей карты, я получил заветные креды и побежал проверять свою теорию похека J.
Моя теория заключалась в следующем. Shared Runners в Gitlab — это составляющая процесса Pipeline среды CI/CD.

Рис.7
Для хакера это лакомый кусочек в случае, если:

Пользователь имеет право на запись в .gitlab_ci.yml в репозитории;
Runner находится во внутренней инфраструктуре.

По умолчанию GitLab Runners доступны для каждого проекта. Это означает, что злоумышленнику не требуется доступ к определенному репозиторию для проведения атак. Злоумышленник, имеющий любой доступ к GitLab, может создать личный репозиторий и начать атаковать инфраструктуру раннера.

Рис. 8
Более того, как правило, для этого используется «docker-in-docker» (DIND) для создания контейнера внутри конвейера (Pipeline).
По указанной выше схеме-картинке, в качестве одноглазого Джо, я прошелся, изучая CI/CD на сервере Gitlab.
Похек J
Немного пройдясь по проектам злополучного репозитория, забрав шаблонный .gitlab_ci.yml и удалив оттуда все лишнее, я собрал такой вот джентельменский набор буковок:

Рис.9
Перед тем как проводить манипуляции, важно клацнуть на раннер, который нам нужен в настройках CI/CD репозитория.
Поднимаем на своей Front Gun пушке nc:

Рис.10
Запускаем билд и ждем прилета нашего бэкконнекта.

Рис.11
И мы в докере. Полученный shell кривой и неудобный. Поэтому получаем хороший TTY (как же тут без табов и .bash_history):
apt update
apt install python3
python3 -c ‘import pty; pty.spawn(“/bin/bash”)’
# Ctrl+Z
stty raw -echo; fg; ls; export SHELL=/bin/bash; export TERM=screen; stty rows 38 columns 116; reset;
И вот мы гуляем по среде Shared Runner-a. Конечно, нам от него никакого импакта, кроме как возможных билдов других пользователей. Но мы же в докере, а значит нужно повышаться до докер-хоста.
И в моем кейсе все прошло достаточно тривиально 🙂
Заходим в /var и видим по дефолту лежащий docker.sock.

Рис.12
Тут у меня глаза загорелись! Настраиваем среду для запуска docker-ce:
apt install apt-transport-https ca-certificates curl software-properties-common -y
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable"
apt update
apt install docker-ce -y
И вводим заветную команду для профита:
docker run -it --privileged -v /:/host/ ubuntu bash -c "chroot /host/"

Рис. 13
Забегаю с рутом посмотреть, а что там в /home и наблюдаю пользователей инфры.

Рис.14
Счастью не было предела и отчет начал писаться под выброс легкого адреналин). Отдельная благодарность команде VK Bug Bounty за быстрый триаж и отличную выплату!
В заключение
Для полного понимания вышеуказанной цепочки различных мисконфигураций и уязвимостей можно привести следующую схему:

Рис.15
Возращаясь ко второму заголовку: «Explore – не баг, а фича!», стоит отметить, что данный функционал, доступный анонимному пользователю – это все-таки баг. Отслеживать все процессы и пуши, происходящие в Gitlab, а также то, какие данные будут доступны «случайному» пользователю, крайне сложно. Поэтому стоит серьёзно отнестись к настройке приватности вашего репозитория.
По данным нашей «кибербалайки» СКИПА на текущий момент в Рунете развернуто 14798 инстансов с Gitlab из которых 3263 имеют включенный функционал Explore для анонимных пользователей, что потенциально говорит о возможной утечке чувствительных данных.

Рис.16
Недавнее исследование Truffle Security еще одной «фичи», затрагивающей Github и в том числе частные репозитории Gitlab, связанной с раскрытием чувствительных данных в форках проекта, наводит на мысль, что указанные инстансы должны быть тщательно закрыты от посторонних глаз и тем более злобных хакеров.
Давайте делать наш Рунет безопаснее! J