Це третій епізод у серія статей про найпоширеніший вид атак на ланцюги постачання програмного забезпечення: ті, що зловживають публічним реєстром з відкритим вихідним кодом компоненти програмного забезпечення. Після аналізу в попередньому епізоді «Анатомія шкідливих пакетів: які тенденції?«як зловмисники впроваджують шкідливу поведінку в нові або існуючі опубліковані компоненти, ми готові одягнути наші пожежні жилети та дослідити, як ми можемо успішно блокувати шкідливе програмне забезпечення, що постачається таким чином, або ж, як варіант, впоратися з потенційно серйозним кіберінцидентом, оскільки ми обрали неправильний підхід».
Більшість фахівців з безпеки мають уявлення про те, як боротися з цією загрозою. Ми чули, як менеджери з безпеки без вагань кажуть, що SCA Інструменти вже повідомляють вам, коли версія пакета є шкідливою. Або що вони залежать від добре відомих, ретельно перевірених програмних компонентів, де будь-яке шкідливе програмне забезпечення буде негайно виявлено та видалено. Вони використовують відкриті мінорні/патч-версії для автоматичного отримання виправлень вразливостей, і це правильний, рекомендований спосіб знизити ризик для залежностей від відкритого коду, дотримуючись «латати рано, латати часто”Принцип.
У цьому епізоді ми розглянемо, чому ці ідеї хибні, і як такі помилкові уявлення сприяють популярності цього механізму атаки, а також величезному ризику, з яким стикаються організації. Закінчимо тим, що працює, і які зусилля та ресурси потрібні.
Поширені помилки
Під час нашої подорожі у сфері безпеки програмного забезпечення ми спостерігали за розвитком методів атак та широким спектром ідей від людей, які дбають про безпеку. Організації часто неправильно розуміють, що працює проти цієї загрози, тому спочатку ми розглянемо, що не працює, стисло викладено в наступному, не вичерпному, списку помилкових уявлень.
Помилка №1: SCA інструменти вже повідомляють про шкідливі компоненти
Дійсно! Але після того, як сталося… Коли, ймовірно, вже занадто пізно, якщо елемент був використаний у збірці програмного забезпечення, і зловмисники вже закріпилися в розробнику або CI/CD хост. Можливо, секрети було викрадено, завантажено та встановлено додаткове шкідливе програмне забезпечення, а можливо, зловмисник перемістився в інше місце та вже отримав доступ до нього в іншому місці.
Аналіз складу програмного забезпечення (SCA) інструменти були розроблені для виявлення потенційних відомих вразливостей. Сучасні інструменти чудово справляються зі своєю роботою, збільшуючи співвідношення сигнал/шум, визначаючи, чи є вразливість дійсно досяжною або придатною для використання. Але вони марні проти нового шкідливого програмного забезпечення. Уявіть собі шкідливий компонент як вразливість нульового дня: лише коли виявляється його шкідлива поведінка, про компонент повідомляється до реєстру, який після перевірки командою безпеки підтверджується як шкідливий та видаляється з реєстру. [1].
На той момент світ (включно SCAs) знає, що встановлення або використання компонента (або певної версії(й) існуючого компонента) не є гарною ідеєю. Але це коли компонент недоступний у реєстріЗнання про наявність у мене вразливостей у сторонніх компонентах або навіть компонентах, які реєстр класифікував як шкідливі, добре, але, на жаль... SCA або звичайні інструменти аудиту не допомагають у цьому контексті. Якщо не SCAІнструмент /audit дійсно може заздалегідь знати, що компонент є шкідливим, ще до того, як його використовуватимуть у вашій організації..
Пам’ятайте, що будь-яке рішення проти шкідливих компонентів з відкритим кодом має їх виявляти. на льоту, між публікацією компонента в реєстрі та першим використанням компонента (версії) у вашій організації. Це включає транзитивні компоненти.
Помилка №2: Контроль скриптів встановлення під час збірки запобігає шкідливій поведінці компонентів з відкритим кодом
Різні менеджери пакетів пропонують можливість запуску скриптів (включених до tar-архіву компонентів) [2]), з законних причин, таких як компіляція необхідних елементів на різних платформах, генерація коду або проведення тестів, і ми всі повинні знати, що ними можуть зловживати зловмисники, якщо шкідливі скрипти включені до tar-архіву, або якщо зловмисник може запустити шкідливий скрипт замість справного.
Знаючи це, ми можемо налаштувати менеджер пакетів так, щоб він ігнорував скрипти. Наприклад, за допомогою NPM –Ігнорувати сценарії прапорець (або властивість конфігурації в .npmrc файл) пропускає скрипти під час встановлення. Це може спричинити деякі проблеми, оскільки запуск скриптів є поширеним явищем у багатьох екосистемах: деякі менеджери пакетів навіть не дозволяють вимикати виконання скриптів (підказка: запит «Які менеджери пакетів не дозволяють вимикати виконання скриптів встановлення?«у вашому улюбленому ШІ). Але це не захищає загалом (нам потрібно забезпечити, щоб конфігурація вимкнення пропуску була скрізь).
А коли шкідлива поведінка знаходиться не в скриптах встановлення, а в програмному забезпеченні, яке виконується під час виконання, цей варіант сам по собі нас не захищає.
Помилка №3: Закріплення версій запобігає встановленню шкідливих компонентів
Існує компроміс між раннім та частим латанням відкриті версії (дозволяючи менеджеру пакетів автоматично встановлювати нові оновлення, коли вони доступні для виправлень безпеки) та версія закріплення (наявність усіх прямих та транзитивних залежностей для програмного забезпечення у фіксованій версії). Принципи безпеки є впертими та іноді суперечливими, як це трапляється з принципом «виправляй рано, виправляй часто» та «До оновлення не слід ставитися легковажно»Деякі менеджери пакетів виконують автоматичні оновлення з діапазонами серверів рекомендованим способом. Чудово, якщо ви також хочете отримувати шкідливі оновлення! Так, компоненти необхідно оновлювати, щоб отримувати виправлення безпеки, які якомога швидше закривають вразливості, але… ніколи не дозволяйте менеджеру пакетів робити це автоматично.
Помилка №4: Використання перевірених компонентів безпечне. Будь-яка шкідлива версія буде негайно знайдена, розкрита та видалена.
Чому компоненту довіряють? Можливо, тому що він дуже популярний, багато хто стежить за вразливостями, велика кількість учасників підтримки, а також численні основні розробники, які ретельно перевіряють усі... pull requestsРеальність зовсім інша. Деякі важливі компоненти підтримуються одним неоплачуваним розробником. Широко використовувані фреймворки мають кілька постійних учасників, зі швидко зменшуваною кількістю commitна одного розробника (популярні проекти мають довгий хвіст учасників, які виконують деякі аварійні заходи commit і ніколи не повертаються). І популярних проектів з одним розробником предостатньо.
Уявіть, що ви кажете «О, ми використовуємо образи Spring Boot / Angular / React / PyTorch / офіційні базові Docker, тому ризик, про який ви говорите, досить низький». Можливо, це правда, адже ми, постачальники рішень безпеки, постійно залякуємо, а втручання в команди розробників для зменшення спірного ризику — це нісенітниця. У вас може виникнути спокуса перейти до абзацу про прийняття ризику (у наступному розділі) і все. На жаль, найпопулярніші компоненти є мішенями для зловмисників, і, наприклад, популярні Бібліотеку PyTorch атакували в минулому.
«Негайно виявлено, розкрито та видалено». Видалення нового шкідливого компонента з публічного реєстру займає кілька днів. Реєстри обережно ставляться до видалення версії компонента, і це добре. Наш досвід показує, що після повідомлення з нашого боку середній час, необхідний реєстру для видалення ураженої версії, становить 39 годин, що перевищує півтора дня. Є шкідливі компоненти, які з'являються в реєстрі через тиждень після нашого початкового повідомлення про інцидент, перш ніж їх видалити. А в деяких випадках компонент видаляється лише після того, як жертва або компанія з реагування на інциденти повідомляє про інцидент, пов'язаний з цим компонентом.
Що НЕ працює проти шкідливих компонентів
Будь-який неконкретний підхід зазнає жалюгідної невдачі. Це точно, ви не забезпечуєте ефективних контрзаходів для ризику, пов'язаного з цією загрозою.
Традиційний SCA Інструменти повідомляють про відоме шкідливе програмне забезпечення, але мають широке вікно впливу. Якщо вони не виконують проактивне виявлення шкідливого програмного забезпечення з примусовим блокуванням шкідливих компонентів, вони не працюють проти цієї загрози.
Вимкнення скриптів встановлення може допомогти, але це потрібно застосовувати скрізь, де потрібно встановити компонент. Те саме стосується закріплення версій, оскільки версії не можна закріплювати з безпечного початкового стану назавжди.
Припускати, що популярні компоненти отримують достатньо уваги, щоб їм не можна було впровадити ненавмисну поведінку під час атаки на ланцюг поставок без майже миттєвого виявлення для запобігання будь-якій шкоді, наївно та ризиковано. Ви ж не хочете жити на межі, чи не так?
Якщо ви зупинитеся на цьому етапі, то прийняття ризику єдине, що ви можете зробити: Це деcisіона, яку необхідно задокументувати у вашій моделі загроз/оцінці ризиків, включаючи обґрунтування прийняття ризику та його потенційних наслідків. Підвищте обізнаність, повідомивши про це керівництво та інші відповідні сторони. Деякі надзвичайний стан можна було б спланувати, коли шкідливий компонент встановлено або включено до вашого програмного забезпечення, але це складно, оскільки зловмисники мають багато шляхів, якими можуть піти. Деталі атаки на ланцюг поставок, заснованої на використанні шкідливого компонента, кардинально змінять публічне розкриття інформації про інцидент, що, ймовірно, є обов'язковим згідно з нормативно-правовою базою вашої організації. Ви також можете звернутися до компенсуючі елементи керування or ризик передачі наприклад, зі страховкою.
Однак існують засоби контролю, які враховують цю загрозу, і їх слід враховувати, якщо ви не задоволені прийняттям ризику. Будь ласка, читайте далі.
Що працює проти атак, що використовують шкідливі компоненти
Обробка твердотільної версії
Закріплення версій за допомогою контрольованих та обґрунтованих поліпшень версій – це правильний шлях, щоб збалансувати необхідність усунення вразливостей без отримання шкідливого програмного забезпечення. Але пам’ятайте про помилкову думку №3: самого лише закріплення версій недостатньо для блокування шкідливого коду, що надходить з нових версій, оскільки в майбутньому вам потрібно буде оновлювати версії, що безпосередньо чи непрямо залежать від них. У цей момент вам потрібні достатньо вагомі докази того, що всі модифіковані версії не містять шкідливого програмного забезпечення.
Раннє попередження
Один із підходів до проблеми шкідливих компонентів – це система раннього попередження (тут названа Раннє попередження про шкідливе програмне забезпечення або MEW), де нові опубліковані версії (для нових або існуючих компонентів) аналізуються механізмом виявлення, який, якщо знайдено достатньо доказів, може класифікувати нову версію як потенційно шкідливу.
Автоматизація тут є важливою, оскільки неможливо вручну перевірити всі нові компоненти за поточної швидкості публікації. Тому механізм виявлення повинен поєднувати різноманітні методи, можливо, включаючи статичний, динамічний аналіз та аналіз можливостей, репутацію користувачів, а також докази, отримані внаслідок розбіжностей між метаданими компонента та вмістом tar-архіву, або між tar-архівом та вихідним репозиторієм, звідки нібито походить компонент.
Існує темна зона між часом публікації та часом, коли рушій аналізує вміст компонентів, але він не повинен перевищувати кількох хвилин. Схему можна змінити, наприклад, зачекати на аналіз нових компонентів, перш ніж дозволити їх встановлення та використання у збірці програмного забезпечення. pipelineабо аналізувати їх на вимогу, коли це необхідно. Компонент у певній версії є незмінним [3], тому його потрібно проаналізувати лише один раз.
Повна автоматизація неможлива, і необхідна перевірка безпеки на наявність потенційно шкідливих компонентів. Остерігайтеся прихильників цифрової панацеїШтучний інтелект та машинне навчання недостатньо розвинені, щоб взяти останнє слово, коли справа доходить до підтвердження наявності шкідливого програмного забезпечення в підозрілому компоненті. Звичайно, машинне навчання відіграє ключову роль у механізмі виявлення, класифікуючи вхідний компонент на основі отриманих необроблених доказів, але після того, як компонент «поміщено на карантин», останнє слово залишається за ручною перевіркою командою безпеки, яка має досвід роботи зі шкідливими компонентами. Це підтверджує наявність потенційного шкідливого програмного забезпечення або перекласифікує його як безпечне. А період часу становить кілька годин.
Реєстр повідомляє про шкідливу версію/компонент; потім реєстр проводить перевірку для підтвердження та переходить до публічного розкриття інформації та видалення з реєстру. Деякі реєстри зберігають пакет безпеки. Часовий діапазон тут – це дні або тижні з моменту публікації, тобто «час затримки"або"вікно експозиції' для більшості шкідливих компонентів.
Чи можна дізнатися, чи є версія компонента шкідливою?
Отже, для раннього попередження нам потрібно дати задовільну відповідь на це питання: як я можу дізнатися, що бібліотека або пакет (не) є шкідливим? Як зібрати достатньо доказів шкідливої поведінки? Можливо, але складно, оскільки зловмисники використовують багато винахідливості, щоб уникнути виявлення. Існують різні підходи, кожен з яких має свої переваги та недоліки.
Статичний аналіз може перевірити всі шляхи виконання, перевірити наявність методів, що використовуються зловмисниками, без запуску компонента, та виконати завдання попередньої обробки, такі як деобфускація або розшифровка. Оскільки зловмисники намагаються приховати свої злодіяння, спроби обфускації справді є доказом наявності шкідливого програмного забезпечення (але зауважте, що легітимні компоненти обфускують код для збереження інтелектуальної власності, що суперечить «з відкритим вихідним кодом«). Лише незначна частина складних атак із сильним обфускацією потребує «пісочниці», але така сильна обфускація є яскравою ознакою зловмисності. Зверніть увагу, що звичайні SAST Інструменти були розроблені для ненавмисних вразливостей, а не для зловмисних намірів, як бекдори.
Динамічний аналіз запускає компонент та аналізує відповідь, інструментуючи середовище виконання, зазвичай надаючи ізольоване середовище. Шкідлива поведінка, що спрацьовує за певних умов, може залишитися непоміченою: зверніть увагу, що шкідливе програмне забезпечення може використовувати методи ухилення, такі як Віртуалізація/уникнення пісочниці активуватися лише тоді, коли не перебуває під пильною увагою, а також є ознакою шкідливої активності для будь-якого механізму статичного аналізу.
Аналіз можливостей враховує, що робить компонент: де він підключається, до яких файлів він отримує доступ, які команди або програми запускаються, виконується ввід/вивід терміналу або пристрою, або які системні виклики викликаються. Таке відбитки пальців поведінки можна порівнювати (для існуючого компонента) між версіями, тому, коли виявляється неочікувана поведінка, ці докази можуть викликати підозру щодо потенційної шкідливої активності, впровадженої в нову версію. Цей підхід відповідає крокам сортування, яких дотримуються аналітики безпеки, стикаючись із потенційним шкідливим програмним забезпеченням: перевірка за допомогою струни або аналогічні інструменти. Цей підхід виявляє шкідливу поведінку незалежно від умов запуску та працює, коли вихідний код недоступний.
Аналіз контексту збирає інформацію про те, як і ким було опубліковано компонент. Кампанії зловмисників часто використовують новий(і) обліковий запис(и) користувача(ів), який(і) не проходить(ють) жодної суворої перевірки. Відстеження минулої активності може дати уявлення про користувача, здебільшого про аномалії, які можуть натякати на потенційну компрометацію. Репутацію так важко заробити і так легко втратити! Користувач без минулої активності є нейтральним, але карма переслідує зловмисників. Хактивістів, або звичайних користувачів, у яких викрали облікові дані для публікації, слід ретельно відстежувати.
Ще однією контекстною інформацією є будь-яка розбіжність між вихідним репозиторієм, який нібито використовувався для створення tar-архіву компонента, та його вмістом. А також дотримання належних практик, таких як створення тегів або релізів у вихідному репозиторії, що відповідають версіям компонента, опублікованим у публічному реєстрі. Коли вихідний репозиторій у певному commit позначено тегом release, а потім раптово одна версія не відповідає йому, це вже саме по собі є вагомим доказом того, що компонент може бути заражений: зловмисник міг скомпрометувати обліковий запис, який використовувався для публікації компонента, але не має прав на запис у репозиторії вихідного коду). Багато атак регулярно виявляються за допомогою цих правил: наприклад, Атака на Ledger можна легко виявити за цими ознаками. Таким чином, контекстний аналіз виявляє такі аномалії в процесі публікації.
Брандмауер залежностей
Інший підхід полягає у створенні повного білого списку компонентів для всіх графів залежностей, що використовуються у вашому програмному забезпеченні, тому в будь-якій збірці pipeline у вашій організації можна встановлювати та використовувати лише затверджені версії компонентів.брандмауер«застосовується за допомогою внутрішнього реєстру, де зберігаються архіви дозволених версій компонентів (кешовані або проксі-архівовані). Зверніть увагу, що будь-який білий список не працюватиме, якщо у вас немає технології для класифікації будь-якої нової версії як достатньо безпечної, щоб її можна було додати до білого списку.
Зверніть увагу, що раннє попередження (швидке виявлення якомога швидше після публікації нової версії) має бути поєднане з певним способом використання цієї інформації проактивно для блокування компонента, який впливає на збірку. pipelineабо машини розробників [4]Ми називаємо це «брандмауер залежностей«: механізм карантину для захисту автоматизованих збірок від шкідливих пакетів. Внутрішні пакети та реєстри образів добре підходять для захисту організацій від зовнішнього зла, але для ефективності карантину необхідні достатньо вагомі докази.
Пісочниця виконання
Альтернативний підхід до виявлення під час публікації полягає в аналізі поведінки під час виконання. Ідея полягає в тому, щоб фіксувати очікувану поведінку програмного забезпечення та виявляти (або блокувати) будь-які виявлені аномалії. Цей напрямок дій пов'язаний з проблемою необхідності інструментування середовища виконання для моніторингу або блокування, і це перспективна ідея, яка буде додана до арсеналу механізмів захисту від шкідливого компонента-шкідника.
Розробка комплексної стратегії
Рекомендована стратегія повинна поєднувати різні методи в процесі розробки програмного забезпечення, контролюючи оновлення версій для блокування вхідних шкідливих компонентів. Ми повинні забезпечити функцію фіксації версій, щоб уникнути автоматичного зараження під час оновлення версій для отримання виправлень для важливих вразливостей; швидку та ефективну оцінку прямих та непрямих залежностей під час оновлень версій, щоб мати достатньо доказів того, що вони не заражені шкідливим програмним забезпеченням. Збірки програмного забезпечення, що залежать від відомих шкідливих компонентів, повинні бути заблоковані. І всі вони повинні бути забезпечені дотриманням правил.
Використовуйте закріплення версій, коли це можливо, оскільки це робить збірки більш відтворюваними. Закріплення версій з контрольованими, вручну затвердженими посиленими версіями та за допомогою допоміжних технологій, слід оцінити, чи оновлення містить шкідливе програмне забезпечення, чи порушує його роботу, та узгодити оновлення для виправлення вразливостей із запобіганням зараженню шкідливим програмним забезпеченням. Інструменти можуть допомогти тут, (1) визначаючи пріоритети тих вразливостей, які дійсно важливі (досяжні та експлуатовані, з високим ризиком стати ціллю атаки зловмисників), (2) вибираючи цільові версії, сумісні з поточним використанням компонентів і не порушують роботу програмного забезпечення, (3) вибираючи цільові версії, які не містять шкідливої поведінки, та (4) роблячи оновлення версій для прямих та непрямих залежностей швидким, пропонуючи зміни у файлах маніфесту, які можна швидко схвалити. На кроці (3) потрібна конкретна інформація про шкідливі компоненти якомога ближче до часу їх публікації.
Цей процес оновлення залежностей має бути примусово та перевірено у всіх місцях. Процес має бути задокументований, а всі залучені сторони повинні пройти навчання, оскільки часто розробка та збірка/розгортання програмного забезпечення виконується зовнішніми виконавцями. CI/CD pipelines слід відповідно змінити, щоб автоматизація не дозволила шкідливій непрямій залежності проникнути в збірку: guardrails Рекомендованим способом є блокування збірки, якщо є достатньо доказів потенційного шкідливого програмного забезпечення в залежності.
Якщо у вашій організації є внутрішній реєстр, який діє як проксі-сервер безпеки для зберігання дозволених версій компонентів, ви повинні отримати інформацію про шкідливі компоненти (окрім інших критеріїв) для перевірки запитуваного компонента, перш ніж додавати його до списку дозволів.
Використання програмного забезпечення з відкритим кодом з урахуванням безпеки є непростим, і фактор шкідливого програмного забезпечення необхідно повністю враховувати, докладаючи аналогічних зусиль до обробки вразливостей.
Останнє примітка: Походження джерела, у формі атестацій програмного забезпечення, що генеруються під час збірки компонента, є ще одним ключовим елементом у зусиллях щодо відстеження артефакту (tar-архіву компонента) з вихідними кодами та процесом збірки, в якому він був створений. Зауважте, що цей зв'язок між знімком джерела + середовищем збірки та пов'язаним з ним артефактом програмного забезпечення (підписаним довіреною системою збірки) сам по собі не запобігає тому, щоб компонент не містив шкідливої поведінки, але ускладнює для зловмисників впровадження шкідливого програмного забезпечення. А перетворення перевірки походження на загальну вимогу для використання компонентів з відкритим вихідним кодом займе багато часу, і лише нещодавно додано до NPMЗахист цих надійних систем збірки та розгортання від несанкціонованого доступу або забезпечення можливості виявлення будь-якого втручання у збірку – це окрема історія, яка виходить за рамки цієї публікації.
Подальше читання
Наступний епізод Шкідливі пакети з відкритим кодом: підхід Xygeni представить стратегію, якої ми дотримуємося в Xygeni для нашого Раннє попередження про шкідливе програмне забезпечення (MEW) система. Нові версії пакетів у публічних реєстрах пакетів та образів скануються, а докази отримуються за допомогою комбінації статичного, динамічного, можливостей та контекстного аналізу. Докази, у поєднанні з репутацією користувача та історією змін у репозиторіях вихідного коду, дозволяють повністю автоматизовано класифікувати компонент на категорії високого ризику та ймовірно шкідливих. Система навчається на основі попередніх доказів, зібраних з пакетів, щоб звести до мінімуму хибнопозитивні результати.
Організації-підписники отримують попередження про компоненти, які вони використовують прямо чи опосередковано, коли шкідливу версію класифікують. Потім наші аналітики проводять ручний аналіз, який підтверджує або відхиляє класифікацію. У разі підтвердженого шкідливого програмного забезпечення публічний реєстр отримує сповіщення, щоб він міг виконати власний аналіз і зазвичай видалити шкідливу версію або вжити додаткових заходів, таких як блокування або видалення відповідного облікового запису користувача.
Ми пояснимо, як ми допомагаємо NPM, PyPI, GitHub та іншим ключовим інфраструктурам в екосистемі відкритого коду скорочувати час, протягом якого новий опублікований шкідливий компонент залишається активним, доки його не буде підтверджено як шкідливе програмне забезпечення та видалено з реєстру. А також як організації можуть скористатися системою MEW, щоб отримати набагато кращий захист від атак ланцюга поставок програмного забезпечення, що включають компоненти з відкритим кодом.
- [1] У будь-якому разі, користувачам компонента потрібно перевірити, чи архів компонента кешовано або зареєстровано десь, наприклад, у внутрішньому реєстрі, щоб викорінити цю проблему.
- [2] Упакований компонент містить маніфест, який оголошує його вміст і метадані, вихідний або скомпільований код, скрипти встановлення та додаткові елементи, такі як набори тестів, відповідно до формату упаковки та зазвичай у стиснутому вигляді. Це називається «tar-архівом компонента».
- [3] Навіть якщо зловмисник може змінити опублікований компонент через порушення в самому реєстрі, звичайний криптографічний дайджест може виявити будь-які зміни в тар-архіві після завершення аналізу.
- [4] Пам’ятайте, що деякі шкідливі компоненти запускаються під час встановлення, тому це може вплинути на вузли розробників, які мимоволі запускають «npm install X» з X як шкідливим компонентом.
