Title тег: Приклади атак ланцюга постачання: Повний посібник (2013–2024) Мета-опис: Дізнайтеся, що таке атаки ланцюга постачання та розгляньте 9 головних прикладів від SolarWinds до XZ Utils, з механізмами атак, даними про фінансовий вплив та стратегіями захисту.

Що таке шок пропозиції і що він означає для кібербезпеки

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

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

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

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

--- ## Що таке атака на ланцюг постачання?

Атака на ланцюжок постачання (supply chain attack) — це кібератака, яка опосередковано компрометує організацію, націлюючись на довіреного стороннього постачальника, програмний компонент або апаратний елемент у ланцюжку постачання цієї організації. Зловмисники впроваджують шкідливий код або бекдори в легітимне програмне чи апаратне забезпечення на ранніх етапах, так що жертви несвідомо вносять загрозу самі через рутинні процеси оновлення або закупівлі. Власні засоби контролю безпеки жертви обходяться, оскільки атака надходить із довіреного джерела.

Ланцюжок постачання програмного забезпечення охоплює кожен компонент, бібліотеку та процес, залучені до створення та доставки програмного продукту. Це включає сторонні залежності коду, бібліотеки з відкритим вихідним кодом, інфраструктуру збірки, сервери оновлень та апаратне мікропрограмне забезпечення. Будь-який із цих елементів може слугувати точкою входу.

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

Витік даних — це наслідок, а не метод атаки. Атаки на ланцюжок постачань можуть спричинити витоки даних, але не всі витоки даних передбачають компрометацію ланцюжка постачань. Не всі атаки на ланцюжок постачань також призводять до крадіжки даних: NotPetya спричинила знищення, а не ексфільтрацію даних.

Як працюють атаки на ланцюжок поставок

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

Життєвий цикл атаки: крок за кроком

1. Зловмисник ідентифікує довіреного постачальника або програмний компонент, який використовує ціль
2. Зловмисник отримує доступ до системи збірки, репозиторію коду або сервера оновлень постачальника
3. Шкідливий код впроваджується в легітимне програмне забезпечення або апаратні засоби перед розповсюдженням
4. Постачальник розповсюджує скомпрометований продукт через свої звичайні, довірені канали
5. Організація-ціль встановлює оновлення або розгортає компонент, впроваджуючи загрозу
6. Зловмисник використовує створений плацдарм для горизонтального переміщення, шпигунства або розгортання деструктивних корисних навантажень

Таксономія векторів атак

Троянізовані оновлення програмного забезпечення

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

Компрометація системи збирання (build system compromise) націлена на автоматизований процес компіляції, який перетворює вихідний код на виконуване програмне забезпечення. Зловмисник отримує доступ до середовища збирання постачальника та вставляє зловмисний код під час компіляції. Отриманий програмний пакет виглядає ідентично до легітимної версії. Конвеєр CI/CD (Continuous Integration/Continuous Deployment), скомпрометований на цьому етапі, поширить зловмисний код у кожен наступний випуск програмного забезпечення, навіть якщо вихідний код залишається чистим. Ось чому навіть ретельний аудит коду у репозиторії вихідного коду не виявить атаку.

Подумайте про це так: уявіть собі постачальника фармацевтичних препаратів, який перед відправленням непомітно замінює законні ліки на забруднену версію. Лікарня, яка отримує та вводить їх, не зробила нічого поганого. Атака була спрямована на ланцюг постачання, а не на лікарню.

SolarWinds, CCleaner та ASUS ShadowHammer слідували цій моделі. У кожному з випадків зловмисники компрометували інфраструктуру збірки вендора, а не безпосередньо цільові організації.

Атаки на реєстри пакетів з відкритим вихідним кодом

Загальнодоступні реєстри пакетів є одними з найактивніших поверхонь атак у ланцюжку постачання програмного забезпечення. Сюди входять npm для JavaScript, PyPI для Python, RubyGems для Ruby, NuGet для .NET та Maven для Java. Лише реєстр npm містить понад два мільйони пакетів. Один скомпрометований популярний пакет може поширити шкідливий код у мільйони програм.

Три окремі моделі атак націлені на цю екосистему. При тайпосквотингу, зловмисник реєструє пакет із назвою, майже ідентичною назві популярного легітимного пакета (наприклад, lodahs замість lodash), сподіваючись на неуважність розробників. При підміні залежностей, зловмисник використовує в публічному реєстрі таку саму назву, як і назва приватного внутрішнього пакета цільової організації. Системи збирання, які перевіряють публічні реєстри раніше за приватні, автоматично завантажать шкідливу версію. При ін’єкції шкідливого пакета, легітимний пакет компрометується після публікації шляхом крадіжки облікових даних супроводжувача або через соціальну інженерію щодо проєкту.

Про плутанину залежностей вперше було публічно продемонстровано в широкому масштабі у 2021 році дослідником з безпеки Алексом Бірсаном, який успішно отримав виконання коду в конвеєрах збірки Apple, Microsoft, PayPal та ще 35 великих компаній за допомогою цієї техніки. Атака спрацювала не через помилку, а через те, як менеджери пакетів вирішують конфлікти іменування між публічними та приватними реєстрами.

