Explor-им GitLab
Введение
Привет, Хабр! Меня зовут Дмитрий Прохоров, я пентестер из команды CyberOK. Часто на проектах по пентесту, а также в программах Bug Bounty встречаются Gitlab«ы. И встречаются они не только специалистам по ИБ, но и злобным хакерам, которые не прочь завладеть секретами репозиториев и даже исполнить код на сервере! Все представленные материалы несут образовательный характер :)
Сегодня я бы хотел посвятить свой монолог тем, кто любит приоткрывать завесу тайн своего Gitlab через функционал Explore и показывать интересные кейсы из Bug Bounty и пентестов, где небольшая мисконфигурация приводит к тяжелым последствиям.
Explore — не баг, а фича!
Холивар на тему функционала исследования Gitlab для анонимных пользователей тянулся несколько лет с 2017 года. И закрытие данной фичи до 2020 года являлось скорее костылем. Но на проблему обратили внимание и все-таки закрыли Explore и Help для неаутентифицированных пользователей через настройки видимости репозитория (Covid сыграл в этом некую роль).
Рис. 1
В поисках тайн
Введение прошло, переходим к исследованию. Самое очевидное, что стоит поискать в Gitlab — это токены, API-ключи и информацию о внутренней сети.
В проектах встречалось разное:) :
Рис. 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) не жалко вложить собственные средства, которые с большей вероятностью окупятся. И это был именно такой случай. Немного заморочившись с вводом данных своей карты, я получил заветные креды и побежал проверять свою теорию похека :) .
Моя теория заключалась в следующем. Shared Runners в Gitlab — это составляющая процесса Pipeline среды CI/CD.
Рис. 7
Для хакера это лакомый кусочек в случае, если:
1) Пользователь имеет право на запись в .gitlab_ci.yml в репозитории;
2) Runner находится во внутренней инфраструктуре.
По умолчанию GitLab Runners доступны для каждого проекта. Это означает, что злоумышленнику не требуется доступ к определенному репозиторию для проведения атак. Злоумышленник, имеющий любой доступ к GitLab, может создать личный репозиторий и начать атаковать инфраструктуру раннера.
Рис. 8
Более того, как правило, для этого используется «docker-in-docker» (DIND) для создания контейнера внутри конвейера (Pipeline).
По указанной выше схеме-картинке, в качестве одноглазого Джо, я прошелся, изучая CI/CD на сервере Gitlab.
Похек:)
Немного пройдясь по проектам злополучного репозитория, забрав шаблонный .gitlab_ci.yml и удалив оттуда все лишнее, я собрал такой вот джентельменский набор буковок:
Рис. 9
Перед тем как проводить манипуляции, важно клацнуть на раннер, который нам нужен в настройках CI/CD репозитория.
Поднимаем на своей Front Gun пушке nc:
Рис. 10
Запускаем билд и ждем прилета нашего бэкконнекта.
Рис. 11
И мы в докере. Полученный shell кривой и неудобный. Поэтому получаем хороший TTY (как же тут без табов и .bash_history):
И вот мы гуляем по среде Shared Runner-a. Конечно, нам от него никакого импакта, кроме как возможных билдов других пользователей. Но мы же в докере, а значит нужно повышаться до докер-хоста.
И в моем кейсе все прошло достаточно тривиально :)
Заходим в /var и видим по дефолту лежащий docker.sock.
Рис. 12
Тут у меня глаза загорелись! Настраиваем среду для запуска docker-ce:
И вводим заветную команду для профита:
Рис. 13
Забегаю с рутом посмотреть, а что там в /home и наблюдаю пользователей инфры.
Рис. 14
Счастью не было предела и отчет начал писаться под выброс легкого адреналина. Отдельная благодарность команде VK Bug Bounty за быстрый триаж и отличную выплату!
В заключение
Для полного понимания вышеуказанной цепочки различных мисконфигураций и уязвимостей можно привести следующую схему:
Рис. 15
Возвращаясь ко второму заголовку: «Explore — не баг, а фича!», стоит отметить, что данный функционал, доступный анонимному пользователю — это все-таки баг. Отслеживать все процессы и пуши, происходящие в Gitlab, а также то, какие данные будут доступны «случайному» пользователю, крайне сложно. Поэтому стоит серьёзно отнестись к настройке приватности вашего репозитория.
Недавнее исследование Truffle Security еще одной «фичи», затрагивающей Github и в том числе частные репозитории Gitlab, связанной с раскрытием чувствительных данных в форках проекта, наводит на мысль, что указанные инстансы должны быть тщательно закрыты от посторонних глаз и тем более злобных хакеров.
Давайте делать наш Рунет безопаснее! :)
Подписывайтесь на телеграм СайберОК, там еще много интересного про кибербез и мониторинг поверхности внешних атак.
Дмитрий ПрохоровСпециалист по тестированию на проникновение, CyberOK.
