pateikė SeerLight
Bet kokios paslaugos kūrimas būtinai apima nuolatinį saugos darbą. Saugumas yra nuolatinis procesas, apimantis nuolatinę produkto saugumo analizę ir tobulinimą, naujienų apie pažeidžiamumą stebėjimą ir daug daugiau. Įskaitant auditą. Auditus atlieka tiek įmonės viduje, tiek išorės ekspertai, kurie gali radikaliai padėti užtikrinti saugumą, nes nėra pasinėrę į projektą ir yra atviri.
Straipsnis yra apie šį paprasčiausią išorės ekspertų, padėjusių Mail.ru Cloud Solutions (MCS) komandai išbandyti debesies paslaugą, požiūrį ir apie tai, ką jie rado. Kaip „išorinę jėgą“, MCS pasirinko „Digital Security“ bendrovę, žinomą dėl savo didelės patirties informacijos saugumo srityse. Šiame straipsnyje mes išanalizuosime keletą įdomių pažeidžiamumų, aptiktų atliekant išorinį auditą, kad išvengtumėte to paties grėblio kurdami savo debesies paslaugą.
Описание продукта
yra platforma, skirta kurti virtualią infrastruktūrą debesyje. Tai apima IaaS, PaaS ir paruoštų programų vaizdų rinką kūrėjams. Atsižvelgiant į MCS architektūrą, reikėjo patikrinti gaminio saugumą šiose srityse:
- virtualizacijos aplinkos infrastruktūros apsauga: hipervizoriai, maršrutizavimas, ugniasienės;
- klientų virtualios infrastruktūros apsauga: izoliacija vienas nuo kito, įskaitant tinklą, privačius tinklus SDN;
- OpenStack ir jo atvirieji komponentai;
- S3 mūsų pačių sukurtas;
- IAM: kelių nuomininkų projektai su sektinu pavyzdžiu;
- Vizija (kompiuterinė vizija): API ir pažeidžiamumas dirbant su vaizdais;
- žiniatinklio sąsaja ir klasikinės žiniatinklio atakos;
- PaaS komponentų pažeidžiamumas;
- Visų komponentų API.
Galbūt tai yra viskas, kas būtina tolimesnei istorijai.
Kokie darbai buvo atlikti ir kam to reikėjo?
Saugumo auditu siekiama nustatyti pažeidžiamumą ir konfigūracijos klaidas, dėl kurių gali nutekėti asmens duomenys, pakeisti neskelbtiną informaciją ar sutrikdyti paslaugų prieinamumą.
Vidutiniškai 1-2 mėnesius trunkančio darbo metu auditoriai kartoja potencialių užpuolikų veiksmus ir ieško spragų pasirinktos paslaugos kliento ir serverio dalyse. Atliekant MCS debesų platformos auditą buvo nustatyti šie tikslai:
- Autentifikavimo paslaugoje analizė. Šio komponento pažeidžiamumas padėtų iš karto patekti į kitų žmonių paskyras.
- Pavyzdžio ir skirtingų paskyrų prieigos kontrolės studijavimas. Užpuolikui galimybė gauti prieigą prie kažkieno virtualios mašinos yra pageidautinas tikslas.
- Kliento pusės pažeidžiamumas. XSS/CSRF/CRLF/ir kt. Ar galima atakuoti kitus vartotojus per kenkėjiškas nuorodas?
- Serverio pažeidžiamumas: RCE ir visokios injekcijos (SQL/XXE/SSRF ir pan.). Paprastai serverio pažeidžiamumą rasti sunkiau, tačiau dėl jų vienu metu kyla daugybė vartotojų.
- Vartotojo segmento izoliavimo tinklo lygiu analizė. Užpuoliko atveju izoliacijos trūkumas labai padidina atakos paviršių prieš kitus vartotojus.
- Verslo logikos analizė. Ar įmanoma apgauti verslus ir nemokamai kurti virtualias mašinas?
Šiame projekte darbas buvo atliktas pagal „Gray-box“ modelį: auditoriai su paslauga bendravo turėdami paprastų vartotojų privilegijas, tačiau iš dalies turėjo API pirminį kodą ir turėjo galimybę detales patikslinti su kūrėjais. Tai dažniausiai yra patogiausias, o kartu ir gana realus darbo modelis: vidinę informaciją dar gali surinkti užpuolikas, tai tik laiko klausimas.
Rasta pažeidžiamumų
Prieš auditoriui pradedant siųsti įvairius naudingus krovinius (naudingus krovinius, naudojamus atakai vykdyti) į atsitiktines vietas, reikia suprasti, kaip viskas veikia ir koks funkcionalumas yra numatytas. Gali atrodyti, kad tai nenaudingas pratimas, nes daugumoje tirtų vietų pažeidžiamumų nebus. Tačiau tik supratus programos struktūrą ir jos veikimo logiką, bus galima rasti sudėtingiausius atakos vektorius.
Svarbu rasti vietas, kurios atrodo įtartinos arba kažkuo labai skiriasi nuo kitų. Ir pirmasis pavojingas pažeidžiamumas buvo rastas tokiu būdu.
IDORAS
IDOR (Insecure Direct Object Reference) pažeidžiamumas yra vienas iš labiausiai paplitusių verslo logikos spragų, leidžiančių vienam ar kitam pasiekti objektus, prie kurių prieiga iš tikrųjų neleidžiama. IDOR pažeidžiamumas suteikia galimybę gauti informaciją apie įvairaus kritiškumo vartotoją.
Viena iš IDOR parinkčių – atlikti veiksmus su sistemos objektais (vartotojais, banko sąskaitomis, prekių krepšelyje esančiais daiktais), manipuliuojant šių objektų prieigos identifikatoriais. Tai veda prie labiausiai nenuspėjamų pasekmių. Pavyzdžiui, galimybė pakeisti lėšų siuntėjo sąskaitą, per kurią galite jas pavogti iš kitų vartotojų.
MCS atveju auditoriai ką tik aptiko IDOR pažeidžiamumą, susijusį su nesaugiais identifikatoriais. Asmeninėje vartotojo paskyroje UUID identifikatoriai buvo naudojami norint pasiekti bet kokius objektus, kurie, kaip teigia saugumo ekspertai, atrodė įspūdingai nesaugūs (tai yra apsaugoti nuo žiaurios jėgos atakų). Tačiau kai kuriems subjektams buvo nustatyta, kad norint gauti informaciją apie programos vartotojus, naudojami įprasti nuspėjami skaičiai. Manau, galite spėti, kad buvo galima pakeisti vartotojo ID vienu, išsiųsti užklausą dar kartą ir taip gauti informaciją apeinant ACL (prieigos kontrolės sąrašas, duomenų prieigos taisyklės procesams ir vartotojams).
Serverio pusės užklausos klastojimas (SSRF)
„OpenSource“ produktų pranašumas yra tas, kad jie turi daugybę forumų su išsamiais techniniais iškylančių problemų aprašymais ir, jei pasiseks, sprendimo aprašymu. Tačiau ši moneta turi ir kitą pusę: žinomos spragos taip pat išsamiai aprašytos. Pavyzdžiui, „OpenStack“ forume yra nuostabių pažeidžiamumų aprašymų и , kurio taisyti kažkodėl niekas neskuba.
Įprasta programų funkcionalumas yra galimybė vartotojui siųsti nuorodą į serverį, kurią serveris paspaudžia (pavyzdžiui, norint atsisiųsti vaizdą iš nurodyto šaltinio). Jei saugos įrankiai nefiltruoja pačių nuorodų ar iš serverio vartotojams grąžinamų atsakymų, užpuolikai gali lengvai pasinaudoti tokia funkcija.
SSRF pažeidžiamumas gali labai paspartinti atakos vystymąsi. Užpuolikas gali gauti:
- ribota prieiga prie užpulto vietinio tinklo, pavyzdžiui, tik per tam tikrus tinklo segmentus ir naudojant tam tikrą protokolą;
- visapusiška prieiga prie vietinio tinklo, jei galimas pažeminimas iš taikomosios programos lygio į transportavimo lygį ir dėl to visiškas apkrovos valdymas programos lygiu;
- prieiga skaityti vietinius failus serveryje (jei palaikoma file:/// schema);
- ir daug daugiau.
OpenStack jau seniai žinomas SSRF pažeidžiamumas, kuris yra „aklas“: kai susisiekiate su serveriu, jūs negaunate atsakymo iš jo, tačiau gaunate įvairių klaidų / vėlavimų, priklausomai nuo užklausos rezultato. . Remdamiesi tuo, galite atlikti prievado nuskaitymą vidiniame tinkle esančiuose pagrindiniuose kompiuteriuose su visomis iš to išplaukiančiomis pasekmėmis, kurių nereikėtų nuvertinti. Pavyzdžiui, produktas gali turėti „back-office“ API, kuri pasiekiama tik iš įmonės tinklo. Turėdamas dokumentus (nepamirškite apie viešai neatskleistą informaciją), užpuolikas gali naudoti SSRF, kad pasiektų vidinius metodus. Pavyzdžiui, jei jums kažkaip pavyko gauti apytikslį naudingų URL sąrašą, tada naudodami SSRF galite juos peržiūrėti ir įvykdyti užklausą - santykinai tariant, pervesti pinigus iš sąskaitos į sąskaitą arba pakeisti limitus.
Tai ne pirmas kartas, kai „OpenStack“ aptinkamas SSRF pažeidžiamumas. Anksčiau VM ISO atvaizdus buvo galima atsisiųsti iš tiesioginės nuorodos, o tai taip pat sukeldavo panašias pasekmes. Ši funkcija dabar pašalinta iš „OpenStack“. Matyt, bendruomenė tai laikė paprasčiausiu ir patikimiausiu problemos sprendimu.
Ir viešai prieinama HackerOne tarnybos ataskaita (h1), nebėra aklo SSRF išnaudojimas su galimybe nuskaityti egzempliorių metaduomenis suteikia pagrindinę prieigą prie visos Shopify infrastruktūros.
MCS SSRF pažeidžiamumai buvo aptikti dviejose panašių funkcijų vietose, tačiau jų buvo beveik neįmanoma išnaudoti dėl ugniasienės ir kitų apsaugos priemonių. Vienaip ar kitaip MCS komanda šią problemą išsprendė nelaukdama bendruomenės.
XSS, o ne įkeliant apvalkalus
Nepaisant šimtų parašytų tyrimų, metai iš metų XSS (cross-site scripting) ataka vis dar yra labiausiai paplitusi žiniatinklio pažeidžiamumas (arba ?).
Failų įkėlimas yra mėgstamiausia bet kurio saugumo tyrinėtojo vieta. Dažnai paaiškėja, kad galite įkelti savavališką scenarijų (asp/jsp/php) ir vykdyti OS komandas, pentesterių terminologijoje - „įkelti apvalkalą“. Tačiau tokių pažeidžiamumų populiarumas veikia abiem kryptimis: jie įsimenami ir prieš juos kuriamos priemonės, todėl pastaruoju metu tikimybė „įkelti apvalkalą“ siekia nulį.
Atakuojančiai komandai (kuriai atstovauja „Digital Security“) pasisekė. Gerai, MCS serverio pusėje buvo patikrintas atsisiųstų failų turinys, buvo leidžiami tik vaizdai. Tačiau SVG taip pat yra paveikslėlis. Kaip SVG vaizdai gali būti pavojingi? Nes į juos galite įterpti „JavaScript“ fragmentus!
Paaiškėjo, kad atsisiųsti failai yra prieinami visiems MCS paslaugos vartotojams, o tai reiškia, kad galima atakuoti kitus debesies vartotojus, būtent administratorius.
XSS atakos prieš sukčiavimo prisijungimo formą pavyzdys
XSS atakų išnaudojimo pavyzdžiai:
- Kam bandyti pavogti seansą (ypač dabar visur yra HTTP-Only slapukai, apsaugoti nuo vagystės naudojant js scenarijus), jei įkeltas scenarijus gali iš karto pasiekti resurso API? Tokiu atveju naudingoji apkrova gali naudoti XHR užklausas serverio konfigūracijai pakeisti, pavyzdžiui, pridėti užpuoliko viešąjį SSH raktą ir gauti SSH prieigą prie serverio.
- Jei CSP politika (turinio apsaugos politika) draudžia įvesti JavaScript, užpuolikas gali išsiversti be jo. Naudodami gryną HTML sukurkite netikrą prisijungimo prie svetainės formą ir pavogkite administratoriaus slaptažodį naudodami šį išplėstinį sukčiavimą: naudotojo sukčiavimo puslapis patenka į tą patį URL ir vartotojui jį sunkiau aptikti.
- Galiausiai užpuolikas gali susitarti — nustatyti didesnius nei 4 KB slapukus. Vartotojui tereikia vieną kartą atidaryti nuorodą ir visa svetainė tampa nepasiekiama tol, kol vartotojas nesugalvoja specialiai išvalyti naršyklės: daugeliu atvejų žiniatinklio serveris atsisako priimti tokį klientą.
Pažvelkime į kito aptikto XSS pavyzdį, šį kartą su protingesniu išnaudojimu. MCS paslauga leidžia sujungti ugniasienės nustatymus į grupes. Grupės pavadinimas buvo vieta, kur buvo aptiktas XSS. Jo ypatumas buvo tas, kad vektorius nebuvo suaktyvintas iš karto, ne peržiūrint taisyklių sąrašą, o ištrinant grupę:
Tai yra, scenarijus pasirodė toks: užpuolikas sukuria ugniasienės taisyklę, kurios pavadinime yra „įkelti“, administratorius po kurio laiko tai pastebi ir inicijuoja ištrynimo procesą. Ir čia veikia piktybinis JS.
MCS kūrėjams, siekiant apsaugoti nuo XSS atsisiųstuose SVG vaizduose (jei jų negalima atsisakyti), skaitmeninės saugos komanda rekomendavo:
- Įdėkite vartotojų įkeltus failus į atskirą domeną, kuris neturi nieko bendra su „slapukais“. Scenarijus bus vykdomas kito domeno kontekste ir nekels grėsmės MCS.
- Serverio HTTP atsakyme išsiųskite antraštę „Turinio išdėstymas: priedas“. Tada failus atsisiųs naršyklė ir jie nebus vykdomi.
Be to, dabar kūrėjams yra daug būdų, kaip sumažinti XSS išnaudojimo riziką:
- naudodami žymą „Tik HTTP“, galite padaryti seanso „Cookies“ antraštes nepasiekiamas kenkėjiškam „JavaScript“;
- užpuolikui bus daug sunkiau išnaudoti XSS;
- Šiuolaikiniai šablonų varikliai, tokie kaip Angular arba React, automatiškai išvalo vartotojo duomenis prieš išvesdami juos į vartotojo naršyklę.
Dviejų veiksnių autentifikavimo spragos
Siekiant pagerinti paskyros saugumą, vartotojams visada patariama įjungti 2FA (dviejų veiksnių autentifikavimą). Iš tiesų, tai yra veiksmingas būdas užkirsti kelią užpuolikui gauti prieigą prie paslaugos, jei vartotojo kredencialai buvo pažeisti.
Tačiau ar antrojo autentifikavimo faktoriaus naudojimas visada garantuoja paskyros saugumą? Diegiant 2FA yra šios saugos problemos:
- Brutalia jėga OTP kodo paieška (vienkartiniai kodai). Nepaisant veikimo paprastumo, didelės įmonės taip pat susiduria su tokiomis klaidomis kaip apsaugos nuo OTP brutalios jėgos trūkumas: , .
- Silpnas generavimo algoritmas, pavyzdžiui, galimybė numatyti kitą kodą.
- Tokios loginės klaidos, kaip galimybė prašyti kito asmens vienkartinio slaptažodžio jūsų telefone iš Shopify.
MCS atveju 2FA įdiegta remiantis Google Authenticator ir . Pats protokolas jau patikrintas laiko, bet kodo patikros įgyvendinimą programos pusėje verta patikrinti.
MCS 2FA naudojamas keliose vietose:
- Kai autentifikuojamas vartotojas. Yra apsauga nuo brutalios jėgos: vartotojas tik kelis kartus bando įvesti vienkartinį slaptažodį, tada įvestis kuriam laikui užblokuojama. Tai blokuoja galimybę brutalią jėgą pasirinkti OTP.
- Generuojant neprisijungus atsarginius kodus 2FA atlikti, taip pat jį išjungti. Čia nebuvo įdiegta žiaurios jėgos apsauga, kuri leido, jei turėjote paskyros slaptažodį ir aktyvią seansą, atkurti atsarginius kodus arba visiškai išjungti 2FA.
Atsižvelgiant į tai, kad atsarginiai kodai buvo tame pačiame eilutės reikšmių diapazone kaip ir tie, kuriuos sugeneravo OTP programa, tikimybė rasti kodą per trumpą laiką buvo daug didesnė.
OTP pasirinkimo procesas, norint išjungti 2FA naudojant įrankį „Burp: Intruder“.
Rezultatas
Apskritai MCS atrodo saugus kaip produktas. Per auditą bandymų komanda negalėjo gauti prieigos prie klientų VM ir jų duomenų, o MCS komanda greitai ištaisė aptiktas spragas.
Tačiau čia svarbu pažymėti, kad apsauga yra nuolatinis darbas. Paslaugos nėra statiškos, jos nuolat tobulėja. Ir neįmanoma sukurti produkto visiškai be pažeidžiamumų. Bet jūs galite juos rasti laiku ir sumažinti jų pasikartojimo tikimybę.
Dabar visos minėtos MCS spragos jau ištaisytos. Siekdama sumažinti naujų skaičių ir sutrumpinti jų tarnavimo laiką, platformos komanda ir toliau tai daro:
- reguliariai atlikti išorės įmonių auditus;
- remti ir plėtoti dalyvavimą;
- užsiimti saugumu. 🙂
Šaltinis: www.habr.com