Щодо Log4Shell: Log4Shell (CVE-2021-44228), критична вразливість, виявлена у грудні 2021 року у бібліотеці журналювання Java Apache Log4j, часто описується як атака на ланцюжок постачання. Це не так. Log4Shell була ненавмисною програмною вразливістю. Жоден зловмисник не вставляв її в кодову базу Log4j. Плутанина виникає через те, що присутність Log4j як залежності у тисячах програмних продуктів зробила виявлення всіх уражених систем схожим на проблему аудиту ланцюжка постачання. Модель загрози відрізняється: атаки на ланцюжок постачання включають навмисно вставлений зловмисником шкідливий код, тоді як Log4Shell була випадковою помилкою, яку зловмисники згодом використали.

Компрометація MSP та горизонтальне переміщення

Провайдер керованих послуг (MSP) — це компанія, яка віддалено керує ІТ-інфраструктурою, безпекою та системами організації-клієнта. MSP зазвичай використовуються малими та середніми підприємствами, які не мають власних ІТ-відділів. Компрометація MSP надає зловмисникам одночасний адміністративний доступ до всіх клієнтів цього постачальника, перетворюючи MSP на вектори атак із ефектом мультиплікації сили з непропорційним охопленням подальших ланок ланцюга. Консультативний висновок CISA AA22-131A окремо попереджає MSP, що вони є пріоритетними цілями.

Потрапивши всередину будь-якої мережі через троянізоване оновлення або скомпрометовану залежність, зловмисники зазвичай використовують техніки горизонтального переміщення. Ці методи експлуатують легітимні облікові дані та шляхи мережевого доступу для переходу від початково скомпрометованої системи до більш чутливих цілей. Під час атаки на SolarWinds угруповання APT29 використовувало бекдор SUNBURST як початковий плацдарм, після чого перемістилося горизонтально до систем електронної пошти та сховищ чутливих даних у різних державних установах.

Основні приклади атак на ланцюжок поставок

У наведеній нижче таблиці узагальнено найбільш значущі приклади атак на ланцюги постачання з 2013 по 2024 рік, структуровані за суб’єктом, вектором та задокументованим впливом.

Витік даних Target (2013)

Target (2013) — кримінальна група отримала доступ до мережі POS-терміналів Target, спочатку скомпрометувавши Fazio Mechanical Services, стороннього підрядника з обслуговування систем опалення, вентиляції та кондиціонування (ОВК) і холодильного обладнання, який мав облікові дані для віддаленого доступу до систем Target.

Злам Target є найпершим широко вивченим прикладом шаблону атаки на ланцюжок постачання. Зловмисники не пробивалися безпосередньо через периметрові захисні системи Target. Вони отримали облікові дані від невеликого постачальника систем опалення, вентиляції та кондиціонування (ОВК), використали ці облікові дані, щоб потрапити до мережі Target через легітимний шлях доступу, і потім перемістилися латерально до систем торгових точок (POS-систем), які обробляли дані платіжних карток.

Результатом стала крадіжка даних платіжних карток приблизно 40 мільйонів клієнтів та персональних даних близько 110 мільйонів осіб. Загальні витрати Target через цей злам перевищили оціночні 200 мільйонів доларів на виплати за мировими угодами, юридичні витрати та усунення наслідків. Ця атака створила шаблон, який вдосконалювали в подальших атаках: компрометація довіреного постачальника, що має доступ до справжньої цілі, з подальшим використанням цього доступу як точки входу. Розслідування Секретної служби США та Міністерства юстиції підтвердили, що шлях через стороннього постачальника став вектором входу.

Атака на ланцюг постачання SolarWinds (2020)

SolarWinds (2020) — APT29 (Cozy Bear), приписуване Службі зовнішньої розвідки (СЗР) Росії, скомпрометувало процес збирання Платформи моніторингу ІТ Orion, впровадивши бекдор SUNBURST у звичайне оновлення програмного забезпечення, яке завантажили приблизно 18 000 клієнтів SolarWinds.

SolarWinds вважається найбільш значущою кібератакою на ланцюжок постачання в зафіксованій історії. Orion була широко розповсюдженою Платформою для ІТ-моніторингу, яку використовували в урядових установах США та великих корпораціях. Зловмисники впровадили бекдор SUNBURST у конвеєр збірки програмного забезпечення, що означало, що шкідливий код був скомпільований безпосередньо в легітимний пакет оновлення Orion, підписаний дійсними сертифікатами SolarWinds і розповсюджений через офіційні канали оновлення.

Серед приблизно 18 000 організацій, які завантажили троянізоване оновлення, зловмисники вибрали пріоритетні цілі для подальшої експлуатації. До них належали Міністерства фінансів, торгівлі, внутрішньої безпеки та Державний департамент США, а також Microsoft, FireEye та інші великі технологічні компанії. Вторгнення залишалося непоміченим приблизно дев'ять місяців, перш ніж FireEye виявила його під час розслідування аномалії у власних системах.

