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