Բաց կոդով վնասակար փաթեթներից պաշտպանություն. Ի՞նչն է (չի) աշխատում

Սա երրորդ դրվագն է մի շարքում հոդվածների շարք ծրագրային ապահովման մատակարարման շղթայի ամենատարածված հարձակումների մասին՝ նրանք, որոնք չարաշահում են հանրային գրանցամատյանը բաց աղբյուր ծրագրային բաղադրիչներ։ Նախորդ դրվագում վերլուծելուց հետո «Վնասակար փաթեթների անատոմիա. Որո՞նք են միտումները։«Ինչպես են չարամիտ գործողները չարամիտ վարքագիծ ներարկում նոր կամ առկա հրապարակված բաղադրիչների մեջ, մենք պատրաստ ենք հագնել մեր հրդեհաշիջման բաճկոնները և ուսումնասիրել, թե ինչպես կարող ենք հաջողությամբ արգելափակել այս կերպ մատակարարվող չարամիտ ծրագրակազմը, կամ այլընտրանքորեն՝ զբաղվել պոտենցիալ լուրջ կիբեռմիջադեպով, քանի որ մենք սխալ մոտեցում ենք ցուցաբերել»։

Անվտանգությանը տեղյակ մասնագետների մեծ մասն ունի պատկերացումներ այս սպառնալիքի դեմ պայքարի մասին: Մենք լսել ենք անվտանգության մենեջերների, որոնք առանց վարանելու ասում են, որ SCA գործիքներն արդեն իսկ ձեզ տեղեկացնում են, թե երբ է փաթեթի տարբերակը վնասակար ծրագիր։ Կամ որ նրանք կախված են հայտնի, բարձր գնահատականներով ծրագրային բաղադրիչներից, որտեղ ցանկացած վնասակար ծրագիր անմիջապես կհայտնաբերվի և կհեռացվի։ Նրանք օգտագործում են բաց մանր/կարգերի տարբերակներ՝ խոցելիության շտկումներ ավտոմատ կերպով ստանալու համար, և դա բաց կոդով կախվածությունների ռիսկը նվազեցնելու ճիշտ, խորհուրդ տրվող միջոցն է՝ հետևելով «վաղ կարկատեք, հաճախ կարկատեք» սկզբունքը. 

Այս դրվագում մենք կքննարկենք, թե ինչու են այս գաղափարները սխալ, և թե ինչպես են նման թյուրըմբռնումները նպաստում այս հարձակման մեխանիզմի ժողովրդականությանը և այն ճնշող ռիսկին, որին ենթարկվում են կազմակերպությունները: Մենք կեզրափակենք նրանով, թե ինչն է աշխատում, և որոնք են ներգրավված ջանքերն ու ռեսուրսները:

Ընդհանուր թյուրըմբռնումներ

Ծրագրային անվտանգության ոլորտում մեր ճանապարհորդության ընթացքում մենք տեսանք հարձակման տեխնիկայի զարգացումը և անվտանգությանը մոտ կանգնած մարդկանց գաղափարների լայն շրջանակ։ Կազմակերպությունները հաճախ սխալ են հասկանում, թե ինչն է աշխատում այս սպառնալիքի դեմ, ուստի նախ կքննարկենք, թե ինչն է չի աշխատում, որը համառոտ ներկայացված է սխալ պատկերացումների հետևյալ, ոչ սպառիչ ցանկում։

Սխալ պատկերացում #1: SCA գործիքներն արդեն հաղորդում են վնասակար բաղադրիչների մասին

Իսկապես! Բայց փաստից հետո… Երբ, հավանաբար, արդեն շատ ուշ է, եթե տարրը օգտագործվել է ծրագրային ապահովման կառուցման մեջ, և չարագործները արդեն իսկ հենարան են ձեռք բերել մշակողի կամ CI/CD Հոսթ։ Հնարավոր է՝ գաղտնիքները դուրս են բերվել, լրացուցիչ վնասակար ծրագրեր են ներբեռնվել և տեղադրվել, և հնարավոր է՝ թշնամին տեղաշարժվել է կողքից և արդեն մուտք է ստացել այլուր։ 