APT29 використала точку доступу SUNBURST як початковий пункт проникнення, потім переміщувалася горизонтально мережами, що були скомпрометовані, щоб отримати доступ до електронних систем та конфіденційних комунікацій. Операція була оцінена як шпигунська кампанія, а не як деструктивна атака. Реакція уряду США, скоординована через Консультативну інформацію CISA AA20-352A,), включала екстрені директиви, що стосувалися всіх федеральних цивільних агентств.

NotPetya (2017)

NotPetya (2017) — Sandworm, яку приписують російській військовій розвідці ГРУ (військова частина 74455), впровадила шкідливий код в оновлення програмного забезпечення M.E.Doc — українського бухгалтерського застосунку, яким користується значна частина підприємств, що працюють в Україні.

NotPetya не був програмою-вимагачем. Він відображав повідомлення про викуп, але це був лише відволікаючий маневр. Код перезаписував головний завантажувальний запис (MBR) інфікованих систем, що робило їх остаточно невідновними. Це був руйнівний вайпер, створений для завдання максимальної шкоди, без жодного реального механізму оплати. Схожість із програмою-вимагачем була розроблена для того, щоб приховати приналежність атаки під час першочергових заходів із реагування.

Початковим вектором зараження було оновлення M.E.Doc, але NotPetya швидко поширився за межі України через експлойт EternalBlue та мережеве розповсюдження, ставши глобальною катастрофою за лічені години. Загальні збитки оцінюються приблизно в 10 мільярдів доларів США по всьому світу, що робить його найруйнівнішою кібератакою в історії за фінансовим впливом. Серед названих жертв — судноплавний гігант Maersk (приблизно 300 мільйонів доларів збитків; компанії довелося з нуля перевстановити 45 000 ПК та 4 000 серверів), фармацевтичний виробник Merck, FedEx/TNT Express та Mondelez International. Багато з цих організацій не мали прямого зв’язку з Україною і стали супутніми жертвами, досягнутими через глобальну мережеву зв’язність.

Атака детально задокументована в ретроспективному розслідуванні Wired і приписується Sandworm Сполученими Штатами, Великою Британією та Австралією. Sandworm відрізняється від APT29/Cozy Bear: вони діють під керівництвом різних російських спецслужб (ГРУ та СЗР) з різними оперативними мандатами.

Атака на Kaseya VSA (2021)

Kaseya VSA (2021) — REvil, кіберзлочинна група, яка працює за моделлю "програми-вимагача як послуги" (RaaS) і не має зв'язків з жодною державою, використала вразливість нульового дня в Kaseya VSA для одночасного розповсюдження шкідливих оновлень клієнтам MSP.

Kaseya VSA — це Платформа для віддаленого моніторингу та керування, яка широко використовується постачальниками керованих послуг (MSP). REvil, фінансово мотивоване злочинне угруповання, виявило поверхню атаки на MSP та масштабно її експлуатувало. Скомпрометувавши Платформу VSA, REvil змогло одночасно розіслати всім кінцевим клієнтським організаціям шкідливі оновлення, які виглядали так, ніби вони надходять від довіреного MSP.

Результат: було скомпрометовано приблизно 60 MSP, і через них приблизно 1500 компаній-клієнтів постраждали від програм-вимагачів (шкідливе програмне забезпечення, яке шифрує дані жертви та вимагає оплату за ключ дешифрування). REvil вимагав 70 мільйонів доларів США у біткоїнах за універсальний дешифратор. Атака особливо чітко проілюструвала логіку багаторазового посилення ефекту від націлювання на MSP: одна скомпрометована платформа охопила сотні організацій за одну операцію. CISA Advisory AA21-200B) містить повний технічний аналіз.

Атака на ланцюг постачання Codecov (2021)

Codecov (2021) — невідомий зловмисник скомпрометував скрипт Codecov Bash Uploader, інструмент для звітування про покриття коду, інтегрований у CI/CD пайплайни тисяч організацій, та використав його для ексфільтрації змінних середовища, включаючи облікові дані та API-токени.

Codecov — це сервіс аналізу покриття коду, який використовується командами розробки програмного забезпечення для відстеження покриття тестами. Зловмисник змінив скрипт Bash Uploader, який організації завантажують і запускають як частину своїх автоматизованих процесів збірки. Оскільки скрипт виконувався всередині середовища CI/CD, він мав прямий доступ до змінних середовища, що містили облікові дані, токени та ключі доступу до репозиторію.

Компрометація залишалася непоміченою протягом приблизно двох місяців, перш ніж Codecov виявила її у квітні 2021 року. Серед постраждалих організацій були Twilio, HashiCorp і Confluent, які повідомили про розкриття облікових даних. Атака продемонструвала специфічний для CI/CD вектор ланцюга постачання: замість того, щоб компрометувати кінцевий програмний продукт, зловмисники націлилися на інструментарій, який організації використовують для створення та тестування програмного забезпечення. Ця атака знаходиться на перетині компрометації конвеєра збірки та крадіжки облікових даних, що представляє собою окрему модель, відмінну від векторів розповсюдження оновлень, використаних у випадках SolarWinds та CCleaner.

