Това е третият епизод от серия от статии относно най-разпространения вид атаки срещу веригата за доставки на софтуер: тези, които злоупотребяват с публичен регистър на с отворен код софтуерни компоненти. След анализ в предишния епизод „Анатомия на злонамерените пакети: Какви са тенденциите?„как злонамерените участници внедряват злонамерено поведение в нови или съществуващи публикувани компоненти, ние сме готови да облечем пожарните си жилетки и да проучим как можем успешно да блокираме злонамерен софтуер, доставян по този начин, или алтернативно, да се справим с потенциално сериозен киберинцидент, защото сме предприели грешен подход.“
Повечето професионалисти, запознати със сигурността, имат идеи как да се справят с тази заплаха. Чували сме мениджъри по сигурността да казват без колебание, че SCA Инструментите вече ви казват кога дадена версия на пакета е злонамерен софтуер. Или че зависят от добре познати, високо оценени софтуерни компоненти, където всеки злонамерен софтуер би бил незабавно открит и премахнат. Те използват отворени второстепенни/корекции за автоматично получаване на корекции на уязвимости и това е правилният, препоръчителен начин за намаляване на риска от зависимости с отворен код, следвайки „кръпка рано, кръпка често”Принцип.
В този епизод ще разгледаме защо тези идеи са погрешни и как подобни погрешни схващания допринасят за популярността на този механизъм за атака и за огромния риск, пред който са изправени организациите. Ще завършим с това, което работи и какви са необходимите усилия и ресурси.
Често срещани заблуди
По време на нашето пътешествие със софтуерната сигурност, видяхме как се развиват техниките за атака и широк спектър от идеи от хора, загрижени за сигурността. Организациите често не разбират какво работи срещу тази заплаха, така че първо ще разгледаме какво не работи, обобщено в следния, неизчерпателен, списък с погрешни схващания.
Погрешно схващане №1: SCA инструментите вече докладват за злонамерени компоненти
Наистина! Но след факта... Когато вероятно е твърде късно, ако елементът е бил използван в софтуерна компилация и злонамерените лица вече са се установили в лицето на разработчик или CI/CD хост. Тайните може да са били откраднати, допълнителен зловреден софтуер да е бил изтеглен и инсталиран, а може би противникът се е преместил странично и вече е получил достъп другаде.
Анализ на състава на софтуера (SCA) инструментите са проектирани да идентифицират потенциални известни уязвимости. Съвременните инструменти вършат чудесна работа, като увеличават съотношението сигнал-шум, определяйки дали уязвимостта е действително достижима или експлоатируема. Но те са безполезни срещу нов зловреден софтуер. Мислете за злонамерен компонент като за уязвимост от нулев ден: Само когато бъде открито злонамереното му поведение, компонентът се докладва в регистъра, който след преглед от екип по сигурността се потвърждава като злонамерен и се премахва от регистъра. [1].
В този момент светът (включително SCAs) знае, че инсталирането или използването на компонента (или някоя версия(и) на съществуващ компонент) не е добро нещо. Но това е когато компонентът не е наличен от системния регистърДа знам, че имам уязвимости в компоненти на трети страни или дори компоненти, които са били категоризирани като злонамерени от системния регистър, е добре, но за съжаление... SCA или общите инструменти за одит не помагат в този контекст. Освен ако не SCAИнструментът /audit наистина може да знае предварително, че даден компонент е злонамерен, преди да бъде използван във вашата организация..
Не забравяйте, че всяко решение срещу злонамерени компоненти с отворен код трябва да ги открива в движение, между момента, в който компонентът е публикуван в регистъра, и момента, в който компонентът (версията) е използван за първи път във вашата организация. Това включва и транзитивни компоненти.
Погрешно схващане №2: Контролирането на инсталационните скриптове по време на компилация предотвратява злонамерено поведение от компоненти с отворен код
Различни мениджъри на пакети предлагат възможност за изпълнение на скриптове (включени в tarball-а на компонентите) [2]), по основателни причини, като например компилиране на необходими елементи на различни платформи, генериране на код или изпълнение на тестове, и всички ние трябва да знаем, че те могат да бъдат злоупотребени от злонамерени лица, ако в tarball-а са включени злонамерени скриптове или ако атакуващият може да изпълни злонамерен скрипт вместо правилния.
Знаейки това, можем да конфигурираме мениджъра на пакети да игнорира скриптове. Например, с NPM –Игнориране на скриптове флаг (или свойство за конфигурация в .npmrc файл) пропуска скриптовете по време на инсталирането. Това може да доведе до някои проблеми, тъй като изпълнението на скриптове е често срещано в много екосистеми: Някои мениджъри на пакети дори не позволяват деактивирането на изпълнението на скриптове (подсказка: prompt „Кои мениджъри на пакети не позволяват деактивиране на изпълнението на инсталационни скриптове?„в любимия ви изкуствен интелект). Но това не защитава като цяло (трябва да наложим конфигурацията за деактивиране на пропускането да е навсякъде).
И когато злонамереното поведение не се намира в инсталационните скриптове, а в софтуера, който се изпълнява по време на изпълнение, само тази опция не ни защитава.
Погрешно схващане №3: Закрепването на версиите предотвратява инсталирането на злонамерени компоненти
Има компромис между ранното поставяне на кръпки и честото им поставяне. отворени версии (позволявайки на мениджъра на пакети автоматично да инсталира нови актуализации, когато са налични за корекции на сигурността) и версия за закрепване (с всички директни и транзитивни зависимости за софтуер във фиксирана версия). Принципите за сигурност са упорити и понякога противоречиви, както се случва с „кърпи рано, кърпи често“ и „Надграждането не бива да се приема лекомислено“Някои мениджъри на пакети правят автоматични актуализации със сървърни диапазони по препоръчителния начин. Чудесно, ако искате да получавате и злонамерени актуализации! Да, компонентите трябва да бъдат актуализирани, за да получават корекции за сигурност, които затварят уязвимостите възможно най-скоро, но... никога не позволявайте на мениджъра на пакети да прави това автоматично.
Погрешно схващане №4: Използването на надеждни компоненти е безопасно. Всяка злонамерена версия ще бъде незабавно открита, разкрита и премахната.
Защо един компонент е надежден? Вероятно защото е много популярен, с много хора, които търсят уязвимости, голям брой сътрудници по поддръжката, с множество основни администратори, които старателно преглеждат всички... pull requestsРеалността е съвсем различна. Някои основни компоненти се поддържат от един-единствен, неплатен разработчик. Широко използваните рамки имат няколко редовни сътрудници, с бързо намаляващ брой commits на поддържащ (популярните проекти имат дълга опашка от сътрудници, които извършват някои drive-by commit и никога да не се върнат). И изобилстват популярни проекти с един-единствен поддържащ.
Представете си, че казвате „О, ние използваме Spring Boot / Angular / React / PyTorch / официални базови Docker образи, така че рискът, за който говорите, е доста нисък.“ Може би това е вярно, ние, доставчиците на решения за сигурност, непрекъснато всяваме паника и намесата в екипите за разработка за смекчаване на спорен риск е безсмислена. Може да се изкушите да преминете към параграфа за приемане на риска (в следващия раздел) и всичко е готово. За съжаление, най-популярните компоненти са цели за злонамерени лица и например популярните Библиотеката PyTorch беше атакувана в миналото.
„Бързо открито, разкрито и премахнато“. Премахването на нов злонамерен компонент от публичния регистър отнема дни. Регистрите са предпазливи относно премахването на версия на компонент, за добро. Нашият опит показва, че след като бъде докладвано от наша страна, средното време за премахване на засегнатата версия от регистъра е 39 часа, повече от ден и половина. Има злонамерени компоненти, които са в регистъра седмица след първоначалното ни докладване, преди да бъдат премахнати. А в някои случаи компонентът се премахва само след като жертва или компания за реагиране при инциденти докладва за инцидент, включващ компонента.
Какво НЕ работи срещу злонамерени компоненти
Всеки неспецифичен подход ще се провали с гръм и трясък. Това е сигурно, вие не осигурявате ефективни контрамерки за риска, свързан с тази заплаха.
Традиционен SCA Инструментите ви информират за известен зловреден софтуер, но имат голям прозорец на експозиция. Освен ако не извършват проактивно откриване на зловреден софтуер с принудително блокиране на злонамерени компоненти, те не работят срещу тази заплаха.
Деактивирането на инсталационните скриптове може да помогне, но трябва да се прилага навсякъде, където трябва да се инсталира компонент. Същото важи и за закрепването на версиите, тъй като версиите не могат да бъдат закрепвани от безопасно начално състояние завинаги.
Да се предположи, че популярните компоненти получават достатъчно внимание, че не могат да бъдат инжектирани с непредвидено поведение при атака срещу веригата за доставки без почти мигновено откриване, за да се предотвратят каквито и да било щети, е наивно и рисковано. Не искате да живеете на ръба, нали?
Ако спрете на този етап, тогава приемане на риск е единственото нещо, което можеш да направиш: Това е деcisион, който трябва да бъде документиран във вашия модел на заплахата/оценка на риска, включително обосновката за приемане на риска и неговите потенциални последици. Повишете осведомеността, като го съобщите на ръководството и други съответни страни. Някои непредвидени разходи може да се планира, когато злонамерен компонент е инсталиран или включен във вашия софтуер, но това е трудно, защото нападателите имат много пътища, които да следват. Подробностите за атака по веригата за доставки, базирана на използването на злонамерен компонент, драстично ще променят публичното разкриване на инцидента, което вероятно е задължително съгласно регулаторната рамка на вашата организация. Можете също така да се обърнете към компенсиращи контроли or трансферен риск например със застраховка.
Въпреки това, има контролни мерки, които се справят със заплахата и трябва да бъдат взети предвид, ако не сте доволни от приемането на риска. Моля, продължете да четете.
Какво работи срещу атаки, използващи злонамерени компоненти
Работа с твърда версия
Закрепването на версиите с контролирани и информирани подобрения е правилният начин, за да се балансира необходимостта от премахване на уязвимости, без да се получава злонамерен софтуер. Но запомнете погрешното схващане №3: Самото закрепване на версиите не е достатъчно, за да блокира злонамерен код, идващ от нови версии, защото в бъдеще ще трябва да актуализирате версии, които са пряко или косвено зависими. В този момент се нуждаете от достатъчно убедителни доказателства, че всички модифицирани версии не съдържат злонамерен софтуер.
Ранно предупреждение
Един подход към проблема със злонамерените компоненти е система за ранно предупреждение (наречена тук Ранно предупреждение за злонамерен софтуер или MEW), където публикуваните нови версии (за нови или съществуващи компоненти) се анализират от система за откриване, която при наличие на достатъчно доказателства може да класифицира новата версия като потенциално злонамерена.
Автоматизацията е от съществено значение тук, тъй като е невъзможно ръчно да се прегледат всички нови компоненти при текущата скорост на публикуване. Така че системата за откриване трябва да комбинира различни техники, може би включително статичен, динамичен и анализ на възможностите, репутация на потребителите и доказателства, произтичащи от несъответствия между метаданните на компонента и съдържанието на tarball файла или между tarball файла и хранилището с източник, откъдето се предполага, че идва компонентът.
Налице е тъмна зона между времето на публикуване и момента, в който двигателят анализира съдържанието на компонентите, но не бива да надвишава няколко минути. Схемата може да бъде променена, например чрез изчакване на анализа на новите компоненти, преди да се позволи тяхното инсталиране и използване в изграждането на софтуера. pipelineили да ги анализирате при поискване, когато е необходимо. Компонент в дадена версия е непроменлив [3], така че е необходимо да се анализира само веднъж.
Пълната автоматизация не е възможна и е необходим преглед на сигурността за потенциално злонамерени компоненти. Пазете се от поддръжниците на дигиталната панацеяИзкуственият интелект и машинното обучение не са достатъчно развити, за да вземат последната дума, когато става въпрос за потвърждаване дали даден подозрителен компонент има зловреден софтуер. Разбира се, машинното обучение играе ключова роля в системата за откриване при класифицирането на входния компонент от суровите доказателства, но след като компонентът бъде „поставен под карантина“, последната дума е на ръчния преглед от екип по сигурността с опит със злонамерени компоненти. Това потвърждава всеки потенциален зловреден софтуер или го прекласифицира като безопасен. А периодът от време е в диапазона от часове.
Регистърът докладва за злонамерената версия/компонент; след това регистърът извършва проверка за потвърждение и пристъпва към публично разкриване и премахване от регистъра. Някои регистри съхраняват пакет за съхранение на сигурност. Времевият диапазон тук е дните или седмиците от публикуването, което е „време на престой' или 'прозорец на експозиция„за повечето злонамерени компоненти“.
Възможно ли е да се разбере дали дадена версия на компонент е злонамерена?
Така че, за ранно предупреждение, трябва да дадем задоволителен отговор на този въпрос: Как мога да разбера, че дадена библиотека или пакет (не) е злонамерен? Как да събера достатъчно доказателства за злонамерено поведение? Възможно е, но е трудно, тъй като нападателите използват много изобретателност, за да избегнат откриването. Има различни подходи, всеки с плюсове и минуси.
Статичен анализ може да изследва всички пътища на изпълнение, да проверява за техники, използвани от атакуващите, без да стартира компонента, и да извършва задачи за предварителна обработка, като де-обфускация или дешифриране. Тъй като атакуващите се опитват да скрият пакостите си, опитите за обфускация наистина са доказателство за злонамерен софтуер (но имайте предвид, че легитимните компоненти обфускират кода, за да запазят интелектуалната собственост, което противоречи на „с отворен код„“). Само малка част от високосложните атаки със силно обфускация се нуждаят от пясъчник, но подобно силно обфускация е ясен знак за злонамереност. Моля, обърнете внимание, че конвенционалните SAST Инструментите са проектирани за непреднамерени уязвимости, а не за злонамерени намерения, като например задните врати.
Динамичен анализ стартира компонента и анализира отговора, като инструментира средата за изпълнение, обикновено чрез предоставяне на изолирана среда. Злонамерено поведение, задействано при определени условия, може да остане незабелязано: моля, обърнете внимание, че злонамереният софтуер може да използва техники за избягване, като например Виртуализация/Избягване на пясъчник да се активира само когато не е под наблюдение, а също така е индикатор за злонамерена дейност за всеки двигател за статичен анализ.
Анализ на възможностите взема предвид какво прави компонентът: към кои файлове осъществява достъп, кои команди или програми се изпълняват, кои входно-изходни операции се извършват от терминала или устройството или кои системни повиквания се извикват. Това снемане на пръстови отпечатъци на поведение може да се сравнява (за съществуващ компонент) в различни версии, така че когато се открие неочаквано поведение, това доказателство може да породи съмнение за потенциална злонамерена дейност, инжектирана в новата версия. Този подход следва стъпките за сортиране, които анализаторите по сигурността следват, когато се сблъскат с потенциален зловреден софтуер: проверка с помощта на струни или подобни инструменти. Този подход открива злонамерено поведение, независимо от условията за задействане, и работи, когато няма наличен изходен код.
Анализ на контекста събира информация за това как и от кого е публикуван компонентът. Кампаниите на злонамерени лица често използват нов(и) потребителски акаунт(и), който(и) не е(са) подложен(и) на строг процес на проверка. Проследяването на минала активност може да даде представа за съответния потребител, най-вече за аномалии, които могат да намекват за потенциален компрометиращ риск. Репутацията е толкова трудна за спечелване и толкова лесна за загуба! Потребител без минала активност е неутрален, но кармата преследва злонамерените. Хакерите или обикновените потребители, чиито идентификационни данни за публикуване са откраднати, трябва да бъдат внимателно проследявани.
Друга контекстуална информация е всяко несъответствие между хранилището с източник, за което се предполага, че е използвано за създаване на tarball-а на компонента, и съдържанието на самия tarball. А също и следване на добри практики, като създаване на етикети или издания в хранилището с източник, съответстващи на версиите на компонента, публикувани в публичния регистър. Когато хранилището с източник на определено място... commit е маркиран с release и изведнъж една версия не го следва, само това е силно доказателство, че компонентът може да е заразен: злонамереният участник може да е компрометирал акаунта, използван за публикуване на компонента, но няма права за запис в хранилището на изходния код). Много атаки рутинно се откриват с помощта на тези правила: например, Атака върху Леджър биха могли лесно да бъдат открити по тези линии. Следователно, контекстният анализ идентифицира подобни аномалии в процеса на публикуване.
Защитна стена на зависимостите
Друг подход е да имате изчерпателен бял списък с компоненти за всички графове на зависимости, използвани във вашия софтуер, така че във всяка компилация pipeline Във вашата организация могат да се инсталират и използват само одобрени версии на компоненти. „защитна стена„“ се прилага с помощта на вътрешен регистър, където се предоставят tarball-овете за разрешените версии на компонентите (кеширани или прокси). Моля, обърнете внимание, че всеки бял списък няма да работи, освен ако не разполагате с технологията за класифициране на нова версия като сравнително безопасна, така че да може да бъде добавена към белия списък.
Моля, обърнете внимание, че ранното предупреждение (бързо откриване възможно най-скоро след публикуването на новата версия) трябва да бъде комбинирано с някакъв начин за проактивно използване на тази информация за блокиране на компонента, засягащ компилацията. pipelineили машините на разработчиците [4]Ние наричаме това „защитна стена за зависимости„: карантинен механизъм за защита на автоматизирани компилации от злонамерени пакети. Вътрешните пакети и регистрите на изображения са добри за изолиране на организациите от външно зло, но са необходими достатъчно силни доказателства, за да бъде карантината ефективна.
пясъчник по време на изпълнение
Алтернативен подход за откриване по време на публикуване е да се анализира поведението по време на изпълнение. Идеята е да се улови очакваното поведение от софтуера и да се открият (или блокират) всички открити аномалии. Тази линия на действие има проблема с необходимостта от инструментиране на средата за изпълнение за наблюдение или блокиране и е обещаваща идея, която ще бъде добавена към арсенала от защитни механизми срещу злонамерените компоненти-вредители.
Определяне на цялостна стратегия
Препоръчителната стратегия трябва да комбинира различни техники в процеса на разработване на софтуер, като поеме контрол върху актуализациите на версиите, за да блокира входящите злонамерени компоненти. Трябва да осигурим фиксиране на версиите, за да избегнем автоматично заразяване с актуализиране на версиите, за да получим корекции за важните уязвимости; бърза и ефикасна оценка на преките и косвените зависимости по време на актуализации на версиите, за да имаме достатъчно доказателства, че те не са заразени със зловреден софтуер. Компилациите на софтуер, които зависят от известни злонамерени компоненти, трябва да бъдат блокирани. И всички трябва да бъдат прилагани.
Използвайте закрепване на версии, когато е възможно, тъй като това прави компилациите по-възпроизводими. Закрепване на версии с контролирани, ръчно одобрени подобрения на версиите, и с помощта на помощна технология, трябва да оцени дали актуализацията носи злонамерен софтуер или нарушава работата на софтуера и да съгласува актуализирането за отстраняване на уязвимости с избягването на инфекция със злонамерен софтуер. Инструментите могат да помогнат тук чрез (1) приоритизиране на това кои уязвимости са наистина важни (достъпни и експлоатируеми, с висок риск от атаки от страна на атакуващите), (2) избиране на целеви версии, които са съвместими с текущото използване на компонентите и не нарушават работата на софтуера, (3) избиране на целеви версии, които не съдържат злонамерено поведение, и (4) бързо актуализиране на версията за преки и косвени зависимости, като предлага промени в манифестните файлове, които биха могли да бъдат бързо одобрени. Стъпка (3) изисква конкретна информация за злонамерените компоненти възможно най-близо до времето на публикуването им.
Този процес на актуализиране на зависимостите трябва да бъде изпълнено намлява проверена на всички места. Процесът трябва да бъде документиран и всички участващи страни трябва да бъдат обучени, тъй като често разработването и изграждането/внедряването на софтуер се възлага на външни лица. CI/CD pipelines трябва да бъдат съответно модифицирани, така че автоматизацията да не позволи на злонамерена непряка зависимост да се промъкне в компилацията: guardrails Блокирането на компилацията, ако има достатъчно доказателства за потенциален зловреден софтуер в зависимост, е препоръчителният начин.
Ако вашата организация има вътрешен регистър, действащ като защитен прокси за съхраняване на разрешените версии на компоненти, трябва да получите информация за злонамерени компоненти (освен други критерии) за проверка на заявен компонент, преди да го добавите към списъка с разрешени.
Консумирането на софтуер с отворен код с осигурена безопасност не е лесно и факторът злонамерен софтуер трябва да бъде взет изцяло предвид, като подобни усилия трябва да се положат и за справяне с уязвимостите.
Последна бележка: Произход на източника, под формата на софтуерни атестации, генерирани по време на изграждането на компонента, е друг ключов елемент в усилията за проследяване на артефакта (tarball на компонента) с изходните кодове и процеса на изграждане, който го е създал. Обърнете внимание, че тази връзка между моментната снимка на източника + средата за изграждане и свързания софтуерен артефакт (подписан от доверената система за изграждане) не предотвратява сама по себе си компонентът да не съдържа злонамерено поведение, но затруднява злонамерените злонамерени програми да бъдат инжектирани от злонамерени лица. А превръщането на валидирането на произхода в общо изискване за използване на компоненти с отворен код ще отнеме много време и само наскоро добавен към NPMОсигуряването на защита от неправомерно използване на тези надеждни системи за изграждане и внедряване или разрешаването на откриването на всякаква неправомерна промяна в изграждането е съвсем друга тема, която е извън обхвата на тази публикация.
Допълнителна информация
Следващият епизод Злонамерени пакети с отворен код: Подходът на Xygeni ще представи стратегията, която следваме в Xygeni за нашите Ранно предупреждение за злонамерен софтуер (MEW) система. Новите версии на пакетите в публичните регистри на пакети и изображения се сканират и се получават доказателства, използвайки комбинация от статичен, динамичен, анализ на възможностите и контекстуален анализ. Доказателствата, комбинирани с репутацията на потребителите и историята на промените в хранилищата на изходния код, позволяват изцяло автоматизирано класифициране на компонент във високорискови и вероятно злонамерени категории. Системата се учи от минали доказателства, събрани от пакетите, за да намали до минимум фалшивите положителни резултати.
Организациите, които са абонирани, получават предупредително известие за компоненти, които използват, пряко или косвено, когато бъде категоризирана злонамерена версия. След това нашите анализатори извършват ръчен анализ, който потвърждава или отхвърля класификацията. За потвърден зловреден софтуер публичният регистър се уведомява, за да може да извърши собствен анализ и обикновено да премахне злонамерената версия или да предприеме допълнителни действия, като например блокиране или премахване на въпросния потребителски акаунт.
Ще обясним как помагаме на NPM, PyPI, GitHub и други ключови инфраструктури в екосистемата с отворен код да намалят времето, през което публикуваният нов злонамерен компонент остава активен, докато не бъде потвърден като зловреден софтуер и премахнат от регистъра. И как организациите могат да се възползват от системата MEW, за да имат много по-добра защита срещу атаки по веригата за доставки на софтуер, включващи компоненти с отворен код.
- [1] Във всеки случай, потребителите на компонента трябва да проверят дали tarball-ът на компонента е кеширан или регистриран някъде, например във вътрешен регистър, така че болестта да бъде премахната.
- [2] Пакетираният компонент включва манифест, който декларира неговото съдържание и метаданни, изходен или компилиран код, инсталационни скриптове и допълнителни елементи, като например тестови пакети, според формат на пакетиране и обикновено в компресирана форма. Това се нарича „tarball на компонента“.
- [3] Дори ако злонамереният участник може да промени публикуван компонент поради нарушение в самия регистър, обикновен криптографски дайджест може да открие всяка промяна в tarball-а, след като анализът е извършен.
- [4] Не забравяйте, че някои злонамерени компоненти се изпълняват по време на инсталиране, така че това може да повлияе на разработчици, които неволно изпълняват „npm install X“ с X като злонамерен компонент.