Ծրագրային ապահովման կազմի վերլուծություն (SCA) գործիքները նախագծվել են հնարավոր հայտնի խոցելիությունները հայտնաբերելու համար: Ժամանակակից գործիքները հիանալի աշխատանք են կատարում՝ բարձրացնելով ազդանշան-աղմուկ հարաբերակցությունը, որոշելով, թե արդյոք խոցելիությունը իրականում հասանելի է, թե շահագործելի: Սակայն դրանք անօգուտ են նոր վնասակար ծրագրերի դեմ: Մտածեք վնասակար բաղադրիչի մասին որպես զրոյական օրվա խոցելիության մասին. միայն այն դեպքում, երբ հայտնաբերվում է դրա վնասակար վարքագիծը, բաղադրիչը հաղորդվում է պահող գրանցամատյանին, որը անվտանգության թիմի կողմից վերանայումից հետո հաստատվում է որպես վնասակար և հեռացվում է գրանցամատյանից: [1]. 

Այդ պահին աշխարհը (ներառյալ SCAs) գիտի, որ բաղադրիչի (կամ գոյություն ունեցող բաղադրիչի որոշ տարբերակ(ներ)ի) տեղադրումը կամ օգտագործումը լավ բան չէ։ Սակայն սա այն դեպքում է, երբ բաղադրիչը հասանելի չէ գրանցամատյանում։Լավ է իմանալ, որ ես ունեմ խոցելիություններ երրորդ կողմի բաղադրիչներում, կամ նույնիսկ բաղադրիչներում, որոնք գրանցամատյանի կողմից դասակարգվել են որպես վնասակար, բայց, ցավոք, SCA կամ ընդհանուր աուդիտի գործիքները այս համատեքստում չեն օգնում։ Քանի դեռ SCA/audit գործիքը կարող է նախապես իմանալ, որ բաղադրիչը վնասակար է, նախքան այն ձեր կազմակերպությունում կօգտագործվի։.

Հիշե՛ք, որ վնասակար բաց կոդով բաղադրիչների դեմ ցանկացած լուծում պետք է հայտնաբերի դրանք։ թռիչքի ժամանակ, բաղադրիչի գրանցամատյանում հրապարակման և ձեր կազմակերպությունում դրա առաջին օգտագործման միջև ընկած ժամանակահատվածում։ Եվ դա ներառում է նաև անցումային բաղադրիչները։  

Սխալ պատկերացում #2. տեղադրման սկրիպտների կառավարումը կառուցման ժամանակ կանխում է բաց կոդով բաղադրիչների վնասակար վարքագիծը

Տարբեր փաթեթների կառավարիչներ առաջարկում են սկրիպտներ գործարկելու հնարավորություն (ներառված են բաղադրիչի tarball-ում) [2]), օրինական պատճառներով, ինչպիսիք են տարբեր հարթակներում անհրաժեշտ տարրերի կոմպիլյացիան, կոդի ստեղծումը կամ թեստեր անցկացնելը, և մենք բոլորս պետք է իմանանք, որ դրանք կարող են չարաշահվել չարամիտ գործողների կողմից, եթե tarball-ում ներառված են վնասակար սկրիպտներ, կամ եթե հարձակվողը կարող է վնասակար սկրիպտ գործարկել լավի փոխարեն։