Атака на ланцюг постачання CCleaner (2017)

CCleaner (2017) — група AXIOM, пов'язана з державним кіберспонсорством Китаю, скомпрометувала середовище збірки компанії Piriform (розробника CCleaner) та внесла шкідливе програмне забезпечення Floxif до законного інсталятора CCleaner, що розповсюджувався через офіційні канали.

CCleaner — це популярна утиліта для оптимізації ПК, яку використовують мільйони споживачів та компаній. Атака продемонструвала, що компрометування ланцюгів поставок не обмежується лише корпоративним програмним забезпеченням. Приблизно 2,27 мільйона користувачів завантажили заражену версію до того, як було виявлено компрометацію.

Атака мала другий етап: цільовий пейлоад був попередньо налаштований так, щоб активуватися лише на системах, що належать приблизно 40 високотехнологічним компаніям, серед яких Cisco, Intel, Samsung та Sony. Для переважної більшості постраждалих користувачів зловмисне програмне забезпечення пасивно збирало дані. Для цільових технологічних компаній це становило серйозне проникнення в чутливі мережі. Аналіз Cisco Talos) інфраструктури командно-контрольних серверів CCleaner надав перший повний технічний розбір атаки.

ASUS ShadowHammer (2019)

ASUS ShadowHammer (2019) — група BARIUM, пов'язана з державним хакінгом Китаю, скомпрометувала утиліту Live Update від ASUS та розповсюдила бекдорену версію, підписану дійсними цифровими сертифікатами ASUS, через офіційні сервери оновлень ASUS.

Ця атака продемонструвала значні наслідки для цифрової довіри: на легітимні сертифікати підпису коду не можна покладатися як на доказ цілісності програмного забезпечення, якщо сама інфраструктура підписання була скомпрометована. Троянізоване оновлення ASUS містило дійсні сертифікати ASUS і розповсюджувалося через офіційний механізм оновлення ASUS, пройшовши кожну Стандартну перевірку. Приблизно 500 000 користувачів ASUS отримали оновлення з бекдором.

Зловмисники не цікавилися всіма 500 000 користувачами. Шкідливий корисний навантаження було попередньо налаштовано для активації лише на системах із приблизно 600 конкретними MAC-адресами, що свідчить про попередню розвідку щодо конкретних цілей. Кампанію було виявлено та задокументовано дослідницькою командою Kaspersky (Securelist)) у 2019 році.

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

Атака на ланцюжок постачання 3CX (2023)

3CX (2023) — Група Lazarus, приписувана Бюро загальної розвідки Північної Кореї (RGB), здійснила першу публічно підтверджену атаку типу «ланцюг постачання на ланцюг постачання», проникнувши до середовища збірки 3CX через попередній компроміс ланцюга постачання програмного забезпечення Trading Technologies.

Персональний комп'ютер співробітника 3CX був скомпрометований через троянізований інсталятор Trading Technologies X_TRADER, фінансової торгової платформи. Цей інсталятор Trading Technologies був скомпрометований ланцюгом постачання групою Lazarus під час попередньої операції. Скомпрометована машина співробітника надала зловмисникам доступ до середовища збірки 3CX, яке вони використали для впровадження шкідливого програмного забезпечення в 3CX Desktop App, платформу VoIP-комунікацій, яку використовують понад 600 000 компаній та 12 мільйонів користувачів щодня по всьому світу.

Атака непропорційно сильно вдарила по компаніях фінансового сектора. Оскільки компрометація 3CX сама по собі була наслідком попередньої атаки ланцюга постачання, це перший підтверджений випадок, коли атака ланцюга постачання спричинила другу атаку ланцюга постачання. Практичне значення: організаціям тепер потрібно враховувати не лише те, чи безпечні їхні безпосередні постачальники, а й те, чи не були скомпрометовані постачальники їхніх постачальників. Повний технічний аналіз задокументовано в аналізі інциденту від Mandiant.)

Бекдор XZ Utils (2024)

XZ Utils (2024) — діючи під вигаданою особою "Jia Tan", що, за оцінками дослідників безпеки, було операцією державного рівня на основі поведінкових індикаторів, без підтвердженої остаточної публічної приналежності, невідомий зловмисник приблизно два роки проникав у проєкт з відкритим кодом XZ Utils, перш ніж вставити бекдор, націлений на автентифікацію SSH у системах Linux.

XZ Utils — це бібліотека для стиснення даних, яка працює як невидима інфраструктура на мільйонах серверів Linux. Це не орієнтований на користувача застосунок, а різновид базового програмного забезпечення, від якого негласно залежить інше програмне забезпечення. Зловмисник, що діяв під ім'ям «Jia Tan», почав вносити легітимний високоякісний код у проєкт XZ Utils у 2022 році, здобуваючи довіру та зрештою отримавши права на внесення змін завдяки тривалій взаємодії з мейнтейнером проєкту.

