ProHoster > Blog > Administrim > Auditi i sigurisë së platformës cloud MCS

Auditi i sigurisë së platformës cloud MCS

Auditi i sigurisë së platformës cloud MCS
SkyShip Dusk nga SeerLight

Ndërtesa e çdo shërbimi përfshin patjetër punën e vazhdueshme mbi sigurinë. Siguria është një proces i vazhdueshëm që përfshin analiza dhe përmirësim të vazhdueshëm të mbrojtjes së produktit, monitorimin e lajmeve për dobësitë dhe shumë të tjera. Po ashtu, janë auditimet. Auditimet kryhen si nga forcat e brendshme, ashtu edhe nga ekspertë të jashtëm, të cilët mund të ndihmojnë ndjeshëm në siguri, pasi nuk janë të angazhuar në projekt dhe kanë një pikëpamje pa paragjykime.

Ky artikull flet pikërisht për këtë pikëpamje pa paragjykime të ekspertëve të jashtëm, të cilët ndihmuan ekipin e Mail.ru Cloud Solutions (MCS) të testonin shërbimin cloud dhe për atë që gjetën. Si 'forcat e jashtme', MCS zgjodhi kompaninë Digital Security, e njohur për ekspertizën e saj të lartë në qarqet e sigurisë. Në këtë artikull, ne do të shqyrtojmë disa dobësi interesante që janë gjetur gjatë auditimit të jashtëm - për t'ju ndihmuar të shmangni të njëjtat gabime kur të krijoni shërbimin tuaj cloud.

PĂ«rshkrimi i produktit

Mail.ru Cloud Solutions (MCS) është një platformë për ndërtimin e infrastrukturës virtuale në cloud. Ajo përfshin IaaS, PaaS, dhe një treg të gatshëm me imazhe aplikacionesh për zhvilluesit. Duke marrë në konsideratë arkitekturën MCS, është e nevojshme të kontrollohet siguria e produktit në këto drejtime: mbrojtja e infrastrukturës së mjedisit virtualizues: hipervizorët, rrjetëzimi, firewall-et;

  • mbrojtja e infrastrukturĂ«s virtuale tĂ« klientĂ«ve: izolimi nga njĂ«ri-tjetri, duke pĂ«rfshirĂ« rrjetin, rrjetet private nĂ« SDN;
  • OpenStack dhe komponentĂ«t e tij tĂ« hapur;
  • S3 e zhvilluar vetĂ«;
  • IAM: projekte multinantĂ«se me model rolet;
  • Vision (shikimi i makinĂ«s): API dhe dobĂ«si gjatĂ« punĂ«s me imazhe;
  • ndĂ«rfaqja web dhe sulmet klasike mbi web-in;
  • dobĂ«sitĂ« e komponentĂ«ve PaaS;
  • API tĂ« tĂ« gjitha komponentĂ«ve.
  • Mund tĂ« themi se nga tĂ« gjitha informacionet e rĂ«ndĂ«sishme pĂ«r historinĂ« nĂ« vazhdim - kjo Ă«shtĂ« gjithçka.

ÇfarĂ« lloj punĂ«sh u kryen dhe pĂ«rse janĂ« tĂ« nevojshme?

Auditimi i sigurisë është i orientuar për të zbuluar dobësi dhe gabime konfiguruese që mund të çojnë në humbjen e të dhënave personale, modifikimin e informacionit të ndjeshëm ose në shkeljen e disponueshmërisë së shërbimeve.

Auditi i sigurisë ka për qëllim identifikimin e dobësive dhe gabimeve të konfigurimit që mund të çojnë në rrjedhjen e të dhënave personale, modifikimin e informacionit të ndjeshëm ose në shkeljen e disponueshmërisë së shërbimeve.