Սա իմանալով՝ մենք կարող ենք կարգավորել փաթեթների կառավարիչը՝ սկրիպտները անտեսելու համար։ Օրինակ՝ NPM-ի դեպքում –ignore-scripts դրոշ (կամ կարգավորման հատկություն .npmrc ֆայլը) բաց է թողնում սկրիպտները տեղադրման ընթացքում: Սա կարող է որոշ խնդիրներ առաջացնել, քանի որ սկրիպտների գործարկումը տարածված է շատ էկոհամակարգերում. Որոշ փաթեթների կառավարիչներ նույնիսկ թույլ չեն տալիս անջատել սկրիպտի կատարումը (հուշում՝ հուշում «Ո՞ր փաթեթների կառավարիչներն են թույլ չեն տալիս անջատել տեղադրման սկրիպտների կատարումը։«ձեր սիրելի արհեստական ​​ինտելեկտում)։ Բայց սա ընդհանուր առմամբ չի պաշտպանում (մենք պետք է պարտադրենք, որ բաց թողնելու անջատման կարգավորումը ամենուրեք լինի)։ 

Եվ երբ վնասակար վարքագիծը գտնվում է ոչ թե տեղադրման սկրիպտներում, այլ գործարկման ժամանակ կատարվող ծրագրաշարում, այս տարբերակն ինքնին մեզ չի պաշտպանում։ 

Սխալ պատկերացում #3. Տարբերակի ամրացումը կանխում է վնասակար բաղադրիչների տեղադրումը

Կա փոխզիջում վաղ կարկատման և հաճախակի կիրառման միջև բաց տարբերակներ (թույլ տալով փաթեթների կառավարչին ավտոմատ կերպով տեղադրել նոր թարմացումներ, երբ դրանք հասանելի են անվտանգության շտկումների համար) և տարբերակի ամրացում (ունենալով ծրագրային ապահովման բոլոր ուղղակի և անցումային կախվածությունները ֆիքսված տարբերակում): Անվտանգության սկզբունքները համառ են և երբեմն հակասական, ինչպես պատահում է «վաղ թարմացնել, հաճախ թարմացնել» դեպքում և «Թարմացումը չպետք է թեթևամտորեն ընդունվի»Որոշ փաթեթների կառավարիչներ ավտոմատ թարմացումներ են կատարում սերվերի տիրույթներով՝ խորհուրդ տրված եղանակով: Հիանալի է, եթե դուք նույնպես ցանկանում եք ստանալ վնասակար թարմացումները: Այո, բաղադրիչները պետք է թարմացվեն՝ անվտանգության շտկումներ ստանալու համար, որոնք հնարավորինս շուտ կփակեն խոցելիությունները, բայց… երբեք թույլ մի տվեք, որ փաթեթների կառավարիչը դա անի ավտոմատ կերպով:

Սխալ պատկերացում #4. Հուսալի բաղադրիչների օգտագործումը անվտանգ է: Ցանկացած վնասակար տարբերակ անմիջապես կգտնվի, կբացահայտվի և կհեռացվի:

Ինչո՞ւ է որևէ բաղադրիչ վստահելի։ Հնարավոր է՝ այն շատ տարածված է, շատերը փնտրում են խոցելիություններ, ունի մեծ թվով աջակցողներ սպասարկման համար, բազմաթիվ հիմնական սպասարկողներ, որոնք ջանասիրաբար վերանայում են բոլոր բաղադրիչները։ pull requestsԻրականությունը բավականին այլ է։ Որոշ կարևոր բաղադրիչներ պահպանվում են մեկ, չվճարվող մշակողի կողմից։ Լայնորեն օգտագործվող շրջանակները ունեն մի քանի մշտական ​​​​հեղինակներ, արագորեն նվազող թվով commitյուրաքանչյուր սպասարկողի համար (հայտնի նախագծերն ունեն ներդրողների երկար շարք, որոնք կատարում են որոշակի ավտոմատացված աշխատանք) commit և երբեք չեն վերադառնա)։ Եվ մեկ սպասարկողով հայտնի նախագծերը շատ են։

