avtor SeerLight
Gradnja katere koli storitve nujno vključuje nenehno delo na področju varnosti. Varnost je stalen proces, ki vključuje nenehno analizo in izboljšave varnosti izdelkov, spremljanje novic o ranljivostih in še veliko več. Vključno z revizijami. Revizije izvajajo tako interni kot zunanji strokovnjaki, ki lahko korenito pomagajo pri varnosti, ker niso potopljeni v projekt in so odprtega duha.
Članek govori o tem najbolj neposrednem pogledu zunanjih strokovnjakov, ki so ekipi Mail.ru Cloud Solutions (MCS) pomagali preizkusiti storitev v oblaku, in o tem, kaj so ugotovili. Kot »zunanjo silo« je MCS izbral podjetje Digital Security, znano po svojem visokem strokovnem znanju v krogih informacijske varnosti. In v tem članku bomo analizirali nekaj zanimivih ranljivosti, odkritih v okviru zunanje revizije - tako da se boste izognili enakemu deležu, ko boste ustvarili lastno storitev v oblaku.
Описание продукта
je platforma za gradnjo virtualne infrastrukture v oblaku. Vključuje IaaS, PaaS in tržnico že pripravljenih slik aplikacij za razvijalce. Glede na arhitekturo MCS je bilo potrebno preveriti varnost izdelka na naslednjih področjih:
- varovanje infrastrukture virtualizacijskega okolja: hipervizorji, usmerjanje, požarni zidovi;
- zaščita virtualne infrastrukture strank: izolacija drug od drugega, vključno z omrežjem, zasebnimi omrežji v SDN;
- OpenStack in njegove odprte komponente;
- S3 lastne zasnove;
- IAM: večnajemniški projekti z vzornikom;
- Vid (računalniški vid): API-ji in ranljivosti pri delu s slikami;
- spletni vmesnik in klasični spletni napadi;
- ranljivosti komponent PaaS;
- API vseh komponent.
Morda je to vse, kar je bistveno za nadaljnjo zgodovino.
Kakšno delo je bilo opravljeno in zakaj je bilo potrebno?
Varnostna revizija je namenjena prepoznavanju ranljivosti in konfiguracijskih napak, ki bi lahko povzročile uhajanje osebnih podatkov, spreminjanje občutljivih informacij ali motnje v razpoložljivosti storitve.
Med delom, ki v povprečju traja 1-2 meseca, revizorji ponavljajo dejanja potencialnih napadalcev in iščejo ranljivosti v odjemalskem in strežniškem delu izbrane storitve. V okviru revizije oblačne platforme MCS so bili opredeljeni naslednji cilji:
- Analiza avtentikacije v storitvi. Ranljivosti v tej komponenti bi pomagale takoj vstopiti v račune drugih ljudi.
- Preučevanje vzornika in nadzor dostopa med različnimi računi. Za napadalca je zmožnost pridobitve dostopa do virtualnega stroja nekoga drugega zaželen cilj.
- Ranljivosti na strani odjemalca. XSS/CSRF/CRLF/itd. Ali je mogoče napasti druge uporabnike prek zlonamernih povezav?
- Ranljivosti na strani strežnika: RCE in vse vrste injekcij (SQL/XXE/SSRF in tako naprej). Ranljivosti strežnika je na splošno težje najti, vendar vodijo do ogrožanja več uporabnikov hkrati.
- Analiza izolacije uporabniškega segmenta na ravni omrežja. Za napadalca pomanjkanje izolacije močno poveča površino napada proti drugim uporabnikom.
- Analiza poslovne logike. Ali je mogoče zavajati podjetja in ustvarjati virtualne stroje brezplačno?
V tem projektu je delo potekalo po modelu "Gray-box": revizorji so sodelovali s storitvijo s privilegiji navadnih uporabnikov, vendar so delno imeli izvorno kodo API-ja in imeli možnost razjasniti podrobnosti z razvijalci. Običajno je to najprimernejši in hkrati precej realističen model dela: napadalec lahko še vedno zbira notranje informacije, samo vprašanje časa je.
Najdene ranljivosti
Preden revizor začne pošiljati različne tovore (tovor, ki se uporablja za izvedbo napada) na naključna mesta, je treba razumeti, kako stvari delujejo in katere funkcionalnosti so na voljo. Morda se zdi, da je to neuporabna vaja, saj na večini preučevanih mest ne bo nobenih ranljivosti. Toda le razumevanje strukture aplikacije in logike njenega delovanja bo omogočilo iskanje najbolj zapletenih vektorjev napadov.
Pomembno je najti mesta, ki se zdijo sumljiva ali se na nek način zelo razlikujejo od drugih. In na ta način je bila najdena prva nevarna ranljivost.
IDOR
Ranljivost IDOR (Insecure Direct Object Reference) je ena najpogostejših ranljivosti v poslovni logiki, ki omogoča enemu ali drugemu dostop do objektov, do katerih dostop dejansko ni dovoljen. Ranljivosti IDOR ustvarjajo možnost pridobivanja informacij o uporabniku različnih stopenj kritičnosti.
Ena od možnosti IDOR je izvajanje dejanj s sistemskimi objekti (uporabniki, bančni računi, artikli v nakupovalnem vozičku) z manipulacijo identifikatorjev dostopa do teh objektov. To vodi do najbolj nepredvidljivih posledic. Na primer, možnost zamenjave računa pošiljatelja sredstev, prek katerega jih lahko ukradete drugim uporabnikom.
V primeru MCS so revizorji pravkar odkrili ranljivost IDOR, povezano z nezaščitenimi identifikatorji. V osebnem računu uporabnika so bili identifikatorji UUID uporabljeni za dostop do kakršnih koli predmetov, ki so se zdeli, kot pravijo varnostni strokovnjaki, izjemno nevarni (to je zaščiteni pred napadi s surovo silo). Toda za nekatere subjekte je bilo odkrito, da se redne predvidljive številke uporabljajo za pridobivanje informacij o uporabnikih aplikacije. Mislim, da lahko uganete, da je bilo mogoče ID uporabnika spremeniti za enega, znova poslati zahtevo in tako pridobiti informacije mimo ACL (seznam za nadzor dostopa, pravila za dostop do podatkov za procese in uporabnike).
Ponarejanje zahtev na strani strežnika (SSRF)
Dobra stran izdelkov OpenSource je, da imajo ogromno forumov s podrobnimi tehničnimi opisi težav, ki se pojavljajo, in če imate srečo, tudi opisom rešitve. Toda ta kovanec ima drugo stran: znane ranljivosti so tudi podrobno opisane. Na forumu OpenStack so na primer čudoviti opisi ranljivosti и , ki se iz nekega razloga nihče ne mudi popraviti.
Pogosta funkcionalnost aplikacij je zmožnost uporabnika, da strežniku pošlje povezavo, na katero strežnik klikne (na primer za prenos slike iz določenega vira). Če varnostna orodja ne filtrirajo samih povezav ali odgovorov, vrnjenih s strežnika uporabnikom, lahko takšno funkcionalnost zlahka uporabijo napadalci.
Ranljivosti SSRF lahko močno pospešijo razvoj napada. Napadalec lahko dobi:
- omejen dostop do napadenega lokalnega omrežja, na primer samo prek določenih segmentov omrežja in z uporabo določenega protokola;
- popoln dostop do lokalnega omrežja, če je možna vrnitev z aplikativnega na transportni nivo in posledično polno upravljanje obremenitve na aplikativnem nivoju;
- dostop do branja lokalnih datotek na strežniku (če je podprta shema file:///);
- in še veliko več.
V OpenStacku je že dolgo znana ranljivost SSRF, ki je po naravi »slepa«: ko vzpostavite stik s strežnikom, od njega ne prejmete odgovora, prejmete pa različne vrste napak/zakasnitev, odvisno od rezultata zahteve. . Na podlagi tega lahko izvajate skeniranje vrat na gostiteljih v notranjem omrežju z vsemi posledicami, ki jih ne smete podcenjevati. Na primer, izdelek ima lahko zaledni API, ki je dostopen samo iz omrežja podjetja. Z dokumentacijo (ne pozabite na insajderje) lahko napadalec uporabi SSRF za dostop do notranjih metod. Na primer, če ste nekako uspeli pridobiti približen seznam uporabnih URL-jev, potem lahko z uporabo SSRF pregledate njih in izvedete zahtevo - relativno rečeno, prenesete denar z računa na račun ali spremenite omejitve.
To ni prvič, da je bila v OpenStacku odkrita ranljivost SSRF. V preteklosti je bilo mogoče naložiti slike VM ISO z neposredne povezave, kar je prav tako vodilo do podobnih posledic. Ta funkcija je zdaj odstranjena iz OpenStacka. Očitno je skupnost menila, da je to najpreprostejša in najbolj zanesljiva rešitev problema.
In javno dostopno poročilo storitve HackerOne (h1), izkoriščanje ne več slepega SSRF z zmožnostjo branja metapodatkov instance vodi do korenskega dostopa do celotne infrastrukture Shopify.
V MCS so bile ranljivosti SSRF odkrite na dveh mestih s podobno funkcionalnostjo, vendar jih je bilo skoraj nemogoče izkoristiti zaradi požarnih zidov in drugih zaščit. Tako ali drugače je ekipa MCS to težavo vseeno odpravila, ne da bi čakala na skupnost.
XSS namesto nalaganja lupin
Kljub stotinam napisanih študij je napad XSS (cross-site scripting) iz leta v leto še vedno najbolj spletna ranljivost (oz ?).
Nalaganje datotek je priljubljeno mesto za vsakega raziskovalca varnosti. Pogosto se izkaže, da lahko naložite poljuben skript (asp/jsp/php) in izvedete ukaze OS, v terminologiji pentesterjev - "naloži lupino". Toda priljubljenost takšnih ranljivosti deluje v obe smeri: zapomnijo si jih in proti njim se razvijejo sredstva, tako da se v zadnjem času verjetnost »nalaganja lupine« nagiba k ničli.
Napadajoča ekipa (ki jo predstavlja Digital Security) je imela srečo. V redu, v MCS na strani strežnika je bila preverjena vsebina prenesenih datotek, dovoljene so bile samo slike. Toda SVG je tudi slika. Kako so lahko slike SVG nevarne? Ker lahko vanje vdelate delčke JavaScripta!
Izkazalo se je, da so prenesene datoteke na voljo vsem uporabnikom storitve MCS, kar pomeni, da je možno napadati tudi druge uporabnike oblaka, in sicer skrbnike.
Primer napada XSS na obrazec za prijavo z lažnim predstavljanjem
Primeri izkoriščanja napada XSS:
- Zakaj bi poskušali ukrasti sejo (še posebej, ker so zdaj piškotki samo HTTP povsod, zaščiteni pred krajo s skripti js), če lahko naloženi skript takoj dostopa do API-ja vira? V tem primeru lahko koristni tovor uporabi zahteve XHR za spremembo konfiguracije strežnika, na primer doda napadalčev javni ključ SSH in pridobi dostop SSH do strežnika.
- Če pravilnik CSP (pravilnik o zaščiti vsebine) prepoveduje vbrizgavanje JavaScripta, se lahko napadalec znajde brez njega. Z uporabo čistega HTML-ja ustvarite lažen prijavni obrazec za spletno mesto in s tem naprednim lažnim predstavljanjem ukradite skrbniško geslo: lažna stran za uporabnika konča na istem URL-ju in uporabnik jo težje zazna.
- Končno lahko napadalec poskrbi — nastavite piškotke, večje od 4 KB. Uporabnik mora le enkrat odpreti povezavo in celotno spletno mesto postane nedostopno, dokler uporabnik ne pomisli, da bi posebej očistil brskalnik: v veliki večini primerov spletni strežnik zavrne sprejem takšnega odjemalca.
Poglejmo primer drugega zaznanega XSS, tokrat z bolj pametnim izkoriščanjem. Storitev MCS omogoča združevanje nastavitev požarnega zidu v skupine. Ime skupine je bilo mesto, kjer je bil zaznan XSS. Njegova posebnost je bila, da se vektor ni sprožil takoj, ne ob ogledu seznama pravil, ampak pri brisanju skupine:
To pomeni, da se je scenarij izkazal za naslednje: napadalec ustvari pravilo požarnega zidu z "obremenitvijo" v imenu, skrbnik ga čez nekaj časa opazi in sproži postopek izbrisa. In tukaj deluje zlonamerni JS.
Za razvijalce MCS, za zaščito pred XSS v prenesenih slikah SVG (če jih ni mogoče opustiti), je skupina za digitalno varnost priporočila:
- Datoteke, ki so jih naložili uporabniki, postavite na ločeno domeno, ki nima nobene zveze s »piškotki«. Skript bo izveden v kontekstu druge domene in ne bo predstavljal nevarnosti za MCS.
- V odgovoru HTTP strežnika pošljite glavo »Content-disposition: attachment«. Nato bo brskalnik prenesel datoteke in jih ne bo izvedel.
Poleg tega je zdaj razvijalcem na voljo veliko načinov za zmanjšanje tveganja izkoriščanja XSS:
- z uporabo zastavice »Samo HTTP« lahko zlonamernemu JavaScriptu preprečite dostop do glav »Piškotki« seje;
- bo napadalcu veliko težje izkoristil XSS;
- sodobni mehanizmi predlog, kot sta Angular ali React, samodejno očistijo uporabniške podatke, preden jih izpišejo v uporabnikov brskalnik.
Ranljivosti dvofaktorske avtentikacije
Za izboljšanje varnosti računa uporabnikom vedno svetujemo, da omogočijo 2FA (dvofaktorsko preverjanje pristnosti). Dejansko je to učinkovit način, da napadalcu preprečite dostop do storitve, če so bile poverilnice uporabnika ogrožene.
Toda ali uporaba drugega faktorja preverjanja pristnosti vedno zagotavlja varnost računa? Pri izvajanju 2FA obstajajo naslednje varnostne težave:
- Surovo iskanje kode OTP (enkratne kode). Kljub enostavnosti delovanja se velika podjetja srečujejo tudi z napakami, kot je pomanjkanje zaščite pred OTP brute force: , .
- Šibek algoritem generiranja, na primer zmožnost predvidevanja naslednje kode.
- Logične napake, kot je možnost, da zahtevate enkratno geslo nekoga drugega v telefonu, kot je ta iz Shopifyja.
V primeru MCS je 2FA implementiran na podlagi Google Authenticatorja in . Sam protokol je že časovno preizkušen, vendar je vredno preveriti izvedbo preverjanja kode na strani aplikacije.
MCS 2FA se uporablja na več mestih:
- Pri preverjanju pristnosti uporabnika. Obstaja zaščita pred grobo silo: uporabnik ima le nekaj poskusov vnosa enkratnega gesla, nato pa je vnos za nekaj časa blokiran. To blokira možnost izbire OTP s surovo silo.
- Pri ustvarjanju rezervnih kod brez povezave za izvajanje 2FA, pa tudi pri onemogočanju. Tukaj ni bila implementirana nobena zaščita na podlagi surove sile, kar je omogočilo, če ste imeli geslo za račun in aktivno sejo, ponovno generiranje rezervnih kod ali popolno onemogočanje 2FA.
Glede na to, da so se rezervne kode nahajale v istem obsegu vrednosti nizov kot tiste, ki jih je ustvarila aplikacija OTP, je bila možnost, da kodo najdemo v kratkem času, veliko večja.
Postopek izbire OTP za onemogočanje 2FA z uporabo orodja »Burp: Intruder«.
Rezultat
Na splošno se zdi, da je MCS kot izdelek varen. Med revizijo skupina za pentestiranje ni mogla pridobiti dostopa do odjemalskih VM-jev in njihovih podatkov, odkrite ranljivosti pa je ekipa MCS hitro odpravila.
Toda tukaj je pomembno vedeti, da je varnost nenehno delo. Storitve niso statične, ampak se nenehno razvijajo. In nemogoče je razviti izdelek popolnoma brez ranljivosti. Lahko pa jih odkrijete pravočasno in zmanjšate možnost njihove ponovitve.
Zdaj so vse omenjene ranljivosti v MCS že odpravljene. In da bi ohranili število novih na minimum in skrajšali njihovo življenjsko dobo, ekipa platforme nadaljuje s tem:
- redno izvajati revizije s strani zunanjih podjetij;
- podpirati in razvijati sodelovanje;
- ukvarjati z varnostjo. 🙂
Vir: www.habr.com