GitHub підтвердив у вівторок, що нападники отримали несанкціонований доступ до своїх внутрішніх репозиторіїв після компрометації пристрою працівника за допомогою отруєного розширення Visual Studio Code. Платформа, що належить Microsoft, виявила та локалізувала компрометацію, видалила шкідливе розширення, ізольовала вплинутий endpoint і негайно розпочала реагування на інцидент.
Компанія заявила, що наразі вважає, що порушення стосувалося лише екстракції внутрішніх репозиторіїв GitHub. Репозиторії клієнтів, підприємства та дані користувачів, збережені поза внутрішніми системами GitHub, не вважаються ураженими.
Масштаб порушення
GitHub підтвердив, що твердження нападника про приблизно 3 800 внутрішніх репозиторіїв є напрямково узгодженими зі своїм власним розслідуванням. Група загроз TeamPCP взяла на себе відповідальність за порушення безпеки і, як повідомляється, намагається продати вкрадені дані на підземних кіберкримінальних форумах за більше ніж $50 000. Група стверджує, що дані містять власний вихідний код платформи та внутрішні організаційні файли з приблизно 4 000 приватних репозиторіїв.
GitHub сказав, що швидко змінив критичні облікові дані після виявлення порушення, надавши пріоритет найбільш важливим секретам. Компанія продовжує аналізувати журнали, перевіряти зміну секретів і спостерігати за подальшою діяльністю.
Чому доступ до внутрішнього сховища — це серйозно
Компанія заявила, що не має доказів впливу на інформацію клієнтів, збережену поза внутрішніми сховищами. Дослідники з безпеки зазначили, що конкретна формулювання має значення. Відсутність доказів впливу не є підтвердженням безпеки даних клієнтів. Це означає, що розслідування триває, а повний радіус ураження ще не визначено.
Внутрішні сховища зазвичай містять конфігурації інфраструктури, сценарії розгортання, внутрішню документацію API, тимчасові облікові дані, прапорці функцій, інструменти моніторингу та недокументовані сервіси. Доступ до вихідного коду внутрішньої системи надає схему архітектури всієї системи, навіть без прямого доступу до даних клієнтів.
Спеціалісти з безпеки також відзначили значущість прямого згадування GitHub щодо моніторингу подальшої діяльності. Сучасні атаки рідко зупиняються на початковому доступі. Стандартна послідовність передбачає перехід від початкового плацдарму до розвідки, підвищення привілеїв, забезпечення стійкості, а потім другої хвилі цільової діяльності після того, як захисники вважають, що загроза була ліквідована.
Що робить GitHub
GitHub повідомив, що критичні секрети були змінені того ж дня, коли було виявлено порушення, спочатку — найбільш чутливі облікові дані. Компанія продовжує моніторити інфраструктуру на наявність будь-якої вторинної активності і опублікує детальніший звіт про інцидент після завершення розслідування. Клієнтів буде проінформовано через встановлені канали реагування на інциденти, якщо буде виявлено будь-який вплив на їхні дані.
Розробникам, які використовують GitHub, рекомендовано перевірити та змінити будь-які ключі API, збережені в репозиторіях, як заходи обережності, навіть якщо вважається, що репозиторії клієнтів безпосередньо не були вплинуті.