SeerLight-ի կողմից
Ցանկացած ծառայության կառուցումը անպայման ներառում է անվտանգության ապահովման մշտական աշխատանք: Անվտանգությունը շարունակական գործընթաց է, որը ներառում է արտադրանքի անվտանգության մշտական վերլուծություն և բարելավում, խոցելիության մասին նորությունների մոնիտորինգ և շատ ավելին: Ներառյալ աուդիտները: Աուդիտներն իրականացվում են ինչպես ներքին, այնպես էլ արտաքին փորձագետների կողմից, որոնք կարող են արմատապես օգնել անվտանգության հարցում, քանի որ խորասուզված չեն նախագծի մեջ և ունեն բաց միտք:
Հոդվածը վերաբերում է արտաքին փորձագետների այս ամենապարզ տեսակետին, ովքեր օգնել են Mail.ru Cloud Solutions (MCS) թիմին փորձարկել ամպային ծառայությունը, և այն մասին, թե ինչ են նրանք գտել: Որպես «արտաքին ուժ» MCS-ն ընտրեց Digital Security ընկերությունը, որը հայտնի է տեղեկատվական անվտանգության շրջանակներում իր բարձր փորձով: Եվ այս հոդվածում մենք կվերլուծենք որոշ հետաքրքիր խոցելիություններ, որոնք հայտնաբերվել են արտաքին աուդիտի շրջանակներում, այնպես որ դուք խուսափեք նույն փոցխից, երբ ստեղծեք ձեր սեփական ամպային ծառայությունը:
Описание продукта
ամպի մեջ վիրտուալ ենթակառուցվածք ստեղծելու հարթակ է: Այն ներառում է IaaS, PaaS և մշակողների համար պատրաստի հավելվածների պատկերների շուկա: Հաշվի առնելով MCS ճարտարապետությունը՝ անհրաժեշտ էր ստուգել արտադրանքի անվտանգությունը հետևյալ ոլորտներում.
- վիրտուալացման միջավայրի ենթակառուցվածքի պաշտպանություն՝ հիպերվիզորներ, երթուղիներ, firewalls;
- հաճախորդների վիրտուալ ենթակառուցվածքի պաշտպանություն. մեկուսացում միմյանցից, ներառյալ ցանցը, մասնավոր ցանցերը SDN-ում.
- OpenStack-ը և դրա բաց բաղադրիչները;
- S3 մեր սեփական դիզայնով;
- ԻԱՄ.
- Vision (համակարգչային տեսողություն). API-ներ և խոցելիություններ պատկերների հետ աշխատելիս.
- վեբ ինտերֆեյս և դասական վեբ հարձակումներ;
- PaaS բաղադրիչների խոցելիությունները;
- Բոլոր բաղադրիչների API:
Թերևս դա այն ամենն է, ինչ կարևոր է հետագա պատմության համար:
Ինչպիսի՞ աշխատանքներ են իրականացվել և ինչի՞ համար է դա անհրաժեշտ։
Անվտանգության աուդիտը ուղղված է խոցելիության և կազմաձևման սխալների բացահայտմանը, որոնք կարող են հանգեցնել անձնական տվյալների արտահոսքի, զգայուն տեղեկատվության փոփոխմանը կամ ծառայության հասանելիության խափանմանը:
Աշխատանքի ընթացքում, որը տևում է միջինը 1-2 ամիս, աուդիտորները կրկնում են պոտենցիալ հարձակվողների գործողությունները և խոցելիություններ են փնտրում ընտրված ծառայության հաճախորդի և սերվերի մասերում: MCS ամպային հարթակի աուդիտի համատեքստում սահմանվել են հետևյալ նպատակները.
- Ծառայության մեջ նույնականացման վերլուծություն: Այս բաղադրիչի խոցելիությունը կօգնի անմիջապես մուտք գործել այլ մարդկանց հաշիվներ:
- Տարբեր հաշիվների միջև դերային մոդելի և մուտքի վերահսկման ուսումնասիրություն: Հարձակվողի համար ուրիշի վիրտուալ մեքենա մուտք գործելու հնարավորությունը ցանկալի նպատակ է:
- Հաճախորդի կողմի խոցելիությունները. XSS / CSRF / CRLF / և այլն: Հնարավո՞ր է հարձակվել այլ օգտվողների վրա վնասակար հղումների միջոցով:
- Սերվերի կողմի խոցելիություններ. RCE և բոլոր տեսակի ներարկումներ (SQL/XXE/SSRF և այլն): Սերվերի խոցելիությունը, ընդհանուր առմամբ, ավելի դժվար է գտնել, բայց դրանք հանգեցնում են միանգամից բազմաթիվ օգտատերերի փոխզիջման:
- Օգտագործողի հատվածի մեկուսացման վերլուծություն ցանցի մակարդակում: Հարձակվողի համար մեկուսացման բացակայությունը մեծապես մեծացնում է հարձակման մակերեսը այլ օգտվողների դեմ:
- Բիզնեսի տրամաբանության վերլուծություն. Հնարավո՞ր է խաբել բիզնեսին և անվճար ստեղծել վիրտուալ մեքենաներ:
Այս նախագծում աշխատանքն իրականացվել է «Gray-box» մոդելի համաձայն. աուդիտորները ծառայության հետ շփվել են սովորական օգտատերերի արտոնություններով, սակայն մասամբ տիրապետել են API-ի սկզբնական կոդը և հնարավորություն են ունեցել մանրամասներ ճշտել մշակողների հետ: Սա սովորաբար աշխատանքի ամենահարմար և միևնույն ժամանակ բավականին իրատեսական մոդելն է. ներքին տեղեկատվությունը դեռևս կարող է հավաքվել հարձակվողի կողմից, դա միայն ժամանակի հարց է:
Հայտնաբերվել են խոցելիություններ
Մինչ աուդիտորը կսկսի զանազան օգտակար բեռներ (հարձակումն իրականացնելու համար օգտագործվող ծանրաբեռնվածությունը) ուղարկել պատահական վայրեր, անհրաժեշտ է հասկանալ, թե ինչպես են աշխատում իրերը և ինչ գործառույթներ են տրամադրվում: Կարող է թվալ, թե սա անօգուտ վարժություն է, քանի որ ուսումնասիրված վայրերի մեծ մասում խոցելի տեղեր չեն լինի։ Բայց միայն հավելվածի կառուցվածքը և դրա գործողության տրամաբանությունը հասկանալը հնարավորություն կտա գտնել ամենաբարդ հարձակման վեկտորները:
Կարևոր է գտնել այնպիսի վայրեր, որոնք կասկածելի են թվում կամ ինչ-որ կերպ շատ տարբեր են մյուսներից: Եվ առաջին վտանգավոր խոցելիությունը հայտնաբերվեց այս կերպ.
ԻԴՈՐ
IDOR-ի (Insecure Direct Object Reference) խոցելիությունը բիզնես տրամաբանության ամենատարածված խոցելիություններից է, որը թույլ է տալիս մեկին կամ մյուսին մուտք ունենալ դեպի այն օբյեկտները, որոնց մուտքն իրականում թույլատրված չէ: IDOR-ի խոցելիությունը հնարավորություն է ստեղծում տարբեր աստիճանի կրիտիկական օգտատիրոջ մասին տեղեկատվություն ստանալու համար:
IDOR-ի տարբերակներից մեկը համակարգի օբյեկտների (օգտատերերի, բանկային հաշիվների, զամբյուղի ապրանքների) հետ գործողություններ կատարելն է՝ այդ օբյեկտների մուտքի նույնացուցիչները շահարկելով: Սա հանգեցնում է ամենաանկանխատեսելի հետեւանքների։ Օրինակ՝ միջոցներ ուղարկողի հաշիվը փոխարինելու հնարավորությունը, որի միջոցով կարող եք դրանք գողանալ այլ օգտատերերից։
MCS-ի դեպքում աուդիտորները հենց նոր հայտնաբերեցին IDOR-ի խոցելիություն՝ կապված ոչ անվտանգ նույնացուցիչների հետ: Օգտատիրոջ անձնական հաշվում UUID նույնացուցիչներն օգտագործվել են ցանկացած օբյեկտ մուտք գործելու համար, որոնք, ինչպես ասում են անվտանգության փորձագետները, տպավորիչ անապահով էին թվում (այսինքն՝ պաշտպանված բիրտ ուժի հարձակումներից): Սակայն որոշ սուբյեկտների համար պարզվել է, որ կանոնավոր կանխատեսելի թվեր են օգտագործվում հավելվածի օգտատերերի մասին տեղեկություններ ստանալու համար։ Կարծում եմ, կարող եք կռահել, որ հնարավոր էր մեկով փոխել օգտվողի ID-ն, նորից ուղարկել հարցումը և այդպիսով տեղեկատվություն ստանալ՝ շրջանցելով ACL-ը (մուտքի վերահսկման ցուցակը, գործընթացների և օգտատերերի տվյալների հասանելիության կանոնները):
Սերվերի կողմից հարցումների կեղծում (SSRF)
OpenSource-ի արտադրանքի լավ բանն այն է, որ նրանք ունեն հսկայական թվով ֆորումներ՝ ծագած խնդիրների մանրամասն տեխնիկական նկարագրությամբ և, եթե հաջողակ եք, լուծման նկարագրությամբ: Բայց այս մետաղադրամն ունի հակադարձ կողմ. հայտնի խոցելիությունները նույնպես մանրամասն նկարագրված են: Օրինակ, OpenStack ֆորումում կան խոցելիության հրաշալի նկարագրություններ и , որը ինչ-ինչ պատճառներով ոչ ոք չի շտապում շտկել։
Հավելվածների ընդհանուր ֆունկցիոնալությունը օգտագործողի կողմից սերվերին հղում ուղարկելու հնարավորությունն է, որի վրա սերվերը կտտացնում է (օրինակ՝ պատկերը նշված աղբյուրից ներբեռնելու համար): Եթե անվտանգության գործիքներն իրենք չեն զտում հղումները կամ սերվերից օգտվողներին վերադարձված պատասխանները, նման գործառույթը հեշտությամբ կարող է օգտագործվել հարձակվողների կողմից:
SSRF-ի խոցելիությունը կարող է մեծապես նպաստել հարձակման զարգացմանը: Հարձակվողը կարող է ստանալ.
- սահմանափակ մուտք դեպի հարձակման ենթարկված տեղական ցանց, օրինակ, միայն ցանցի որոշակի հատվածների միջոցով և օգտագործելով որոշակի արձանագրություն.
- ամբողջական մուտք դեպի լոկալ ցանց, եթե հնարավոր է կիրառական մակարդակից բեռնափոխադրման մակարդակի իջեցում և, որպես հետևանք, կիրառական մակարդակում բեռնվածության ամբողջական կառավարում.
- մուտք դեպի սերվերի վրա տեղական ֆայլեր կարդալու (եթե ֆայլը:/// սխեման աջակցվում է);
- եւ շատ ավելին:
OpenStack-ում վաղուց հայտնի է SSRF խոցելիությունը, որն իր բնույթով «կույր» է. երբ կապվում ես սերվերի հետ, նրանից պատասխան չես ստանում, բայց ստանում ես տարբեր տեսակի սխալներ/ուշացումներ՝ կախված հարցման արդյունքից։ . Ելնելով դրանից՝ դուք կարող եք ներքին ցանցի հոսթների վրա կատարել պորտի սկանավորում՝ դրանից բխող բոլոր հետևանքներով, որոնք չպետք է թերագնահատվեն: Օրինակ, արտադրանքը կարող է ունենալ back-office API, որը հասանելի է միայն կորպորատիվ ցանցից: Փաստաթղթերով (մի մոռացեք ինսայդերների մասին) հարձակվողը կարող է օգտագործել SSRF՝ ներքին մեթոդներին մուտք գործելու համար: Օրինակ, եթե ինչ-որ կերպ կարողացաք ստանալ օգտակար URL-ների մոտավոր ցուցակ, ապա SSRF-ի միջոցով կարող եք անցնել դրանց միջով և կատարել հարցում՝ համեմատաբար ասած՝ գումար փոխանցել հաշվից հաշիվ կամ փոխել սահմանաչափերը:
Սա առաջին դեպքը չէ, երբ OpenStack-ում SSRF խոցելիություն է հայտնաբերվել: Նախկինում VM ISO պատկերները հնարավոր էր ներբեռնել ուղիղ հղումով, ինչը նույնպես հանգեցրեց նմանատիպ հետևանքների։ Այս ֆունկցիան այժմ հեռացվել է OpenStack-ից: Ըստ ամենայնի, համայնքը սա համարել է խնդրի ամենապարզ և վստահելի լուծումը։
Եվ HackerOne ծառայության հրապարակայնորեն հասանելի զեկույցը (h1), այլևս կույր SSRF-ի օգտագործումը՝ օրինակների մետատվյալները կարդալու ունակությամբ, հանգեցնում է Root մուտքի դեպի Shopify ամբողջ ենթակառուցվածքը:
MCS-ում SSRF-ի խոցելիությունները հայտնաբերվել են երկու տեղերում՝ նմանատիպ ֆունկցիոնալությամբ, բայց դրանք գրեթե անհնար էր օգտագործել՝ firewalls-ի և այլ պաշտպանությունների պատճառով: Այսպես թե այնպես, MCS թիմը, այնուամենայնիվ, շտկեց այս խնդիրը՝ չսպասելով համայնքին:
XSS կեղևները բեռնելու փոխարեն
Չնայած գրված հարյուրավոր ուսումնասիրություններին, տարեցտարի XSS (միջկայքի սկրիպտավորում) հարձակումը դեռևս ամենաշատն է վեբ խոցելիություն (կամ ?):
Ֆայլերի վերբեռնումը սիրված վայր է ցանկացած անվտանգության հետազոտողի համար: Հաճախ պարզվում է, որ դուք կարող եք բեռնել կամայական սկրիպտը (asp/jsp/php) և կատարել ՕՀ հրամաններ, գրիչների տերմինաբանությամբ՝ «load shell»: Բայց նման խոցելիության հանրաճանաչությունն աշխատում է երկու ուղղությամբ. դրանք հիշվում են և դրանց դեմ միջոցներ են մշակվում, այնպես որ վերջերս «պատյան բեռնելու» հավանականությունը զրոյի է հասնում։
Հարձակվող թիմի (ի դեմս Digital Security-ի) բախտը բերեց: Լավ, սերվերի կողմից MCS-ում ստուգվել է ներբեռնված ֆայլերի բովանդակությունը, թույլատրվել են միայն պատկերներ: Բայց SVG-ն նույնպես նկար է։ Ինչպե՞ս կարող են SVG պատկերները վտանգավոր լինել: Քանի որ դուք կարող եք տեղադրել JavaScript-ի հատվածներ դրանց մեջ:
Պարզվել է, որ ներբեռնված ֆայլերը հասանելի են MCS ծառայության բոլոր օգտատերերին, ինչը նշանակում է, որ հնարավոր է հարձակվել ամպային այլ օգտատերերի, մասնավորապես՝ ադմինիստրատորների վրա։
Ֆիշինգի մուտքի ձևի վրա XSS հարձակման օրինակ
XSS հարձակման շահագործման օրինակներ.
- Ինչու՞ փորձել գողանալ նիստը (մանավանդ, որ այժմ ամենուր կան միայն HTTP-Only քուքիները՝ պաշտպանված գողությունից՝ օգտագործելով js սկրիպտներ), եթե բեռնված սկրիպտը կարող է անմիջապես մուտք գործել ռեսուրսի API: Այս դեպքում ծանրաբեռնվածությունը կարող է օգտագործել XHR հարցումները՝ սերվերի կոնֆիգուրացիան փոխելու համար, օրինակ՝ ավելացնել հարձակվողի հանրային SSH բանալին և ստանալ SSH մուտք դեպի սերվեր:
- Եթե CSP քաղաքականությունը (բովանդակության պաշտպանության քաղաքականությունը) արգելում է JavaScript-ի ներարկումը, հարձակվողը կարող է հաղթահարել առանց դրա: Օգտագործելով մաքուր HTML՝ կայքի համար ստեղծեք կեղծ մուտքի ձև և գողացեք ադմինիստրատորի գաղտնաբառը այս առաջադեմ ֆիշինգի միջոցով. օգտվողի ֆիշինգի էջը հայտնվում է նույն URL-ում, և օգտվողի համար ավելի դժվար է հայտնաբերել այն:
- Ի վերջո, հարձակվողը կարող է կազմակերպել — սահմանել 4 ԿԲ-ից մեծ թխուկներ: Օգտագործողին անհրաժեշտ է միայն մեկ անգամ բացել հղումը, և ամբողջ կայքը դառնում է անհասանելի, քանի դեռ օգտատերը չի մտածում հատուկ մաքրել բրաուզերը. ճնշող մեծամասնությունում վեբ սերվերը կհրաժարվի ընդունել այդպիսի հաճախորդ:
Եկեք նայենք մեկ այլ հայտնաբերված XSS-ի օրինակին, այս անգամ ավելի խելացի շահագործմամբ: MCS ծառայությունը թույլ է տալիս համատեղել firewall-ի կարգավորումները խմբերի մեջ: Խմբի անվանումն այն էր, որտեղ հայտնաբերվել է XSS-ը: Դրա առանձնահատկությունն այն էր, որ վեկտորը չի գործարկվում անմիջապես, ոչ թե կանոնների ցանկը դիտելիս, այլ խումբ ջնջելիս.
Այսինքն՝ սցենարը ստացվել է հետևյալը. հարձակվողը ստեղծում է firewall-ի կանոն՝ անվանման մեջ «load», ադմինիստրատորը որոշ ժամանակ անց նկատում է դա և սկսում ջնջման գործընթացը։ Եվ հենց այստեղ է աշխատում վնասակար JS-ը:
MCS ծրագրավորողների համար ներբեռնված SVG պատկերներում XSS-ից պաշտպանվելու համար (եթե դրանք հնարավոր չէ լքել), Թվային անվտանգության թիմը խորհուրդ է տվել.
- Տեղադրեք օգտատերերի կողմից վերբեռնված ֆայլերը առանձին տիրույթում, որը ոչ մի կապ չունի «քուքիների» հետ։ Սցենարը կկատարվի այլ տիրույթի համատեքստում և վտանգ չի ներկայացնի MCS-ի համար:
- Սերվերի HTTP պատասխանում ուղարկեք «Content-disposition: attachment» վերնագիրը: Այնուհետև ֆայլերը կներբեռնվեն բրաուզերի կողմից և չեն կատարվի:
Բացի այդ, այժմ մշակողների համար հասանելի են բազմաթիվ եղանակներ՝ մեղմելու XSS-ի շահագործման ռիսկերը.
- օգտագործելով «Միայն HTTP» դրոշը, դուք կարող եք նիստի «Cookies» վերնագրերը անհասանելի դարձնել վնասակար JavaScript-ի համար;
- Հարձակվողի համար շատ ավելի դժվար կլինի օգտագործել XSS-ը.
- Կաղապարների ժամանակակից շարժիչները, ինչպիսիք են Angular-ը կամ React-ը, ավտոմատ կերպով մաքրում են օգտատիրոջ տվյալները՝ նախքան դրանք օգտատիրոջ զննարկիչ ուղարկելը:
Երկու գործոնով վավերացման խոցելիություններ
Հաշվի անվտանգությունը բարելավելու համար օգտատերերին միշտ խորհուրդ է տրվում միացնել 2FA (երկու գործոնով նույնականացում): Իրոք, սա արդյունավետ միջոց է կանխելու հարձակվողին մուտք գործել ծառայություն, եթե օգտագործողի հավատարմագրերը վտանգված են:
Բայց արդյոք նույնականացման երկրորդ գործոնի օգտագործումը միշտ երաշխավորում է հաշվի անվտանգությունը: 2FA-ի իրականացման ընթացքում կան անվտանգության հետևյալ խնդիրները.
- OTP կոդի կոպիտ որոնում (մեկանգամյա կոդեր): Չնայած գործողության պարզությանը, այնպիսի սխալներ, ինչպիսիք են OTP կոպիտ ուժի դեմ պաշտպանության բացակայությունը, նույնպես հանդիպում են խոշոր ընկերությունների կողմից. , .
- Թույլ գեներացման ալգորիթմ, օրինակ՝ հաջորդ ծածկագիրը կանխատեսելու հնարավորություն։
- Տրամաբանական սխալներ, ինչպիսիք են ձեր հեռախոսում ուրիշի OTP պահանջելու հնարավորությունը, նման են սա Shopify-ից:
MCS-ի դեպքում 2FA-ն իրականացվում է Google Authenticator-ի և . Արձանագրությունն ինքնին արդեն ժամանակի փորձարկվել է, բայց կիրառման կողմում կոդի ստուգման իրականացումը արժե ստուգել:
MCS 2FA-ն օգտագործվում է մի քանի վայրերում.
- Օգտատիրոջ իսկությունը հաստատելիս: Կա պաշտպանություն բիրտ ուժից. օգտագործողը միայն մի քանի փորձ է անում մուտքագրել մեկանգամյա գաղտնաբառ, այնուհետև մուտքագրումը որոշ ժամանակով արգելափակվում է: Սա արգելափակում է OTP-ի բիրտ ուժի ընտրության հնարավորությունը:
- 2FA-ն կատարելու համար անցանց պահուստային կոդեր ստեղծելիս, ինչպես նաև այն անջատելիս: Այստեղ ոչ մի կոպիտ ուժային պաշտպանություն չի իրականացվել, ինչը հնարավորություն է տվել, եթե հաշվի գաղտնաբառ ունեիք և ակտիվ նիստ ունեք, վերականգնել պահուստային կոդերը կամ ամբողջությամբ անջատել 2FA-ն:
Հաշվի առնելով, որ պահուստային կոդերը գտնվում էին լարային արժեքների նույն տիրույթում, ինչ ստեղծվել է OTP հավելվածի կողմից, կարճ ժամանակում կոդը գտնելու հնարավորությունը շատ ավելի մեծ էր:
«Burp: Intruder» գործիքի միջոցով 2FA-ն անջատելու համար OTP ընտրելու գործընթացը
Արդյունք
Ընդհանուր առմամբ, MCS-ն անվտանգ է որպես արտադրանք: Աուդիտի ընթացքում փորձարկող թիմը չկարողացավ մուտք ունենալ հաճախորդի VM-ներին և դրանց տվյալներին, և հայտնաբերված խոցելիությունները արագորեն շտկվեցին MCS թիմի կողմից:
Բայց այստեղ կարևոր է նշել, որ անվտանգությունը շարունակական աշխատանք է։ Ծառայությունները ստատիկ չեն, դրանք անընդհատ զարգանում են: Եվ անհնար է ամբողջովին առանց խոցելիության արտադրանք մշակել։ Բայց դուք կարող եք ժամանակին գտնել դրանք և նվազագույնի հասցնել դրանց կրկնության հավանականությունը:
Այժմ MCS-ում նշված բոլոր խոցելիությունները արդեն շտկվել են։ Իսկ նորերի թիվը նվազագույնի հասցնելու և դրանց կյանքի ժամկետը նվազեցնելու համար հարթակի թիմը շարունակում է անել հետևյալը.
- պարբերաբար աուդիտներ անցկացնել արտաքին ընկերությունների կողմից.
- աջակցել և զարգացնել մասնակցությունը;
- զբաղվել անվտանգությամբ. 🙂
Source: www.habr.com