na SeerLight
Kujenga huduma yoyote lazima ni pamoja na kazi ya mara kwa mara juu ya usalama. Usalama ni mchakato endelevu unaojumuisha uchanganuzi na uboreshaji wa mara kwa mara wa usalama wa bidhaa, ufuatiliaji wa habari kuhusu udhaifu na mengine mengi. Ikiwa ni pamoja na ukaguzi. Ukaguzi unafanywa ndani na wataalam wa nje, ambao wanaweza kusaidia kwa kiasi kikubwa usalama kwa sababu hawajazama katika mradi huo na wana mawazo wazi.
Nakala hii inahusu mtazamo huu wa moja kwa moja wa wataalam wa nje ambao walisaidia timu ya Mail.ru Cloud Solutions (MCS) kujaribu huduma ya wingu, na kuhusu walichopata. Kama "nguvu ya nje," MCS ilichagua kampuni ya Digital Security, inayojulikana kwa ujuzi wake wa juu katika duru za usalama wa habari. Na katika nakala hii tutachambua udhaifu fulani unaovutia unaopatikana kama sehemu ya ukaguzi wa nje - ili uepuke safu sawa wakati unaunda huduma yako ya wingu.
ΠΠΏΠΈΡΠ°Π½ΠΈΠ΅ ΠΏΡΠΎΠ΄ΡΠΊΡΠ°
ni jukwaa la kujenga miundombinu ya mtandaoni katika wingu. Inajumuisha IaaS, PaaS, na soko la picha za programu zilizotengenezwa tayari kwa wasanidi programu. Kwa kuzingatia usanifu wa MCS, ilikuwa ni lazima kuangalia usalama wa bidhaa katika maeneo yafuatayo:
- kulinda miundombinu ya mazingira ya virtualization: hypervisors, routing, firewalls;
- ulinzi wa miundombinu halisi ya wateja: kutengwa kutoka kwa kila mmoja, ikiwa ni pamoja na mtandao, mitandao ya kibinafsi katika SDN;
- OpenStack na vipengele vyake wazi;
- S3 ya muundo wetu wenyewe;
- IAM: miradi ya wapangaji wengi na mfano wa kuigwa;
- Maono (maono ya kompyuta): API na udhaifu wakati wa kufanya kazi na picha;
- interface ya wavuti na mashambulizi ya mtandao ya classic;
- udhaifu wa vipengele vya PaaS;
- API ya vipengele vyote.
Labda hiyo ndiyo yote ambayo ni muhimu kwa historia zaidi.
Ni aina gani ya kazi iliyofanywa na kwa nini ilihitajika?
Ukaguzi wa usalama unalenga kubaini udhaifu na hitilafu za usanidi ambazo zinaweza kusababisha kuvuja kwa data ya kibinafsi, urekebishaji wa taarifa nyeti, au kukatizwa kwa upatikanaji wa huduma.
Wakati wa kazi, ambayo hudumu kwa wastani wa miezi 1-2, wakaguzi hurudia vitendo vya washambuliaji wanaowezekana na kutafuta udhaifu katika sehemu za mteja na seva za huduma iliyochaguliwa. Katika muktadha wa ukaguzi wa jukwaa la wingu la MCS, malengo yafuatayo yalitambuliwa:
- Uchambuzi wa uthibitishaji katika huduma. Udhaifu katika kipengele hiki utasaidia kuingia katika akaunti za watu wengine mara moja.
- Kusoma mfano wa kuigwa na udhibiti wa ufikiaji kati ya akaunti tofauti. Kwa mshambuliaji, uwezo wa kufikia mashine pepe ya mtu mwingine ni lengo linalohitajika.
- Udhaifu wa upande wa mteja. XSS/CSRF/CRLF/etc. Je, inawezekana kushambulia watumiaji wengine kupitia viungo hasidi?
- Athari za upande wa seva: RCE na aina zote za sindano (SQL/XXE/SSRF na kadhalika). Athari za seva kwa ujumla ni ngumu zaidi kupata, lakini husababisha maelewano ya watumiaji wengi mara moja.
- Uchambuzi wa kutengwa kwa sehemu ya watumiaji katika kiwango cha mtandao. Kwa mshambulizi, ukosefu wa kutengwa huongeza sana uso wa mashambulizi dhidi ya watumiaji wengine.
- Uchambuzi wa mantiki ya biashara. Je, inawezekana kudanganya biashara na kuunda mashine pepe bila malipo?
Katika mradi huu, kazi ilifanywa kulingana na mfano wa "Sanduku la Grey": wakaguzi waliingiliana na huduma na marupurupu ya watumiaji wa kawaida, lakini walikuwa na msimbo wa chanzo wa API na walipata fursa ya kufafanua maelezo na watengenezaji. Hii ni kawaida rahisi zaidi, na wakati huo huo mfano halisi wa kazi: taarifa za ndani bado zinaweza kukusanywa na mshambuliaji, ni suala la muda tu.
Udhaifu umepatikana
Kabla ya mkaguzi kuanza kutuma mizigo mbalimbali (mzigo unaotumika kutekeleza shambulio hilo) kwa maeneo ya nasibu, ni muhimu kuelewa jinsi mambo yanavyofanya kazi na ni utendaji gani unaotolewa. Inaweza kuonekana kuwa hii ni zoezi lisilo na maana, kwa sababu katika maeneo mengi yaliyojifunza hakutakuwa na udhaifu. Lakini kuelewa tu muundo wa maombi na mantiki ya uendeshaji wake itafanya iwezekanavyo kupata vectors ngumu zaidi ya mashambulizi.
Ni muhimu kupata maeneo ambayo yanaonekana kuwa ya kutiliwa shaka au ni tofauti sana na wengine kwa namna fulani. Na hatari ya kwanza ya hatari ilipatikana kwa njia hii.
IDOR
IDOR (Marejeleo ya Kitu cha Moja kwa Moja Isiyo salama) ni mojawapo ya udhaifu wa kawaida katika mantiki ya biashara, ambayo inaruhusu mmoja au mwingine kupata ufikiaji wa vitu ambavyo ufikiaji hauruhusiwi. Udhaifu wa IDOR huunda uwezekano wa kupata taarifa kuhusu mtumiaji wa viwango tofauti vya uhakiki.
Moja ya chaguo za IDOR ni kufanya vitendo na vitu vya mfumo (watumiaji, akaunti za benki, vitu kwenye gari la ununuzi) kwa kuendesha vitambulisho vya upatikanaji wa vitu hivi. Hii inasababisha matokeo yasiyotabirika zaidi. Kwa mfano, uwezekano wa kuchukua nafasi ya akaunti ya mtumaji wa fedha, kwa njia ambayo unaweza kuiba kutoka kwa watumiaji wengine.
Kwa upande wa MCS, wakaguzi wamegundua uwezekano wa kuathiriwa wa IDOR unaohusishwa na vitambulishi visivyo salama. Katika akaunti ya kibinafsi ya mtumiaji, vitambulishi vya UUID vilitumiwa kufikia vitu vyovyote, ambavyo vilionekana, kama wataalam wa usalama wanavyosema, kutokuwa na usalama kwa njia ya kuvutia (hiyo ni, kulindwa dhidi ya mashambulizi ya kikatili). Lakini kwa vyombo fulani, iligunduliwa kuwa nambari za kawaida zinazotabirika hutumiwa kupata habari kuhusu watumiaji wa programu. Nadhani unaweza kukisia kuwa iliwezekana kubadilisha kitambulisho cha mtumiaji kimoja, kutuma ombi tena na hivyo kupata maelezo kwa kupita ACL (orodha ya udhibiti wa ufikiaji, sheria za ufikiaji wa data kwa michakato na watumiaji).
Ughushi wa Ombi la Upande wa Seva (SSRF)
Jambo jema kuhusu bidhaa za OpenSource ni kwamba wana idadi kubwa ya mabaraza yenye maelezo ya kina ya kiufundi ya matatizo yanayotokea na, ikiwa una bahati, maelezo ya suluhisho. Lakini sarafu hii ina upande wa nyuma: udhaifu unaojulikana pia unaelezwa kwa undani. Kwa mfano, kuna maelezo ya ajabu ya udhaifu kwenye jukwaa la OpenStack ΠΈ , ambayo kwa sababu fulani hakuna mtu anaye haraka kurekebisha.
Utendaji wa kawaida wa programu ni uwezo wa mtumiaji kutuma kiunga kwa seva, ambayo seva inabofya (kwa mfano, kupakua picha kutoka kwa chanzo maalum). Ikiwa zana za usalama hazichuji viungo vyenyewe au majibu yanayoletwa kutoka kwa seva kwa watumiaji, utendakazi kama huo unaweza kutumiwa na washambuliaji kwa urahisi.
Udhaifu wa SSRF unaweza kuendeleza sana maendeleo ya shambulio. Mshambulizi anaweza kupata:
- ufikiaji mdogo wa mtandao wa ndani ulioshambuliwa, kwa mfano, tu kupitia sehemu fulani za mtandao na kutumia itifaki fulani;
- upatikanaji kamili wa mtandao wa ndani, ikiwa kupungua kutoka ngazi ya maombi hadi ngazi ya usafiri inawezekana na, kwa sababu hiyo, usimamizi kamili wa mzigo katika ngazi ya maombi;
- ufikiaji wa kusoma faili za kawaida kwenye seva (ikiwa faili:/// mpango unasaidiwa);
- na mengi zaidi.
Athari ya SSRF imejulikana kwa muda mrefu katika OpenStack, ambayo ni "kipofu" kwa asili: unapowasiliana na seva, hupokea jibu kutoka kwayo, lakini unapokea aina tofauti za makosa / ucheleweshaji, kulingana na matokeo ya ombi. . Kulingana na hili, unaweza kufanya uchunguzi wa bandari kwenye wasimamizi kwenye mtandao wa ndani, na matokeo yote yanayofuata ambayo haipaswi kupunguzwa. Kwa mfano, bidhaa inaweza kuwa na API ya ofisi ya nyuma ambayo inapatikana tu kutoka kwa mtandao wa shirika. Ukiwa na hati (usisahau kuhusu watu wa ndani), mshambulizi anaweza kutumia SSRF kufikia mbinu za ndani. Kwa mfano, ikiwa kwa namna fulani uliweza kupata orodha ya takriban ya URL muhimu, basi kwa kutumia SSRF unaweza kuzipitia na kutekeleza ombi - kwa kiasi, kuhamisha pesa kutoka akaunti hadi akaunti au kubadilisha mipaka.
Hii si mara ya kwanza kwa athari ya SSRF kugunduliwa katika OpenStack. Katika siku za nyuma, iliwezekana kupakua picha za VM ISO kutoka kwa kiungo cha moja kwa moja, ambacho pia kilisababisha matokeo sawa. Kipengele hiki sasa kimeondolewa kwenye OpenStack. Inavyoonekana, jamii ilizingatia hili kuwa suluhisho rahisi na la kutegemewa kwa shida.
Na ndani ripoti inayopatikana hadharani kutoka kwa huduma ya HackerOne (h1), utumiaji wa SSRF ambayo si kipofu tena yenye uwezo wa kusoma metadata ya mfano husababisha ufikiaji wa Mizizi kwa miundombinu yote ya Shopify.
Katika MCS, udhaifu wa SSRF uligunduliwa katika sehemu mbili zenye utendakazi sawa, lakini ulikuwa karibu kutowezekana kutumia kutokana na ngome na ulinzi mwingine. Kwa njia moja au nyingine, timu ya MCS ilisuluhisha tatizo hili hata hivyo, bila kusubiri jumuiya.
XSS badala ya kupakia makombora
Licha ya mamia ya tafiti zilizoandikwa, shambulio la mwaka baada ya mwaka la XSS (uandikaji wa tovuti tofauti) bado ndilo kubwa zaidi kuathirika kwa wavuti (au ?).
Upakiaji wa faili ni mahali panapopendwa na mtafiti yeyote wa usalama. Mara nyingi zinageuka kuwa unaweza kupakia hati ya kiholela (asp/jsp/php) na kutekeleza amri za OS, katika istilahi ya pentesters - "ganda la mzigo". Lakini umaarufu wa udhaifu huo hufanya kazi kwa pande zote mbili: hukumbukwa na tiba zinatengenezwa dhidi yao, ili hivi karibuni uwezekano wa "kupakia shell" huwa na sifuri.
Timu ya kushambulia (iliyowakilishwa na Digital Security) ilikuwa na bahati. Sawa, katika MCS kwenye upande wa seva maudhui ya faili zilizopakuliwa yalikaguliwa, picha pekee ndizo ziliruhusiwa. Lakini SVG pia ni picha. Picha za SVG zinawezaje kuwa hatari? Kwa sababu unaweza kupachika vijisehemu vya JavaScript ndani yake!
Ilibadilika kuwa faili zilizopakuliwa zinapatikana kwa watumiaji wote wa huduma ya MCS, ambayo ina maana kwamba inawezekana kushambulia watumiaji wengine wa wingu, yaani wasimamizi.
Mfano wa shambulio la XSS kwenye fomu ya kuingia ya hadaa
Mifano ya unyonyaji wa shambulio la XSS:
- Kwa nini ujaribu kuiba kipindi (haswa kwa kuwa sasa vidakuzi vya HTTP-Pekee viko kila mahali, vimelindwa dhidi ya wizi kwa kutumia maandishi ya js), ikiwa hati iliyopakiwa inaweza kufikia API ya rasilimali mara moja? Katika hali hii, upakiaji unaweza kutumia maombi ya XHR kubadilisha usanidi wa seva, kwa mfano, kuongeza kitufe cha umma cha SSH na kupata ufikiaji wa SSH kwa seva.
- Ikiwa sera ya CSP (sera ya ulinzi wa maudhui) inakataza JavaScript isitungwe, mshambulizi anaweza kuishi bila hiyo. Kwa kutumia HTML safi, tengeneza fomu ya kuingia kwenye tovuti ghushi na uibe nenosiri la msimamizi kupitia ulaghai huu wa hali ya juu: ukurasa wa kuhadaa wa mtumiaji huishia kwenye URL sawa, na ni vigumu zaidi kwa mtumiaji kuugundua.
- Hatimaye, mshambuliaji anaweza kupanga β weka Vidakuzi vikubwa kuliko KB 4. Mtumiaji anahitaji tu kufungua kiungo mara moja, na tovuti nzima inakuwa haipatikani hadi mtumiaji anafikiri kusafisha hasa kivinjari: katika hali nyingi, seva ya wavuti itakataa kukubali mteja kama huyo.
Wacha tuangalie mfano wa XSS nyingine iliyogunduliwa, wakati huu na unyonyaji wa busara zaidi. Huduma ya MCS hukuruhusu kuchanganya mipangilio ya ngome katika vikundi. Jina la kikundi ndipo XSS iligunduliwa. Upekee wake ulikuwa kwamba vekta haikuanzishwa mara moja, sio wakati wa kutazama orodha ya sheria, lakini wakati wa kufuta kikundi:
Hiyo ni, hali iligeuka kuwa ifuatayo: mshambulizi huunda sheria ya firewall na "mzigo" kwa jina, msimamizi anatambua baada ya muda na kuanzisha mchakato wa kufuta. Na hapa ndipo JS hasidi inafanya kazi.
Ili wasanidi programu wa MCS walinde dhidi ya XSS katika picha za SVG zilizopakiwa (ikiwa haziwezi kuachwa), timu ya Usalama wa Dijiti ilipendekeza:
- Weka faili zilizopakiwa na watumiaji kwenye kikoa tofauti ambacho hakihusiani na "vidakuzi". Hati itatekelezwa katika muktadha wa kikoa tofauti na haitaleta tishio kwa MCS.
- Katika jibu la HTTP la seva, tuma kichwa cha "Maudhui-mwenye: kiambatisho". Kisha faili zitapakuliwa na kivinjari na hazitatekelezwa.
Kwa kuongezea, sasa kuna njia nyingi zinazopatikana kwa wasanidi programu ili kupunguza hatari za unyonyaji wa XSS:
- kwa kutumia alama ya "HTTP Pekee", unaweza kufanya vichwa vya kipindi "Vidakuzi" visifikiwe na JavaScript hasidi;
- itafanya kuwa vigumu zaidi kwa mshambuliaji kutumia XSS;
- injini za violezo vya kisasa kama vile Angular au React husafisha kiotomatiki data ya mtumiaji kabla ya kuitoa kwa kivinjari cha mtumiaji.
Athari za uthibitishaji wa vipengele viwili
Ili kuboresha usalama wa akaunti, watumiaji wanashauriwa kila mara kuwezesha 2FA (uthibitishaji wa vipengele viwili). Hakika, hii ni njia mwafaka ya kuzuia mvamizi kupata ufikiaji wa huduma ikiwa kitambulisho cha mtumiaji kimeingiliwa.
Lakini je, kutumia kipengele cha pili cha uthibitishaji daima huhakikisha usalama wa akaunti? Kuna masuala yafuatayo ya usalama katika utekelezaji wa 2FA:
- Utafutaji wa nguvu wa msimbo wa OTP (misimbo ya mara moja). Licha ya unyenyekevu wa operesheni, makosa kama vile ukosefu wa ulinzi dhidi ya nguvu ya kikatili ya OTP pia hukutana na kampuni kubwa: , .
- Algorithm ya kizazi dhaifu, kwa mfano uwezo wa kutabiri nambari inayofuata.
- Hitilafu za kimantiki, kama vile uwezo wa kuomba OTP ya mtu mwingine kwenye simu yako, kama hii kutoka kwa Shopify.
Kwa upande wa MCS, 2FA inatekelezwa kulingana na Kithibitishaji cha Google na . Itifaki yenyewe tayari imejaribiwa kwa wakati, lakini utekelezaji wa uthibitishaji wa msimbo kwenye upande wa maombi inafaa kukaguliwa.
MCS 2FA inatumika katika maeneo kadhaa:
- Wakati wa kuthibitisha mtumiaji. Kuna ulinzi dhidi ya nguvu ya kikatili: mtumiaji ana majaribio machache tu ya kuingiza nenosiri la wakati mmoja, kisha ingizo limezuiwa kwa muda. Hii inazuia uwezekano wa uteuzi wa nguvu-katili wa OTP.
- Wakati wa kutengeneza misimbo ya kuhifadhi nakala za nje ya mtandao ili kutekeleza 2FA, na pia kuizima. Hapa, hakuna ulinzi wa nguvu wa kikatili uliotekelezwa, ambayo ilifanya iwezekane, ikiwa ulikuwa na nenosiri la akaunti na kipindi kinachotumika, kuunda upya misimbo ya chelezo au kuzima 2FA kabisa.
Kwa kuzingatia kwamba misimbo ya hifadhi rudufu ilikuwa katika safu sawa ya maadili ya kamba kama yale yaliyotolewa na programu ya OTP, nafasi ya kupata msimbo kwa muda mfupi ilikuwa kubwa zaidi.
Mchakato wa kuchagua OTP ili kuzima 2FA kwa kutumia zana ya "Burp: Intruder".
Matokeo
Kwa ujumla, MCS inaonekana kuwa salama kama bidhaa. Wakati wa ukaguzi, timu ya wachunguzi haikuweza kufikia VM za mteja na data zao, na udhaifu uliopatikana ulisahihishwa haraka na timu ya MCS.
Lakini hapa ni muhimu kutambua kwamba usalama ni kazi inayoendelea. Huduma sio tuli, zinaendelea kubadilika. Na haiwezekani kuendeleza bidhaa kabisa bila udhaifu. Lakini unaweza kuzipata kwa wakati na kupunguza uwezekano wa kujirudia.
Sasa udhaifu wote uliotajwa katika MCS tayari umerekebishwa. Na ili kuweka idadi ya wapya kwa kiwango cha chini na kupunguza maisha yao, timu ya jukwaa inaendelea kufanya hivi:
- kufanya ukaguzi wa mara kwa mara na makampuni ya nje;
- kusaidia na kuendeleza ushiriki;
- kujihusisha na usalama. π
Chanzo: mapenzi.com