da SeerLight
Custruì ogni serviziu necessariamente include u travagliu constante nantu à a sicurità. A sicurezza hè un prucessu cuntinuu chì include l'analisi constante è a migliione di a sicurità di u produttu, u monitoraghju di e nutizie nantu à e vulnerabilità è assai di più. Cumpresi auditi. L'auditi sò realizati sia in-house sia da esperti esterni, chì ponu aiutà radicalmente cù a sicurità perchè ùn sò micca immersi in u prugettu è anu una mente aperta.
L'articulu hè nantu à sta vista più diretta di l'esperti esterni chì aiutavanu a squadra Mail.ru Cloud Solutions (MCS) à pruvà u serviziu di nuvola, è di ciò chì anu truvatu. Cum'è una "forza esterna", MCS hà sceltu a cumpagnia di Sicurezza Digitale, cunnisciuta per a so alta cumpetenza in i circles di sicurità di l'infurmazioni. È in questu articulu avemu da analizà alcune vulnerabilità interessanti truvate cum'è parte di un auditu esternu - per evitari u listessu rake quandu crea u vostru propiu serviziu di nuvola.
Descrizzione
hè una piattaforma per custruisce infrastruttura virtuale in u cloud. Include IaaS, PaaS, è un mercatu d'imaghjini di applicazioni pronti per i sviluppatori. In cunsiderà l'architettura MCS, era necessariu di verificà a sicurità di u pruduttu in i seguenti spazii:
- prutezzione di l'infrastruttura di l'ambiente di virtualizazione: ipervisori, routing, firewalls;
- prutezzione di l'infrastruttura virtuale di i clienti: isolamentu di l'altri, cumprese a rete, e rete private in SDN;
- OpenStack è i so cumpunenti aperti;
- S3 di u nostru propiu disignu;
- IAM: prughjetti multi-tenant cù un mudellu di rolu;
- Visione (visione di l'urdinatore): API è vulnerabilità quandu u travagliu cù l'imaghjini;
- interfaccia web è attacchi web classici;
- vulnerabilità di cumpunenti PaaS;
- API di tutti i cumpunenti.
Forse hè tuttu ciò chì hè essenziale per più storia.
Chì travagliu hè statu fattu è perchè era necessariu ?
Un auditu di sicurità hè destinatu à identificà vulnerabili è errori di cunfigurazione chì puderanu purtà à a fuga di dati persunali, a mudificazione di l'infurmazioni sensibili, o l'interruzzione di a dispunibilità di u serviziu.
Duranti u travagliu, chì dura in media 1-2 mesi, l'auditori repite l'azzioni di l'attaccanti putenziali è cercanu vulnerabili in e parti di u cliente è di u servitore di u serviziu sceltu. In u cuntestu di l'auditu di a piattaforma cloud MCS, i seguenti scopi sò stati identificati:
- Analisi di l'autentificazione in u serviziu. Vulnerabilità in questu cumpunente aiutanu à entra immediatamente in i cunti di l'altri.
- Studià u mudellu di rolu è u cuntrollu di l'accessu trà e diverse cunti. Per un attaccante, a capacità di accede à a macchina virtuale di qualcunu altru hè un scopu desideratu.
- Vulnerabilità di u latu di u cliente. XSS/CSRF/CRLF/etc. Hè pussibule attaccà à l'altri utilizatori attraversu ligami maliziusi?
- Vulnerabilità di u latu di u servitore: RCE è ogni tipu d'iniezioni (SQL / XXE / SSRF è cusì). I vulnerabili di u servitore sò generalmente più difficiuli di truvà, ma portanu à u cumprumissu di parechji utilizatori à una volta.
- Analisi di l'isolamentu di u segmentu di l'utilizatori à u livellu di a rete. Per un attaccante, a mancanza di isolamentu aumenta assai a superficia di attaccu contru à l'altri utilizatori.
- Analisi di a logica cummerciale. Hè pussibule ingannà l'imprese è creà macchine virtuali gratuitamente?
In questu prughjettu, u travagliu hè statu realizatu secondu u mudellu "Gray-box": l'auditori interagiscenu cù u serviziu cù i privilegi di l'utilizatori ordinali, ma pussede in parte u codice fonte di l'API è hà avutu l'uppurtunità di clarificà i dettagli cù i sviluppatori. Questu hè di solitu u più còmuda, è à u stessu tempu un mudellu di travagliu assai realistu: l'infurmazioni internu ponu sempre esse recullati da un attaccante, hè solu questione di tempu.
Vulnerabilità trovate
Prima chì l'auditore cumencia à mandà diversi carichi utili (a carichi utili per fà l'attaccu) à i lochi aleatorii, hè necessariu capisce cumu funziona e cose è chì funziunalità hè furnita. Pò esse chì questu hè un esercitu inutile, perchè in a maiò parte di i lochi studiati ùn ci sarà micca vulnerabilità. Ma solu capiscenu a struttura di l'applicazione è a logica di u so funziunamentu permetterà di truvà i vettori di attaccu più cumplessi.
Hè impurtante di truvà lochi chì pareanu suspetti o sò assai diffirenti di l'altri in qualchì modu. È a prima vulnerabilità periculosa hè stata truvata in questu modu.
IDOR
I vulnerabili IDOR (Insecure Direct Object Reference) sò una di e vulnerabilità più cumuni in a logica di l'affari, chì permette à unu o l'altru di accede à l'uggetti à quale l'accessu ùn hè micca permessu. I vulnerabili IDOR creanu a pussibilità di ottene infurmazioni nantu à un utilizatore di varii gradi di criticità.
Una di l'opzioni IDOR hè di fà l'azzioni cù l'uggetti di u sistema (utilizatori, cunti bancari, articuli in u carrettu di shopping) manipulendu l'identificatori di accessu à questi oggetti. Questu porta à e cunsequenze più imprevisible. Per esempiu, a pussibilità di rimpiazzà u contu di u mittente di fondi, per mezu di quale pudete arrubballi da altri utilizatori.
In u casu di MCS, l'auditori anu scupertu solu una vulnerabilità IDOR assuciata à identificatori micca sicuri. In u contu persunale di l'utilizatori, l'identificatori UUID sò stati utilizati per accede à qualsiasi ogetti, chì parevanu, cum'è dicenu l'esperti di sicurezza, impressiunamente inseguru (vale à dì, prutetti da attacchi di forza bruta). Ma per certi entità, hè statu scupertu chì i numeri prevedibili regulari sò usati per ottene infurmazioni nantu à l'utilizatori di l'applicazione. Pensu chì pudete guessà chì era pussibile cambià l'ID d'utilizatore per unu, mandà a dumanda di novu è cusì ottene infurmazioni bypassendu l'ACL (lista di cuntrollu di accessu, regule d'accessu di dati per i prucessi è l'utilizatori).
Falsificazione di richieste di u latu di u server (SSRF)
A bona cosa di i prudutti OpenSource hè chì anu un gran numaru di fori cù descrizzioni tecniche detallate di i prublemi chì si sviluppanu è, se site furtunatu, una descrizzione di a suluzione. Ma sta munita hà un flip side: e vulnerabilità cunnisciute sò ancu descritte in dettu. Per esempiu, ci sò descrizzioni maravigliose di vulnerabilità nantu à u foru OpenStack и , chì per una certa ragione nimu ùn hè in furia di riparà.
Una funziunalità cumuni di l'applicazioni hè a capacità per l'utilizatore per mandà un ligame à u servitore, chì u servitore cliccà nantu à (per esempiu, per scaricà una maghjina da una fonte specifica). Se l'arnesi di sicurezza ùn filtranu micca i ligami stessi o e risposte tornate da u servitore à l'utilizatori, tali funziunalità ponu esse facilmente utilizati da l'attaccanti.
A vulnerabilità SSRF pò avanzà assai u sviluppu di un attaccu. Un attaccu pò piglià:
- accessu limitatu à a reta lucale attaccata, per esempiu, solu à traversu certi segmenti di rete è utilizendu un certu protokollu;
- un accessu cumpletu à a reta lucale, se u downgrading da u livellu di l'applicazione à u nivellu di trasportu hè pussibule è, in u risultatu, a gestione di a carica completa à u livellu di l'applicazione;
- accessu à leghje i schedari lucali nantu à u servitore (se u schema file:/// hè supportatu);
- è assai più.
Una vulnerabilità SSRF hè stata cunnisciuta longu in OpenStack, chì hè "cecu" in natura: quandu cuntattate u servitore, ùn riceve micca una risposta da ellu, ma riceve diversi tipi d'errori / ritardi, secondu u risultatu di a dumanda. . Basatu nantu à questu, pudete eseguisce una scansione di portu nantu à l'ospiti in a reta interna, cù tutte e cunsequenze chì ùn deve micca esse sottovalutate. Per esempiu, un pruduttu pò avè una API back-office chì hè accessibile solu da a reta corporativa. Cù documentazione (ùn vi scurdate di l'insiders), un attaccu pò aduprà SSRF per accede à i metudi interni. Per esempiu, s'ellu era in qualchì modu capaci di ottene una lista apprussimativa di URL utili, allora usendu SSRF pudete passà per elli è eseguisce una dumanda - relativamente parlante, trasferisce soldi da un contu à un contu o cambià i limiti.
Questa ùn hè micca a prima volta chì una vulnerabilità SSRF hè stata scuperta in OpenStack. In u passatu, era pussibule di scaricà l'imagine VM ISO da un ligame direttu, chì hà ancu purtatu à cunsiquenzi simili. Questa funzione hè stata sguassata da OpenStack. Apparentemente, a cumunità hà cunsideratu questu a suluzione più simplice è affidabile à u prublema.
E in rapportu publicamente dispunibile da u serviziu HackerOne (h1), sfruttamentu di un SSRF micca più cecu cù a capacità di leghje i metadati di istanza porta à l'accessu Root à tutta l'infrastruttura Shopify.
In MCS, i vulnerabili SSRF sò stati scuperti in dui lochi cù funziunalità simili, ma eranu quasi impussibili di sfruttà per via di firewalls è altre prutezzione. In un modu o l'altru, a squadra MCS hà risoltu stu prublema in ogni modu, senza aspittà à a cumunità.
XSS invece di carricà cunchiglia
Malgradu centinaie di studii scritti, annu dopu annu l'attaccu XSS (scripting cross-site) hè sempre u più vulnerabilità web (o ?).
I caricamenti di schedari sò un locu favuritu per ogni ricercatore di sicurezza. Spessu risulta chì pudete carricà un script arbitrariu (asp/jsp/php) è eseguisce cumandamenti OS, in a terminologia di pentesters - "load shell". Ma a pupularità di tali vulnerabilità travaglia in i dui direzzione: sò ricurdati è i rimedii sò sviluppati contru à elli, perchè pocu tempu a probabilità di "carricà una cunchiglia" tende à cero.
A squadra attaccante (rapprisentatu da Digital Security) hè stata furtunata. OK, in MCS da u latu di u servitore, u cuntenutu di i fugliali scaricati hè statu verificatu, solu l'imaghjini sò permessi. Ma SVG hè ancu una stampa. Cumu l'imaghjini SVG ponu esse periculosi? Perchè pudete incrustà snippets JavaScript in elli!
Hè risultatu chì i schedarii telecaricati sò dispunibuli per tutti l'utilizatori di u serviziu MCS, chì significa chì hè pussibule attaccà à l'altri utilizatori di nuvola, à dì amministratori.
Un esempiu di un attaccu XSS à una forma di login di phishing
Esempii di sfruttamentu di attaccu XSS:
- Perchè pruvà à arrubbari una sessione (soprattuttu chì avà i cookies HTTP-Only sò in ogni locu, prutetti da u furtu cù script js), se u script caricatu pò accede immediatamente à l'API di risorse? In questu casu, u payload pò aduprà richieste XHR per cambià a cunfigurazione di u servitore, per esempiu, aghjunghje a chjave publica SSH di l'attaccante è acquistà l'accessu SSH à u servitore.
- Se a pulitica CSP (pulitica di prutezzione di cuntenutu) pruibisce JavaScript da esse injected, un attaccu pò passà senza ellu. Utilizendu HTML puru, crea una forma di login falsa per u situ è robba a password di l'amministratore per questu phishing avanzatu: a pagina di phishing per l'utilizatore finisci in u stessu URL, è hè più difficiuli per l'utilizatore per detect.
- Infine, l'attaccante pò organizà - stabilisce Cookie più grande di 4 KB. L'utilizatore solu bisognu di apre u ligame una volta, è u situ sanu diventa inaccessibile finu à chì l'utilizatore pensa à pulizziari specificamente u navigatore: in a maiò parte di i casi, u servitore web ricusarà di accettà un tali cliente.
Fighjemu un esempiu di un altru XSS rilevatu, sta volta cù un sfruttamentu più intelligente. U serviziu MCS permette di cumminà i paràmetri di firewall in gruppi. U nome di u gruppu era induve u XSS hè statu rilevatu. A so peculiarità era chì u vettore ùn hè micca attivatu immediatamente, micca quandu si vede a lista di e regule, ma quandu sguassate un gruppu:
Vale à dì, u scenariu hè statu u seguente: un attaccante crea una regula di firewall cù "carga" in u nome, l'amministratore l'avvisa dopu un pocu tempu è inizia u prucessu di eliminazione. È questu hè induve u JS maliziusu travaglia.
Per i sviluppatori MCS, per pruteggiri contr'à XSS in l'imaghjini SVG scaricati (se ùn ponu micca esse abbandunati), a squadra di Sicurezza Digitale hà cunsigliatu:
- Pone i fugliali caricati da l'utilizatori nantu à un duminiu separatu chì ùn hà nunda di fà cù "cookies". U script serà eseguitu in u cuntestu di un duminiu sfarente è ùn ponu micca una minaccia per MCS.
- In a risposta HTTP di u servitore, mandate l'intestazione "Content-disposition: attachment". Allora i schedari seranu scaricati da u navigatore è micca eseguitu.
Inoltre, ci sò avà parechje manere dispunibuli per i sviluppatori per mitigà i risichi di sfruttamentu XSS:
- usendu a bandiera "HTTP Only", pudete rende l'intestazione "Cookies" di sessione inaccessibili à JavaScript maliziusi;
- farà assai più difficiuli per un attaccu di sfruttà XSS;
- I mutori muderni di mudelli cum'è Angular o React sanitizan automaticamente i dati di l'utilizatori prima di trasmette à u navigatore di l'utilizatori.
Vulnerabilità di autentificazione à dui fattori
Per migliurà a sicurità di u contu, l'utilizatori sò sempre cunsigliati per attivà 2FA (autentificazione à dui fattori). Infatti, questu hè un modu efficau per impedisce chì un attaccu accede à l'accessu à un serviziu se e credenziali di l'utilizatori sò stati cumprumessi.
Ma l'usu di un secondu fattore d'autentificazione garantisce sempre a sicurezza di u contu? Ci sò i seguenti prublemi di sicurezza in l'implementazione di 2FA:
- Ricerca in forza bruta di u codice OTP (codici una volta). Malgradu a simplicità di u funziunamentu, l'errori cum'è a mancanza di prutezzione contra a forza bruta OTP sò ancu scontrati da e grande cumpagnie: , .
- Algoritmu di generazione debule, per esempiu a capacità di predichendu u prossimu codice.
- Errori lògichi, cum'è a capacità di dumandà l'OTP d'altru in u vostru telefunu, cum'è questu da Shopify.
In u casu di MCS, 2FA hè implementatu basatu annantu à Google Authenticator è . U protokollu stessu hè digià statu pruvatu à tempu, ma l'implementazione di a verificazione di codice in u latu di l'applicazione vale a pena di verificà.
MCS 2FA hè adupratu in parechji posti:
- Quandu autentificà l'utilizatore. Ci hè una prutezzione contra a forza bruta: l'utilizatore hà solu qualchì tentativu di inserisce una password unica, dopu l'input hè bluccatu per un tempu. Questu blucca a pussibilità di selezzione di forza bruta di OTP.
- Quandu generà codici di salvezza offline per fà 2FA, è ancu disattivà. Quì, nisuna prutezzione di forza bruta hè stata implementata, chì hà permessu, se avete avutu una password per u contu è una sessione attiva, per rinfurzà i codici di salvezza o disattivà 2FA completamente.
Cunsiderendu chì i codici di salvezza eranu situati in a listessa gamma di valori di stringa cum'è quelli generati da l'applicazione OTP, a chance di truvà u codice in pocu tempu era assai più altu.
U prucessu di selezziunà un OTP per disattivà 2FA cù u strumentu "Burp: Intruder".
risultatu
In generale, MCS pare esse sicuru cum'è un pruduttu. Duranti l'auditu, a squadra di pentesting ùn hà micca pussutu accede à i VM di u cliente è i so dati, è e vulnerabilità trovate sò state rapidamente corrette da a squadra MCS.
Ma quì hè impurtante nutà chì a sicurità hè un travagliu cuntinuu. I servizii ùn sò micca statici, sò in constante evoluzione. È hè impussibile di sviluppà un pruduttu cumpletamente senza vulnerabilità. Ma pudete truvà in u tempu è minimizzà a chance di a so recurrenza.
Avà tutti i vulnerabili citati in MCS sò digià stati riparati. È per mantene u numeru di novi à u minimu è riduce a so vita, a squadra di a piattaforma cuntinueghja à fà questu:
- realizà regolarmente audit da cumpagnie esterne;
- sustene è sviluppà a participazione;
- impegnà in a sicurità. 🙂
Source: www.habr.com