Це перший епізод із серії статей про найпоширеніший вид атак на ланцюги поставок програмного забезпечення: ті, що (зловживають) публічним реєстром програмних компонентів, призначених для проекти з відкритим кодом завантажувати артефакти, якими можна поділитися з іншими користувачами. Коли зловмисники публікують там шкідливе програмне забезпечення, використовуючи реєстр як засіб для поширення шкідливого програмного забезпечення, ми маємо атаку ланцюга поставок, коли організації-жертви встановлюють або запускають заражений компонент програмного забезпечення.
Для спрощення обговорення ми поговоримо про програмні пакети:, компоненти в упакованій формі, створені третіми сторонами. Це включає не лише компоненти, що використовуються менеджерами пакетів, такими як NPM або Poetry, але й компоненти операційної системи включаючи бібліотеки та виконувані бінарні файли, зображення контейнерів, та віртуальні машини, або розширення інструментів для інструментів розробки, збірки та розгортання. Ми бачили шкідливі пакети всюди. Кіберзлочинці не заперечують: вони в захваті від альтернатив, що надаються сучасними програмними інфраструктурами, і використовують реєстр та інструмент, який найкраще відповідає їхнім намірам. Тож пам’ятайте, що програмні пакети – це скорочення для образів контейнерів, бінарних пакетів, репозиторіїв з відкритим кодом та розширень або плагінів усіх видів (IDE, CI/CD системи, інструменти для збірки). Усі вони регулярно піддаються атакам.
Серіал матиме 5 епізодів:
- У чому проблема з пакетами з відкритим кодом? Це тема цієї публікації. Чому злочинці всіх мастей публікують шкідливі пакети? Чому мені варто хвилюватися?
- Анатомія шкідливих пакетів: які тенденції? У цьому епізоді ми зосереджуємося на загрозі, яку ми відстежуємо за допомогою нашої системи MEW день у день. Через великий фоновий шум, спричинений великою кількістю шкідливих пакетів, що використовують помилки типу або плутанину залежностей, менший відсоток атак є набагато підступнішим і становить більший ризик. Як змінилася поведінка зловмисників щодо ОС останнім часом? Які цифри? Які тактики, методи та процедури використовуються, а також які шкідливі дії спостерігаються?
- Захист від шкідливих пакетів з відкритим кодом: що (не) працюєБільшість фахівців, що обізнані з безпекою, мають уявлення про те, як боротися з цією загрозою. Ми чули, як менеджери з безпеки без вагань кажуть, що SCA Інструменти вже повідомляють вам, коли версія пакета є шкідливою. Або що вони залежать від добре відомих, ретельно перевірених програмних компонентів, де будь-яке шкідливе програмне забезпечення буде негайно виявлено та видалено. Вони що вони використовують відкриті мінорні/патч-версії для автоматичного отримання виправлень вразливостей, і це правильний, рекомендований спосіб знизити ризик для залежностей від відкритого коду, дотримуючись принципу «патчай рано, патчай часто». У цьому епізоді ми розглянемо, чому ці ідеї хибні, і як такі помилкові уявлення сприяють популярності цього механізму атаки та величезному ризику, з яким стикаються організації. Ми закінчимо тим, що працює, і які зусилля та ресурси для цього потрібні.
- Шкідливі пакети з відкритим кодом: підхід XygeniУ цьому епізоді ми представимо стратегію, якої ми дотримуємося в Xygeni для нашої системи раннього попередження про шкідливе програмне забезпечення (MEW). Як ця багатоетапна система працює в режимі реального часу, коли публікується нова версія пакета, як збираються докази з різних джерел, як проводиться сортування, яких критеріїв класифікації ми дотримуємося та чому все ж таки потрібен певний ручний аналіз для підтвердження природи кандидата на шкідливий пакет? Як зворотний зв'язок від наших внутрішніх команд та команд реєстру допомагає системі навчатися на основі зібраних раніше даних, щоб мінімізувати кількість хибнопозитивних результатів. Ми також пояснимо, як ми допомагаємо NPM, GitHub, PyPI та іншим ключовим інфраструктурам в екосистемах відкритого коду з відкритим кодом скорочувати час перебування..
- Використання відкритого коду: чого очікувати від поганих хлопцівСерія завершується, зосереджуючись на найновіших діях, які зловмисники вживають, щоб зробити атаки прихованішими, складнішими для виявлення, більш цілеспрямованими проти конкретних галузей та отримати більше вигоди від цього класу атак. Чи будуть атаки програм-вимагачів здійснюватися за допомогою цього засобу? Як зловмисники використовують інструменти штучного інтелекту для доставки складніших шкідливих пакетів? Чи знаходяться найпопулярніші проекти в небезпеці? Це дасть читачам уявлення про цю гонку озброєнь та про те, чого очікувати в короткостроковій (друга половина 2024 року) та середньостроковій (2025) перспективі. Ми дізнаємося, як такі атаки, як нещодавня... Бекдор XZ-Utilsабо напад на тих, хто живе за рахунок землі електрон-будівельник у березні 2024 року показують, що нам слід пильно стежити за розвитком подій у супротивників.
Давайте розпочнемо з першого епізоду: Що відбувається зі шкідливими пакетами з відкритим кодом?
У чому проблема з пакетами з відкритим кодом?
В останні роки правопорушники всіх видів використовували реєстри програмного забезпечення з відкритим вихідним кодом для поширення шкідливої поведінки. Ці дії такі ж старі, як і сам відкритий вихідний код, але їхня частота різко зросла за останні три роки.
Публікація шкідливих компонентів у публічних реєстрах (атаки на основі залежностей) – це асиметрична партизанська війна, яку зловмисники використовують для розповсюдження шкідливого програмного забезпечення, використовуючи довіру, яку організації надають компонентам з відкритим кодом від невідомих розробників (пам’ятайте про залежність коміксів xkcd?). Оскільки ви довіряєте пакетам і не проти вручну переглянути вміст пакета та його залежності, ці атаки надзвичайно ефективні. А асиметрія виникає тому, що їх можна значною мірою автоматизувати, і зловмисникам не потрібно безпосередньо взаємодіяти з жертвою. Вони просто завантажують пакет до публічного реєстру та відпускають його.
Шкідливі пакети зросли в 6 разів у 2022 році, і продовжувала зростати у 2.5 раза у 2023 році. Минулого року було виявлено колосальні 245 000 шкідливих пакетів, що більш ніж удвічі перевищує загальну кількість за попередні роки разом узяті. Це експоненціальне зростання! Від сотень видалень пакетів як підтвердженого шкідливого програмного забезпечення протягом 2021 року до тисяч протягом 2022 року ми спостерігали набагато більше фонового «шуму» протягом 2023 року, з подібними темпами цього року. І приховані на цьому тлі, спричиненому недосвідченими кіберзлочинцями, які йдуть «шляхом найменшого опору», незначна частина гучних атак потрапила на заголовки навіть у загальних ЗМІ.
Чому це проблема такого масштабу? Існує надлишок довіри по всьому ланцюжку. Програмне забезпечення з відкритим вихідним кодом розповсюджується разом із вихідним кодом і випускається за певною ліцензією. Так, кожен може перевірити вихідний код; але хто це робить загалом? Хто, перевіривши, що програмне забезпечення не містить шкідливого програмного забезпечення, збирає програмне забезпечення з вихідних кодів? Хто, перш ніж передати упакований компонент (також відомий як пакет) нижче за течією до менеджера пакетів або інструменту збірки, переконується, що пакет не заражений шкідливим програмним забезпеченням і відповідає передбачуваному вихідному коду, з якого він має походити?
Чому інфраструктура дозволяє такі легкі атаки?
Реєстри пакетів відкриті, часто вимагаючи мінімальної перевірки особи видавця. «Будь-хто може публікувати тут своє програмне забезпечення!» Планка для зловмисників встановлена низько: вони використовують одноразові адреси електронної пошти та одноразові облікові записи GitHubgithub для створення сотень шкідливих пакетів у коротких, схожих на фішингові, кампаніях. Тільки для цільових пакетів потрібна вища витонченість: ми навіть бачили створення надійного репозиторію вихідного коду GitHub з багатьма зірками та commitвід кількох фальшивих учасників та інші показники популярності та підтримки. Отримання спостерігачі за зірками та репутація від фальшивих внесків нескладно автоматизувати. Ми спостерігали зловживання в інфраструктурах відкритого програмного забезпечення всіх видів, не лише шкідливе програмне забезпечення, як-от інцидент з чайним протоколом.
Менеджери пакетів були розроблені для зручності використання, а не для безпеки.Вони можуть запускати скрипти до та після встановлення (іноді необхідна компіляція нативного коду для бібліотеки). Також, Менеджери пакетів встановлювати пакети з кількох джерел, а іноді за замовчуванням використовуються публічні реєстри. Вони не перевіряли невідповідність між метаданими в запиті на публікацію та метаданими в самому пакеті.
Залежності вкладені та утворюють граф. У певних екосистемах, таких як Node (JavaScript), дрібнозернисті залежності накопичуються сотнями або тисячами. Одне — мати суворий контроль над прямими залежностями, оголошеними моїми програмними проектами, але транзитивні залежності важче контролювати. Відкритий код дотримувався принципу «друзі моїх друзів — мої друзі». Братерство — це норма на дикому Далекому Сході! Зловмисники знають про це та глибоко приховують свою зловмисну поведінку в незрозумілих залежностях, які часто залишаються невідомими. Так було і з потік подій інцидент, спрямований проти Гаманець Copay.
Так працювало програмне забезпечення з відкритим кодом з моменту його створення. Це мало що змінить. Деякі реєстри пакетів вимагають у кращому випадку двофакторної автентифікації, і часто лише для найпопулярніших пакетів. Деякі реєстри надають області видимості, простір імен, що належить перевіреній організації, але трагічно інші не підтримують його (PyPI) або роблять його необов'язковим (NPM). Цікаво відзначити, що навіть проста схема скринінгу (на основі контролю DNS або репозиторію/організації GitHub, що відповідає ідентифікатору групи) та створення Обов'язкові підписи PGP для всіх артефактів, окрім контрольних сум, видаляє більшу частину «шуму», шкідливих пакетів, схожих на помилки в написанні тексту, та обмежує значну частину плутанина залежностейСкладні атаки можливі, але набагато складніші, і лише деякі з них подібні до com.github.codingandcoding:плагін-компілятора-maven відомий завдяки Maven Central. І не всі реєстри Maven дотримуються однакових практик!
Засоби контролю безпеки менеджерів пакетів можуть обтяжувати, але не перешкоджати атакам залежностей. Проблема багатофакторної автентифікації полягає в тому, що для автоматизації генеруються похідні облікові дані, такі як токени доступу або ключі APIapi, для облікових записів, які використовуються у викликах APIapi, здійснених зі скриптів автоматизації, без підтримки інтерактивного користувача, який би надавав другий фактор. Багатофакторна автентифікація добре підходить для захисту облікових записів користувачів від витоку паролів, але згенеровані токени доступу або ключі APIapi повинні бути захищені, поки вони активні, інакше зловмисники видадуть себе за їхнього власника. Значна частина кампаній ланцюга поставок на основі пакетів починається з витоку ключа/токена. Просто пам’ятайте про такі інциденти, як Гросбух, 3CX, та багато інших, де неінтерактивні облікові дані були вперше викрадені під час попереднього вторгнення для запуску атаки на ланцюг поставок.
Реакція на цю загрозу була недостатньо рішучою. У третьому епізоді ми зосередимося на тому, що спрацювало, а що зазнало жахливої невдачі. Галузь повинна працювати разом над standardпроцеси, навчання та інструменти для зменшення ризиків для глобальних ланцюгів поставок. Це проблема, яку одна організація не може вирішити самостійно.
На завершення цього розділу, ключове непорозуміння: ми говоримо про malicious пакети, а не уразливий Вразливості виникають через помилки проектування або кодування, випадково введені без поганого наміру. Ці вразливості можуть бути використані, але багато з них – ні. Шкідливі пакети завжди навмисні, і існує 100% можливість їх використання, якщо вони будуть виконані. Немає порівнянного ризику! Отже Парадоксально бачити, скільки зусиль докладається для виявлення та усунення вразливостей, а також відсутність еквівалентних заходів для шкідливих компонентів..
«Ми серйозно ставимося до безпеки»
Давайте уявимо собі звичне Корпорація AcmeAcme, головний постачальник програмного забезпечення для WileCoyote.com, має більшість програмного забезпечення від третіх сторін, понад 80% з яких – це проекти з відкритим кодом. Вони створюють програмне забезпечення для внутрішнього використання, але також надають програмне забезпечення своїм партнерам, постачальникам та клієнтам/кінцевим користувачам. Acme має програмне забезпечення, написане на Go, JavaScript, Java, C# та Python, і запускає більшу частину свого програмного забезпечення в хмарі, під кластерами Kuberneteskubernetes. Acme створює свої власні образи з базових образів, взятих з Docker Hub та інших реєстрів. Крім того, вони спільно використовують кілька бібліотек, пакетів та образів контейнерів у публічних реєстрах.
Acme серйозно ставиться до безпеки. Вони досить добре усвідомлюють проблему open source security, і ризик, який це несе. Усі розробники, системні менеджери та DevOps-інженери використовують ці милі маленькі крипто-ключі для другофакторної автентифікації. Усі commitпідписані репозиторії коду, увімкнено захист гілок з обов'язковими перевірками коду, CI/CD заблоковані, секрети зберігаються в секретному сховищі, а внутрішній реєстр частково відображає зовнішні реєстри, де зберігаються лише дозволені компоненти з білого списку. Програмне забезпечення, створене Acme, повинно брати сторонні залежності з цього реєстру.
Ймовірно, більшість організацій відповідають цьому профілю. Шановний читачу, ваша організація точно відповідає цьому профілю, якщо ви ще тут, чи не так?
Потім одного нещасливого дня, важливий фронтенд-розробник в Acme біг npm install acme-cute-lib, забуваючи, що @acme/cute-lib була правильною залежністю з визначеною областю дії. Точна помилка не важлива, багато чого може піти не так, навіть якщо повністю контролювати життєвий цикл програмного забезпечення. Наш розробник не знав, що APT-група націлена на Acme, і опублікував шкідливий компонент під цим ім'ям, хитрим чином, щоб шкідлива поведінка активувалася лише тоді, коли програмне забезпечення встановлено на комп'ютерах Acme. Пакет не виявлявся протягом тижнів після його публікації.
Запускається інсталяційний скрипт, який шукає облікові дані (у ноутбуці нашого розробника було багато цікавих токенів доступу), що дозволяє доступ до внутрішніх репозиторіїв програмного забезпечення та вищезгаданого внутрішнього репозиторію, доступ до якого, звичайно, можливий лише через VPN. Шкідливий код зумів використати існуюче VPN-з'єднання та опублікувати шкідливий компонент другого рівня у внутрішньому реєстрі, вплинувши на спільну бібліотеку утиліт, що використовується більшістю програмного забезпечення, що постачається Acme.
Через кілька тижнів інші організації, що використовували опубліковані інструменти Acme, почали бачити дивний трафік у своїх мережах, причому трафік використовував протокол Acme, але спрямовувався на хости, схожі на домен Acme. Трафік був зашифрований, але інструменти системного моніторингу виявляли доступ до неочікуваних файлів та виконання процесів, які виглядали як системні команди, але зрештою запускали завантажені виконувані файли.
Решта – це вже історія: Acme спочатку заперечувала, що така поведінка була їм приписана, і що всі заходи безпеки були вжиті. Лише після того, як ЗМІ з кібербезпеки почали запитувати, чому джерелом виявленої поведінки були компоненти Acme, а аналіз безпеки показав, наскільки ці компоненти були заражені прихованим шкідливим програмним забезпеченням, Acme довелося визнати інцидент і звернутися до фірми з реагування на інциденти. Негативна маркетингова кампанія, яка миттєво підірвала важко зароблену довіру.Acme знаходився за одну інсталяцію npm від disaster«…» – був поширений заголовок. Потім почалися судові позови та розірвані контракти.
Чи бачите ви схожість з відомими минулими інцидентами? Acme потрапила в інцидент з ланцюгом поставок у два етапи, використовуючи поєднання... плутанина з залежностями/друкарська помилка атаки, які використовували робочу станцію розробника як плацдарм для зараження компонентів, що потрапляли в програмне забезпечення, що використовується третіми сторонами. Як цьому можна запобігти або пом'якшити наслідки?
Чому отруєні пакети такі популярні
Цей гіпотетичний інцидент показує, що навіть за розумного підходу до безпеки відкритого коду, організаціям потрібні конкретні заходи, щоб уникнути зараження шкідливим програмним забезпеченням у компонентах з відкритим кодом. Схематично, зловмисник може:
- Створіть новий пакет (слідуючи відомим шляхам помилок у друкарстві або плутанини із залежностями, це найчастіше використовуваний зловмисниками шлях);
- Спробуйте заразити існуючий, або вставивши його у вихідний код, або намагаючись замаскувати його під контрибутора через pull requestабо використання соціальної інженерії, щоб стати розробником (як це зробив «Джао Тан» у випадку з бекдором XZ) праворуч9ctrl Користувач GitHub зробив це в потік подій інцидент восени 2018 року), або шляхом отримання облікових даних репозиторію з відкритим кодом та видавання себе за розробника;
- Впроваджувати шкідливе програмне забезпечення під час збірки пакета, або запускаючи шкідливий скрипт збірки, або втручання в завантаження пакетів за допомогою перехоплень типу «людина посередині» (на щастя, TLS зараз завжди потрібен у більшості реєстрів).
- Вставте упакований компонент безпосередньо в реєстр, зазвичай шляхом захоплення облікових даних реєстру (бажаний варіант для багатьох складних атак, таких як атака Acme, де скомпрометована робоча станція на першому етапі мала внутрішній токен доступу до реєстру, наприклад, у звичайному .env or ~/.m2/settings.xml: зловмисники знають, де шукати секрети). Також використовувалися вразливості в реєстрах.
Отруєння реєстрів шкідливим програмним забезпеченням є основою для атак залежностей. Нічого нового під сонцем: його поширеність різко зросла, але ті ж методи працюють зараз, що й п'ять років тому.
джерело: Колекція ножів Backstabber'а.
Шкідливий пакет може працювати під час встановлення, збірки програмного забезпечення або під час виконання. Його поведінка варіюється від вилучення інформації, наприклад, вилучення секретів для другої фази спроби, до вилучення вихідного коду та розміщення додаткового шкідливого програмного забезпечення. У наступному епізоді ми розглянемо шкідливі пакети та те, як вони публікуються.
Подальше читання
Наступний епізод Анатомія шкідливих пакетів: які тенденції? зосередимося на реальних випадках, які ми відстежуємо за допомогою нашої системи раннього попередження про шкідливі програми день у день. Ми розглянемо, які типи шкідливих програм були помічені, а також які тактики, методи та процедури є найпопулярнішими. Ми розглянемо обфускацію та те, як вона намагається приховати себе від потенційних перевіряльників, методи ухилення від виявлення та як вони розвиваються з телеметрією та горизонтальним рухом. Будь ласка, слідкуйте за оновленнями!
Посилання
- Колекція ножів Backstabber's Knife: Огляд атак на ланцюг поставок програмного забезпечення з відкритим кодомМ. Ом та ін., травень 2020 р.
- Захист від шкідливого програмного забезпечення з відкритим кодомБіла книга від Xygeni.
- Software Supply Chain Security Ретроспектива: Формування безпечнішого 2024 рокуЗвіт від Xygeni.
