SavePearlHarbor

Explor-им GitLab

—

от автора

admin

Введение

Привет, Хабр! Меня зовут Дмитрий Прохоров, я пентестер из команды CyberOK. Часто на проектах по пентесту, а также в программах Bug Bounty встречаются Gitlab’ы. И встречаются они не только специалистам по ИБ, но и злобным хакерам, которые не прочь завладеть секретами репозиториев и даже исполнить код на сервере! Все представленные материалы несут образовательный характер 🙂

Сегодня я бы хотел посвятить свой монолог тем, кто любит приоткрывать завесу тайн своего Gitlab через функционал Explore и показывать интересные кейсы из Bug Bounty и пентестов, где небольшая мисконфигурация приводит к тяжелым последствиям.

Explore – не баг, а фича!

Холивар на тему функционала исследования Gitlab для анонимных пользователей тянулся несколько лет с 2017 года. И закрытие данной фичи до 2020 года являлось скорее костылем. Но на проблему обратили внимание и все-таки закрыли Explore и Help для неаутентифицированных пользователей через настройки видимости репозитория (Covid сыграл в этом некую роль).

Рис. 1

Рис. 1

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

В поисках тайн

Введение прошло, переходим к исследованию. Самое очевидное, что стоит поискать в Gitlab — это токены, API-ключи и информацию о внутренней сети.

В проектах встречалось разное 🙂 :

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

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

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

Рис. 4 Раскрытие ключей API в файле .sh
Рис. 5 Раскрытие окружения Shared Runner в файле. yml – Ansible

Рис. 5 Раскрытие окружения Shared Runner в файле. yml – Ansible

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

Расшаренные бегуны

Что ж, если на различные токены и секреты репозиторий пуст, то идем в раздел CI/CD проекта и смотрим, что там в Jobs-ах:

Рис. 6 Еще одно место для утечек переменных окружения

Рис. 6 Еще одно место для утечек переменных окружения

Наличие процессов CI/CD — это уже хорошо и здесь можно выстроить интересный вектор, о котором очень подробно рассказали ребята из Pulse Security.

И именно этот вектор позволил мне попасть в шорт-лист Pentest Award, а также забрать хорошую баунти в одной из программ VK.

Главной проблемой был доступ к данному репозиторию. К сожалению, утечки токена Shared Runner-а не было, но мы как хитрые багхантеры знаем, что при возможности приобретения легального доступа (да-да, не Try Harder) не жалко вложить собственные средства, которые с большей вероятностью окупятся. И это был именно такой случай. Немного заморочившись с вводом данных своей карты, я получил заветные креды и побежал проверять свою теорию похека 🙂 .

Моя теория заключалась в следующем. Shared Runners в Gitlab — это составляющая процесса Pipeline среды CI/CD.

Рис.7

Рис.7

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

1)    Пользователь имеет право на запись в .gitlab_ci.yml в репозитории;

2)    Runner находится во внутренней инфраструктуре.

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

Рис. 8

Рис. 8

Более того, как правило, для этого используется «docker-in-docker» (DIND) для создания контейнера внутри конвейера (Pipeline).

По указанной выше схеме-картинке, в качестве одноглазого Джо, я прошелся, изучая CI/CD на сервере Gitlab.

Похек 🙂

Немного пройдясь по проектам злополучного репозитория, забрав шаблонный .gitlab_ci.yml и удалив оттуда все лишнее, я собрал такой вот джентельменский набор буковок:

Рис.9

Рис.9

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

Поднимаем на своей Front Gun пушке nc:

Рис.10

Рис.10

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

Рис.11

Рис.11

И мы в докере. Полученный shell кривой и неудобный. Поэтому получаем хороший TTY (как же тут без табов и .bash_history):

И вот мы гуляем по среде Shared Runner-a. Конечно, нам от него никакого импакта, кроме как возможных билдов других пользователей. Но мы же в докере, а значит нужно повышаться до докер-хоста.

И в моем кейсе все прошло достаточно тривиально 🙂

Заходим в /var и видим по дефолту лежащий docker.sock.

Рис.12

Рис.12

Тут у меня глаза загорелись! Настраиваем среду для запуска docker-ce:

 И вводим заветную команду для профита:

Рис. 13

Рис. 13

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

Рис.14

Рис.14

Счастью не было предела и отчет начал писаться под выброс легкого адреналина. Отдельная благодарность команде VK Bug Bounty за быстрый триаж и отличную выплату!

В заключение

Для полного понимания вышеуказанной цепочки различных мисконфигураций и уязвимостей можно привести следующую схему:

Рис.15

Рис.15

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

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

Рис.16

Рис.16

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

Давайте делать наш Рунет безопаснее! 🙂

Подписывайтесь на телеграм СайберОК, там еще много интересного про кибербез и мониторинг поверхности внешних атак.

Дмитрий Прохоров

Специалист по тестированию на проникновение, CyberOK.


ссылка на оригинал статьи https://habr.com/ru/articles/840506/

Комментарии

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

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