Сучасні атаки дедалі рідше починаються зі зламу серверів. Натомість вони ховаються в інструментах, яким фахівці довіряють щодня. Після серії інцидентів із Nx Console та кампанією Megalodon агентство CISA попередило про нову хвилю supply chain атак, спрямованих на корпоративні, хмарні і DevOps-середовища.
Розповідаємо вам, що сталося, чому такі атаки особливо небезпечні та чому між технічною загрозою і реакцією бізнесу досі часто виникає розрив.
Що сталося?
У центрі уваги агентів з кібербезпеки опинилися два інциденти, що продемонстрували вразливості звичних робочих процесів до атак через ланцюг постачання програмного забезпечення.
Компрометація Nx Console
Один із інцидентів стосувався шкідливої версії розширення Nx Console для Visual Studio Code.
За даними CISA, зловмисники скористалися попереднім зламом систем розробників Nx і поширили заражене розширення, яке зрештою потрапило на пристрій співробітника GitHub. Це дало змогу отримати несанкціонований доступ до внутрішніх репозиторіїв компанії та викрасти конфіденційну інформацію.
Кампанія Megalodon
Друга кампанія, відома під назвою Megalodon, була спрямована на GitHub-репозиторії та CI/CD-процеси.
Дослідники виявили тисячі шкідливих комітів, які впроваджували заражені GitHub Actions workflow-файли. Після запуску такі робочі процеси збирали секрети CI/CD, хмарні облікові дані, токени доступу та інші конфіденційні дані.
За різними оцінками, кампанія зачепила понад 5 500 репозиторіїв, продемонструвавши, наскільки привабливою ціллю для зловмисників залишаються автоматизовані процеси розробки та розгортання ПЗ.
Що таке supply chain attack і чим вона небезпечна
Supply chain attack — це кібератака на ланцюг постачання програмного забезпечення, під час якої зловмисники використовують скомпрометовані компоненти чи сервіси, яким довіряють користувачі та організації.
Особливу небезпеку становить те, що такі інциденти часто починаються не на периметрі мережі, а всередині ланцюга постачання програмного забезпечення. Якщо шкідливий компонент потрапляє до середовища розробки, він може отримати доступ до токенів, секретів, хмарних облікових даних та інших критично важливих ресурсів ще до того, як спрацюють традиційні засоби захисту.
У спрощеному вигляді supply chain атака зазвичай виглядає так:
- Зловмисники знаходять компонент, який активно використовується в процесах розробки (розширення IDE, GitHub Action, пакет чи інший елемент екосистеми).
- Отримують доступ до цього компонента або вбудовують у нього шкідливий код.
- Шкідлива версія інструмента поширюється через рутинні канали оновлень.
- Розробники та організації встановлюють його, не підозрюючи про загрозу, оскільки він не викликає підозр.
- Заражений код отримує доступ до чутливих даних і сервісів компанії.
- Викрадені дані використовуються для подальшого проникнення в інфраструктуру або компрометації інших систем.
Що рекомендує CISA
Aгентство опублікувало низку рекомендацій для організацій, які використовують GitHub, CI/CD-конвеєри та сторонні пакети у своїх процесах розробки.
Серед основних порад:
- перевірити встановлені розширення та інші інструменти розробки на наявність несанкціонованих змін;
- провести аудит GitHub Actions, workflow-файлів і репозиторіїв;
- контролювати активність контриб’юторів та відстежувати підозрілі зміни в проєктах;
- у разі підозри на компрометацію проаналізувати журнали CI/CD, хмарного аудиту та пристроїв розробників;
- ротувати або відкликати токени, ключі доступу, облікові дані та інші секрети, які могли бути скомпроментовані;
- фіксувати залежності на перевірених версіях замість автоматичного використання найновіших релізів;
- використовувати пакети лише з перевірених джерел;
Важливо: CISA наголошує не поспішати з використанням щойно опублікованих пакетів і, за можливості, чекати щонайменше три години після релізу. За цей час спільнота може виявити та повідомити про потенційно шкідливі зміни.
Як пояснити ці ризики бізнесу
Проблема supply chain атак полягає не лише в їхній технічній складності. Для багатьох організацій не менш важливим викликом залишається донесення масштабу загрози до керівництва. Навіть якщо команди безпеки регулярно звітують про ризики, рада топменеджерів не завжди може оцінити їхній потенційний вплив на бізнес.
Для команди безпеки викрадений токен доступу — це червоний прапорець. Для ради директорів — лише технічна деталь, доки вона не перетворюється на фінансові збитки. Саме цей розрив у сприйнятті ризиків аналітики Gartner називають однією з головних проблем сучасної кібербезпеки.
Експерти рекомендують CISO та security командам формулювати ризики через їхній вплив на бізнес-процеси. Замість технічних термінів варто відповідати на запитання, які хвилюють керівництво:
- Скільки коштуватиме потенційний простій?
- Які сервіси можуть бути недоступними?
- Як інцидент вплине на клієнтів?
- Які репутаційні ризики він створює для компанії?
Іншими словами, ризик supply chain атаки варто описувати не як компрометацію GitHub Actions, а як можливість порушення надання послуг. Саме такий підхід допомагає спрощує ухвалення рішень щодо інвестицій у кібербезпеку.
Що варто винести з цих інцидентів
У кібербезпеці давно діє правило: міцність системи визначається її найслабшою ланкою. Інциденти з Nx Console та Megalodon показують, що така ланка може ховатися там, де її найменше очікують побачити.Сучасним організаціям важливо стежити не лише за безпекою ланцюга постачання, а й за тим, щоб інформація про загрози не губилася між технічними командами та керівництвом. Адже вчасно помічений і правильно пояснений ризик приносить не менше користі, ніж своєчасно встановлений патч.