На початку 2024 року користувач під псевдонімом «Jia Tan» впровадив бекдор у версії XZ Utils 5.6.0 та 5.6.1. Бекдор був розроблений для компрометації автентифікації SSH у вразливих дистрибутивах Linux, що потенційно надавало зловмиснику віддалений доступ до будь-якого сервера, на якому була запущена скомпрометована версія бібліотеки. SSH є основним протоколом віддаленого адміністрування для серверів Linux у всьому світі, що робить потенційний масштаб впливу надзвичайно великим.

Бекдор був виявлений до широкого розповсюдження Андресом Фройндом, інженером Microsoft, який помітив незвичне споживання ресурсів процесора та погіршення продуктивності SSH під час планової роботи та відстежив джерело. Його відкриття, опубліковане в березні 2024 року, запобігло компрометації ланцюжка поставок, яка могла вплинути на мільйони серверів. Повний технічний опис наведено в рекомендації OpenSSF (CVE-2024-3094).

Чому атаки на ланцюжок поставок є такими небезпечними

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

Шкідливе програмне забезпечення надходить із довіреного джерела: постачальника, чиї сертифікати, домени та інфраструктуру оновлень цільова організація вже авторизувала. Троянізовані оновлення часто несуть дійсні цифрові сертифікати підпису коду, видані законному постачальнику, тому перевірка сертифікатів проходить бездоганно. Антивірусні засоби та засоби виявлення на кінцевих точках можуть не позначити програмне забезпечення, підписане довіреним постачальником і доставлене офіційними каналами. Досвідчені зловмисники також навмисно затримують активні операції після початкового доступу, щоб уникнути спрацьовування виявлення аномалій. APT29 діяла в мережах, скомпрометованих SolarWinds, приблизно дев'ять місяців до виявлення. Цей час перебування (dwell time) ілюструє, наскільки тривалим може бути розрив між компрометацією та виявленням.

Атаки на ланцюжок поставок зросли за частотою та складністю протягом останнього десятиліття. Звіти ENISA про ландшафт загроз документують стійку тенденцію до зростання, при цьому атаки на ланцюжок поставок визначені як категорія загроз найвищого рівня для секторів критичної інфраструктури. Ескалація спостерігається в історичних даних: компрометація CCleaner у 2017 році торкнулася 2,27 мільйона кінцевих користувачів; операція SolarWinds у 2020 році скомпрометувала понад 100 урядових установ США; майже вдала атака на XZ Utils у 2024 році була спрямована на ключову інфраструктуру Linux, що використовується мільйонами серверів у всьому світі. Амбіції зловмисників значно зросли з кожним циклом.

Фінансові наслідки відповідають цьому масштабу. NotPetya завдав збитків у всьому світі на суму близько 10 мільярдів доларів, причому лише компанія Maersk повідомила про збитки у розмірі приблизно 300 мільйонів доларів. Під час атаки на Kaseya вимога викупу становила 70 мільйонів доларів для 1500 постраждалих компаній. Заходи уряду США у відповідь на злам SolarWinds коштували сотні мільйонів доларів витрат на відновлення та посилення інвестицій у безпеку. Об'єктами атак ставали державні та бюджетні організації (SolarWinds), компанії з надання фінансових послуг (3CX), технологічні компанії (цілі другого етапу CCleaner), а також оператори критичної інфраструктури в пріоритетних секторах, визначених CISA. Жодна галузь, яка залежить від стороннього програмного забезпечення або керованих послуг, не залишилася поза увагою зловмисників.

Хто здійснює атаки на ланцюги постачання

Атаки на ланцюжок постачання здійснюються двома чіткими категоріями зловмисників: державними групами з розширеними постійними загрозами (APT) та фінансово мотивованими злочинними організаціями.

Розширена стійка загроза (APT) — це витончений, добре забезпечений ресурсами суб'єкт загрози, як правило, розвідувальне агентство держави або військовий кіберпідрозділ, який проводить довготривалі, цільові кампанії вторгнень з конкретними стратегічними цілями. APT надають перевагу атакам на ланцюжок постачання, оскільки один компроміс на ранньому етапі (upstream) забезпечує одночасний доступ до сотень або тисяч цілей високої цінності, максимізуючи приріст розвідданих від однієї операції та мінімізуючи ризик виявлення. Атрибуція діяльності APT є ймовірнісною, ґрунтуючись на криміналістичних показниках, включаючи збіги коду, шаблони інфраструктури та операційний таймінг, а не на прямих доказах.

До груп, пов'язаних з державами, яким приписують задокументовані атаки на ланцюжки постачань, належать: APT29 (Cozy Bear), пов'язана зі Службою зовнішньої розвідки Росії (СЗР), яка провела операцію SolarWinds; Sandworm, пов'язана з Головним розвідувальним управлінням (ГРУ) Росії, яка провела NotPetya через M.E.Doc; Lazarus Group, пов'язана з Головним розвідувальним управлінням Північної Кореї, яка провела атаку 3CX; група BARIUM, пов'язана з операціями, спонсорованими державою Китай, яка провела ASUS ShadowHammer; та група AXIOM, також пов'язана з операціями, спонсорованими державою Китай, яка провела атаку CCleaner. BARIUM та AXIOM є окремими групами, незважаючи на те, що обидві мають китайську атрибуцію.