Պատկերացրեք, որ ասում եք. «Օ՜, մենք օգտագործում ենք Spring Boot / Angular / React / PyTorch / պաշտոնական Docker պատկերները, այնպես որ այն ռիսկը, որի մասին դուք խոսում եք, բավականին ցածր է»։ Հնարավոր է՝ դա ճիշտ է, մենք՝ անվտանգության մատակարարներս, անընդհատ վախեցնում ենք և խառնվում մշակողների թիմերին՝ վիճելի ռիսկը մեղմելու համար, անհեթեթություն է: Դուք կարող եք գայթակղվել անցնել ռիսկի ընդունման պարբերությանը (հաջորդ բաժնում) և ամեն ինչ պատրաստ է: Դժբախտաբար, ամենատարածված բաղադրիչները չարագործների թիրախ են, և, օրինակ, հայտնի... PyTorch գրադարանը հարձակման է ենթարկվել անցյալում է.

«Անհապաղ հայտնաբերվել, բացահայտվել և հեռացվել է»։  Հանրային գրանցամատյանից նոր վնասակար բաղադրիչը հեռացնելու համար օրեր են պահանջվում: Գրանցամատյանները զգուշորեն են վերաբերվում բաղադրիչի տարբերակի հեռացմանը՝ դրական արդյունքի հասնելու համար: Մեր փորձը ցույց է տալիս, որ մեր կողմից հաղորդվելուց հետո, գրանցամատյանի համար ազդակիր տարբերակը հեռացնելու միջին ժամանակը 39 ժամ է, ավելի քան մեկուկես օր: Կան վնասակար բաղադրիչներ, որոնք հեռացումից մեկ շաբաթ անց են գրանցամատյանում մեր սկզբնական հաղորդումից հետո: Եվ որոշ դեպքերում բաղադրիչը հեռացվում է միայն այն բանից հետո, երբ տուժողը կամ միջադեպերին արձագանքող ընկերությունը հաղորդում է բաղադրիչի հետ կապված միջադեպի մասին: 

Ինչը չի աշխատում վնասակար բաղադրիչների դեմ

Ցանկացած անորոշ մոտեցում խորապես ձախողվելու է։ Սա անկասկած է, դուք արդյունավետ հակազդեցություններ չեք ապահովում այս սպառնալիքի հետ կապված ռիսկի դեմ։ 

Ավանդական SCA Գործիքները ձեզ տեղեկացնում են հայտնի վնասակար ծրագրերի մասին, բայց ունեն մեծ ազդեցության պատուհան։ Եթե դրանք նախաձեռնողաբար չեն հայտնաբերում վնասակար ծրագրերը՝ վնասակար բաղադրիչների հարկադիր արգելափակմամբ, դրանք չեն աշխատում այս սպառնալիքի դեմ։ 

Տեղադրման սկրիպտների անջատումը կարող է օգնել, բայց պետք է պարտադրվի ամենուր, որտեղ անհրաժեշտ է տեղադրել բաղադրիչ: Նույնը վերաբերում է նաև տարբերակների ամրացմանը, քանի որ տարբերակները չեն կարող հավերժ ամրացվել անվտանգ սկզբնական վիճակից:

Ենթադրել, որ հայտնի բաղադրիչները բավարար ուշադրության են արժանանում, որպեսզի դրանց վրա չնախատեսված վարքագիծ չառաջանա մատակարարման շղթայի հարձակման ժամանակ՝ առանց գրեթե ակնթարթային հայտնաբերման և որևէ վնասի կանխարգելման համար, միամիտ և ռիսկային է։ Դուք չեք ուզենա ապրել վտանգի եզրին, այնպես չէ՞։

Եթե ​​կանգ առնեք այս պահին, ապա՝ ռիսկի ընդունում միակ բանն է, որ կարող ես անել. Սա դե էcisորը պետք է փաստաթղթավորվի ձեր սպառնալիքի մոդելում/ռիսկի գնահատման մեջ, ներառյալ ռիսկը ընդունելու հիմնավորումը և դրա հնարավոր հետևանքները: Բարձրացրեք իրազեկվածությունը՝ այն հաղորդելով ղեկավարությանը և այլ համապատասխան կողմերին: Որոշ պայմանականություն կարող է պլանավորվել, երբ ձեր ծրագրաշարում տեղադրվում կամ ներառվում է վնասակար բաղադրիչ, բայց դա դժվար է, քանի որ հարձակվողները բազմաթիվ ուղիներ ունեն հետևելու: Վնասակար բաղադրիչի օգտագործման վրա հիմնված մատակարարման շղթայի հարձակման մանրամասները կտրուկ կփոխեն միջադեպի հրապարակային բացահայտումը, որը, հավանաբար, պարտադիր է ձեր կազմակերպության կարգավորող շրջանակի համաձայն: Դուք կարող եք նաև դիմել փոխհատուցող կառավարումներ or փոխանցման ռիսկ օրինակ՝ ապահովագրության հետ։

