de SeerLight
Construirea oricărui serviciu include în mod necesar munca constantă asupra securității. Securitatea este un proces continuu care include analiza constantă și îmbunătățirea securității produsului, monitorizarea știrilor despre vulnerabilități și multe altele. Inclusiv audituri. Auditurile sunt efectuate atât în interior, cât și de către experți externi, care pot ajuta radical la securitate deoarece nu sunt cufundați în proiect și au mintea deschisă.
Articolul este despre această vedere cea mai simplă a experților externi care au ajutat echipa Mail.ru Cloud Solutions (MCS) să testeze serviciul cloud și despre ceea ce au găsit. Ca „forță externă”, MCS a ales compania Digital Security, cunoscută pentru expertiza sa înaltă în cercurile de securitate a informațiilor. Și în acest articol vom analiza câteva vulnerabilități interesante găsite în cadrul unui audit extern - astfel încât să evitați același rake atunci când vă creați propriul serviciu cloud.
Описание продукта
este o platformă pentru construirea infrastructurii virtuale în cloud. Include IaaS, PaaS și o piață de imagini de aplicații gata făcute pentru dezvoltatori. Ținând cont de arhitectura MCS, a fost necesar să se verifice siguranța produsului în următoarele zone:
- protejarea infrastructurii mediului de virtualizare: hipervizoare, rutare, firewall-uri;
- protecția infrastructurii virtuale a clienților: izolarea unul de celălalt, inclusiv rețea, rețele private în SDN;
- OpenStack și componentele sale deschise;
- S3 de design propriu;
- IAM: proiecte multi-chiriași cu model de urmat;
- Viziune (viziune pe computer): API-uri și vulnerabilități atunci când lucrați cu imagini;
- interfață web și atacuri web clasice;
- vulnerabilități ale componentelor PaaS;
- API-ul tuturor componentelor.
Poate că asta este tot ceea ce este esențial pentru istoria ulterioară.
Ce fel de lucrare a fost efectuată și de ce a fost nevoie?
Un audit de securitate are ca scop identificarea vulnerabilităților și erorilor de configurare care ar putea duce la scurgeri de date personale, modificarea informațiilor sensibile sau întreruperea disponibilității serviciului.
În timpul lucrărilor, care durează în medie 1-2 luni, auditorii repetă acțiunile potențialilor atacatori și caută vulnerabilități în părțile client și server ale serviciului selectat. În contextul auditului platformei cloud MCS, au fost identificate următoarele obiective:
- Analiza autentificarii in serviciu. Vulnerabilitățile din această componentă ar ajuta la intrarea imediată în conturile altor persoane.
- Studierea modelului de rol și controlul accesului între diferite conturi. Pentru un atacator, abilitatea de a obține acces la mașina virtuală a altcuiva este un obiectiv de dorit.
- Vulnerabilități la nivelul clientului. XSS/CSRF/CRLF/etc. Este posibil să ataci alți utilizatori prin link-uri rău intenționate?
- Vulnerabilități la nivelul serverului: RCE și tot felul de injecții (SQL/XXE/SSRF și așa mai departe). Vulnerabilitățile serverului sunt în general mai dificil de găsit, dar duc la compromisul multor utilizatori simultan.
- Analiza izolării segmentului de utilizator la nivel de rețea. Pentru un atacator, lipsa izolării crește foarte mult suprafața de atac împotriva altor utilizatori.
- Analiza logicii afacerii. Este posibil să înșeli companiile și să creezi mașini virtuale gratuit?
În acest proiect, munca s-a desfășurat conform modelului „Gray-box”: auditorii au interacționat cu serviciul cu privilegiile utilizatorilor obișnuiți, dar dețineau parțial codul sursă al API-ului și au avut ocazia să clarifice detaliile cu dezvoltatorii. Acesta este de obicei cel mai convenabil și, în același timp, destul de realist model de lucru: informațiile interne pot fi în continuare colectate de către un atacator, este doar o chestiune de timp.
Vulnerabilități găsite
Înainte ca auditorul să înceapă să trimită diferite sarcini utile (sarcina utilă utilizată pentru a efectua atacul) în locuri aleatorii, este necesar să înțeleagă cum funcționează lucrurile și ce funcționalitate este furnizată. Poate părea că acesta este un exercițiu inutil, deoarece în majoritatea locurilor studiate nu vor exista vulnerabilități. Dar numai înțelegerea structurii aplicației și a logicii funcționării acesteia va face posibilă găsirea celor mai complexi vectori de atac.
Este important să găsiți locuri care par suspecte sau care sunt foarte diferite de altele într-un fel. Și prima vulnerabilitate periculoasă a fost găsită în acest fel.
IDOR
Vulnerabilitățile IDOR (Insecure Direct Object Reference) sunt una dintre cele mai comune vulnerabilități din logica afacerii, care permite unuia sau altuia să obțină acces la obiecte la care accesul nu este de fapt permis. Vulnerabilitățile IDOR creează posibilitatea de a obține informații despre un utilizator de diferite grade de criticitate.
Una dintre opțiunile IDOR este de a efectua acțiuni cu obiectele de sistem (utilizatori, conturi bancare, articole din coșul de cumpărături) prin manipularea identificatorilor de acces la aceste obiecte. Acest lucru duce la cele mai imprevizibile consecințe. De exemplu, posibilitatea înlocuirii contului expeditorului de fonduri, prin care le puteți fura de la alți utilizatori.
În cazul MCS, auditorii tocmai au descoperit o vulnerabilitate IDOR asociată cu identificatori nesiguri. În contul personal al utilizatorului, identificatorii UUID au fost utilizați pentru a accesa orice obiecte, care păreau, după cum spun experții în securitate, impresionant de nesigure (adică protejate de atacurile de forță brută). Însă pentru anumite entități, s-a descoperit că numerele obișnuite previzibile sunt folosite pentru a obține informații despre utilizatorii aplicației. Cred că puteți ghici că a fost posibil să schimbați ID-ul utilizatorului cu unul, să trimiteți din nou cererea și să obțineți astfel informații ocolind ACL (lista de control acces, reguli de acces la date pentru procese și utilizatori).
Falsificarea cererii pe partea serverului (SSRF)
Lucrul bun despre produsele OpenSource este că au un număr mare de forumuri cu descrieri tehnice detaliate ale problemelor care apar și, dacă ai noroc, o descriere a soluției. Dar această monedă are un revers: vulnerabilitățile cunoscute sunt, de asemenea, descrise în detaliu. De exemplu, există descrieri minunate ale vulnerabilităților pe forumul OpenStack и , pe care din anumite motive nimeni nu se grăbește să o repare.
O funcționalitate comună a aplicațiilor este capacitatea utilizatorului de a trimite un link către server, pe care serverul face clic (de exemplu, pentru a descărca o imagine dintr-o sursă specificată). Dacă instrumentele de securitate nu filtrează legăturile în sine sau răspunsurile returnate de la server către utilizatori, o astfel de funcționalitate poate fi utilizată cu ușurință de către atacatori.
Vulnerabilitățile SSRF pot avansa foarte mult în dezvoltarea unui atac. Un atacator poate obține:
- acces limitat la rețeaua locală atacată, de exemplu, numai prin anumite segmente de rețea și folosind un anumit protocol;
- acces deplin la rețeaua locală, dacă este posibilă retrogradarea de la nivelul de aplicație la nivelul de transport și, ca urmare, gestionarea completă a sarcinii la nivel de aplicație;
- acces pentru a citi fișierele locale de pe server (dacă este acceptată schema file:///);
- și multe altele.
O vulnerabilitate SSRF este cunoscută de mult în OpenStack, care este de natură „oarbă”: atunci când contactați serverul, nu primiți un răspuns de la acesta, dar primiți diferite tipuri de erori/întârzieri, în funcție de rezultatul solicitării. . Pe baza acestui lucru, puteți efectua o scanare de porturi pe gazdele din rețeaua internă, cu toate consecințele care decurg, care nu trebuie subestimate. De exemplu, un produs poate avea un API de back-office care este accesibil numai din rețeaua corporativă. Cu documentație (nu uitați de persoane din interior), un atacator poate folosi SSRF pentru a accesa metodele interne. De exemplu, dacă ați reușit să obțineți cumva o listă aproximativă de adrese URL utile, atunci folosind SSRF puteți să le parcurgeți și să executați o solicitare - relativ vorbind, să transferați bani de la cont la cont sau să modificați limitele.
Nu este prima dată când o vulnerabilitate SSRF este descoperită în OpenStack. În trecut, era posibil să descărcați imagini ISO VM dintr-o legătură directă, ceea ce a dus, de asemenea, la consecințe similare. Această caracteristică a fost acum eliminată din OpenStack. Aparent, comunitatea a considerat că aceasta este cea mai simplă și mai fiabilă soluție la problemă.
Și în raport disponibil public de la serviciul HackerOne (h1), exploatarea unui SSRF care nu mai oarbă cu capacitatea de a citi metadatele instanței duce la accesul root la întreaga infrastructură Shopify.
În MCS, vulnerabilitățile SSRF au fost descoperite în două locuri cu funcționalități similare, dar erau aproape imposibil de exploatat datorită firewall-urilor și altor protecții. Într-un fel sau altul, echipa MCS a rezolvat oricum această problemă, fără să aștepte comunitatea.
XSS în loc de a încărca shell-uri
În ciuda sutelor de studii scrise, an de an atacul XSS (cross-site scripting) este încă cel mai mare vulnerabilitate web (sau ?).
Încărcările de fișiere sunt locul preferat pentru orice cercetător de securitate. Se dovedește adesea că puteți încărca un script arbitrar (asp/jsp/php) și puteți executa comenzi ale sistemului de operare, în terminologia pentesterilor - „încărcare shell”. Dar popularitatea unor astfel de vulnerabilități funcționează în ambele direcții: ele sunt amintite și sunt dezvoltate remedii împotriva lor, astfel că recent probabilitatea de „încărcare a unui shell” tinde spre zero.
Echipa de atac (reprezentată de Digital Security) a avut noroc. OK, în MCS pe partea de server a fost verificat conținutul fișierelor descărcate, au fost permise doar imagini. Dar SVG este și o imagine. Cum pot fi periculoase imaginile SVG? Pentru că puteți încorpora fragmente JavaScript în ele!
S-a dovedit că fișierele descărcate sunt disponibile pentru toți utilizatorii serviciului MCS, ceea ce înseamnă că este posibil să atace alți utilizatori cloud, și anume administratorii.
Un exemplu de atac XSS asupra unui formular de conectare de tip phishing
Exemple de exploatare a atacurilor XSS:
- De ce să încerci să furi o sesiune (mai ales că acum cookie-urile HTTP-Only sunt peste tot, protejate de furt folosind scripturi js), dacă scriptul încărcat poate accesa imediat API-ul resurselor? În acest caz, sarcina utilă poate folosi solicitări XHR pentru a modifica configurația serverului, de exemplu, pentru a adăuga cheia SSH publică a atacatorului și pentru a obține acces SSH la server.
- Dacă politica CSP (politica de protecție a conținutului) interzice injectarea JavaScript, un atacator se poate descurca fără el. Folosind HTML pur, creați un formular de conectare fals pentru site și furați parola administratorului prin acest phishing avansat: pagina de phishing pentru utilizator ajunge la aceeași adresă URL și este mai dificil pentru utilizator să o detecteze.
- În cele din urmă, atacatorul poate aranja — setați cookie-uri mai mari de 4 KB. Utilizatorul trebuie să deschidă linkul o singură dată, iar întregul site devine inaccesibil până când utilizatorul se gândește să curețe în mod specific browserul: în marea majoritate a cazurilor, serverul web va refuza să accepte un astfel de client.
Să ne uităm la un exemplu de alt XSS detectat, de data aceasta cu un exploit mai inteligent. Serviciul MCS vă permite să combinați setările paravanului de protecție în grupuri. Numele grupului a fost locul în care a fost detectat XSS. Particularitatea sa a fost că vectorul nu a fost declanșat imediat, nu la vizualizarea listei de reguli, ci la ștergerea unui grup:
Adică, scenariul s-a dovedit a fi următorul: un atacator creează o regulă de firewall cu „încărcare” în nume, administratorul o observă după un timp și inițiază procesul de ștergere. Și aici funcționează JS rău intenționat.
Pentru dezvoltatorii MCS, pentru a proteja împotriva XSS în imaginile SVG descărcate (dacă nu pot fi abandonate), echipa de securitate digitală a recomandat:
- Plasați fișierele încărcate de utilizatori pe un domeniu separat care nu are nimic de-a face cu „cookie-uri”. Scriptul va fi executat în contextul unui alt domeniu și nu va reprezenta o amenințare pentru MCS.
- În răspunsul HTTP al serverului, trimiteți antetul „Content-disposition: attachment”. Apoi fișierele vor fi descărcate de browser și nu vor fi executate.
În plus, există acum multe modalități disponibile pentru dezvoltatori pentru a atenua riscurile exploatării XSS:
- folosind indicatorul „Numai HTTP”, puteți face ca anteturile „Cookies” de sesiune să fie inaccesibile pentru JavaScript rău intenționat;
- va face mult mai dificil pentru un atacator să exploateze XSS;
- motoarele de șablon moderne, cum ar fi Angular sau React, igienizează automat datele utilizatorului înainte de a le trimite în browserul utilizatorului.
Vulnerabilitati de autentificare cu doi factori
Pentru a îmbunătăți securitatea contului, utilizatorii sunt sfătuiți întotdeauna să activeze 2FA (autentificare cu doi factori). Într-adevăr, aceasta este o modalitate eficientă de a împiedica un atacator să obțină acces la un serviciu dacă acreditările utilizatorului au fost compromise.
Dar utilizarea unui al doilea factor de autentificare garantează întotdeauna siguranța contului? Există următoarele probleme de securitate în implementarea 2FA:
- Căutare prin forță brută a codului OTP (coduri unice). În ciuda simplității operațiunilor, erori precum lipsa protecției împotriva forței brute OTP sunt întâlnite și de companiile mari: , .
- Algoritm de generare slab, de exemplu capacitatea de a prezice următorul cod.
- Erori logice, cum ar fi capacitatea de a solicita OTP altcuiva pe telefonul dvs., ca aceasta de la Shopify.
În cazul MCS, 2FA este implementat pe baza Google Authenticator și . Protocolul în sine a fost deja testat în timp, dar implementarea verificării codului din partea aplicației merită verificată.
MCS 2FA este utilizat în mai multe locuri:
- La autentificarea utilizatorului. Există protecție împotriva forței brute: utilizatorul are doar câteva încercări de a introduce o parolă unică, apoi intrarea este blocată pentru o perioadă. Acest lucru blochează posibilitatea selectării OTP prin forță brută.
- Când generați coduri de rezervă offline pentru a efectua 2FA, precum și când îl dezactivați. Aici nu a fost implementată nicio protecție brută, ceea ce a făcut posibilă, dacă aveai o parolă pentru cont și o sesiune activă, să regenerezi codurile de rezervă sau să dezactivezi complet 2FA.
Având în vedere că codurile de rezervă se aflau în aceeași gamă de valori de șir cu cele generate de aplicația OTP, șansa de a găsi codul într-un timp scurt a fost mult mai mare.
Procesul de selectare a unui OTP pentru a dezactiva 2FA folosind instrumentul „Burp: Intruder”.
Rezultat
În general, MCS pare să fie sigur ca produs. În timpul auditului, echipa de testare nu a reușit să obțină acces la VM-urile client și la datele acestora, iar vulnerabilitățile găsite au fost corectate rapid de echipa MCS.
Dar aici este important de menționat că securitatea este o muncă continuă. Serviciile nu sunt statice, ele sunt în continuă evoluție. Și este imposibil să dezvoltați un produs complet fără vulnerabilități. Dar le puteți găsi la timp și puteți minimiza șansa de reapariție.
Acum toate vulnerabilitățile menționate în MCS au fost deja remediate. Și pentru a menține numărul de noi la minimum și pentru a le reduce durata de viață, echipa platformei continuă să facă acest lucru:
- efectuează în mod regulat audituri de către companii externe;
- sprijinirea și dezvoltarea participării;
- se angajează în securitate. 🙂
Sursa: www.habr.com