#gitlab #github #secrets #security

История третья. GitHub.

Третья история это не баг репорт, а собственное исследование в целях повышения опыта и экспертизы в вопросах безопасности.
НЕ ПОВТОРЯТЬ, ЭТО ПРОТИВОЗАКОННО, НЕЛЬЗЯ ПОВТОРЯТЬ
История лишь для ознакомления, повторять абсолютно запрещено, заметка исключительно в целях сокрытия СВОИХ проектов от глупых действий.

Все эти игрища были лишь в организации, где изначально у меня были хоть какие-то, но минимальные права.
Будет ли это работать при публичных репозиториях?
Как мне проверить это и защитить свои публичные репозитории от хакеров?

Немного теории. Выжимка для самых маленьких - вы ведь не хотите читать всю документацию GitHub.
1) Когда я запускаю у себя(личный репо, репо организации) воркфлоу - это МОЙ секьюрити контекст.
Мой securitycontext = мне доступны все секреты.
Если я сделаю форк от любого публичного репозитория, затем "что-то подменяю" в коде и отправлю pull request - это Fork а значит недоступен SecurityContext и секреты. То есть при любом форке - секреты недоступны, только если автор репозитория специально руками не сделает это(по умолчанию выключено).
Однако есть директива pull_request_target
https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request_target
Если в каком-то репозитории есть такая директива = при форке и пулл реквесте мы получаем доступ к SecurityContext.
2)GitHub не дурак и отслеживает любые изменения файлов воркфлоу.
Даже если у нас есть pull_request_target, но мы взяли и подменили workflow файл, добавив туда нечто типа run: python scripts/print_secret.py - этих изменений не будет в воркфлоу - есть дифф между оригиналом

Это всё теория, а что насчёт практики.
Чтобы "взломать все интернеты" нам надо соблюдение таких условий
- чтобы была опасная директива pull_request_target - "pull_request_target"
- чтобы директория была - path:.github/workflows/
- чтобы мы могли как-то где-то что-то запустить, НЕ изменяя файл воркфлоу, но заинжектить свой вредоносный код, а точнее защититься от такой ситуации в своих публичных репозиториях.

Как мы можем заинжектить, не меняя ничего в воркфлоу?
Нам надо найти куски кода, где в run есть:
- нечто типа python script.py (подменяем сам скрипт и он выполняется, извлекая секреты)
- pip install (в setup.py инжектим pre-install и выполнение нашего кода, получаем доступ к секретам)
-npm install/command (ну тут понятно - лепи что хочешь)
- всё подобное, что выше, но для других языков/утилит

В двух словах поиск будет типа

org:*****  path:.github/workflows/ "pull_request_target" "${{ secrets." "install"

В общем и целом это помогает злоумышленнику получить доступ к вашим секретам через форк и пулл реквест.
Однако когда я начал писать об этом репорт, я уже решил почитать документацию и везде написано, что такие действия опасные.
То есть тот, кто включил у себя pull_request_target - сам себе злобный буратино.
Та же ситуация с запуском скриптов из всех примеров выше.
Вероятно от https://hackerone.com/ я получу такой же ответ.
Репорт не стал писать. И слишком много условий и в документации есть миллионы ворнингов.

Итоги.
Первые две истории - это реальные репорты с реальным ответом. Все семь репортов мне закрыли с
Informative (Closed). Само собой без каких-либо выплат. Остальные пять репортов я тут публиковать не буду - их них ещё можно протянуть дальше кейсы и попробовать дальше эволюционировать в реальную уязвимость (они уровнем выше, чем эти истории на мой взгляд).
Третья же история это самостоятельное погружение "а как это работает".

Для себя же стоит запомнить:
- никогда не использовать в своих публичных репозиториях pull_request_target - при форке идёт передача SecurityContext и все секреты отдаются публично.
- нникогда не использовать в своих публичных репозиториях запуск сторонник скриптов типа python script.py
- не рассчитывать на сохранность всех секретов GitLab
- я ещё поиграю в хакера и попробую заработать на других потенциальных уязвимостях

И да - я опять поленился писать лонгрид в один пост, сорян.