Այնուամենայնիվ, կան վերահսկողության միջոցներ, որոնք ուղղված են սպառնալիքին և պետք է դիտարկվեն, եթե դուք գոհ չեք ռիսկի ընդունումից: Խնդրում ենք շարունակել կարդալ:

Ի՞նչն է աշխատում վնասակար բաղադրիչներ օգտագործող հարձակումների դեմ

Solid տարբերակի մշակում

Տարբերակի ամրագրումը վերահսկվող և տեղեկացված տարբերակների փոփոխությունների միջոցով լավագույն լուծումն է՝ խոցելիությունները հեռացնելու անհրաժեշտությունը հավասարակշռելու համար՝ առանց վնասակար ծրագրեր ստանալու։ Սակայն հիշեք #3 սխալ պատկերացումը. միայն տարբերակի ամրագրումը բավարար չէ նոր տարբերակներից եկող վնասակար կոդը կանխելու համար, քանի որ ապագայում ձեզ անհրաժեշտ կլինի թարմացնել ցանկացած ուղղակի կամ անուղղակի կախվածության տարբերակներ։ Այդ պահին ձեզ անհրաժեշտ են բավականաչափ ուժեղ ապացույցներ, որ բոլոր փոփոխված տարբերակները չեն պարունակում վնասակար ծրագրեր։

Վաղ նախազգուշացում

Վնասակար բաղադրիչների խնդրի լուծման մեկ մոտեցումը վաղ նախազգուշացման համակարգն է (այստեղ անվանված է որպես Վնասակար ծրագրերի վաղ նախազգուշացում կամ MEW), որտեղ հրապարակված նոր տարբերակները (նոր կամ գոյություն ունեցող բաղադրիչների համար) վերլուծվում են հայտնաբերման մեխանիզմի կողմից, որը, բավարար ապացույցներ գտնելու դեպքում, կարող է նոր տարբերակը դասակարգել որպես պոտենցիալ վնասակար։ 

Ավտոմատացումը այստեղ կարևոր է, քանի որ անհնար է ձեռքով վերանայել բոլոր նոր բաղադրիչները ներկայիս հրապարակման տեմպով: Այսպիսով, հայտնաբերման շարժիչը պետք է համատեղի մի շարք տեխնիկաներ, ներառյալ ստատիկ, դինամիկ և կարողությունների վերլուծությունը, օգտատիրոջ հեղինակությունը և բաղադրիչի մետատվյալների և tarball-ի բովանդակության միջև անհամապատասխանություններից բխող ապացույցները, կամ tarball-ի և աղբյուրի պահոցի միջև, որտեղից ենթադրաբար ծագում է բաղադրիչը:

Կա մութ գոտի հրապարակման ժամանակի և շարժիչի կողմից բաղադրիչների պարունակության վերլուծության միջև ընկած ժամանակահատվածը, սակայն այն չպետք է գերազանցի մի քանի րոպեն։ Սխեման կարող է փոփոխվել, օրինակ՝ սպասելով նոր բաղադրիչների վերլուծությանը, նախքան դրանց տեղադրումը և ծրագրային ապահովման կառուցման մեջ օգտագործելը թույլատրելը։ pipelines, կամ վերլուծել դրանք ըստ պահանջի, երբ անհրաժեշտ է։ Տվյալ տարբերակի բաղադրիչը անփոփոխ է։ [3], ուստի այն պետք է վերլուծվի միայն մեկ անգամ։