nga SeerLight
Ndërtimi i çdo shërbimi përfshin domosdoshmërisht punën e vazhdueshme për sigurinë. Siguria është një proces i vazhdueshëm që përfshin analiza të vazhdueshme dhe përmirësim të sigurisë së produktit, monitorim të lajmeve rreth dobësive dhe shumë më tepër. Përfshirë auditimet. Auditimet kryhen si brenda dhe nga ekspertë të jashtëm, të cilët mund të ndihmojnë rrënjësisht për sigurinë, sepse nuk janë të zhytur në projekt dhe kanë një mendje të hapur.
Artikulli ka të bëjë me këtë pamje më të drejtpërdrejtë të ekspertëve të jashtëm që ndihmuan ekipin e Mail.ru Cloud Solutions (MCS) të testonte shërbimin cloud dhe për atë që ata gjetën. Si një "forcë e jashtme", MCS zgjodhi kompaninë Digital Security, e njohur për ekspertizën e saj të lartë në qarqet e sigurisë së informacionit. Dhe në këtë artikull ne do të analizojmë disa dobësi interesante të gjetura si pjesë e një auditimi të jashtëm - në mënyrë që të shmangni të njëjtën grabujë kur krijoni shërbimin tuaj cloud.
Описание продукта
është një platformë për ndërtimin e infrastrukturës virtuale në cloud. Ai përfshin IaaS, PaaS dhe një treg të imazheve të aplikacioneve të gatshme për zhvilluesit. Duke marrë parasysh arkitekturën MCS, ishte e nevojshme të kontrollohej siguria e produktit në fushat e mëposhtme:
- mbrojtja e infrastrukturës së mjedisit të virtualizimit: hipervizorët, rrugëzimet, muret e zjarrit;
- 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 i dizajnit tonë;
- IAM: projekte me shumë qiramarrës me një model roli;
- Vizioni (vizioni kompjuterik): API-të dhe dobësitë kur punoni me imazhe;
- ndërfaqe në internet dhe sulme klasike në ueb;
- dobësitë e komponentëve PaaS;
- API e të gjithë komponentëve.
Ndoshta kjo është gjithçka që është thelbësore për historinë e mëtejshme.
Çfarë lloj pune u krye dhe pse ishte e nevojshme?
Një auditim i sigurisë ka për qëllim identifikimin e dobësive dhe gabimeve të konfigurimit që mund të çojnë në rrjedhje të të dhënave personale, modifikim të informacionit të ndjeshëm ose ndërprerje të disponueshmërisë së shërbimit.
Gjatë punës, e cila zgjat mesatarisht 1-2 muaj, auditorët përsërisin veprimet e sulmuesve të mundshëm dhe kërkojnë dobësi në pjesët e klientit dhe serverit të shërbimit të zgjedhur. Në kuadër të auditimit të platformës cloud MCS, u identifikuan qëllimet e mëposhtme:
- Analiza e vërtetimit në shërbim. Dobësitë në këtë komponent do të ndihmonin për të hyrë menjëherë në llogaritë e njerëzve të tjerë.
- Studimi i modelit të rolit dhe kontrollit të aksesit midis llogarive të ndryshme. Për një sulmues, aftësia për të fituar akses në makinën virtuale të dikujt tjetër është një qëllim i dëshirueshëm.
- Dobësitë nga ana e klientit. XSS/CSRF/CRLF/etj. A është e mundur të sulmoni përdoruesit e tjerë përmes lidhjeve me qëllim të keq?
- Dobësitë në anën e serverit: RCE dhe të gjitha llojet e injeksioneve (SQL/XXE/SSRF e kështu me radhë). Dobësitë e serverit janë përgjithësisht më të vështira për t'u gjetur, por ato çojnë në kompromisin e shumë përdoruesve menjëherë.
- Analiza e izolimit të segmentit të përdoruesit në nivel rrjeti. Për një sulmues, mungesa e izolimit rrit shumë sipërfaqen e sulmit kundër përdoruesve të tjerë.
- Analiza e logjikës së biznesit. A është e mundur të mashtroni bizneset dhe të krijoni makina virtuale falas?
Në këtë projekt, puna u krye sipas modelit "Grey-box": auditorët ndërvepruan me shërbimin me privilegjet e përdoruesve të zakonshëm, por posedonin pjesërisht kodin burimor të API dhe patën mundësinë të sqaronin detajet me zhvilluesit. Ky është zakonisht modeli më i përshtatshëm dhe në të njëjtën kohë mjaft realist i punës: informacioni i brendshëm ende mund të mblidhet nga një sulmues, është vetëm çështje kohe.
U gjetën dobësi
Përpara se auditori të fillojë të dërgojë ngarkesa të ndryshme (ngarkesa e përdorur për të kryer sulmin) në vende të rastësishme, është e nevojshme të kuptohet se si funksionojnë gjërat dhe çfarë funksionaliteti ofrohet. Mund të duket se ky është një ushtrim i padobishëm, sepse në shumicën e vendeve të studiuara nuk do të ketë dobësi. Por vetëm të kuptuarit e strukturës së aplikacionit dhe logjikës së funksionimit të tij do të bëjë të mundur gjetjen e vektorëve më kompleksë të sulmit.
Është e rëndësishme të gjesh vende që duken të dyshimta ose janë shumë të ndryshme nga të tjerët në një farë mënyre. Dhe dobësia e parë e rrezikshme u gjet në këtë mënyrë.
IDOR
Dobësitë IDOR (Insecure Direct Object Reference) janë një nga dobësitë më të zakonshme në logjikën e biznesit, e cila lejon një ose një tjetër të fitojë akses në objekte në të cilat qasja në fakt nuk lejohet. Dobësitë e IDOR krijojnë mundësinë e marrjes së informacionit për një përdorues me shkallë të ndryshme kritike.
Një nga opsionet IDOR është kryerja e veprimeve me objektet e sistemit (përdoruesit, llogaritë bankare, artikujt në karrocën e blerjeve) duke manipuluar identifikuesit e aksesit në këto objekte. Kjo çon në pasojat më të paparashikueshme. Për shembull, mundësia e zëvendësimit të llogarisë së dërguesit të fondeve, përmes së cilës ju mund t'i vidhni ato nga përdoruesit e tjerë.
Në rastin e MCS, auditorët sapo zbuluan një cenueshmëri IDOR të lidhur me identifikues jo të sigurt. Në llogarinë personale të përdoruesit, identifikuesit UUID u përdorën për të hyrë në çdo objekt, i cili dukej, siç thonë ekspertët e sigurisë, jashtëzakonisht i pasigurt (d.m.th., i mbrojtur nga sulmet e forcës brutale). Por për disa subjekte, u zbulua se numrat e rregullt të parashikueshëm përdoren për të marrë informacion rreth përdoruesve të aplikacionit. Unë mendoj se mund të merrni me mend se ishte e mundur të ndryshoni ID-në e përdoruesit me një, të dërgoni përsëri kërkesën dhe kështu të merrni informacione duke anashkaluar ACL-në (lista e kontrollit të aksesit, rregullat e aksesit të të dhënave për proceset dhe përdoruesit).
Falsifikim i kërkesës nga ana e serverit (SSRF)
E mira e produkteve të OpenSource është se ato kanë një numër të madh forumesh me përshkrime të hollësishme teknike të problemeve që lindin dhe, nëse jeni me fat, një përshkrim të zgjidhjes. Por kjo monedhë ka një anë tjetër: dobësitë e njohura përshkruhen gjithashtu në detaje. Për shembull, ka përshkrime të mrekullueshme të dobësive në forumin OpenStack и , të cilat për disa arsye askush nuk po nxiton ta rregullojë.
Një funksionalitet i zakonshëm i aplikacioneve është aftësia që përdoruesi të dërgojë një lidhje në server, në të cilën serveri klikon (për shembull, për të shkarkuar një imazh nga një burim i caktuar). Nëse mjetet e sigurisë nuk filtrojnë vetë lidhjet ose përgjigjet e kthyera nga serveri te përdoruesit, një funksionalitet i tillë mund të përdoret lehtësisht nga sulmuesit.
Dobësitë SSRF mund të avancojnë shumë zhvillimin e një sulmi. Një sulmues mund të marrë:
- akses i kufizuar në rrjetin lokal të sulmuar, për shembull, vetëm përmes segmenteve të caktuara të rrjetit dhe duke përdorur një protokoll të caktuar;
- akses i plotë në rrjetin lokal, nëse është i mundur zvogëlimi nga niveli i aplikimit në nivelin e transportit dhe, si rezultat, menaxhimi i plotë i ngarkesës në nivelin e aplikimit;
- aksesi për të lexuar skedarët lokalë në server (nëse skema file:/// mbështetet);
- dhe shumë gjëra të tjera.
Një cenueshmëri SSRF është e njohur prej kohësh në OpenStack, e cila është e natyrës "të verbër": kur kontakton serverin, nuk merr përgjigje prej tij, por merr lloje të ndryshme gabimesh/vonesash, në varësi të rezultatit të kërkesës. . Bazuar në këtë, ju mund të kryeni një skanim portash në hostet në rrjetin e brendshëm, me të gjitha pasojat që pasojnë që nuk duhen nënvlerësuar. Për shembull, një produkt mund të ketë një API back-office që është i aksesueshëm vetëm nga rrjeti i korporatës. Me dokumentacion (mos harroni për të brendshëm), një sulmues mund të përdorë SSRF për të hyrë në metodat e brendshme. Për shembull, nëse keni qenë disi në gjendje të merrni një listë të përafërt të URL-ve të dobishme, atëherë duke përdorur SSRF mund t'i kaloni ato dhe të ekzekutoni një kërkesë - duke folur relativisht, transferoni para nga llogaria në llogari ose ndryshoni kufijtë.
Kjo nuk është hera e parë që një cenueshmëri SSRF zbulohet në OpenStack. Në të kaluarën, ishte e mundur të shkarkoheshin imazhe VM ISO nga një lidhje direkte, e cila gjithashtu çoi në pasoja të ngjashme. Ky funksion tani është hequr nga OpenStack. Me sa duket, komuniteti e konsideroi këtë zgjidhjen më të thjeshtë dhe më të besueshme të problemit.
Dhe në Raporti i disponueshëm publikisht nga shërbimi HackerOne (h1), shfrytëzimi i një SSRF jo më të verbër me aftësinë për të lexuar metadatat e instancës çon në aksesin Root në të gjithë infrastrukturën Shopify.
Në MCS, dobësitë SSRF u zbuluan në dy vende me funksionalitet të ngjashëm, por ato ishin pothuajse të pamundura për t'u shfrytëzuar për shkak të mureve të zjarrit dhe mbrojtjeve të tjera. Në një mënyrë apo tjetër, ekipi MCS e rregulloi këtë problem gjithsesi, pa pritur komunitetin.
XSS në vend të ngarkimit të predhave
Megjithë qindra studime të shkruara, sulmi XSS (skriptimi i faqeve të ndryshme) vit pas viti është ende më i madhi dobësi në ueb (ose ?).
Ngarkimet e skedarëve janë një vend i preferuar për çdo studiues të sigurisë. Shpesh rezulton se mund të ngarkoni një skript arbitrar (asp/jsp/php) dhe të ekzekutoni komandat e OS, në terminologjinë e pentestuesve - "predha e ngarkesës". Por popullariteti i dobësive të tilla funksionon në të dy drejtimet: ato mbahen mend dhe zhvillohen mjete kundër tyre, kështu që kohët e fundit probabiliteti i "ngarkimit të një guaskë" priret në zero.
Ekipi sulmues (i përfaqësuar nga Digital Security) ishte me fat. OK, në MCS në anën e serverit u kontrollua përmbajtja e skedarëve të shkarkuar, lejoheshin vetëm imazhet. Por SVG është gjithashtu një foto. Si mund të jenë të rrezikshme imazhet SVG? Sepse ju mund të futni fragmente JavaScript në to!
Doli se skedarët e shkarkuar janë të disponueshëm për të gjithë përdoruesit e shërbimit MCS, që do të thotë se është e mundur të sulmohen përdoruesit e tjerë të cloud, përkatësisht administratorët.
Një shembull i një sulmi XSS në një formë login phishing
Shembuj të shfrytëzimit të sulmit XSS:
- Pse të përpiqeni të vidhni një sesion (veçanërisht pasi tani kukit "Vetëm HTTP" janë kudo, të mbrojtur nga vjedhja duke përdorur skriptet js), nëse skripti i ngarkuar mund të hyjë menjëherë në API-në e burimit? Në këtë rast, ngarkesa mund të përdorë kërkesat XHR për të ndryshuar konfigurimin e serverit, për shembull, të shtojë çelësin publik SSH të sulmuesit dhe të fitojë akses SSH në server.
- Nëse politika CSP (politika e mbrojtjes së përmbajtjes) e ndalon injektimin e JavaScript, një sulmues mund t'ia dalë pa të. Duke përdorur HTML të pastër, krijoni një formular të rremë hyrjeje për faqen dhe vidhni fjalëkalimin e administratorit përmes këtij phishing të avancuar: faqja e phishing për përdoruesin përfundon në të njëjtën URL dhe është më e vështirë për përdoruesin ta zbulojë atë.
- Më në fund, sulmuesi mund të rregullojë — vendosni "Cookies" më të mëdha se 4 KB. Përdoruesi duhet të hapë lidhjen vetëm një herë, dhe i gjithë faqja bëhet e paarritshme derisa përdoruesi të mendojë të pastrojë posaçërisht shfletuesin: në shumicën dërrmuese të rasteve, serveri në internet do të refuzojë të pranojë një klient të tillë.
Le të shohim një shembull të një XSS tjetër të zbuluar, këtë herë me një shfrytëzim më të zgjuar. Shërbimi MCS ju lejon të kombinoni cilësimet e murit të zjarrit në grupe. Emri i grupit ishte vendi ku u zbulua XSS. E veçanta e tij ishte se vektori nuk u aktivizua menjëherë, jo kur shikoni listën e rregullave, por kur fshini një grup:
Kjo do të thotë, skenari doli të ishte si vijon: një sulmues krijon një rregull firewall me "ngarkesë" në emër, administratori e vëren atë pas një kohe dhe fillon procesin e fshirjes. Dhe këtu funksionon JS keqdashës.
Që zhvilluesit MCS të mbrohen nga XSS në imazhet e ngarkuara SVG (nëse ato nuk mund të hiqen), ekipi i Sigurisë Dixhitale rekomandoi:
- Vendosni skedarët e ngarkuar nga përdoruesit në një domen të veçantë që nuk ka të bëjë fare me "cookies". Skripti do të ekzekutohet në kontekstin e një domeni tjetër dhe nuk do të përbëjë kërcënim për MCS.
- Në përgjigjen HTTP të serverit, dërgoni kokën "Content-disposition: attachment". Pastaj skedarët do të shkarkohen nga shfletuesi dhe nuk do të ekzekutohen.
Përveç kësaj, tani ka shumë mënyra në dispozicion të zhvilluesve për të zbutur rreziqet e shfrytëzimit të XSS:
- duke përdorur flamurin "Vetëm HTTP", ju mund t'i bëni titujt "Cookies" të sesioneve të paarritshëm për JavaScript me qëllim të keq;
- do ta bëjë shumë më të vështirë për një sulmues që të shfrytëzojë XSS;
- motorët modern të shablloneve si Angular ose React i pastrojnë automatikisht të dhënat e përdoruesit përpara se t'i nxjerrin në shfletuesin e përdoruesit.
Dobësitë e vërtetimit me dy faktorë
Për të përmirësuar sigurinë e llogarisë, përdoruesit këshillohen gjithmonë të aktivizojnë 2FA (autentifikimi me dy faktorë). Në të vërtetë, kjo është një mënyrë efektive për të parandaluar një sulmues të fitojë akses në një shërbim nëse kredencialet e përdoruesit janë komprometuar.
Por a garanton gjithmonë sigurinë e llogarisë përdorimi i një faktori të dytë vërtetimi? Ekzistojnë çështjet e mëposhtme të sigurisë në zbatimin e 2FA:
- Kërkimi me forcë brutale të kodit OTP (kodet një herë). Megjithë thjeshtësinë e funksionimit, gabime të tilla si mungesa e mbrojtjes kundër forcës brutale OTP hasen edhe nga kompanitë e mëdha: , .
- Algoritmi i dobët i gjenerimit, për shembull aftësia për të parashikuar kodin tjetër.
- Gabimet logjike, të tilla si aftësia për të kërkuar OTP të dikujt tjetër në telefonin tuaj, si kjo nga Shopify.
Në rastin e MCS, 2FA zbatohet bazuar në Google Authenticator dhe . Vetë protokolli tashmë është testuar me kohë, por zbatimi i verifikimit të kodit në anën e aplikacionit ia vlen të kontrollohet.
MCS 2FA përdoret në disa vende:
- Gjatë vërtetimit të përdoruesit. Ekziston mbrojtje kundër forcës brutale: përdoruesi ka vetëm disa përpjekje për të futur një fjalëkalim një herë, pastaj hyrja bllokohet për një kohë. Kjo bllokon mundësinë e zgjedhjes së OTP me forcë brutale.
- Kur gjeneroni kode rezervë jashtë linje për të kryer 2FA, si dhe duke e çaktivizuar atë. Këtu, nuk u zbatua asnjë mbrojtje me forcë brutale, gjë që bëri të mundur, nëse kishit një fjalëkalim për llogarinë dhe një seancë aktive, të rigjeneroni kodet rezervë ose të çaktivizoni plotësisht 2FA.
Duke marrë parasysh që kodet rezervë ndodheshin në të njëjtin gamë vlerash vargu si ato të gjeneruara nga aplikacioni OTP, mundësia për të gjetur kodin në një kohë të shkurtër ishte shumë më e lartë.
Procesi i zgjedhjes së një OTP për të çaktivizuar 2FA duke përdorur mjetin "Burp: Intruder".
Result
Në përgjithësi, MCS duket të jetë i sigurt si produkt. Gjatë auditimit, ekipi i penduar nuk ishte në gjendje të fitonte akses në VM-të e klientëve dhe të dhënat e tyre, dhe dobësitë e gjetura u korrigjuan shpejt nga ekipi MCS.
Por këtu është e rëndësishme të theksohet se siguria është një punë e vazhdueshme. Shërbimet nuk janë statike, ato janë vazhdimisht në zhvillim. Dhe është e pamundur të zhvillohet një produkt plotësisht pa dobësi. Por ju mund t'i gjeni në kohë dhe të minimizoni mundësinë e përsëritjes së tyre.
Tani të gjitha dobësitë e përmendura në MCS tashmë janë rregulluar. Dhe për të mbajtur numrin e të rinjve në minimum dhe për të zvogëluar jetëgjatësinë e tyre, ekipi i platformës vazhdon ta bëjë këtë:
- të kryejë rregullisht auditime nga kompani të jashtme;
- mbështesin dhe zhvillojnë pjesëmarrjen;
- angazhohen në siguri. 🙂
Burimi: www.habr.com