MCS mākoņa platformas droŔības audits

MCS mākoņa platformas droŔības audits
SkyShip Dusk autors SeerLight

Jebkura pakalpojuma izveide obligāti ietver pastāvÄ«gu darbu pie droŔības. DroŔība ir nepārtraukts process, kas ietver pastāvÄ«gu produktu droŔības analÄ«zi un uzlaboÅ”anu, ziņu uzraudzÄ«bu par ievainojamÄ«bām un daudz ko citu. Ieskaitot auditus. Auditus veic gan iekŔēji, gan ārēji eksperti, kuri var radikāli palÄ«dzēt droŔības jomā, jo viņi nav iedziļinājuÅ”ies projektā un ir atvērti.

Raksts ir par Å”o vistieŔāko ārējo ekspertu viedokli, kuri palÄ«dzēja Mail.ru Cloud Solutions (MCS) komandai pārbaudÄ«t mākoņpakalpojumu, un par to, ko viņi atrada. Kā ā€œÄrējais spēksā€ MCS izvēlējās Digital Security uzņēmumu, kas pazÄ«stams ar savu augsto pieredzi informācijas droŔības aprindās. Un Å”ajā rakstā mēs analizēsim dažas interesantas ievainojamÄ«bas, kas tika atklātas ārējā audita ietvaros, lai, veidojot savu mākoņpakalpojumu, izvairÄ«tos no tā paÅ”a grābekļa.

ŠžŠæŠøсŠ°Š½ŠøŠµ ŠæрŠ¾Š“уŠŗтŠ°

Mail.ru mākoņa risinājumi (MCS) ir platforma virtuālās infrastruktÅ«ras veidoÅ”anai mākonÄ«. Tas ietver IaaS, PaaS un gatavu lietojumprogrammu attēlu tirgu izstrādātājiem. Ņemot vērā MCS arhitektÅ«ru, bija nepiecieÅ”ams pārbaudÄ«t produkta droŔību Ŕādās jomās:

  • virtualizācijas vides infrastruktÅ«ras aizsardzÄ«ba: hipervizori, marÅ”rutÄ“Å”ana, ugunsmÅ«ri;
  • klientu virtuālās infrastruktÅ«ras aizsardzÄ«ba: izolācija vienam no otra, ieskaitot tÄ«klu, privātos tÄ«klus SDN;
  • OpenStack un tā atvērtās sastāvdaļas;
  • S3 mÅ«su paÅ”u dizains;
  • IAM: vairāku Ä«rnieku projekti ar paraugu;
  • VÄ«zija (datorredze): API un ievainojamÄ«bas, strādājot ar attēliem;
  • tÄ«mekļa saskarne un klasiskie tÄ«mekļa uzbrukumi;
  • PaaS komponentu ievainojamÄ«bas;
  • Visu komponentu API.

Varbūt tas ir viss, kas ir būtiski tālākai vēsturei.

Kādi darbi tika veikti un kāpēc tas bija vajadzīgs?

DroŔības audita mērÄ·is ir identificēt ievainojamÄ«bas un konfigurācijas kļūdas, kas var izraisÄ«t personas datu noplÅ«di, sensitÄ«vas informācijas izmaiņas vai pakalpojumu pieejamÄ«bas traucējumus.

Darba laikā, kas ilgst vidēji 1-2 mēneÅ”us, auditori atkārto potenciālo uzbrucēju darbÄ«bas un meklē ievainojamÄ«bas izvēlētā servisa klienta un servera daļās. MCS mākoņplatformas audita kontekstā tika noteikti Ŕādi mērÄ·i:

  1. Autentifikācijas analÄ«ze pakalpojumā. IevainojamÄ«bas Å”ajā komponentā palÄ«dzētu nekavējoties iekļūt citu cilvēku kontos.
  2. Lomu modeļa un piekļuves kontroles izpēte starp dažādiem kontiem. Uzbrucējam iespēja piekļūt kāda cita virtuālajai maŔīnai ir vēlams mērÄ·is.
  3. Klienta puses ievainojamības. XSS/CSRF/CRLF/u.c. Vai ir iespējams uzbrukt citiem lietotājiem, izmantojot ļaunprātīgas saites?
  4. Servera puses ievainojamības: RCE un visa veida injekcijas (SQL/XXE/SSRF un tā tālāk). Servera ievainojamības parasti ir grūtāk atrast, taču tās noved pie daudzu lietotāju kompromisa vienlaikus.
  5. Lietotāja segmenta izolācijas analīze tīkla līmenī. Uzbrucējam izolācijas trūkums ievērojami palielina uzbrukuma virsmu pret citiem lietotājiem.
  6. Biznesa loÄ£ikas analÄ«ze. Vai ir iespējams maldināt uzņēmumus un izveidot virtuālās maŔīnas bez maksas?