Не всі атаки на ланцюги постачання є операціями державних структур. Атаку на Kaseya VSA здійснила організація REvil, російськомовна кіберзлочинна група, що надає послуги програм-вимагачів (ransomware-as-a-service) і не має жодних зв'язків з державою. Фінансово вмотивовані злочинні групи перейняли методи атак на ланцюги постачання, оскільки компрометація одного постачальника керованих послуг (MSP) дозволяє доставити програми-вимагачі сотням клієнтських організацій за одну операцію, що драматично збільшує віддачу порівняно з атаками на окремих жертв.

Як захиститися від атак на ланцюжок постачання

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

Чек-лист корпоративного та організаційного захисту

• Впровадьте політику специфікації програмного забезпечення (SBOM) для всього ПЗ, яке ваша організація купує або створює, щоб ви могли ідентифікувати уражені компоненти у разі виявлення компрометації ланцюга постачання
• Проводьте аудит практик безпеки сторонніх постачальників перед закупівлею та на щорічній основі, використовуючи стандартизовані анкети, узгоджені з NIST SP 800-161r1
• Вимагайте від постачальників надання поточних SBOM для всіх програмних продуктів, що потрапляють у ваше середовище, як частину процесу закупівель та укладання контрактів
• Застосовуйте принципи архітектури нульової довіри: забезпечте доступ за принципом найменших привілеїв для всього ПЗ та сервісів, впроваджуйте мережеву мікросегментацію для стримування бічного переміщення та здійснюйте безперервну перевірку замість довіри до мережевого розташування
• Моніторте аномальну поведінку у ПЗ від перевірених постачальників, оскільки відхилення поведінки від відомих базових показників можуть вказувати на скомпрометоване оновлення, навіть якщо підписи є дійсними
• Переглядайте сертифікати безпеки постачальників (SOC 2 Type II, ISO 27001) та включайте чіткі вимоги до безпеки та зобов'язання щодо повідомлення про злам у контракти з постачальниками
• Дотримуйтесь рекомендацій CISA щодо безпеки ланцюга постачання) та впроваджуйте фреймворк NIST SP 800-161r1 (C-SCRM), щоб поширити управління ризиками на сторонніх постачальників
• Підтримуйте план реагування на інциденти, який чітко охоплює компрометацію стороннього програмного забезпечення, включаючи процедури екстреної ізоляції ураженого ПЗ у всьому вашому середовищі

Що таке специфікація програмного забезпечення (SBOM)?

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

SBOM важливий для безпеки ланцюга поставок, оскільки він дає відповідь на питання, на яке організаціям важко відповісти під час інциденту: "Чи зачепило нас?" Коли було виявлено інцидент із SolarWinds, організації без програмної інвентаризації змушені були вручну перевіряти кожну систему, щоб визначити, чи використовували вони Orion. Організації з наявними SBOM могли безпосередньо запитувати свою інвентаризацію. Така сама логіка застосувалася під час майже критичного інциденту з XZ Utils: знання, які сервери використовували певну версію бібліотеки, стало різницею між годинами часу реагування та тижнями невизначеності.

Виконавчий указ 14028 «Про вдосконалення кібербезпеки країни» (підписаний у травні 2021 року як пряма відповідь на атаку на SolarWinds) зобов'язав постачальників програмного забезпечення, які співпрацюють із федеральним урядом США, надавати специфікації SBOM. CISA опублікувала посібник із впровадження SBOM як для розробників, так і для споживачів. Інструменти, зокрема SPDX, CycloneDX та Syft, дозволяють автоматично генерувати SBOM для більшості баз вихідного коду та образів контейнерів.

Архітектура нульової довіри та захист ланцюжка постачання

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

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

Нульова довіра — це філософія безпеки та модель архітектури, а не програмний продукт для придбання. Основними авторитетними джерелами є Модель зрілості нульової довіри CISA) та NIST SP 800-207.)

Чек-лист захисту для розробників та DevOps

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

• Закріплюйте та блокуйте версії залежностей у всіх маніфестах пакетів (package-lock.json, requirements.txt, Gemfile.lock), щоб нова опублікована шкідлива версія не могла бути автоматично завантажена під час наступної збірки
• Налаштуйте систему збірки так, щоб надавати перевагу приватним реєстрам перед публічними, і резервуйте всі внутрішні простори імен пакетів у публічних реєстрах, щоб запобігти атакам із підміною залежностей (dependency confusion attacks)
• Запускайте автоматичне сканування залежностей під час кожної збірки за допомогою таких інструментів, як Dependabot, OWASP Dependency-Check або Snyk, щоб виявляти відомі вразливі або підозрілі пакети до того, як вони потраплять у продуктивне середовище
• Генеруйте SBOM для кожного релізу за допомогою CycloneDX або Syft і зберігайте його разом із артефактами збірки, щоб мати доступний для аудиту перелік компонентів для кожної розгорнутої версії
• Вимагайте підписані коміти та впроваджуйте правила захисту гілок у вашому основному конвеєрі збірки, щоб запобігти потраплянню несанкціонованого коду в процес збірки
• Проводьте аудит сторонніх пакетів перед їх додаванням: перевіряйте історію публікацій розробника, кількість завантажень, активність репозиторію та те, чи не було пакет нещодавно передано новому власнику

