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