Gjatë punimeve, që zgjatën mesatarisht 1-2 muaj, auditorët përsërisnin veprimet e potencialëve sulmues dhe kërkonin dobësi në pjesën e klientit dhe serverit të shërbimit të zgjedhur. Në kontekstin e auditimit të platformës në re MCS u përcaktuan këto qëllime:

  1. Analiza e autentifikimit në shërbim. Dobësitë në këtë komponent do të ndihmonin menjëherë në aksesin në llogaritë e të tjerëve.
  2. Studimi i modelit të roleve dhe ndarjes së qasjes mes llogarive të ndryshme. Për një sulmues, mundësia për të aksesuar makinën virtuale të dikujt tjetër është një qëllim i dëshiruar.
  3. Dobësitë e pjesës së klientit. XSS/CSRF/CRLF/etj. A mund të ketë mundësi për të sulmuar përdorues të tjerë nëpërmjet lidhjeve të dëmshme?
  4. Dobësitë e pjesës serverike: RCE dhe çdo formë injeksionesh (SQL/XXE/SSRF e kështu me radhë). Dobësitë serverike, zakonisht, janë më të vështira për t'u gjetur, por ato çojnë në kompromisimin e një numri të madh përdoruesish.
  5. Analiza e izolimit të segmenteve të përdoruesve në nivelin e rrjetit. Për një sulmues, mungesa e izolimit rrit ndjeshëm sipërfaqen e sulmit ndaj përdoruesve të tjerë.
  6. Analiza e logjikës biznesore. A është e mundur të manipulohet biznesi dhe të krijohen makina virtuale falas?

Në këtë projekt, punët janë realizuar sipas modelit "Gray-box": auditorët interaguan me shërbimin me privilegje të përdoruesve të zakonshëm, por pjesërisht kishin tekstet burimore të API-së dhe kishin mundësi të saktësonin detajet me zhvilluesit. Zakonisht, ky është modeli më i përshtatshëm dhe gjithashtu mjaft realist i punës: informacioni i brendshëm mund të merret nga një sulmues, është vetëm një çështje kohe.

Dobësitë e gjetura

Para se auditorët të fillojnë të dërgojnë payload-e të ndryshme (ngarkesat e dobishme me të cilat kryhet sulmi) në vende të rastësishme, është e nevojshme të kuptohet si funksionon çdo gjë, çfarë funksionaliteti ofrohet. Mund të duket si një aktivitet i padobishëm, pasi në shumicën e vendeve të shqyrtuara nuk do të ketë asnjë dobësi. Por vetëm kuptimi i strukturës së aplikacionit dhe logjikës së tij të punës do të japë mundësinë për të gjetur vectorët e sulmeve më të vështira.

ËshtĂ« e rĂ«ndĂ«sishme tĂ« gjejmĂ« vende qĂ« duken tĂ« dyshimta ose ndryshe nga tĂ« tjerat. Dhe dobĂ«sia e parĂ« e rrezikshme u gjet pikĂ«risht nĂ« kĂ«tĂ« mĂ«nyrĂ«.

IDOR

IDOR-platfarma (Insecure Direct Object Reference, referenca të drejtpërdrejta të pa siguruara për objekte) është një nga shpeshtat më të zakonshme të dobësive në logjikën e biznesit, e cila lejon në një mënyrë ose tjetër aksesin në objekte, për të cilat në fakt nuk është lejuar qasje. Dobësitë IDOR krijojnë mundësinë për të marrë informacion mbi përdoruesit me një shkallë të ndryshme kriticiteti.

Një nga variantet e IDOR është kryerja e veprimeve me objektet e sistemit (përdoruesit, llogaritë bankare, produkte në shportë) përmes manipulimeve me identifikuesit e aksesit në këto objekte. Kjo çon në pasojat më të paparashikueshme. Për shembull, mundësinë e zëvendësimit të llogarisë së dërguesit të fondeve, përmes së cilës mund të vidhen ata nga përdorues të tjerë.

