nga SeerLight
Krijimi i çdo shërbimi përfshin domosdoshmërisht punë të vazhdueshme për sigurinë. Siguria është një proces i vazhdueshëm që përfshin analizimin dhe përmirësimin e vazhdueshëm të mbrojtjes, monitorimin e lajmeve për dobësi dhe shumë të tjera. Kjo përfshin gjithashtu auditimet. Auditimet kryhen si nga forcat e brendshme, ashtu edhe nga ekspertët e jashtëm, të cilët mund të ndihmojnë ndjeshëm me sigurinë, pasi nuk janë të përfshirë thellë në projekt dhe kanë një perspektivë të pastër.
Ky artikull është për atë pikëpamje të pastër të ekspertëve të jashtëm, të cilët ndihmuan ekipin e Mail.ru Cloud Solutions (MCS) të testojë shërbimin cloud, dhe për atë që ata gjetën. Si "forca të jashtme", MCS zgjodhi kompaninë Digital Security, e njohur për ekspertizën e saj të lartë në fushën e sigurisë informative. Në këtë artikull, do të shqyrtojmë disa e dobësi interesante të gjetura gjatë auditimit të jashtëm - për të evituar të njëjtat gabime kur të krijoni shërbimin tuaj cloud.
Përshkrimi i produktit
është një platformë për ndërtimin e infrastruktures virtuale në cloud. Ajo përfshin IaaS, PaaS, dhe një treg për imazhe aplikacionesh të gatshme për zhvilluesit. Duke pasur parasysh arkitekturën e MCS, ishte e nevojshme të kontrollohej siguria e produktit në drejtimet e mëposhtme:
- mbrojtja e infrastrukturës së ambientit të virtualizimit: hipervizorët, rrugëzimi, firewall-et;
- mbrojtja e infrastrukturës virtuale të klientëve: izolimi nga njëri-tjetri, duke përfshirë rrjetet private në SDN;
- OpenStack dhe komponentët e tij të hapur;
- S3 i zhvilluar vetë;
- IAM: projektet shumëzyra me model rolet;
- Vision (shikimi i makinave): API dhe dobësi gjatë punës me imazhe;
- ndërfaqja web dhe sulmet klasike në web;
- dobësi të komponentëve PaaS;
- API-të e të gjitha komponentëve.
Mund të themi se kjo është e gjitha për historinë e ardhshme.
Cilat punë u kryen dhe pse janë të nevojshme?
Auditi i sigurisë është i orientuar në identifikimin e dobësive dhe gabimeve të konfigurimit, të cilat mund të çojnë në rrjedhje të të dhënave personale, modifikim të informacionit të ndjeshëm ose shkelje të disponueshmërisë së shërbimeve.
Gjatë punëve që zgjatin mesatarisht 1-2 muaj, auditorët përsërisin veprimet e potencialeve keqbërëse dhe kërkojnë dobësi në pjesën e klientit dhe serverit të shërbimit të zgjedhur. Në kontekstin e auditit të platformës cloud MCS, u caktuan objektiva të mëposhtme:
- Analiza e autentikimit në shërbim. Dobësitë në këtë komponent do të lejonin menjëherë që të hynin në llogaritë e të tjerëve.
- Studimi i modelit të rolit dhe ndarjes së aksesit midis llogarive të ndryshme. Për një keqbërës, mundësia për të accesuar një makinë virtuale të të tjerëve është një objektiv i dëshiruar.
- Dobësitë e pjesës së klientit. XSS/CSRF/CRLF/etj. A ka ndoshta mundësi për të sulmuar përdorues të tjerë përmes lidhjeve të dëmshme?
- Dobësitë e pjesës së serverit: RCE dhe të gjitha llojet e injeksioneve (SQL/XXE/SSRF e kështu me radhë). Dobësitë serverike janë zakonisht më të vështira për t'u gjetur, por ato çojnë në komprometimin e shumë përdoruesve menjëherë.
- Analiza e izolimit të segmenteve të përdoruesve në nivelin e rrjetit. Për një keqbërës, mungesa e izolimit rrit ndjeshëm sipërfaqen e sulmit ndaj përdoruesve të tjerë.
- Analiza e logjikës së biznesit. A është e mundur të mashtrohet biznesi dhe të krijohen makina virtuale falas?
Në këtë projekt, punët u kryen sipas modelit "Gray-box": auditorët ndërvepruan me shërbimin me privilegjet e përdoruesve të zakonshëm, por pjesërisht kishin kodin burimor të API-së dhe kishin mundësinë të sqarojnë detajet me zhvilluesit. Zakonisht kjo është modeli më i përshtatshëm, dhe në të njëjtën kohë mjaft realistik: informacioni i brendshëm gjithsesi mund të mblidhet nga keqbërësit, është vetëm një çështje kohe.
Dobësitë e gjetura
Para se auditori të fillojë të dërgojë payload të ndryshëm në vende të rastësishme, është e nevojshme të kuptohet se si funksionon gjithçka, cili funksionalitet është i pranishëm. Mund të duket se ky është një aktivitet i padobishëm, pasi në shumicën e vendeve të studiuara nuk do të ketë dobësi. Por vetëm kuptimi i strukturës së aplikacionit dhe logjikës së tij do të japë mundësinë për të identifikuar vektorët e sulmit më të vështirë.
Ë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 në këtë mënyrë.
IDOR
IDOR-ç Vulnerabilities (Insecure Direct Object Reference, lidhje të drejtpërdrejta të pasigurta me objekte) janë një nga format më të zakonshme të dobësive në logjikën e biznesit, e cila lejon në një mënyrë ose tjetër të qasje në objekte për të cilat në të vërtetë nuk është e lejuar. Dobësitë IDOR krijojnë mundësi për të marrë informacione rreth përdoruesve me nivele të ndryshme rëndësie.
Një nga format e IDOR është realizimi i veprimeve me objektet e sistemit (përdoruesit, llogaritë bankare, produktet në shportë) përmes manipulimeve me identifikuesit e qasjes në këto objekte. Kjo çon në pasoja shumë të paparashikueshme. Për shembull, mundësia për të zëvendësuar llogarinë e dërguesit të parave, përmes së cilës mund të vjedhen ato nga përdoruesit e tjerë.
Në rastin e MCS, auditorët zbuluan një dobësi IDOR, e lidhur me identifikuesit e pasigurt. Në llogarinë personale të përdoruesit, për qasje në çdo objekt, u përdorën identifikues UUID, të cilët duken, siç thonë ekspertët e sigurisë, të jesh të papërmbajtshëm (dmth të mbrojtur nga sulmi përmes provës). Por për entitete të caktuara u zbulua se për të marrë informacion rreth përdoruesve të aplikacionit, përdoren numra të zakonshëm dhe të parashikueshëm. Mendoj se ju e keni marrë vesh se mund të ndryshoni ID-në e përdoruesit me njësi, të dërgoni kërkesën përsëri dhe kështu të merrni informacionin në anashkalim të ACL (listës së kontrollit të aksesit, rregullave të aksesit në të dhëna për procese dhe përdorues).
Server Side Request Forgery (SSRF)
Produktet OpenSource janë të mira sepse ka një sasi të madhe forumesh me përshkrime të detajuara teknike të problemeve që lindin dhe, nëse keni fat, me përshkrimin e zgjidhjeve. Por, ka një anë të errët të kësaj medalje: gjithashtu janë të detajuara dobësitë e njohura. Për shembull, në forumet OpenStack ka përshkrime të shkëlqyera të dobësive dhe , të cilat për një arsye të panjohur, askush nuk ka nxituar t'i korrigjojë.
Një funksionalitet i zakonshëm i aplikacioneve është mundësia për përdoruesin të dërgojë një lidhje në server, në të cilin serveri kalon (për shembull, për të ngarkuar një imazh nga burimi i caktuar). Nëse filtrimi i mjetet e sigurisë për këto lidhje ose përgjigjet që kthehen nga serveri për përdoruesit është i pamjaftueshëm, ky funksionalitet gjithmonë përdoret lehtësisht nga sulmuesit.
Dobësitë SSRF mund të avancojnë ndjeshëm zhvillimin e sulmit. Sulmuesi mund të fitojë:
- qasje të kufizuar në rrjetin lokal të sulmuar, për shembull, vetëm në segmentet e caktuara të rrjetit dhe për një protokoll të caktuar;
- qasje të plotë në rrjetin lokal, nëse mundësia e kalimit nga niveli i aplikacioneve në nivelin e transportit është e mundur dhe, si pasojë, kontroll të plotë mbi ngarkesën në nivelin e aplikacioneve;
- qasje për leximin e skedarëve lokalë në server (nëse mbështetet skema file://);
- dhe shumë të tjera.
Në OpenStack, prej kohësh është e njohur një dobësi SSRF me karakter "të verbër": kur i drejtohesh serverit, nuk merr përgjigje prej tij, por merr lloje të ndryshme gabimesh/delay, në varësi të rezultatit të kërkesës. Në bazë të kësaj, mund të kryhet skanimi i porteve në hostet në rrjetin e brendshëm, 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, të qasshëm vetëm nga rrjeti korporativ. Duke pasur dokumentacionin (mos harrojmë për insajderët), sulmuesi mund të përdorë SSRF për të u drejtuar metodave të brendshme. Për shembull, nëse ndonjëherë arriti të merrte një listë të përafërt të URL-ve të dobishme, atëherë mund të kalojë përmes tyre dhe të dërgojë një kërkesë - për shembull, të transferojë para nga një llogari në një tjetër ose të ndryshojë limitet.
Kjo nuk është hera e parë që zbulohet dobësia SSRF në OpenStack. Më parë ishte e mundur të ngarkohej imazhe ISO të VM-në përmes lidhjes direkte, që gjithashtu çonte në pasoja të ngjashme. Aktualisht, kjo funksion është hequr nga OpenStack. Duket se komiteti e konsideroi këtë si zgjidhjen më të thjeshtë dhe më të besueshme të problemit.
Dhe në Në një raport publik nga shërbimi HackerOne (h1), shfrytëzimi i SSRF që nuk është i verbër me mundësinë e leximit të metadave të instancës çon në marrjen e qasjes Root në të gjithë infrastrukturën Shopify.
Në MCS në dy vende me funksionalitet të ngjashëm u zbuluan dobësi SSRF, por ishte pothuajse e pamundur t'i shfrytëzohej për shkak të firewalleve dhe mbrojtjeve të tjera. Megjithatë, ekipi MCS e rregulloi këtë problem, pa pritur për komitetin.
XSS në vend të ngarkimit të "shell"
Megjithëse janë shkruar qindra studime, vit pas viti, XSS (sulmi i skriptimit të ndërmjetëm) mbetet në ueb (ose ?).
Ngarkimi i skedareve është një vend i preferuar për çdo studiues sigurie. Shpesh ndodhet, është e mundur të ngarkohet një skript i rastësishëm (asp/jsp/php) dhe të ekzekutohen komandat e OS-së; në terminologjinë e pentesterëve, kjo quhet "ngarkimi i shell-it". Por popullariteti i këtyre dobësive funksionon në të dyja drejtimet: për to kujtohen dhe zhvillohen mjete për t'i parandaluar ato, kështu që së fundmi, probabiliteti për të "ngarkuar shell" po i afrohet zeros.
Ekipa sulmuese (në emër të Digital Security) kishte fat. OK, në MCS kontrollohej përmbajtja e skedareve të ngarkuar në anën e serverit; lejohej vetëm imazhe. Por SVG është gjithashtu një imazh. Cilat janë rreziqet nga imazhet SVG? Ato mund të përmbajnë fragmente JavaScript!
Doli se skedaret e ngarkuar janë të arritshme nga të gjithë përdoruesit e shërbimit MCS — domethënë, mund të sulmohet edhe përdorues të tjerë të cloud-it, konkretisht administratorë.
Shembuj i një inkurgimi përmes një sulmi XSS të formularit të phishing-ut për hyrje
Shembujt e shfrytëzimit të sulmit XSS:
- Pse të përpiqesh të vjedhësh sesionin (sidomos tani që kudo ka cookies HTTP-Only, të mbrojtura nga vjedhjet përmes skripteve js), nëse skripti i ngarkuar mund të aksesojë menjëherë API-në e burimit? Në këtë rast, ngarkesa mund të ndryshojë konfigurimin e serverit përmes kërkesave XHR; për shembull, të shtojë çelësin SSH të hapur të sulmuesit dhe të fitojë akses SSH në server.
- Nëse politika CSP (politika e mbrojtjes së përmbajtjes) ndalon inkursionin e JavaScript, sulmuesi mund të bëjë pa të. Ai mund të krijojë një formular të rremë hyrjeje në sit në HTML të pastër dhe të grabisë fjalëkalimin e administratorit përmes një phishing-u të avancuar: faqja e phishing-ut për përdoruesin del në të njëjtin URL, dhe përdoruesi e ka më të vështirë ta zbulojë atë.
- Në fund, sulmuesi mund të organizojë — të vendosë cookies që janë më të mëdha se 4 KB. Përdoruesi duhet të hapë një herë linkun — dhe të gjithë siti bëhet i papërshkueshëm, derisa të kuptohet që duhet të pastroni 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ë një XSS të zbuluar, këtë herë me një shfrytëzim më të sofistikuar. Shërbimi MCS lejon grupimin e rregullave të firewall-it. Në emrin e grupit u zbulua XSS. Veçoria e saj ishte se vektori nuk aktivizohej menjëherë, jo gjatë shikimit të listës së rregullave, por gjatë fshirjes së grupit:
Pra, skenari dukej kështu: sulmuesi krijon një rregull firewall-i me "ngarkesë" në emër, administratori e vë re atë pas një kohe, dhe fillon procesin e fshirjes. Dhe këtu funksionon JavaScript-i keqdashës.
Për të mbrojtur nga XSS në imazhet SVG të ngarkuara, ekipi i Digital Security rekomandoi zhvilluesve të MCS:
- Të vendosen skedaret e ngarkuara nga përdoruesit në një domain të veçantë, që nuk ka asnjë lidhje me "cookies". Skripti do të ekzekutohet në kontekstin e një domaini tjetër dhe nuk do të paraqesë rrezik për MCS.
- Në përgjigjen HTTP të serverit, të jepet titulli "Content-disposition: attachment". Kështu, skedaret do të shkarkohen nga shfletuesi, dhe jo të ekzekutohen.
Për më tepër, tani janë në dispozicion shumë mënyra për të lehtësuar rreziqet e shfrytëzimit të XSS:
- me ndihmën e flamurit "HTTP Only", ndjenjat sesionale "Cookies" mund të bëhen të papërshkueshme për JavaScript-in e keqdashës;
- do ta komplikohet ndjeshëm shfrytëzimin e XSS për sulmuesin;
- shabllon modernë, si Angular ose React, automatikisht pastrorin të dhënat e përdoruesve para se t'i tregojnë në shfletuesin e përdoruesit.
Dobësitë e dyfaktorit të identifikimit
Për të rritur sigurinë e llogarive, përdoruesit gjithmonë rekomandohet të aktivizojnë 2FA (identifikim me dy faktorë). Në të vërtetë, është një mënyrë efektive për të parandaluar një sulmues të fitojë qasje në shërbim, nëse kredencialet e përdoruesit janë komprometuar.
Por a jep gjithmonë përdorimi i faktorit të dytë të identifikimit garanci për ruajtjen e llogarisë? Në zbatimin e 2FA ekzistojnë disa probleme sigurie:
- Provimi i dhunshëm të kodit OTP (kodeve njëpërdorimshme). Sidoqoftë, njëherë e thjeshtë, gabimet e tilla si mosmbrojtja nga provat e dhunshme të OTP, ndodhin edhe në kompani të 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 të huaja në telefonin tuaj, siç është në Shopify.
Në rastin e MCS, 2FA është zbatuar mbi bazën e Google Authenticator dhe Protokolli i vetë është provuar me kalimin e kohës, por zbatimi i kontrollit të kodit në anën e aplikacionit duhet të verifikohet.
Në MCS, 2FA përdoret në disa vende:
- Gjatë autentifikimit të përdoruesit. Këtu ka mbrojtje ndaj provave të shumta: përdoruesi ka vetëm disa përpjekje për të futur kodin e njëhershëm, pastaj futja bllokohet për një periudhë kohe. Kjo bllokon mundësinë e përdorimit të OTP-së përmes provave të shumta.
- Gjatë gjenerimit të kodeve rezervë offline për realizimin e 2FA, si dhe për çaktivizimin e saj. Këtu nuk ka pasur mbrojtje nga provat e shumta, gjë që lejonte, me një fjalëkalim të llogarisë dhe një sesion aktiv, të rinovoheshin kode rezervë ose të çaktivizohej plotësisht 2FA.
Duke parë se kodet rezervë ishin të vendosura në të njëjtin interval vlerash si OTP-të e gjeneruara nga aplikacioni, mundësia për të gjetur kodin brenda një kohe të shkurtër ishte shumë më e lartë.
Procesi i provimit të 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ë auditi, ekipi i testuesve të penetrimit nuk arriti të merrte akses në VM-të e klientëve dhe në të dhënat e tyre, dhe vulnerabilitetet e gjetura u rregulluan shpejt nga ekipi i MCS.
Por këtu është e rëndësishme të theksohet se siguria është një punë e vazhdueshme. Shërbimet nuk janë statike, ato vazhdojnë të zhvillohen. Ndërsa është e pamundur të krijohet një produkt plotësisht pa vulnerabilitete. Megjithatë, është e mundur të gjejnë ato në kohë dhe të minimizojnë mundësinë e përsëritjes së tyre.
Tani të gjithë vulnerabilitetet e përmendura në MCS janë rregulluar. Për të bërë numrin e të rinjve minimal dhe për të zvogëluar kohën e ekzistencës së tyre, ekipi i platformës vazhdon ta bëjë këtë:
- të kryejnë auditime të rregullta nga kompani të jashtme;
- të mbështesin dhe zhvillojnë pjesëmarrjen;
- të angazhohen në siguri. 🙂
Burimi: habr.com