Å ajā projektā darbs tika veikts pēc ā€œGray-boxā€ modeļa: auditori mijiedarbojās ar pakalpojumu ar parasto lietotāju privilēģijām, bet daļēji viņiem piederēja API pirmkods un bija iespēja precizēt detaļas ar izstrādātājiem. Tas parasti ir ērtākais un tajā paŔā laikā diezgan reālistisks darba modelis: uzbrucējs joprojām var savākt iekŔējo informāciju, tas ir tikai laika jautājums.

Atrastas ievainojamības

Pirms auditors uz nejauŔām vietām sāk sÅ«tÄ«t dažādas kravnesÄ«bas (uzbrukuma veikÅ”anai izmantoto kravu), ir jāsaprot, kā lietas darbojas un kāda funkcionalitāte tiek nodroÅ”ināta. Var Ŕķist, ka tas ir bezjēdzÄ«gs vingrinājums, jo lielākajā daļā pētÄ«to vietu ievainojamÄ«bu nebÅ«s. Bet tikai izpratne par lietojumprogrammas struktÅ«ru un tās darbÄ«bas loÄ£iku ļaus atrast vissarežģītākos uzbrukuma vektorus.

Ir svarÄ«gi atrast vietas, kas Ŕķiet aizdomÄ«gas vai kaut kādā ziņā ļoti atŔķiras no citām. Un Ŕādā veidā tika atrasta pirmā bÄ«stamā ievainojamÄ«ba.

IDOR

IDOR (Insecure Direct Object Reference) ievainojamības ir viena no visbiežāk sastopamajām biznesa loģikas ievainojamībām, kas ļauj vienam vai otram piekļūt objektiem, kuriem piekļuve faktiski nav atļauta. IDOR ievainojamības rada iespēju iegūt informāciju par dažādas kritiskuma pakāpes lietotāju.

Viena no IDOR iespējām ir veikt darbÄ«bas ar sistēmas objektiem (lietotājiem, bankas kontiem, precēm iepirkumu grozā), manipulējot ar piekļuves identifikatoriem Å”iem objektiem. Tas noved pie visneparedzamākajām sekām. Piemēram, iespēja nomainÄ«t naudas sÅ«tÄ«tāja kontu, caur kuru jÅ«s varat tos nozagt no citiem lietotājiem.

MCS gadÄ«jumā auditori tikko atklāja IDOR ievainojamÄ«bu, kas saistÄ«ta ar nedroÅ”iem identifikatoriem. Lietotāja personÄ«gajā kontā UUID identifikatori tika izmantoti, lai piekļūtu jebkuriem objektiem, kas, kā saka droŔības eksperti, Ŕķita iespaidÄ«gi nedroÅ”i (tas ir, aizsargāti no brutāla spēka uzbrukumiem). Bet dažām entÄ«tijām tika atklāts, ka informācijas iegÅ«Å”anai par lietojumprogrammas lietotājiem tiek izmantoti regulāri paredzami skaitļi. Domāju, ka var nojaust, ka bija iespējams mainÄ«t lietotāja ID par vienu, nosÅ«tÄ«t pieprasÄ«jumu vēlreiz un tādējādi iegÅ«t informāciju, apejot ACL (piekļuves kontroles saraksts, datu piekļuves noteikumi procesiem un lietotājiem).

Servera puses pieprasījuma viltoŔana (SSRF)

OpenSource produktu labā puse ir tā, ka tajos ir milzÄ«gs skaits forumu ar detalizētiem tehniskiem aprakstiem par problēmām, kas rodas, un, ja jums paveicas, arÄ« risinājuma aprakstu. Taču Å”ai monētai ir arÄ« otrā puse: detalizēti aprakstÄ«tas arÄ« zināmās ievainojamÄ«bas. Piemēram, OpenStack forumā ir brÄ«niŔķīgi ievainojamÄ«bu apraksti [XSS] Šø [SSRF], kuru nez kāpēc neviens nesteidzas labot.

IzplatÄ«ta lietojumprogrammu funkcionalitāte ir iespēja lietotājam nosÅ«tÄ«t serverim saiti, uz kuras serveris noklikŔķina (piemēram, lai lejupielādētu attēlu no noteikta avota). Ja droŔības rÄ«ki nefiltrē paÅ”as saites vai no servera lietotājiem atdotās atbildes, uzbrucēji var viegli izmantot Ŕādu funkcionalitāti.

SSRF ievainojamības var ievērojami veicināt uzbrukuma attīstību. Uzbrucējs var iegūt:

  • ierobežota piekļuve uzbrukuma lokālajam tÄ«klam, piemēram, tikai caur noteiktiem tÄ«kla segmentiem un izmantojot noteiktu protokolu;
  • pilnÄ«ga piekļuve lokālajam tÄ«klam, ja ir iespējama pazemināŔana no lietojumprogrammas lÄ«meņa uz transporta lÄ«meni, un lÄ«dz ar to pilnas slodzes pārvaldÄ«ba lietojumprogrammas lÄ«menÄ«;
  • piekļuve lokālo failu lasÄ«Å”anai serverÄ« (ja tiek atbalstÄ«ta shēma file:///);
  • Šø Š¼Š½Š¾Š³Š¾Šµ Š“руŠ³Š¾Šµ.

OpenStack jau sen ir zināma SSRF ievainojamÄ«ba, kas pēc bÅ«tÄ«bas ir "akla": sazinoties ar serveri, jÅ«s nesaņemat no tā atbildi, bet atkarÄ«bā no pieprasÄ«juma rezultāta saņemat dažāda veida kļūdas/aiztures. . Pamatojoties uz to, varat veikt portu skenÄ“Å”anu iekŔējā tÄ«klā esoÅ”ajos saimniekdatoros ar visām no tā izrietoÅ”ajām sekām, kuras nevajadzētu novērtēt par zemu. Piemēram, produktam var bÅ«t back-office API, kas ir pieejama tikai no korporatÄ«vā tÄ«kla. Izmantojot dokumentāciju (neaizmirstiet par iekŔējām personām), uzbrucējs var izmantot SSRF, lai piekļūtu iekŔējām metodēm. Piemēram, ja jums kaut kā izdevās iegÅ«t aptuvenu noderÄ«go URL sarakstu, tad, izmantojot SSRF, varat tos iziet cauri un izpildÄ«t pieprasÄ«jumu - nosacÄ«ti runājot, pārskaitÄ«t naudu no konta uz kontu vai mainÄ«t limitus.

Å Ä« nav pirmā reize, kad OpenStack tiek atklāta SSRF ievainojamÄ«ba. Agrāk VM ISO attēlus bija iespējams lejupielādēt no tieŔās saites, kas arÄ« izraisÄ«ja lÄ«dzÄ«gas sekas. Å Ä« funkcija tagad ir noņemta no OpenStack. AcÄ«mredzot sabiedrÄ«ba to uzskatÄ«ja par vienkārŔāko un uzticamāko problēmas risinājumu.

Un Å”is publiski pieejams pārskats no pakalpojuma HackerOne (h1), vairs neakla SSRF izmantoÅ”ana ar iespēju nolasÄ«t gadÄ«jumu metadatus nodroÅ”ina saknes piekļuvi visai Shopify infrastruktÅ«rai.

MCS SSRF ievainojamÄ«bas tika atklātas divās vietās ar lÄ«dzÄ«gu funkcionalitāti, taču tās bija gandrÄ«z neiespējami izmantot ugunsmÅ«ru un citu aizsardzÄ«bas lÄ«dzekļu dēļ. Tā vai citādi MCS komanda Å”o problēmu atrisināja, negaidot kopienu.

XSS tā vietā, lai ielādētu čaulas

Neskatoties uz simtiem rakstītu pētījumu, gadu no gada XSS (cross-site scripting) uzbrukums joprojām ir visvairāk bieži sastopams tīmekļa ievainojamība (vai uzbrukums?).

Failu augÅ”upielāde ir iecienÄ«ta vieta jebkuram droŔības pētniekam. Bieži vien izrādās, ka jÅ«s varat ielādēt patvaļīgu skriptu (asp/jsp/php) un izpildÄ«t OS komandas, pentesteru terminoloÄ£ijā - ā€œload shellā€. Taču Ŕādu ievainojamÄ«bu popularitāte darbojas abos virzienos: tās tiek atcerētas un pret tām tiek izstrādāti lÄ«dzekļi, tā ka pēdējā laikā varbÅ«tÄ«ba ā€œielādēt čauluā€ mēdz bÅ«t nulle.

Uzbrucēju komandai (kuru pārstāv Digital Security) paveicās. Labi, MCS servera pusē tika pārbaudīts lejupielādēto failu saturs, bija atļauti tikai attēli. Bet SVG arī ir bilde. Kā SVG attēli var būt bīstami? Jo jūs varat iegult tajos JavaScript fragmentus!

Izrādījās, ka lejupielādētie faili ir pieejami visiem MCS servisa lietotājiem, kas nozīmē, ka ir iespējams uzbrukt citiem mākoņa lietotājiem, proti, administratoriem.

MCS mākoņa platformas droŔības audits
Piemērs XSS uzbrukumam pikŔķerÄ“Å”anas pieteikÅ”anās veidlapai

XSS uzbrukuma izmantoÅ”anas piemēri:

  • Kāpēc mēģināt nozagt sesiju (jo Ä«paÅ”i tāpēc, ka tagad HTTP-Only sÄ«kfaili ir visur, aizsargāti pret zādzÄ«bām, izmantojot js skriptus), ja ielādētais skripts var nekavējoties piekļūt resursa API? Å ajā gadÄ«jumā kravnesÄ«ba var izmantot XHR pieprasÄ«jumus, lai mainÄ«tu servera konfigurāciju, piemēram, pievienotu uzbrucēja publisko SSH atslēgu un iegÅ«tu SSH piekļuvi serverim.
  • Ja CSP politika (satura aizsardzÄ«bas politika) aizliedz ievadÄ«t JavaScript, uzbrucējs var iztikt bez tā. Izmantojot tÄ«ru HTML, izveidojiet viltotu vietnes pieteikÅ”anās veidlapu un nozagiet administratora paroli, izmantojot Å”o uzlaboto pikŔķerÄ“Å”anas metodi: lietotāja pikŔķerÄ“Å”anas lapa nonāk tajā paŔā URL, un lietotājam to ir grÅ«tāk noteikt.
  • Beidzot uzbrucējs var noorganizēt klienta DoS ā€” iestatÄ«t sÄ«kfailus, kas lielāki par 4 KB. Lietotājam tikai vienu reizi ir jāatver saite, un visa vietne kļūst nepieejama, lÄ«dz lietotājs domā Ä«paÅ”i notÄ«rÄ«t pārlÅ«kprogrammu: vairumā gadÄ«jumu tÄ«mekļa serveris atsakās pieņemt Ŕādu klientu.

ApskatÄ«sim cita atklātā XSS piemēru, Å”oreiz ar gudrāku izmantoÅ”anu. MCS pakalpojums ļauj apvienot ugunsmÅ«ra iestatÄ«jumus grupās. Grupas nosaukums bija vieta, kur tika atklāts XSS. Tā Ä«patnÄ«ba bija tāda, ka vektors netika aktivizēts uzreiz, nevis skatot noteikumu sarakstu, bet gan dzÄ“Å”ot grupu:

MCS mākoņa platformas droŔības audits

Tas ir, scenārijs izrādÄ«jās Ŕāds: uzbrucējs izveido ugunsmÅ«ra kārtulu, kuras nosaukumā ir ā€œloadā€, administrators pēc kāda laika to pamana un uzsāk dzÄ“Å”anas procesu. Un Å”eit darbojas ļaunprātÄ«gais JS.

MCS izstrādātājiem, lai aizsargātu pret XSS lejupielādētajos SVG attēlos (ja tos nevar pamest), Digital Security komanda ieteica:

  • Novietojiet lietotāju augÅ”upielādētos failus atseviŔķā domēnā, kam nav nekāda sakara ar ā€œsÄ«kfailiemā€. Skripts tiks izpildÄ«ts cita domēna kontekstā un neradÄ«s draudus MCS.
  • Servera HTTP atbildē nosÅ«tiet galveni "Satura izvietojums: pielikums". Pēc tam faili tiks lejupielādēti pārlÅ«kprogrammā un netiks izpildÄ«ti.

Turklāt tagad izstrādātājiem ir pieejami daudzi veidi, kā mazināt XSS izmantoŔanas riskus:

  • izmantojot karogu ā€œTikai HTTPā€, varat padarÄ«t sesijas ā€œCookiesā€ galvenes nepieejamas ļaunprātÄ«gam JavaScript;
  • pareizi Ä«stenota CSP politika uzbrucējam bÅ«s daudz grÅ«tāk izmantot XSS;
  • mÅ«sdienu veidņu dzinēji, piemēram, Angular vai React, automātiski sanitizē lietotāja datus pirms to izvadÄ«Å”anas lietotāja pārlÅ«kprogrammā.

Divfaktoru autentifikācijas ievainojamības

Lai uzlabotu konta droŔību, lietotājiem vienmēr ir ieteicams iespējot 2FA (divu faktoru autentifikāciju). PatieŔām, tas ir efektÄ«vs veids, kā novērst uzbrucēja piekļuvi pakalpojumam, ja lietotāja akreditācijas dati ir apdraudēti.

Bet vai otrā autentifikācijas faktora izmantoÅ”ana vienmēr garantē konta droŔību? IevieÅ”ot 2FA, pastāv Ŕādas droŔības problēmas:

  • Brutāla OTP koda meklÄ“Å”ana (vienreizēji kodi). Neskatoties uz darbÄ«bas vienkārŔību, lielie uzņēmumi saskaras arÄ« ar tādām kļūdām kā aizsardzÄ«bas trÅ«kums pret OTP brutālu spēku: VājÅ” futrālis, Facebook gadÄ«jums.
  • Vāja Ä£enerÄ“Å”anas algoritms, piemēram, spēja paredzēt nākamo kodu.
  • Šādas loÄ£iskas kļūdas, piemēram, iespēja pieprasÄ«t kāda cita OTP jÅ«su tālrunÄ« tas bija no Shopify.

MCS gadÄ«jumā 2FA tiek ieviests, pamatojoties uz Google Authenticator un Duo. Pats protokols jau ir pārbaudÄ«ts laika gaitā, taču ir vērts pārbaudÄ«t koda verifikācijas ievieÅ”anu lietojumprogrammas pusē.

MCS 2FA tiek izmantots vairākās vietās:

  • Veicot lietotāja autentifikāciju. Ir aizsardzÄ«ba pret brutālu spēku: lietotājam ir tikai daži mēģinājumi ievadÄ«t vienreizēju paroli, pēc tam ievade kādu laiku tiek bloķēta. Tas bloķē iespēju OTP atlasÄ«t ar brutālu spēku.
  • Ä¢enerējot bezsaistes rezerves kodus, lai veiktu 2FA, kā arÄ« to atspējojot. Å eit netika ieviesta aizsardzÄ«ba pret brutālu spēku, kas ļāva, ja jums bija konta parole un aktÄ«va sesija, atjaunot rezerves kodus vai pilnÄ«bā atspējot 2FA.

Ņemot vērā, ka rezerves kodi atradās tajā paŔā virkņu vērtÄ«bu diapazonā, ko Ä£enerēja OTP lietojumprogramma, iespēja Ä«sā laikā atrast kodu bija daudz lielāka.

MCS mākoņa platformas droŔības audits
OTP atlases process, lai atspējotu 2FA, izmantojot rÄ«ku ā€œBurp: Intruderā€.

Piedzīvojiet efektīvu rezultātu spēku

Kopumā Ŕķiet, ka MCS kā produkts ir droÅ”s. Audita laikā pentestÄ“Å”anas komanda nevarēja piekļūt klientu virtuālajām maŔīnām un to datiem, un MCS komanda ātri izlaboja atrastās ievainojamÄ«bas.

Bet Å”eit ir svarÄ«gi atzÄ«mēt, ka droŔība ir nepārtraukts darbs. Pakalpojumi nav statiski, tie pastāvÄ«gi attÄ«stās. Un nav iespējams izstrādāt produktu pilnÄ«gi bez ievainojamÄ«bām. Bet jÅ«s varat tos atrast savlaicÄ«gi un samazināt to atkārtoÅ”anās iespēju.

Tagad visas minētās ievainojamÄ«bas MCS jau ir novērstas. Un, lai samazinātu jaunu skaitu un samazinātu to kalpoÅ”anas laiku, platformas komanda turpina rÄ«koties Ŕādi:

Avots: www.habr.com

Pievieno komentāru