GH Actions - Cache Poisoning

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

• Якщо ви хочете побачити вашу компанію в рекламі HackTricks або завантажити HackTricks у PDF Перевірте ПЛАНИ ПІДПИСКИ!

• Отримайте офіційний PEASS & HackTricks мерч

• Відкрийте Сім'ю PEASS, нашу колекцію ексклюзивних NFT

• Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами на Twitter 🐦 @hacktricks_live.

• Поділіться своїми хакерськими трюками, надсилайте PR до HackTricks та HackTricks Cloud репозиторіїв.

Для отримання додаткових відомостей перегляньте оригінальний пост https://scribesecurity.com/blog/github-cache-poisoning/

Забруднення кешу

Дія Git action/cache вводить механізм кешування в процес безперервної інтеграції (CI), охоплюючи дві критичні стадії:

1. Виконання дії: Ця стадія включає пошук та отримання кешованих даних під час виконання CI. Пошук використовує унікальний ключ кешу, що призводить до двох результатів:

• Кеш-попадання: Запитані дані знаходяться в кеші і відповідно отримуються для негайного використання.

• Кеш-промах: В кеші не знайдено відповідних даних, що викликає свіже завантаження необхідних файлів та каталогів, подібно до першого запиту.

2. Після дії робочого процесу: Ця стадія присвячена кешуванню даних після робочого процесу CI. Зокрема, якщо відбувається кеш-промах під час виконання дії, поточний стан вказаних каталогів кешується за вказаним ключем. Цей процес автоматизований і не потребує явного виклику.

Заходи безпеки: Ізоляція кешу та обмеження доступу

Для забезпечення безпеки та забезпечення ізоляції кешу, застосовуються обмеження доступу, створюючи логічне розділення між різними гілками. Наприклад, кеш, створений для гілки Feature-A (з базою в основній гілці), буде недоступний для pull-запиту для гілки Feature-B (також на базі в основній гілці).

Дія кешу дотримується конкретного порядку пошуку:

• Спочатку вона шукає кеш-попадання в тій самій гілці, що і виконання робочого процесу.

• У разі невдачі пошуку вона розширює пошук до батьківської гілки та інших вищестоячих гілок.

Важливо, що доступ до кешу обмежений гілково, поширюючись на всі робочі процеси та запуски конкретної гілки. Крім того, GitHub накладає політику тільки для читання для записів кешу після їх створення, забороняючи будь-які модифікації.

Реальний вплив: Від атаки робочого процесу з низькими до високих дозволів

Ілюстративний сценарій CI показує, як зловмисник може використовувати забруднення кешу для ескалації привілеїв від робочого процесу з низькими дозволами до робочого процесу з високими дозволами:

• Робочий процес Unit-test, відповідальний за запуск модульних тестів та інструментів покриття коду, припускається використання компрометованого або вразливого інструменту. Цей робочий процес використовує дію Git action/cache, що робить кеш доступним для будь-якого робочого процесу.

• Робочий процес Release, який відповідає за побудову та випуск програмного артефакту, оптимізує свою роботу, кешуючи залежності Golang.

У цьому сценарії робочий процес unit-test вводить зловмисний запис кешу, замінюючи законний бібліотечний реєстратор Golang (`go