Популярні GitHub Actions actions-cool/issues-helper і actions-cool/maintain-one-comment скомпрометовано внаслідок атаки на ланцюг постачання: усі наявні теги в репозиторіях були перенаправлені на шкідливі коміти, які витягують облікові дані з конвеєрів CI/CD і надсилають їх на сервер зловмисників. Будь-який робочий процес GitHub Actions, що посилається на ці дії за версією (тегом), під час наступного запуску завантажить шкідливий код. Єдиний спосіб захисту — прив’язка до повного SHA-хешу завідомо безпечного коміту.

Механізм атаки: imposter-коміти

За даними дослідника Варуна Шарми зі StepSecurity, атаку реалізовано через техніку imposter-комітів — метод компрометації ланцюга постачання, за якого шкідливий код впроваджується шляхом посилання на коміт або тег, що існує лише у форку, який контролює зловмисник, а не в оригінальному довіреному репозиторії. Такий підхід дає змогу обійти стандартні перевірки через Pull Request і домогтися виконання довільного коду.

Як повідомляє StepSecurity, кожен наявний тег у репозиторії actions-cool/issues-helper було пересунуто так, щоб він вказував на підставний коміт, який не фігурує в звичайній історії комітів дії. Це означає, що шкідливий код стає невидимим під час стандартного перегляду історії репозиторію.

Ланцюжок виконання шкідливого коду

Під час запуску в середовищі GitHub Actions Runner шкідливий коміт виконує таку послідовність дій:

• Завантажує середовище виконання JavaScript Bun на ранер
• Зчитує пам’ять процесу Runner.Worker для витягування облікових даних
• Виконує вихідний HTTPS-запит до домену, який контролює зловмисник, для передавання викрадених даних

Зчитування пам’яті процесу Runner.Worker — особливо небезпечний вектор, оскільки цей процес містить секрети, токени доступу та інші облікові дані, що використовуються в конвеєрі CI/CD. Компрометація цих даних може відкрити зловмисникам доступ до репозиторіїв, хмарних середовищ та інших ресурсів, пов’язаних із робочими процесами.

Масштаб компрометації

За даними дослідників, окрім actions-cool/issues-helper, 15 тегів другого GitHub Action — actions-cool/maintain-one-comment — також було скомпрометовано з аналогічною функціональністю. GitHub заблокував доступ до репозиторію actions-cool/maintain-one-comment, вказавши на порушення умов використання платформи. Конкретні причини цього рішення не розкриваються.

Оскільки всі теги тепер вказують на шкідливі коміти, під загрозою опиняється кожен робочий процес, який посилається на ці дії за версією — наприклад, через конструкції на кшталт actions-cool/issues-helper@v3 або actions-cool/issues-helper@latest. Під час наступного запуску такий робочий процес автоматично завантажить і виконає шкідливий код.

Індикатори компрометації

Домен ексфільтрації даних, зафіксований під час аналізу:

• t.m-kosche[.]com — домен, на який надсилаються викрадені облікові дані

Організаціям рекомендовано перевірити мережеві журнали на наявність звернень до цього домену з середовища CI/CD.

Оцінка впливу

Ця атака становить високий рівень небезпеки для організацій, які використовують у своїх конвеєрах CI/CD задіяні GitHub Actions. Компрометація облікових даних ранера може призвести до каскадних наслідків: несанкціонованого доступу до приватних репозиторіїв, хмарної інфраструктури, реєстрів контейнерів та інших ресурсів, секрети яких передаються через GitHub Actions.

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

Рекомендації з реагування

1. Негайно припиніть використання actions-cool/issues-helper і actions-cool/maintain-one-comment в усіх робочих процесах
2. Проведіть аудит журналів CI/CD-ранерів на предмет вихідних з’єднань до домену t.m-kosche[.]com
3. Ротуйте всі секрети, які були доступні в робочих процесах, що використовували скомпрометовані дії: токени GitHub, ключі API, облікові дані хмарних провайдерів
4. Перейдіть на прив’язку до повних SHA-хешів комітів для всіх сторонніх GitHub Actions замість посилань за тегами або гілками — це єдиний надійний спосіб захисту від подібних атак
5. Запровадьте моніторинг мережевої активності ранерів для виявлення аномальних вихідних з’єднань із середовища CI/CD

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