di SeerLight
La costruzione di qualsiasi servizio include necessariamente un lavoro costante sulla sicurezza. La sicurezza è un processo continuo, che comprende un'analisi e un miglioramento continuo della protezione del prodotto, il monitoraggio delle notizie sulle vulnerabilità e molto altro. Comprende anche gli audit. Gli audit vengono eseguiti sia internamente che da esperti esterni, che possono dare un aiuto fondamentale in materia di sicurezza, poiché non sono coinvolti nel progetto e hanno una visione non offuscata.
L'articolo parla proprio di questo sguardo non offuscato degli esperti esterni, che hanno aiutato il team di Mail.ru Cloud Solutions (MCS) a testare il servizio cloud, e di ciò che hanno trovato. Come "forze esterne", MCS ha scelto l'azienda Digital Security, nota per la sua alta expertise nei circoli della sicurezza informatica. In questo articolo esamineremo alcune vulnerabilità interessanti trovate durante l'audit esterno, affinché non vi troviate di fronte a simili ostacoli quando costruirete il vostro servizio cloud.
Descrizione del prodotto
protezione dell'infrastruttura dell'ambiente di virtualizzazione: hypervisor, routing, firewall;
- protezione dell'infrastruttura virtuale dei clienti: isolamento reciproco, inclusa la rete, reti private in SDN;
- OpenStack e i suoi componenti open source;
- S3 di sviluppo proprio;
- IAM: progetti multitenant con modello di ruolo;
- Vision (visione artificiale): API e vulnerabilità nella gestione delle immagini;
- interfaccia web e attacchi web classici;
- vulnerabilità dei componenti PaaS;
- API di tutti i componenti.
- Probabilmente, dal punto di vista significativo per la storia successiva, è tutto.
Quali lavori sono stati eseguiti e a cosa servono?
L'audit di sicurezza è finalizzato all'individuazione di vulnerabilità e errori di configurazione che possono portare a perdite di dati personali, modifica di informazioni sensibili o interruzione dei servizi.
L'audit di sicurezza è finalizzato a identificare vulnerabilità e errori di configurazione che potrebbero portare a fughe di dati personali, modifiche di informazioni sensibili o interruzioni della disponibilità dei servizi.
Durante i lavori, che durano in media 1-2 mesi, gli auditor ripetono le azioni di potenziali malintenzionati e cercano vulnerabilità nella parte client e server del servizio scelto. Nel contesto dell'audit della piattaforma cloud MCS sono stati definiti i seguenti obiettivi:
- Analisi dell'autenticazione nel servizio. Le vulnerabilità in questo componente permetterebbero di accedere immediatamente a account altrui.
- Studio del modello di ruoli e della separazione degli accessi tra diversi account. Per un malintenzionato, la possibilità di accedere a una macchina virtuale altrui è un obiettivo ambito.
- Vulnerabilità nella parte client. XSS/CSRF/CRLF/altro. Esiste la possibilità di attaccare altri utenti tramite link dannosi?
- Vulnerabilità nella parte server: RCE e iniezioni di vario tipo (SQL/XXE/SSRF e così via). Le vulnerabilità server sono generalmente più difficili da trovare, ma compromettono immediatamente un gran numero di utenti.
- Analisi dell'isolamento dei segmenti utente a livello di rete. Per un malintenzionato, la mancanza di isolamento aumenta significativamente la superficie di attacco su altri utenti.
- Analisi della logica di business. È possibile ingannare il sistema e creare macchine virtuali gratuitamente?
In questo progetto, i lavori sono stati effettuati secondo il modello "Gray-box": gli auditor interagivano con il servizio con privilegi di utenti normali, ma possedevano parzialmente i codici sorgente dell'API e potevano richiedere dettagli agli sviluppatori. Di solito questo è il modello di lavoro più conveniente e comunque abbastanza realistico: le informazioni interne possono essere comunque raccolte da un malintenzionato, è solo una questione di tempo.
Vulnerabilità trovate
Prima che l'auditor inizi a inviare diversi payload (la carico utile utilizzata per condurre l'attacco) in posti casuali, è necessario comprendere come funziona tutto, quale funzionalità è presentata. Potrebbe sembrare un'attività inutile, poiché nella maggior parte dei luoghi esaminati non ci saranno vulnerabilità. Ma solo comprendere la struttura dell'applicazione e la logica del suo funzionamento consentirà di trovare i vettori d'attacco più complessi.
È importante trovare luoghi che sembrano sospetti o differiscono notevolmente da altri. E la prima pericolosa vulnerabilità è stata trovata proprio in questo modo.
IDOR
Le vulnerabilità IDOR (Insecure Direct Object Reference, riferimento diretto non sicuro agli oggetti) sono una delle più comuni varianti di vulnerabilità nella logica aziendale, che consentono di accedere, in un modo o nell'altro, a oggetti per i quali l'accesso non è effettivamente autorizzato. Le vulnerabilità IDOR creano la possibilità di ottenere informazioni sugli utenti con vari livelli di criticità.
Una delle varianti di IDOR è l'esecuzione di azioni sugli oggetti del sistema (utenti, conti bancari, prodotti nel carrello) tramite manipolazioni con gli identificatori di accesso a questi oggetti. Ciò porta a conseguenze estremamente imprevedibili. Ad esempio, può consentire la sostituzione dell'account del mittente di fondi, consentendo di rubarli ad altri utenti.
Nel caso di MCS, gli auditor hanno scoperto una vulnerabilità IDOR legata a identificatori non sicuri. Nel pannello personale dell'utente, per accedere a qualsiasi oggetto venivano utilizzati identificatori UUID, che apparivano, come dicono gli esperti di sicurezza, notevolmente a prova di forza bruta (cioè protetti contro attacchi di brute force). Ma per alcune entità è stato scoperto che per ottenere informazioni sugli utenti dell'applicazione venivano utilizzati numeri comuni e prevedibili. Penso che possiate immaginare che sarebbe stato possibile modificare l'ID utente di uno e reinviare la richiesta per ottenere così informazioni aggirando l'ACL (Access Control List, regole di accesso ai dati per processi e utenti).
Server Side Request Forgery (SSRF)
I prodotti OpenSource sono ottimi perché esistono un numero enorme di forum con dettagliate descrizioni tecniche dei problemi che sorgono e, se siete fortunati, anche con una descrizione della soluzione. Ma c'è un rovescio della medaglia: sono anche descritte con la stessa dovizia di particolari le vulnerabilità conosciute. Ad esempio, nel forum di OpenStack ci sono ottime descrizioni di vulnerabilità e , che per qualche motivo nessuno si affretta a correggere.
Una funzionalità comune delle applicazioni è la possibilità per l'utente di inviare al server un link, su cui il server si sposta (ad esempio, per caricare un'immagine da una fonte specificata). Con una filtrazione insufficiente da parte dei mezzi di sicurezza dei link stessi o delle risposte restituite dal server, questo tipo di funzionalità viene facilmente sfruttato da malintenzionati.
Le vulnerabilità SSRF possono far avanzare significativamente lo sviluppo dell'attacco. Un attaccante può ottenere:
- accesso limitato alla rete locale attaccata, ad esempio solo in determinati segmenti della rete e utilizzando un protocollo specifico;
- accesso completo alla rete locale, se è possibile un downgrade dal livello delle applicazioni al livello di trasporto e, di conseguenza, un completo controllo del carico a livello delle applicazioni;
- accesso in lettura ai file locali sul server (se è supportato lo schema file:///);
- e molto altro.
In OpenStack è da tempo nota una vulnerabilità SSRF di tipo "cieco": quando si contatta il server non si riceve una risposta, ma si ottengono vari tipi di errori/ritardi a seconda del risultato della richiesta. Sulla base di questo è possibile eseguire la scansione delle porte sui host nella rete interna, con tutte le conseguenze, che non devono essere sottovalutate. Ad esempio, un prodotto può avere un'API per il back office, accessibile solo dalla rete aziendale. Se un attaccante dispone della documentazione (non dimentichiamo gli insider), può utilizzare SSRF per accedere ai metodi interni. Ad esempio, se è riuscito a ottenere in qualche modo un elenco approssimativo di URL utili, è possibile utilizzare SSRF per accedervi ed effettuare richieste — per dirla in modo semplice, trasferire denaro da un conto a un altro o modificare i limiti.
Non è il primo caso di rilevamento di vulnerabilità SSRF in OpenStack. In passato, c'era la possibilità di caricare le immagini ISO delle VM tramite collegamento diretto, il che portava anche a conseguenze simili. Attualmente questa funzione è stata rimossa da OpenStack. Evidentemente, la comunità ha ritenuto che fosse la soluzione più semplice e sicura per il problema.
E a In un rapporto pubblicamente accessibile del servizio HackerOne (h1), l'esploitazione di una SSRF non cieca con possibilità di lettura dei metadati dell'istanza porta all'ottenimento dell'accesso Root all'intera infrastruttura di Shopify.
In MCS sono state scoperte vulnerabilità SSRF in due posti con funzionalità simili, ma erano praticamente impossibili da sfruttare a causa dei firewall e di altre misure di protezione. In ogni caso, il team MCS ha comunque risolto questo problema, non aspettando la comunità.
XSS invece del caricamento di "shell"
Nonostante le centinaia di ricerche scritte, anno dopo anno l'XSS (cross-site scripting) è ancora la web più comune (o ?).
Il caricamento di file è il luogo preferito di qualsiasi ricercatore di sicurezza. Spesso è possibile caricare uno script arbitrario (asp/jsp/php) ed eseguire comandi di sistema operativo; nel gergo dei pentester, si dice "caricare una shell". Ma la popolarità di tali vulnerabilità opera in entrambi i sensi: se ne ricordano e sviluppano mezzi per contrastarle, pertanto la probabilità di "caricare una shell" è recentemente diminuita verso zero.
La squadra di attacco (rappresentata da Digital Security) ha avuto fortuna. Ok, in MCS, sul lato server, il contenuto dei file caricati era controllato, erano consentite solo immagini. Ma anche gli SVG sono immagini. E in cosa possono essere pericolose le immagini SVG? Nel fatto che possono contenere frammenti di JavaScript!
È emerso che i file caricati sono accessibili a tutti gli utenti del servizio MCS, il che significa che è possibile attaccare altri utenti del cloud, in particolare gli amministratori.
Esempio di iniezione tramite una XSS in un modulo di login phishing
Esempi di sfruttamento di attacchi XSS:
- Perché cercare di rubare una sessione (soprattutto considerando che ora ci sono cookie HTTP-Only, protetti contro i furti tramite script JavaScript), se lo script caricato può immediatamente accedere all'API della risorsa? In questo caso, il payload può modificare la configurazione del server tramite richieste XHR, ad esempio, aggiungere una chiave SSH aperta dell'attaccante e ottenere accesso SSH al server.
- Se la politica CSP (Content Security Policy) vieta l'iniezione di JavaScript, l'attaccante può farne a meno. Può creare una falsa pagina di accesso al sito in puro HTML e rubare la password dell'amministratore tramite tale phishing avanzato: la pagina phishing per l'utente appare allo stesso URL, e per l'utente è più difficile scoprirla.
- Infine, l'attaccante può mettere in atto — impostare cookie di dimensioni superiori a 4 KB. All'utente basta aprire un link una sola volta— e l'intero sito diventa inaccessibile, finché non si ricorda di pulire appositamente il browser: nella maggior parte dei casi, il server web rifiuterà di accettare tale client.
Esaminiamo un altro esempio di XSS identificato, questa volta con uno sfruttamento più sottile. Il servizio MCS consente di raggruppare le impostazioni del firewall. È stata scoperta una XSS nel nome del gruppo. La sua peculiarità era che il vettore non si attivava immediatamente, non durante la visualizzazione dell'elenco delle regole, ma durante l'eliminazione del gruppo:
Cioè, lo scenario era il seguente: l'attaccante crea una regola del firewall con un «carico» nel nome, l'amministratore dopo un po' la nota, avvia il processo di eliminazione. Ed è qui che il JavaScript malevolo entra in azione.
Per proteggersi dalle XSS nelle immagini SVG caricate (se non possono essere evitate), il team di Digital Security ha raccomandato agli sviluppatori di MCS:
- Di caricare i file degli utenti su un dominio separato, che non abbia nulla a che fare con i «cookie». Lo script verrà eseguito nel contesto di un altro dominio e non rappresenterà una minaccia per MCS.
- Nella risposta HTTP del server, restituire l'intestazione «Content-disposition: attachment». In questo modo, i file verranno scaricati dal browser invece di essere eseguiti.
Inoltre, ora sono disponibili molti modi per gli sviluppatori per mitigare i rischi di sfruttamento delle XSS:
- con il flag «HTTP Only» è possibile rendere le intestazioni di sessione «Cookies» inaccessibili al JavaScript maligno;
- complica notevolmente l'esploitatezione delle XSS per l'attaccante;
- i moderni motori di template, come Angular o React, puliscono automaticamente i dati degli utenti prima della visualizzazione nel browser dell'utente.
Le vulnerabilità dell'autenticazione a due fattori
Per aumentare la sicurezza degli account, agli utenti è sempre raccomandato di attivare il 2FA (autenticazione a due fattori). Infatti, è un modo efficace per impedire a un attaccante di accedere al servizio, se le credenziali dell'utente sono state compromesse.
Ma l'uso del secondo fattore di autenticazione garantisce sempre la sicurezza dell'account? Nella realizzazione del 2FA ci sono alcuni problemi di sicurezza:
- Tentativi di attacco bruteforce sul codice OTP (codici monouso). Nonostante la semplicità di sfruttamento, errori come la mancanza di protezione contro il bruteforce degli OTP si riscontrano anche in grandi aziende: , .
- Un algoritmo di generazione debole, ad esempio la possibilità di prevedere il codice successivo.
- Errori logici, ad esempio la possibilità di richiedere un OTP di qualcun altro sul proprio telefono, come è successo in Shopify.
Nel caso di MCS, il 2FA è implementato utilizzando Google Authenticator e . Il protocollo è già collaudato nel tempo, mentre l'implementazione della verifica del codice sul lato dell'applicazione dovrebbe essere esaminata.
In MCS il 2FA è utilizzato in diversi luoghi:
- Durante l'autenticazione dell'utente. Qui è presente una protezione contro il bruteforce: l'utente ha solo un numero limitato di tentativi per inserire la password monouso, dopodiché l'inserimento viene bloccato per un certo periodo. Questo blocca la possibilità di tentare di indovinare l'OTP.
- Durante la generazione di codici di backup offline per l'esecuzione del 2FA e anche per la sua disattivazione. Qui non è stata implementata alcuna protezione contro il bruteforce, il che consentiva, in presenza della password dell'account e di una sessione attiva, di rigenerare i codici di backup o di disattivare completamente il 2FA.
Considerando che i codici di backup si trovavano nello stesso intervallo di valori delle stringhe generate dall'applicazione OTP, la possibilità di indovinare un codice in breve tempo era molto più alta.
Il processo di tentativo di indovinare l'OTP per disattivare il 2FA utilizzando lo strumento "Burp: Intruder"
Risultato
In generale, MCS come prodotto si è rivelato sicuro. Durante l'audit, il team di penetration tester non è riuscito ad accedere alle VM e ai dati dei clienti, e le vulnerabilità trovate sono state rapidamente corrette dal team di MCS.
Ma è importante sottolineare che la sicurezza è un lavoro continuo. I servizi non sono statici, essi si evolvono costantemente. E sviluppare un prodotto completamente privo di vulnerabilità non è possibile. Tuttavia, è possibile trovarle tempestivamente e ridurre al minimo la possibilità di ricorrenza.
Attualmente tutte le vulnerabilità menzionate in MCS sono già state corrette. E per ridurre al minimo il numero di nuove vulnerabilità e accorciare il tempo durante il quale esistono, il team della piattaforma continua a lavorare:
- effettuare audit regolarmente da parte di aziende esterne;
- supportare e sviluppare la partecipazione;
- occuparsi della sicurezza. 🙂
Fonte: habr.com
