3 800 репозиторіїв GitHub вкрадено після атаки через шкідливе розширення VS Code

Скомпрометований інструмент розробника призвів до одного з найгучніших зломів репозиторіїв в останній пам'яті. GitHub наразі розслідує інцидент безпеки, під час якого шкідливе розширення Visual Studio Code інфікувало пристрій співробітника, що зрештою призвело до витоку приблизно 3 800 внутрішніх репозиторіїв. Вкрадений код згодом виставило на продаж на форумі кіберзлочинців угруповання, що назвало себе TeamPCP. Для команд безпеки та розробників, які покладаються на внутрішні репозиторії, цей інцидент є різким нагадуванням: безпека пристроїв розробників і ризик злому репозиторіїв — невіддільні проблеми.

Як шкідливе розширення VS Code скомпрометувало співробітника GitHub

Visual Studio Code став домінуючим редактором у професійній розробці програмного забезпечення, а його маркетплейс розширень — величезним. Більшість розробників ставляться до розширень так само, як до мобільних застосунків: встановив, довірився і пішов далі. Саме це припущення й експлуатують зловмисники.

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

Це не теоретичний вектор атаки. Шкідливі пакети та розширення стають дедалі більшою проблемою в екосистемах розробників — від npm і PyPI до магазинів браузерних розширень. Маркетплейс розширень VS Code, хоча й великий та широко використовуваний, традиційно покладається на автоматизоване сканування, яке досвідчені зловмисники можуть обійти через відкладену доставку корисного навантаження або обфускацію.

Що було вкрадено і про що свідчить оголошення TeamPCP про продаж

Згідно з наявною інформацією, під час інциденту було вилучено приблизно 3 800 внутрішніх репозиторіїв GitHub. Угруповання TeamPCP, яке взяло на себе відповідальність, згодом виставило ці матеріали на продаж на форумі кіберзлочинців, що свідчить про фінансову, а не шпигунську мотивацію.

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

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

Чому кінцеві точки розробників є найслабшою ланкою в безпеці репозиторіїв

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

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

Атаки на ланцюжок поставок через розширення та пакети є особливо небезпечними в цьому контексті, оскільки вписуються у звичайну поведінку розробника. Встановлення нового інструменту — рутинна справа. Розробників не навчають ставитися до кожного розширення IDE як до потенційного вектора загрози так, як команди безпеки ставляться до невідомих виконуваних файлів. Цей розрив у підході й активно експлуатують такі угруповання, як TeamPCP.

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

Багаторівневий захист: VPN, Zero-Trust і MFA для захисту доступу до внутрішнього коду

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

Мережевий доступ із нульовою довірою (Zero-trust) — це найбільш актуальний архітектурний зсув у цьому контексті. За моделлю нульової довіри довіра до пристрою оцінюється безперервно, а не припускається автоматично. Навіть якщо зловмисник має дійсний токен сесії, аномальна поведінка (наприклад, масове клонування репозиторіїв у незвичний час) може ініціювати повторну автентифікацію або автоматичне завершення сесії. Поєднання zero-trust із надійним виявленням загроз на кінцевих точках дає командам безпеки можливість бачити, які процеси здійснюють мережеві виклики, включно зі шкідливими розширеннями.

Багатофакторна автентифікація з апаратно прив'язаними ключами додає ще один бар'єр. Стійка до фішингу MFA (FIDO2/passkeys) гарантує, що навіть повністю скомпрометований пристрій не зможе непомітно автентифікуватися в нових сесіях без фізичної взаємодії з боку користувача.

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

Для команд, які надають пріоритет незалежно перевіреній інфраструктурі, Private Internet Access довів свої заяви про відсутність журналів у ході федеральних судових процесів і підтримує повністю відкриті застосунки, підкріплені стороннім аудитом.

Крім VPN, організаціям також слід впровадити список дозволених розширень для інструментів розробників, вимагати підпису коду або організаційного схвалення перед встановленням розширень IDE на корпоративні пристрої, а також вести детальні журнали аудиту шаблонів доступу до репозиторіїв для раннього виявлення масового вилучення.

Що це означає для вас

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

Практичні висновки:

  • Перевірте кожне розширення VS Code, встановлене на вашому робочому комп'ютері. Видаліть усе, що ви не встановлювали навмисно або більше активно не використовуєте.
  • Ставтеся до розширень IDE з тим самим скептицизмом, що й до встановлення невідомих виконуваних файлів. Перевіряйте верифікацію видавця та кількість відгуків перед встановленням.
  • Відстоюйте впровадження в організації списку дозволених розширень на керованих пристроях розробників.
  • Переконайтеся, що ваш доступ до внутрішнього репозиторію захищений стійкою до фішингу MFA, а не лише паролем плюс SMS.
  • Якщо ваша команда отримує доступ до внутрішніх систем через публічні або неконтрольовані мережі, додайте VPN з перевіреною конфіденційністю як один із рівнів стеку віддаленого доступу з нульовою довірою.
  • Співпрацюйте з вашою командою безпеки для налаштування базових сповіщень про масовий доступ до репозиторіїв або незвичну поведінку клонування.

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