У міру просування розробки програмного забезпечення вздовж життєвого циклу ланцюжка постачання, етап створення пакета стає ключовим моментом, перетворюючи вихідний код на виконувані артефакти, підготовлені до розповсюдження. Однак цей критичний етап не застрахований від вразливостей, що робить його головною мішенню для зловмисників, які прагнуть підірвати цілісність та безпеку програмного забезпечення. У цій публікації блогу заглиблюються в поширені загрози, які можуть виникнути на цьому етапі, та окреслюються ефективні стратегії для їх пом'якшення. Цей контент є продовженням нашої серії блогів, присвячених дослідженню... software supply chain security через SDLC.
Етап пакета в життєвому циклі розробки програмного забезпечення
Етап пакетування життєвого циклу постачання програмного забезпечення охоплює процес пакування та підготовки програмного забезпечення до розповсюдження користувачам. Цей етап включає створення інсталяційних пакетів, керування залежностями та генерацію метаданих для програмного забезпечення.
Загрози цілісності збірки – це вразливості, які можуть дозволити зловмисникам вносити несанкціоновані зміни до програмного забезпечення під час процесу пакування. Ці загрози можуть бути впроваджені різними методами, такими як компрометація реєстру пакетів, використання вразливостей в інструментах пакування або маніпулювання залежностями сторонніх розробників.
Повна залежність від компонентів з відкритим кодом у сучасному програмному забезпеченні зробила цей етап найчастішим S-процесом.SCA ціль. Впровадження прихованого шкідливого програмного забезпечення в популярний компонент з відкритим кодом є мрією багатьох кіберзлочинців. Ось чому понад Протягом 2023 року було виявлено 245 000 шкідливих пакетів.
Приклади Software Supply Chain Security Загрози на етапі пакету
Використовувати скомпрометований пакет
Це стосується розгортання або використання програмного пакета, який був підроблений або модифікований зловмисником.
Це може статися після того, як пакет покинув офіційний реєстр пакетів, або через прямий доступ до системи користувача, або за допомогою тактик соціальної інженерії, які обманом змушують користувача завантажити або встановити шкідливий пакет. Прикладом цього вектора був Перегляньте друкарський сквот Атака.
Зловмисник, прагнучи скомпрометувати системи Linux та Mac, проник у процес розробки популярної бібліотеки Node.js під назвою Browserify. Зловмисник вставив шкідливий код у вихідний код проекту, маючи намір поширити його через реєстр пакетів NPM. Після завантаження зараженого пакета Browserify до NPM нічого не підозрюючі розробники завантажували та встановлювали його, вважаючи його легітимною версією. Шкідливий код, вбудований у пакет, працював непомітно, порушуючи цілісність заражених ним систем. Це могло призвести до крадіжки даних, нестабільності системи або навіть віддаленого доступу для зловмисника.
Реєстр компрометованих пакетів
Скомпрометований реєстр пакетів — це сховище програмного забезпечення, в яке проник зловмисник, який отримав несанкціонований доступ до адміністративного інтерфейсу або інфраструктури реєстру.
Це дозволяє зловмиснику змінювати або замінювати легітимні програмні пакети шкідливими, які потім можуть поширюватися серед користувачів, які нічого не підозрюють про їх встановлення. Прикладом такого типу загрози був Атака на дзеркала пакетів: Дослідник, з наміром просувати програмне забезпечення з відкритим кодом, скомпрометував кілька популярних реєстрів пакетів, включаючи Maven Central, NPM та RubyGems. Отримавши доступ до цих реєстрів, дослідник зміг створити дзеркала та репліки оригінальних репозиторіїв, що забезпечило розробникам зручну альтернативу для завантаження пакетів.
Однак ці дзеркала мали зловісну мету. Зламані дзеркала служили дослідникам каналами для розповсюдження шкідливих пакетів. Ці пакети замінювали легітимні, залишаючись непоміченими основними реєстрами, а нічого не підозрюючі розробники несвідомо завантажували та встановлювали їх. Після встановлення ці шкідливі пакети випускали на волю своє корисне навантаження, виконуючи довільний код, крадучи конфіденційні дані або порушуючи роботу.
Завантажити змінений пакет
Зловмисник завантажує модифікований пакет до репозиторію або каналу розповсюдження, який містить шкідливий код або корисні навантаження. Це можна зробити, змінивши вихідний код пакета, упаковку або метадані.
Однією з найвідоміших загроз цього типу була Атака CodeCov у 2021 році. Зловмисник, який прагне скомпрометувати програмні проекти за допомогою CodeCov, популярної технології безперервної інтеграції та безперервної доставки (CI/CD) інструмент використовував витік облікових даних для отримання несанкціонованого доступу до корзини Google Cloud Storage (GCS) проекту. Отримавши доступ до корзини GCS, зловмисник завантажував шкідливий артефакт – модифіковану версію пакета CodeCov, яка потім розповсюджувалася серед користувачів через сервіс CodeCov. Нічого не підозрюючі розробники, покладаючись на функцію автоматичних оновлень, завантажували та встановлювали шкідливий пакет, вважаючи його легітимним. Після встановлення шкідливий код працював непомітно, порушуючи цілісність заражених ним систем. Це могло призвести до крадіжки даних, нестабільності системи або навіть віддаленого доступу для зловмисника.
Атаки на реєстри пакетів настільки поширені, що деякі шаблони атак отримали назву:
In ТипоскватінгЗловмисник завантажує до реєстру кілька шкідливих пакетів з незначними друкарськими помилками або назвами, схожими на легітимні, популярні, сподіваючись, що розробники неправильно напишуть задуману назву пакета, використовуючи шкідливу. Часто шкідливий пакет маскується під легітимний, щоб залишитися непоміченим, збільшуючи ймовірність потрапляння під атаку Stargazing.
Плутанина із залежностями використовує спосіб, яким деякі менеджери пакетів обробляють запитувані пакети з кількох реєстрів. Коли організація використовує внутрішні компоненти, опубліковані у внутрішньому реєстрі, зловмисник, який знає про це, може опублікувати шкідливий компонент з таким самим ім'ям у публічному реєстрі. Якщо ім'я, що використовується для внутрішнього компонента, не обмежене областю видимості, деякі менеджери пакетів отримають шкідливий компонент замість внутрішнього.
З Пакети Трояна, кіберзлочинець маскує шкідливе програмне забезпечення під корисним дійсним кодом. Це може бути використано справжнім автором або учасником, який пропонує себе для підтримки пакета. Це також відомо як Викрадення пакетаЗловмисники використовували багато методів для захоплення існуючого пакета, таких як Захоплення домену коли зловмисник захопив покинутий домен, термін дії якого минув, повторно створив стару електронну адресу адміністратора та виконав відновлення пароля, щоб отримати доступ до облікового запису адміністратора.
Остаточні зауваження
Оскільки організації все частіше впроваджують методології розробки програмного забезпечення, що надають пріоритет автоматизації та безперервній розробці, важливість захисту етапу розробки програмного пакета ще ніколи не була такою першочерговою. Впроваджуючи надійні заходи безпеки протягом цього критичного етапу, організації можуть суттєво знизити ризик потрапляння під дію зловмисних атак, які можуть поставити під загрозу цілісність та безпеку їхнього програмного забезпечення.
Стратегії, описані в цій публікації блогу, разом із наведеними прикладами слугують чітким нагадуванням про те, що етап розробки пакета є вразливою точкою в ланцюжку постачання програмного забезпечення. Організації повинні враховувати ці загрози та впроваджувати необхідні заходи безпеки для захисту свого програмного забезпечення від атак. Роблячи це, вони можуть гарантувати цілісність, безпеку та надійність свого програмного забезпечення для своїх користувачів і клієнтів.
Приєднуйтесь до нашої подорожі до безпечної екосистеми програмного забезпечення
Не пропустіть шанс бути на крок попереду у сфері software supply chain securityПідпишіться на наш блог сьогодні та будьте серед перших, хто отримає наші останні аналітичні дані, забезпечуючи стійкість та безпеку вашої організації попри загрози, що постійно змінюються. Разом ми можемо створити більш надійну та безпечну екосистему програмного забезпечення для всіх.
Пам'ятайте, software supply chain security – це безперервна подорож, а не пункт призначення. Постійно оцінюючи та адаптуючи методи безпеки для реагування на нові загрози, організації можуть захистити свій ланцюжок постачання програмного забезпечення та надавати своїм користувачам надійне програмне забезпечення.
Перегляньте наше відео-демо