Безпека ланцюга постачання: нормативні вимоги та вимоги щодо відповідності

Кілька основних нормативно-правових баз наразі чітко вимагають від організацій враховувати ризики безпеки ланцюга постачання як частину їхніх зобов’язань із кібербезпеки. Ці вимоги перейшли з розряду рекомендацій до обов’язкових вимог значною мірою внаслідок атаки на SolarWinds.

Нормативно-правова база США

У Сполучених Штатах основним регуляторним поштовхом став Виконавчий наказ 14028 «Щодо покращення національної кібербезпеки», підписаний Президентом Байденом 12 травня 2021 року, безпосередньо у відповідь на атаку SolarWinds та інцидент із Kaseya VSA. Наказ EO 14028 зобов'язав постачальників програмного забезпечення, які продають федеральному уряду США, надавати Специфікацію програмного забезпечення (SBOM) для своїх продуктів. Він доручив NIST розробити керівництво з безпеки ланцюга постачання, а CISA — запровадити стандарти SBOM. Цей мандат застосовується до постачальників, що обслуговують федеральний уряд. Він не вимагає SBOM безпосередньо від усіх організацій приватного сектору, хоча вироблені на його основі стандарти були широко прийняті як вимоги щодо закупівель у корпоративних контекстах.

Основним технічним стандартом є NIST SP 800-161r1 («Практики управління ризиками в ланцюгу постачання кібербезпеки для систем та організацій»), який розширює стандартні структури управління ризиками кібербезпеки, щоб явно охопити сторонніх постачальників, вендорів та програмні компоненти. C-SCRM (управління ризиками в ланцюгу постачання кібербезпеки) згідно з NIST SP 800-161r1 вимагає від організацій проводити оцінку ризиків вендорів, перевіряти походження програмного забезпечення, впроваджувати обов’язкові специфікації програмного забезпечення (SBOM) у закупівлі та підтримувати плани реагування на інциденти, що враховують компрометацію сторонніх сторін. Публікація CISA «Захист від атак на ланцюги постачання програмного забезпечення» надає практичні рекомендації щодо впровадження, узгоджені з вимогами EO 14028.

Регуляторна база ЄС

Європейські організації стикаються з паралельними вимогами в межах двох нормативно-правових баз. Директива NIS2 (Директива про мережеву та інформаційну безпеку 2) вимагає від організацій у критично важливих секторах, включаючи енергетику, транспорт, охорону здоров'я та цифрову інфраструктуру, вирішувати ризики безпеки ланцюга постачання в межах їхніх обов'язкових зобов'язань з управління кіберризиками. DORA (Закон про цифрову оперативну стійкість) поширюється на суб'єктів фінансового сектору в ЄС і містить детальні вимоги щодо управління ризиками сторонніх постачальників послуг ІКТ, безпосередньо розглядаючи вектори атак через ланцюг постачання. ENISA (Агентство Європейського Союзу з питань кібербезпеки) виступає основним авторитетним джерелом для організацій ЄС, виконуючи роль, еквівалентну CISA у Сполучених Штатах.

Резюме регуляторних посилань

Часті запитання про атаки на ланцюжок поставок

Що таке атака на ланцюжок поставок?

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

Які існують приклади атак на ланцюжок поставок?

Найзначніші приклади атак на ланцюг постачання з 2013 по 2024 рік:

• SolarWinds (2020): Бекдор SUNBURST було вставлено в оновлення Платформи Orion; він охопив приблизно 18 000 клієнтів, включаючи понад 100 державних установ США
• NotPetya (2017): Руйнівний вірус-вайпер, поширений через оновлення бухгалтерського програмного забезпечення M.E.Doc; завдав глобальних збитків, оцінених у 10 мільярдів доларів
• Kaseya VSA (2021): Угруповання REvil використало вразливість нульового дня у VSA для доставки програм-вимагачів понад 1 500 компаніям через скомпрометованих постачальників послуг (MSP)
• XZ Utils (2024): Дворічна кампанія соціальної інженерії ледь не призвела до впровадження бекдору SSH в інфраструктуру Linux по всьому світу
• CCleaner (2017): Шкідливе ПЗ Floxif охопило 2,27 мільйона користувачів; другий етап був спрямований на 40 великих технологічних компаній
• ASUS ShadowHammer (2019): Оновлення прошивки з бекдором, підписане дійсними сертифікатами ASUS, охопило 500 000 користувачів
• 3CX (2023): Перша підтверджена атака за принципом «ланцюжок поставок у ланцюжку поставок»; охопила понад 600 000 компаній через Lazarus Group

