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
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:
- 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.
- 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.
- 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?
- 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.
- 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ë.
- 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. dhe , 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ë 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 në web (ose ?).
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.
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ë — 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:
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;
- 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: , .
- 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ë te Shopify.
Në rastin e MCS, 2FA është realizuar mbi bazën e Google Authenticator dhe . 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ë.
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ë:
- të kryejnë rregullisht auditime nga kompani të jashtme;
- të mbajnë dhe zhvillojnë pjesëmarrjen;
- të angazhohen në siguri. 🙂
Burimi: habr.com
