de SeerLight
Construcția oricărui serviciu include neapărat o muncă constantă asupra securității. Securitatea este un proces continuu care implică o analiză constantă și îmbunătățirea protecției produsului, monitorizarea știrilor despre vulnerabilități și multe altele. Printre acestea se numără și auditurile. Auditurile sunt efectuate atât cu forțe interne, cât și de experți externi care pot ajuta semnificativ în ceea ce privește securitatea, deoarece nu sunt implicați în proiect și au o perspectivă neblurată.
Articolul se referă tocmai la această perspectivă neblurată a experților externi care au ajutat echipa Mail.ru Cloud Solutions (MCS) să testeze serviciul cloud și la ceea ce au găsit. În calitate de „forțe externe”, MCS a ales compania Digital Security, cunoscută pentru expertiza sa ridicată în cercurile de securitate cibernetică. În acest articol, vom analiza câteva vulnerabilități interesante descoperite în cadrul auditului extern — pentru a vă ajuta să evitați aceleași capcane când veți crea propria soluție cloud.
Descrierea produsului
— este o platformă pentru construirea unei infrastructuri virtuale în cloud. Aceasta include IaaS, PaaS, un marketplace de imagini de aplicații pentru dezvoltatori. Având în vedere arhitectura MCS, a fost necesar să se verifice securitatea produsului pe următoarele direcții:
- protecția infrastructurii mediei de virtualizare: hypervizorii, rutarea, firewalls;
- protecția infrastructurii virtuale a clienților: izolare între ele, inclusiv în rețea, rețele private în SDN;
- OpenStack și componentele sale deschise;
- S3 dezvoltat intern;
- IAM: proiecte multi-tenant cu model de roluri;
- Vision (viziune computerizată): API și vulnerabilități în lucrul cu imagini;
- interfața web și atacuri web clasice;
- vulnerabilități ale componentelor PaaS;
- API-urile tuturor componentelor.
Probabil, tot ce este semnificativ pentru povestea ulterioară — cam atât.
Ce lucrări au fost efectuate și de ce sunt necesare?
Auditul de securitate are ca scop identificarea vulnerabilităților și erorilor de configurare care pot duce la scurgeri de date personale, modficări ale informațiilor sensibile sau la încălcarea disponibilității serviciilor.
În cadrul lucrărilor, care durează în medie 1-2 luni, auditorii repetă acțiunile potențialilor infractori și caută vulnerabilități atât în partea clientului, cât și în cea a serverului serviciului ales. În contextul auditului platformei cloud MCS au fost stabilite următoarele obiective:
- Analiza autentificării în serviciu. Vulnerabilitățile din acest component ar permite accesul imediat în conturi străine.
- Studiul modelului de roluri și segregării accesului între diferite conturi. Pentru un infractor, posibilitatea de a accesa o mașină virtuală străină este un obiectiv dorit.
- Vulnerabilități în partea clientului. XSS/CSRF/CRLF/etc. Există vreo posibilitate de a ataca alți utilizatori prin linkuri malițioase?
- Vulnerabilități în partea serverului: RCE și diverse injecții (SQL/XXE/SSRF etc.). Vulnerabilitățile serverului sunt, de obicei, mai greu de găsit, dar ele pot duce la compromiterea imediată a unui număr mare de utilizatori.
- Analiza izolării segmentelor utilizatorilor la nivel de rețea. Pentru un infractor, lipsa izolării crește semnificativ suprafața de atac asupra altor utilizatori.
- Analiza logicii de afaceri. Poate cineva să înșele sistemul și să creeze mașini virtuale gratuit?
În acest proiect, lucrările s-au desfășurat pe modelul 'Gray-box': auditorii au interacționat cu serviciul având privilegii de utilizatori obișnuiți, dar au avut parțial acces la codul sursă al API-ului și au putut clarifica detalii cu dezvoltatorii. De obicei, acesta este cel mai convenabil și, în același timp, suficient de realist model de lucru: informațiile interne pot fi totuși colectate de un infractor, este doar o chestiune de timp.
Vulnerabilitățile identificate
Înainte ca auditorul să înceapă să trimită diverse payload-uri (încărcături utile folosite în atac), este necesar să înțeleagă cum funcționează totul, ce funcționalitate este prezentă. Poate părea o activitate inutilă, deoarece în majoritatea locurilor studiate nu vor exista vulnerabilități. Dar doar înțelegerea structurii aplicației și a logicei sale de funcționare va permite găsirea celor mai complexe vectori de atac.
Este important să găsești locuri care par suspecte sau care diferă semnificativ de celelalte. Și prima vulnerabilitate periculoasă a fost găsită tocmai în acest mod.
IDOR
Vulnerabilitățile IDOR (Insecure Direct Object Reference, referințe directe nesecurizate la obiecte) sunt unele dintre cele mai frecvente tipuri de vulnerabilități în logica de afaceri, permițând accesul de una sau alta manieră la obiecte la care, în realitate, accesul nu este permis. Vulnerabilitățile IDOR creează posibilități de obținere a informațiilor despre utilizatori de diverse grade de criticitate.
Una dintre variantele IDOR este executarea de acțiuni asupra obiectelor sistemului (utilizatori, conturi bancare, produse în coș) prin manipularea identificatorilor de acces la aceste obiecte. Acest lucru duce la cele mai imprevizibile consecințe. De exemplu, posibilitatea de a substitui contul expeditorului de fonduri, prin care se pot fura fonduri de la alți utilizatori.
În cazul MCS, auditorii au descoperit o vulnerabilitate IDOR legată de identificatorii nesecurizați. În panoul de utilizator, pentru accesarea oricăror obiecte, erau utilizați identificatori UUID, care păreau, cum spun specialiștii în securitate, impresionant invulnerabili (adică protejați împotriva atacului prin forță brută). Însă pentru anumite entități s-a constatat că, pentru obținerea informațiilor despre utilizatorii aplicației, erau folosite numere normale, previzibile. Cred că vă dați seama că se putea schimba ID-ul utilizatorului cu unul mai mic cu o unitate, trimite din nou cererea și astfel putea obține informații ocolind ACL (lista de control acces, reguli pentru accesul la date pentru procese și utilizatori).
Server Side Request Forgery (SSRF)
Produsele open source sunt benefice deoarece există o mulțime de forumuri cu descrieri tehnice detaliate ale problemelor întâmpinate și, dacă aveți noroc, cu soluțiile acestora. Dar această medalie are și o parte negativă: vulnerabilitățile cunoscute sunt de asemenea descrise în detaliu. De exemplu, pe forumul OpenStack există descrieri excelente ale vulnerabilităților și , care din somehow nu sunt imediat corectate de nimeni.
O funcționalitate frecventă a aplicațiilor este posibilitatea ca utilizatorul să trimită un link serverului, la care serverul accesează (de exemplu, pentru a încărca o imagine din sursa specificată). În cazul în care filtrarea de către securitate a linkurilor sau a răspunsurilor returnate de server utilizatorilor este insuficientă, această funcționalitate este ușor exploatată de atacatori.
Vulnerabilitățile SSRF pot avansa semnificativ atacurile. Un atacator poate obține:
- acces limitat la rețeaua locală vizată, de exemplu doar pe anumite segmente ale rețelei și printr-un anumit protocol;
- acces complet la rețeaua locală, dacă este posibilă o degradare de la nivelul aplicației la nivelul de transport și, prin urmare, control total asupra încărcării la nivel de aplicație;
- acces la citirea fișierelor locale de pe server (dacă este suportată schema file://);
- și multe altele.
În OpenStack, o vulnerabilitate SSRF bine cunoscută are un caracter „orb”: atunci când te adresezi unui server, nu primești un răspuns, ci diverse tipuri de erori / întârzieri, în funcție de rezultatul cererii. Pe baza acestui lucru, poți efectua scanări de porturi pe gazdele din rețeaua internă, cu toate consecințele care nu trebuie subestimate. De exemplu, un produs poate avea un API pentru back-office, disponibil doar din rețeaua corporativă. Având documentația (să nu uităm de insideri), un atacator poate folosi SSRF pentru a accesa metodele interne. De exemplu, dacă a reușit cumva să obțină o listă aproximativă de URL-uri utile, atunci cu ajutorul SSRF poate naviga pe acestea și efectua cereri - să zicem, să transfere bani de pe un cont pe altul sau să schimbe limitele.
Nu este prima dată când o vulnerabilitate SSRF este descoperită în OpenStack. În trecut, exista posibilitatea de a încărca imagini ISO VM printr-un link direct, ceea ce ducea la consecințe similare. În prezent, această funcție a fost eliminată din OpenStack. Se pare că comunitatea a considerat aceasta cea mai simplă și sigură soluție la problemă.
Iar în într-un raport accesibil publicului de pe serviciul HackerOne (h1), exploatarea unei SSRF care nu este oculte cu posibilitatea de a citi metadatele instanței duce la obținerea accesului Root la întreaga infrastructură Shopify.
În MCS, au fost descoperite vulnerabilități SSRF în două locuri cu funcționalitate similară, dar erau practic imposibil de exploatat din cauza firewall-urilor și altor măsuri de protecție. Oricum, echipa MCS a corectat această problemă fără a aștepta comunitatea.
XSS în loc de încărcare a „shell-urilor”
În ciuda sutelor de cercetări scrise, de ani de zile XSS (atacul de scripting între site-uri) este în continuare cea mai vulnerabilitate web (sau ?).
Încărcarea fișierelor este locul preferat al oricărui cercetător în securitate. Adesea se dovedește că este posibil să încărcați un script arbitrar (asp/jsp/php) și să executați comenzi OS, terminologia pentesterilor fiind „încărcarea unui shell”. Dar popularitatea unor astfel de vulnerabilități funcționează în ambele sensuri: acestea sunt amintite și se dezvoltă mijloace de apărare împotriva lor, astfel că în ultima vreme probabilitatea de a „încărca un shell” tinde spre zero.
Echipei atacatoare (reprezentată de Digital Security) i-a fost noroc. Bine, în MCS pe partea serverului se verifica conținutul fișierelor încărcate, fiind permise doar imaginile. Dar SVG-urile sunt tot imagini. Ce pericole pot ascunde imaginile SVG? Faptul că din ele pot fi încorporate fragmente de JavaScript!
Se dovedește că fișierele încărcate sunt accesibile tuturor utilizatorilor serviciului MCS - ceea ce înseamnă că se pot ataca alți utilizatori ai norului, și anume - administratorii.
Exemplu de infiltrare printr-un atac XSS cu un formular de autentificare de tip phishing
Exemple de exploatare a atacului XSS:
- De ce să încerci să furii sesiunea (mai ales că acum peste tot sunt cookie-uri HTTP-Only, protejate împotriva furtului prin scripturi js), dacă scriptul încărcat poate accesa direct API-ul resursei? În acest caz, încărcătura utilă poate schimba configurația serverului prin cereri XHR, de exemplu, adăugând cheia SSH deschisă a atacatorului și obținând acces SSH la server.
- Dacă politica CSP (politica de protecție a conținutului) interzice încorporarea JavaScript-ului, atacatorul se poate descurca fără el. Pe HTML pur, poate crea un formular fals de autentificare pe site și poate fura parola administratorului printr-un phishing avansat: pagina de phishing pentru utilizator apare pe același URL, iar utilizatorului îi este mai greu să o descopere.
- În cele din urmă, atacatorul poate organiza — prin setarea cookie-urilor de dimensiuni mai mari de 4 Kbyte. Utilizatorului îi este suficient să deschidă o dată linkul - și întregul site devine inaccesibil, până nu își dă seama că trebuie să își curețe browserul: în majoritatea cazurilor, serverul web va refuza să accepte un astfel de client.
Să examinăm un alt exemplu de XSS identificat, de data aceasta cu o exploatare mai sofisticată. Serviciul MCS permite gruparea setărilor firewall-ului. XSS-ul a fost descoperit în numele grupului. Specificitatea sa consta în faptul că vectorul nu acționa imediat, nu la vizualizarea listei de reguli, ci în momentul ștergerii grupului:
Deci, scenariul era următorul: un atacator creează o regulă a firewall-ului cu un "load" în nume, administratorul o observă după un timp, inițiază procesul de ștergere. Și aici, malware-ul JS își face treaba.
Dezvoltatorii MCS, pentru a se proteja împotriva XSS în imaginile SVG încărcate (dacă nu pot renunța la ele), echipa Digital Security a recomandat:
- Să plaseze fișierele încărcate de utilizatori pe un domeniu separat, care nu are nimic de-a face cu "cookies". Scriptul va fi executat în contextul unui alt domeniu și nu va reprezenta o amenințare pentru MCS.
- În răspunsul HTTP al serverului, să se trimită header-ul "Content-disposition: attachment". Astfel, fișierele vor fi descărcate de browser, nu executate.
În plus, acum există multe modalități de a diminua riscurile exploatării XSS pentru dezvoltatori:
- prin utilizarea flag-ului "HTTP Only" pot face header-urile de sesiune "Cookies" inaccesibile pentru JavaScript-ul rău intenționat;
- va complica semnificativ exploatarea XSS pentru atacator;
- şabloanele moderne, cum ar fi Angular sau React, curăță automat datele utilizatorilor înainte de a le afișa în browser-ul utilizatorului.
Vulnerabilitățile autentificării cu doi factori
Pentru a spori securitatea conturilor, utilizatorilor li se recomandă întotdeauna să activeze 2FA (autentificarea cu doi factori). De fapt, acesta este un mod eficient de a împiedica un atacator să obțină acces la serviciu, dacă datele de autentificare ale utilizatorului au fost compromise.
Dar întotdeauna folosirea celui de-al doilea factor de autentificare oferă garanția siguranței contului? În implementarea 2FA există astfel de probleme de securitate:
- Atacuri brute asupra codului OTP (codurilor unice). În ciuda simplității exploatării, erorile precum lipsa protecției împotriva brutării OTP se întâlnesc și la mari companii: , .
- Un algoritm slab de generare, de exemplu, posibilitatea de a prezice următorul cod.
- Erori logice, de exemplu, posibilitatea de a solicita un OTP străin pe telefonul propriu, așa cum a fost la Shopify.
În cazul MCS, 2FA este implementată pe baza Google Authenticator și . Protocolul în sine a fost testat de timp, iar implementarea verificării codului pe partea aplicației merită verificată.
În MCS, 2FA este utilizată în mai multe locuri:
- În timpul autentificării utilizatorului. Există o protecție împotriva tentativelor repetate: utilizatorului i se oferă doar câteva încercări de introducere a parolei unice, apoi introducerea este blocată pentru o perioadă de timp. Aceasta blochează posibilitatea efectuării unei tentative prin forță brută pentru OTP.
- La generarea codurilor de rezervă offline pentru a efectua 2FA, precum și pentru dezactivarea acesteia. Aici nu a fost implementată o protecție împotriva tentativelor repetate, ceea ce a permis, în prezența parolei contului și a unei sesiuni active, regenerarea codurilor de rezervă sau dezactivarea completă a 2FA.
Având în vedere că codurile de rezervă erau plasate în aceeași gamă de valori a șirurilor ca și OTP-urile generate de aplicație, șansa de a ghici un cod într-un timp scurt era mult mai mare.
Procesul de ghicire a OTP-ului pentru dezactivarea 2FA cu ajutorul instrumentului „Burp: Intruder”
Rezultatul
În general, MCS ca produs s-a dovedit a fi sigur. Pe parcursul auditului, echipei de pen-testeri nu i-a reușit să acceseze VM-urile clienților și datele acestora, iar vulnerabilitățile găsite au fost rapid remediate de echipa MCS.
Dar este important de menționat că securitatea este o muncă continuă. Serviciile nu sunt statice, ele se dezvoltă constant. Iar dezvoltarea unui produs complet fără vulnerabilități este imposibilă. Totuși, este posibil să le identifici la timp și să minimizezi șansa apariției lor din nou.
Toate vulnerabilitățile menționate în MCS au fost deja remediate. Iar pentru a menține numărul celor noi la un minim și a reduce timpul de existență al acestora, echipa platformei continuă să facă următoarele:
- să efectueze audite regulat prin companii externe;
- să susțină și să dezvolte participarea;
- să se ocupe de securitate. 🙂
Sursa: habr.com