Як працює атака на ланцюжок поставок?

Атаки на ланцюжок постачань мають повторювану послідовність:

1. Зловмисник вибирає довіреного постачальника або програмну залежність, на яку покладається ціль.
2. Зловмисник отримує доступ до середовища збірки, репозиторію коду або інфраструктури оновлень цього постачальника.
3. Шкідливий код впроваджується в легітимне програмне забезпечення перед його розповсюдженням.
4. Постачальник поставляє скомпрометований продукт через свої звичайні, довірені канали.
5. Ціль встановлює оновлення, вносячи загрозу всередину свого периметра.
6. Зловмисник активує отриманий доступ для шпигунства, крадіжки даних або деструктивних дій.

Яка найвідоміша атака на ланцюжок поставок?

Атака на SolarWinds (2020) широко вважається найбільш значущою кібератакою на ланцюжок поставок в історії. Угруповання APT29, яке пов’язують зі Службою зовнішньої розвідки РФ (СВР), впровадило бекдор SUNBURST в оновлення SolarWinds Orion, що охопило приблизно 18 000 клієнтів, включаючи понад 100 урядових установ США. Злам залишався непоміченим протягом приблизно дев’яти місяців і безпосередньо призвів до видання Виконавчого указу 14028 про покращення кібербезпеки країни.

Чому атаки на ланцюжок поставок такі небезпечні?

Атаки ланцюга постачання несуть кумулятивний ризик з чотирьох причин. Шкідливе програмне забезпечення надходить від постачальника, якому організація вже довіряє, оминаючи периметрові засоби захисту без використання будь-яких вразливостей у власних системах цілі. Троянізовані оновлення мають дійсні цифрові підписи, проходячи перевірку сертифікатів. Антивірусні інструменти можуть не позначити підписане програмне забезпечення, доставлене постачальником. Висококваліфіковані зловмисники залишаються неактивними після початкового доступу, щоб уникнути спрацьовування виявлення аномальної поведінки. Операція SolarWinds тривала непоміченою дев'ять місяців. Один скомпрометований постачальник може охопити тисячі організацій нижче за ланцюжком, масштабуючи вплив одного вторгнення далеко за межі того, чого зазвичай досягають прямі атаки.

Чи зростає кількість атак ланцюга постачання?

Атаки ланцюга постачання зросли за частотою та складністю протягом останнього десятиліття. Щорічні звіти ENISA про ландшафт загроз документують атаки ланцюга постачання як стійку та зростаючу категорію загроз, обсяг яких зростає рік за роком. Ця траєкторія є очевидною у самих інцидентах: від зламу Target у 2013 році, спричиненого невеликим підрядником з ОВК (опалення, вентиляція та кондиціонування), до шпигунської кампанії SolarWinds у 2020 році, яка зачепила уряд США, до майже вдалої атаки XZ Utils у 2024 році, спрямованої на основну інфраструктуру Linux. Фінансово мотивовані злочинні групи також перейняли методи ланцюга постачання, як показала атака Kaseya: одна скомпрометована платформа MSP досягла сотень клієнтських організацій за лічені години.

Як організації можуть захиститися від атак ланцюга постачання?

Організації можуть зменшити ризик атак на ланцюги поставок за допомогою таких дій:

["- Впровадити політику Списку програмного забезпечення (SBOM) для ведення повного обліку програмних компонентів та виявлення уражених систем при розкритті компрометації.","- Вимагати від постачальників надання SBOM та демонстрації актуальних сертифікатів безпеки (SOC 2, ISO 27001) як умов закупівлі.","- Застосовувати принципи архітектури нульової довіри: доступ з мінімальними привілеями, мікросегментація мережі та безперервний моніторинг поведінки.","- Моніторити програмне забезпечення від довірених постачальників на предмет аномалій поведінки, а не лише на основі індикаторів, що базуються на сигнатурах.","- Дотримуватися рекомендацій CISA щодо безпеки ланцюга постачання та узгодити процеси оцінки ризиків постачальників з NIST SP 800-161r1 (C-SCRM).","- Вести план реагування на інциденти, який чітко охоплює компрометації стороннього програмного забезпечення."]

Нотатки щодо публікації: (1) Впровадьте схему структурованих даних FAQPage у розділі «Поширені запитання» та схему Article на всій сторінці, щоб максимізувати відповідність вимогам для функцій «Користувачі також Пропозиція» та розширених результатів. (2) Зовнішні цитування в цій статті посилаються на CISA, NIST, Mandiant, Kaspersky/Securelist, Wired, OpenSSF та Cisco Talos як на авторитетні джерела. (3) Внутрішні посилання на відповідний контент із кібербезпеки на цьому сайті (посібники щодо атак програм-вимагачів, пояснення архітектури нульової довіри, ресурси для впровадження SBOM, посібники з управління ризиками постачальників, огляди суб’єктів загроз APT) мають бути додані командою з публікації перед розгортанням. На момент написання індекс сайту не містив проіндексованих статей з кібербезпеки, тому розміщення внутрішніх посилань потребує ручної перевірки редакційною командою.