Розкрито деталі атаки на інфраструктуру, що використовується при розробці фреймворку машинного навчання PyTorch, що дозволило витягти ключі доступу, достатні для розміщення довільних даних у репозиторії з релізами проекту в GitHub та AWS, а також для підстановки коду в основну гілку репозиторію та додавання. Підміна релізів PyTorch могла використовуватися для здійснення атаки на великі компанії, такі як Google, Meta, Boeing та Lockheed Martin, які використовують PyTorch у своїх проектах. У рамках програми Bug Bounty компанія Meta виплатила дослідникам $16250 XNUMX за інформацію про проблему.
Суть атаки у можливості виконання свого коду на серверах безперервної інтеграції, що виконують перескладання та виконання завдань для тестування нових змін, що надсилаються до репозиторій. Проблема зачіпає проекти, які використовують власні зовнішні обробники Self-Hosted Runner з GitHub Actions. На відміну від традиційних GitHub Actions, обробники Self-Hosted виконуються не в інфраструктурі GitHub, а на своїх серверах або у віртуальних машинах, що підтримуються розробниками.
Виконання складальних завдань на своїх серверах дозволяє організувати запуск коду, який може здійснити сканування внутрішньої мережі підприємства, пошук у локальній ФС ключів шифрування та токенів доступу, аналіз змінних оточення з параметрами звернення до зовнішніх сховищ або хмарних сервісів. За відсутності належної ізоляції складального оточення знайдені конфіденційні дані можуть бути відправлені атакуючим зовні, наприклад через звернення до зовнішніх API. Для визначення застосування проектами "Self-Hosted Runner" може використовуватися інструментарій Gato, що аналізує загальнодоступні workflow-файли та логи запуску CI-задань.
У PyTorch та багатьох інших проектах, які використовують Self-Hosted Runner, запуск складальних завдань дозволено лише розробникам, зміни яких раніше проходили рецензування та включалися до кодової бази проекту. Наявність статусу «contributor» при використанні в репозиторії налаштувань за замовчуванням дає можливість запускати обробники GitHub Actions при передачі pull-запитів і, відповідно, виконувати свій код у будь-якому оточенні GitHub Actions Runner, прив'язаному до репозиторію або організації, що займається проектом.
Прив'язку до статусу «contributor» виявилося легко оминути — досить попередньо відправити незначну зміну та дочекатися її прийняття до кодової бази, після чого розробник автоматично отримував статус активного учасника, pull-запити якого можна тестувати в CI-інфраструктурі без окремої перевірки. Для отримання статусу активного розробника в ході експерименту використовувалися незначні косметичні зміни, пов'язані з усуненням друкарських помилок у документації. Для отримання доступу до репозиторію та сховища релізів PyTorch в ході атаки при виконанні коду в Self-Hosted Runner був здійснений перехоплення токена GitHub, що застосовувався для доступу до репозиторію зі складальних процесів, а також ключів AWS, задіяних для збереження результатів складання.
Проблема не специфічна для PyTorch і зачіпає багато інших великих проектів, які використовують стандартні налаштування для «Self-Hosted Runner» у GitHub Actions. Наприклад, згадано здійснення схожих атак для підстановки бекдора в деякі великі гаманці криптовалют та блокчейн-проекти з мільярдною капіталізацією, внесення змін до релізів Microsoft Deepspeed та TensorFlow, компрометації однієї з програм компанії CloudFlare, а також виконання коду на комп'ютері у мережі Microsoft. Деталі за даними інцидентами поки що не розкриваються. У рамках діючих програм Bug Bounty дослідники відправили понад 20 заявок на отримання винагород на суму кілька сотень тисяч доларів.
Джерело: opennet.ru