Në rastin e MCS, auditorët zbuluan pikërisht një dobësi IDOR të lidhur me identifikuesit e pasigurt. Në panelin personal të përdoruesit, për të pasur akses në çdo objekt, përdoreshin identifikues UUID, të cilat dukeshin, siç thonë siguria, si të pamundura për tu thyer (pra të mbrojtura nga sulmet e përmbysjes). Por për entitete të caktuara u zbulua se për të marrë informacion mbi përdoruesit e aplikacionit përdoren numra të zakonshëm të parashikueshëm. Mendoj se e kuptoni se mund të ndryshosh ID-në e përdoruesit për njësi, të dërgosh kërkesën përsëri dhe në këtë mënyrë të marrësh informacionin duke anashkaluar ACL (lista e kontrollit të aksesit, rregullat e qasjes në të dhëna për procese dhe përdorues).

Forgery e Kërkesave në Anën e Serverit (SSRF)

Produkte OpenSource janë të mira sepse ka një sasi të madhe forumeve me përshkrime të hollësishme teknike të problemeve që shfaqen dhe, nëse je me fat, me përshkrime të zgjidhjeve. Por kjo medalje ka anën e saj tjetër: dobësitë e njohura janë gjithashtu të përshkruara me hollësi. Për shembull, në forumet OpenStack ka përshkrime të shkëlqyera të dobësive. [XSS] dhe [SSRF], të cilat për ndonjë arsye askush nuk po nxiton t'i rregullojë.

Funksionaliteti i zakontë i aplikacioneve është mundësia për përdoruesin të dërgojë në server një lidhje, në të cilën serveri kalon (për shembull, për të ngarkuar një imazh nga burimi i specifikuar). Nëse filtrimi i mjeteve të sigurisë për lidhjet vetë ose përgjigjet që kthehen nga serveri për përdoruesit është i pamjaftueshëm, ky funksionalitet lehtë shfrytëzohet nga sulmuesit.

Vulnerabilitetet SSRF mund të avancojnë shumë zhvillimin e një sulmi. Një sulmues mund të fitojë:

  • qasje tĂ« kufizuar nĂ« rrjetin lokal tĂ« sulmuar, pĂ«r shembull vetĂ«m nĂ« disa segmente tĂ« caktuar tĂ« rrjetit dhe pĂ«r njĂ« protokoll tĂ« caktuar;
  • qasje tĂ« plotĂ« nĂ« rrjetin lokal, nĂ«se Ă«shtĂ« e mundur kalimi nga niveli i aplikacioneve nĂ« nivelin e transportit dhe, si pasojĂ«, kontrolli i plotĂ« mbi ngarkesĂ«n nĂ« nivelin e aplikacioneve;
  • qasje pĂ«r tĂ« lexuar skedarĂ«t lokalĂ« nĂ« server (nĂ«se mbĂ«shtetet skema file://);
  • dhe shumĂ« tĂ« tjera.

NĂ« OpenStack, vulnerabiliteti SSRF Ă«shtĂ« i njohur prej kohĂ«sh dhe ka natyrĂ« "qorre": kur i drejtohesh serverit nuk merr njĂ« pĂ«rgjigje prej tij, por merr lloje tĂ« ndryshme gabimesh/ndalimesh, varĂ«sisht nga rezultati i kĂ«rkesĂ«s. NĂ« bazĂ« tĂ« kĂ«saj, Ă«shtĂ« e mundur tĂ« bĂ«het skanimi i porteve nĂ« hostet brenda rrjetit, me tĂ« gjitha pasojat qĂ« nuk duhet tĂ« nĂ«nvlerĂ«sohen. PĂ«r shembull, njĂ« produkt mund tĂ« ketĂ« njĂ« API pĂ«r back-office, i aksesueshĂ«m vetĂ«m nga rrjeti korporativ. Duke pasur dokumentacionin (mos harrojmĂ« pĂ«r insajderĂ«t), sulmuesi mund tĂ« pĂ«rdorĂ« SSRF pĂ«r tĂ« marrĂ« qasje nĂ« metodat e brendshme. PĂ«r shembull, nĂ«se ndonjĂ« mĂ«nyrĂ« arriti tĂ« marrĂ« njĂ« listĂ« afĂ«rsisht tĂ« dobishme URL-esh, atĂ«herĂ« me ndihmĂ«n e SSRF mund tĂ« kalojĂ« pĂ«rmes tyre dhe tĂ« bĂ«jĂ« njĂ« kĂ«rkesĂ« – thjesht pĂ«r tĂ« transferuar para nga njĂ« llogari nĂ« tjetrĂ«n ose pĂ«r tĂ« ndryshuar limitet.

Ky nuk është rasti i parë i zbulimit të vulnerabilitetit SSRF në OpenStack. Në të kaluarën kishte mundësinë për të ngarkuar iso-t e VM nga një lidhje e drejtpërdrejtë, e cila gjithashtu shkaktonte pasoja të ngjashme. Aktualisht, kjo funksionalitet është hequr nga OpenStack. Duket se komuniteti e ka konsideruar këtë si zgjidhje më të thjeshtë dhe më të sigurt për problemin.

Dhe në këtë në një raport publik nga shërbimi HackerOne (h1), shfrytëzimi i një SSRF-i jo të verbër me mundësinë për të lexuar metadatat e instancës çon në marrjen e aksesit Root në tërë infrastrukturën e Shopify.

Në MCS në dy vende me funksionalitet të ngjashëm u zbuluan vulnerabilitete SSRF, por ishte pothuajse e pamundur që të shfrytëzoheshin për shkak të firewalleve dhe mbrojtjeve të tjera. Megjithatë, ekipi i MCS e riparoi këtë problem pa pritur komunitetin.

XSS në vend të ngarkesës "shell"

Megjithëse janë shkruar qindra studime, nga viti në vit XSS (sulmi i skriptimit të ndërfaqeve të internetit) ende mbetet vulnerabiliteti më i zakonshëm në web (ose sulm?).

Ngarkimi i skedareve është vendi i preferuar për çdo hulumtues sigurie. Shpesh ndodh që të ngarkohet një skenar i rastësishëm (asp/jsp/php) dhe të ekzekutohen komanda të sistemit operativ, në terminologjinë e pentesterëve - 'ngarko shell'. Por popullariteti i këtyre dobësive funksionon në dy drejtime: ato kujtohen dhe zhvillohen mjete për t'i kundërshtuar, kështu që kohët e fundit probabiliteti për të 'ngarkuar shell' po shkon drejt zeros.

Ekipa sulmuese (në formën e Sigurisë Digjitale) kishte fat. OK, në MCS nga ana e serverit kontrollohej përmbajtja e skedareve të ngarkuar, vetëm imazhet ishin të lejuara. Por SVG është gjithashtu një imazh. Si mund të jenë të rrezikshme imazhet SVG? Sepse ato mund të integrojnë fragmente JavaScript!

Doli se skedaret e ngarkuara ishin të aksesueshëm për të gjithë përdoruesit e shërbimit MCS - do të thotë se mund të sulmojmë përdoruesit e tjerë të cloud-it, përfshirë administratorët.

Auditi i sigurisë së platformës cloud MCS
Shembulli i integrimit me anë të një sulmi XSS në formularin e falsifikimit të hyrjes

Shembuj të eksplantimit të sulmit XSS:

  • Pse tĂ« provojmĂ« tĂ« vjedhim sesionin (sidomos kur tani kudo ka cookies HTTP-Only, tĂ« mbrojtura nga vjedhja me anĂ« tĂ« skenarĂ«ve js), nĂ«se skenari i ngarkuar mund tĂ« adresohet menjĂ«herĂ« me API-nĂ« e burimit? NĂ« kĂ«tĂ« rast, ngarkesa e dobishme mund tĂ« ndryshojĂ« konfigurimin e serverit pĂ«rmes kĂ«rkesave XHR, pĂ«r shembull, duke shtuar çelĂ«sin e hapur SSH tĂ« agresorit dhe duke fituar akses SSH nĂ« server.
  • NĂ«se politika CSP (politika e mbrojtjes sĂ« pĂ«rmbajtjes) ndalon integrimin e JavaScript, sulmuesi mund tĂ« shkojĂ« pa tĂ«. TĂ« dizajnohet njĂ« formular fals i hyrjes nĂ« sit me HTML tĂ« pastĂ«r dhe tĂ« vjedhĂ« fjalĂ«kalimin e administratorit pĂ«rmes njĂ« falskimi tĂ« avancuar: faqja e falsifikuar pĂ«r pĂ«rdoruesin ndodh nĂ« tĂ« njĂ«jtin URL, dhe pĂ«r pĂ«rdoruesin Ă«shtĂ« mĂ« e vĂ«shtirĂ« ta zbulojĂ«.
  • MĂ« nĂ« fund, sulmuesi mund tĂ« organizojĂ« DoS klient — tĂ« vendosĂ« cookies me madhĂ«si mĂ« tĂ« madhe se 4 KB. Mjafton qĂ« pĂ«rdoruesi tĂ« hapĂ« njĂ« herĂ« lidhjen — dhe e gjithĂ« faqja bĂ«het e pamundur, derisa tĂ« kuptojĂ« tĂ« pastrojĂ« shfletuesin: nĂ« shumicĂ«n e rasteve, serveri web do tĂ« refuzojĂ« tĂ« pranojĂ« njĂ« klient tĂ« tillĂ«.

Le të shqyrtojmë një shembull tjetër të zbuluar XSS, këtë herë me një eksplantim më të sofistikuar. Shërbimi MCS lejon grumbullimin e konfigurimeve të firewall-it në grupe. Në emrin e grupit u zbulua XSS. Karakteristika e saj ishte se vektori nuk funksiononte menjëherë, jo gjatë shikimit të listës së rregullave, por gjatë fshirjes së grupit:

Auditi i sigurisë së platformës cloud MCS

Prafolisht, skenari dukej kështu: një sulmues krijon një rregull firewall me "ngarkesë" në emër, administratorët pas një periudhe e vë re atë dhe nisin procesin e fshirjes. Dhe në këtë moment, JavaScript-i dëmtues fillon të funksionojë.

Për zhvilluesit e MCS për të mbrojtur nga XSS në imazhet SVG të ngarkuara (nëse nuk mund të hiqen), ekipi i Sigurisë Digitale rekomandoi:

  • TĂ« ngarkohen skedarĂ«t nga pĂ«rdoruesit nĂ« njĂ« domen tĂ« veçantĂ«, i cili nuk ka asnjĂ« lidhje me "cookies". Skripti do tĂ« ekzekutohet nĂ« kontekstin e njĂ« domene tjetĂ«r dhe nuk do tĂ« paraqesĂ« njĂ« kĂ«rcĂ«nim pĂ«r MCS.
  • NĂ« pĂ«rgjigjen HTTP tĂ« serverit tĂ« kthehet titulli "Content-disposition: attachment". KĂ«shtu, skedarĂ«t do tĂ« shkarkohen nga shfletuesi, jo do tĂ« ekzekutohen.

Për më tepër, tani për zhvilluesit janë të disponueshme shumë mënyra për të kufizuar rreziqet e shfrytëzimit të XSS:

  • me ndihmĂ«n e flagut "HTTP Only" mund tĂ« bĂ«hen titujt sesionikĂ« "Cookies" tĂ« paarritshĂ«m pĂ«r JavaScript-in e dĂ«mshĂ«m;
  • njĂ« politika CSP e integruar siç duhet do ta komplifikojĂ« ndjeshĂ«m shfrytĂ«zimin e XSS pĂ«r sulmuesin;
  • gjeneratorĂ«t modernĂ« tĂ« shablloneve, si Angular ose React, automatikisht pastruan tĂ« dhĂ«nat e pĂ«rdoruesve para se t'i shfaqin nĂ« shfletuesin e pĂ«rdoruesit.

Rreziqet e autentifikimit me dy faktorë

Për të rritur sigurinë e llogarive, përdoruesve gjithmonë u rekomandohet të aktivizojnë 2FA (autentifikimin me dy faktorë). Në të vërtetë, kjo është një mënyrë efektive për të penguar një sulmues të fitojë qasje në shërbim nëse kredencialet e përdoruesit janë komprometuar.

Por a jep përdorimi i faktorit të dytë të autentifikimit gjithmonë garanci për sigurinë e llogarisë? Në zbatimin e 2FA kanë ndodhur këto probleme sigurie:

  • KĂ«rcimi i ashpĂ«r i kodit OTP (kodeve njĂ«pĂ«rdorimshme). PavarĂ«sisht thjeshtĂ«sisĂ« sĂ« shfrytĂ«zimit, gabime tĂ« tilla si mos mbrojtja nga brute force mbi OTP hasen edhe te kompanitĂ« e mĂ«dha: rastet e Slack, rastet e Facebook.
  • Algoritmi i dobĂ«t i gjenerimit, pĂ«r shembull, mundĂ«sia pĂ«r tĂ« parashikuar kodin e ardhshĂ«m.
  • Gabimet logjike, pĂ«r shembull, mundĂ«sia pĂ«r tĂ« kĂ«rkuar OTP-nĂ« e dikujt tjetĂ«r nĂ« telefonin tuaj, siç Ă«shtĂ« ka qenĂ« te Shopify.

Në rastin e MCS, 2FA është realizuar mbi bazën e Google Authenticator dhe Duo. Protokolli vetë është provuar me kalimin e kohës, por implementimi i kontrollit të kodit në anën e aplikacionit duhet të verifikohet.

Në MCS, 2FA përdoret në disa vende:

  • NĂ« autentifikimin e pĂ«rdoruesit. KĂ«tu ka mbrojtje nga pĂ«rpjekjet e tepruara: pĂ«rdoruesi ka vetĂ«m disa pĂ«rpjekje pĂ«r tĂ« futur fjalĂ«kalimin e pĂ«rkohshĂ«m, pas sĂ« cilĂ«s futja bllokohet pĂ«r njĂ« kohĂ« tĂ« caktuar. Kjo bllokon mundĂ«sinĂ« e vjedhjes sĂ« OTP pĂ«rmes provave tĂ« shumta.
  • GjatĂ« gjenerimit tĂ« kodave rezervĂ« offline pĂ«r tĂ« kryer 2FA, si dhe pĂ«r çaktivizimin e saj. KĂ«tu nuk ishte e implementuar mbrojtja nga pĂ«rpjekjet e tepruara, e cila lejonte, nĂ«se ishe nĂ« pronĂ«si tĂ« fjalĂ«kalimit tĂ« llogarisĂ« dhe njĂ« seance funksionale, tĂ« rigjenerosh kodat rezervĂ« ose tĂ« çaktivizosh plotĂ«sisht 2FA.

Duke marrë parasysh se kodat rezervë ishin në të njëjtin diapazon vlerash si OTP-të e gjeneruara nga aplikacioni, shkalla e mundësisë për të gjetur kodin brenda një kohe të shkurtër ishte shumë më e lartë.

Auditi i sigurisë së platformës cloud MCS
Procesi i gjetjes së OTP për çaktivizimin e 2FA me ndihmën e mjetit "Burp: Intruder"

Rezultati

Në përgjithësi, MCS si produkt rezultoi të ishte i sigurt. Gjatë auditit, ekipi i pentesëve nuk arriti të kishte akses në VM-të e klientëve dhe të dhënat e tyre, ndërsa dobësitë e gjetura u korrigjuan shpejt nga ekipi i MCS.

Por është e rëndësishme të theksohet se siguria është një punë e vazhdueshme. Shërbimet nuk janë statike, ato zhvillohen vazhdimisht. Dhe nuk është e mundur të zhvillohet një produkt totalisht pa dobësi. Por është e mundur të gjejnë ato në kohë dhe të minimizojnë mundësinë e përsëritjes së tyre.

Tani, të gjitha dobësitë e përmendura në MCS janë tashmë të korrigjuara. Dhe për të minimizuar numrin e të rejave dhe për të shkurtuar kohën e ekzistencës së tyre, ekipi i platformës vazhdon ta bëjë këtë:

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster