di SeerLight
La costruzione di qualsiasi servizio implica necessariamente un lavoro costante sulla sicurezza. La sicurezza è un processo continuo che richiede un'analisi e un miglioramento costanti della robustezza del prodotto, il monitoraggio delle notizie sulle vulnerabilità e molto altro. Questo include anche audit. Gli audit vengono effettuati sia internamente che con l'aiuto di esperti esterni, i quali possono offrire un aiuto fondamentale in termini di sicurezza, poiché non sono immersi nel progetto e hanno uno sguardo più fresco.
Questo articolo riguarda proprio questo sguardo fresco 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 la società Digital Security, nota per la sua alta expertise nei circoli di sicurezza informatica. In questo articolo esamineremo alcune delle interessanti vulnerabilità scoperte durante l'audit esterno, affinché possiate evitare di incappare in simili errori quando realizzerete il vostro servizio cloud.
Descrizione del prodotto
è una piattaforma per la creazione di infrastrutture virtuali nel cloud. Include IaaS, PaaS e un marketplace di immagini di applicazioni pronte per gli sviluppatori. Considerando l'architettura di MCS, è stato necessario testare la sicurezza del prodotto nei seguenti ambiti:
- protezione dell'infrastruttura dell'ambiente di virtualizzazione: hypervisor, routing, firewall;
- protezione delle infrastrutture virtuali dei clienti: isolamento tra di loro, inclusi le reti private nel SDN;
- OpenStack e i suoi componenti aperti;
- S3 di sviluppo interno;
- IAM: progetti multitenant con modello basato su ruoli;
- 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, da ciò che è rilevante per la storia successiva - è tutto.
Quali lavori sono stati condotti e perché sono necessari?
L'audit di sicurezza è volto a identificare vulnerabilità e errori di configurazione che possono portare a fughe di dati personali, modifiche di informazioni sensibili o alla violazione 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 selezionato. Nel contesto dell’audit della piattaforma cloud MCS sono stati stabiliti i seguenti obiettivi:
- Analisi dell'autenticazione nel servizio. 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, avere accesso a una macchina virtuale altrui è un obiettivo molto ambito.
- Vulnerabilità della parte client. XSS/CSRF/CRLF/etc. È possibile che ci sia la possibilità di attaccare altri utenti tramite link dannosi?
- Vulnerabilità della parte server: RCE e vari tipi di iniezione (SQL/XXE/SSRF e così via). Le vulnerabilità server sono solitamente più difficili da trovare, ma compromettono un gran numero di utenti contemporaneamente.
- Analisi dell'isolamento dei segmenti utente a livello di rete. Per un malintenzionato, l'assenza di isolamento aumenta notevolmente la superficie di attacco sugli altri utenti.
- Analisi della logica di business. È possibile ingannare il business e creare macchine virtuali gratuitamente?
Nel progetto, i lavori sono stati condotti secondo il modello "Gray-box": gli auditor hanno interagito con il servizio con i diritti di utenti normali, ma possedevano parzialmente i codici sorgente delle API e hanno potuto chiarire dettagli con gli sviluppatori. Di solito questo è il modello di lavoro più comodo e realistico: le informazioni interne possono comunque essere raccolte da un malintenzionato, è solo questione di tempo.
Vulnerabilità trovate
Prima che l'auditor inizi a inviare vari payload (dati utilizzati per condurre l'attacco) in luoghi casuali, è necessario capire come funziona tutto, quale funzionalità è presente. Può sembrare un'attività inutile, poiché nella maggior parte dei luoghi studiati non ci saranno vulnerabilità. Ma solo comprendere la struttura dell'applicazione e la logica del suo funzionamento permetterà di trovare i vettori d'attacco più complessi.
È importante individuare luoghi che sembrano sospetti o che differiscono notevolmente dagli altri. La prima pericolosa vulnerabilità è stata trovata proprio in questo modo.
IDOR
Le vulnerabilità IDOR (Insecure Direct Object Reference, riferimenti diretti non sicuri agli oggetti) sono una delle vulnerabilità più comuni nella logica aziendale, che consentono in vari modi di accedere a oggetti per i quali l'accesso non è effettivamente autorizzato. Le vulnerabilità IDOR creano opportunità di accesso a informazioni utente di diversa gravità.
Una delle varianti di IDOR è l'esecuzione di azioni su oggetti di sistema (utenti, conti bancari, prodotti nel carrello) attraverso la manipolazione degli identificatori per accedere a tali oggetti. Questo porta a conseguenze imprevedibili. Ad esempio, c'è il rischio di sostituire l'account del mittente di fondi, consentendo il furto di denaro da parte di altri utenti.
Nel caso di MCS, gli auditor hanno scoperto una vulnerabilità IDOR relativa agli identificatori non sicuri. Nella dashboard dell'utente, per accedere a qualsiasi oggetto venivano utilizzati identificatori UUID, che apparivano, come dicono gli esperti di sicurezza, impressionantemente non vulnerabili (cioè protetti da attacchi di forza bruta). Tuttavia, sono stati identificati casi in cui si utilizzavano numeri semplici e prevedibili per ottenere informazioni sugli utenti dell'applicazione. Penso che tu possa immaginare che bastava aumentare l'ID dell'utente di uno, reinviare la richiesta e ottenere così informazioni al di fuori dell'ACL (access control list, regole di accesso ai dati per processi e utenti).
Server Side Request Forgery (SSRF)
I prodotti OpenSource sono vantaggiosi poiché ci sono numerosi forum con dettagliate descrizioni tecniche dei problemi e, se sei fortunato, anche delle soluzioni. Ma questa medaglia ha un rovescio: anche le vulnerabilità note sono descritte in modo dettagliato. Ad esempio, sul forum di OpenStack ci sono ottime descrizioni delle 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, al quale il server accede (ad esempio, per caricare un'immagine da una fonte designata). Senza una sufficiente filtrazione da parte degli strumenti di sicurezza, questo tipo di funzionalità può essere facilmente sfruttata da malintenzionati.
Le vulnerabilità SSRF possono significare un avanzamento significativo dell'attacco. Il malintenzionato può ottenere:
- accesso limitato alla rete locale attaccata, ad esempio solo su determinati segmenti di rete e tramite un protocollo specifico;
- accesso completo alla rete locale, se è possibile un downgrade dal livello applicativo a quello di trasporto e, di conseguenza, gestione totale del carico a livello applicativo;
- accesso alla lettura di file locali sul server (se è supportato lo schema file:///);
- e molto altro.
In OpenStack è da tempo nota una vulnerabilità SSRF di tipo 'cieco': richiedendo al server, non si riceve risposta, ma si ottengono vari tipi di errori/ritardi, a seconda del risultato della richiesta. Questo consente di eseguire una scansione delle porte degli host sulla rete interna, con tutte le conseguenze del caso, che non si devono sottovalutare. Ad esempio, il prodotto potrebbe avere un'API per il back office, accessibile solo dalla rete aziendale. Con la documentazione (non dimentichiamo gli insider), un malintenzionato potrebbe utilizzare SSRF per contattare metodi interni. Ad esempio, se è riuscito ad ottenere un elenco approssimativo di URL utili, potrebbe utilizzare SSRF per passare attraverso di essi e fare una richiesta — in termini semplici, trasferire denaro da un conto all'altro o modificare i limiti.
Non è il primo caso di vulnerabilità SSRF scoperto in OpenStack. In passato, era possibile caricare immagini ISO delle VM tramite link diretti, il che ha portato a conseguenze simili. Attualmente, questa funzionalità è stata rimossa da OpenStack. Evidentemente, la comunità ha ritenuto che ciò fosse la soluzione più semplice e sicura al problema.
E in In un rapporto pubblico del servizio HackerOne (h1), l'exploitation di una SSRF non cieca con la possibilità di leggere metadati dell'istanza porta al conseguimento dell'accesso Root a tutta l'infrastruttura di Shopify.
Nel MCS sono state trovate vulnerabilità SSRF in due punti con funzionalità simile, ma erano praticamente impossibili da sfruttare a causa dei firewall e di altre protezioni. Tuttavia, il team di MCS ha comunque corretto questo problema, senza attendere la comunità.
XSS invece di caricare 'shell'
Nonostante centinaia di ricerche scritte, anno dopo anno XSS (attacco di cross-site scripting) rimane la (o ?).
Il caricamento dei file è il posto preferito di ogni ricercatore di sicurezza. Spesso è possibile caricare script arbitrari (asp/jsp/php) e eseguire comandi di sistema operativo, nella terminologia dei pentester – "caricare una shell". Tuttavia, la popolarità di tali vulnerabilità gioca a doppio filo: se ne tiene conto e vengono sviluppati strumenti contro di esse, quindi ultimamente la probabilità di "caricare una shell" si avvicina a zero.
Il team di attacco (rappresentato da Digital Security) è stato fortunato. Infatti, in MCS, sul lato server, il contenuto dei file caricati veniva controllato, e solo le immagini erano consentite. Ma un SVG è considerato un'immagine. Quali rischi possono presentare le immagini SVG? Quello che si può fare è incorporare frammenti di JavaScript!
Si è scoperto 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 sfruttamento tramite un attacco XSS di un modulo di login phishing
Esempi di sfruttamento di un attacco XSS:
- Perché tentare di rubare una sessione (soprattutto considerando che ora ovunque ci sono cookie HTTP-Only, protetti contro il furto tramite script js), se lo script caricato può accedere immediatamente all'API della risorsa? In questo caso, il payload può cambiare la configurazione del server tramite richieste XHR, ad esempio, aggiungendo la chiave SSH dell'aggressore e ottenendo accesso SSH al server.
- Se la politica CSP (Content Security Policy) vieta l'inserimento di JavaScript, l'aggressore può farne a meno. Può creare una falsa pagina HTML di accesso al sito e rubare la password dell'amministratore tramite un phishing avanzato: la pagina phishing per l'utente appare allo stesso URL, rendendo più difficile per l'utente rilevarla.
- Infine, l'aggressore può organizzare – impostare cookie di dimensioni superiori a 4 KB. All'utente basta aprire il link una sola volta – e l'intero sito diventa inaccessibile, finché non si accorge di dover pulire il browser: nella stragrande maggioranza dei casi, il server web rifiuterà di accettare tale client.
Esaminiamo un esempio di un'altra vulnerabilità XSS identificata, questa volta con un sfruttamento più astuto. Il servizio MCS permette di raggruppare le impostazioni del firewall. Nel nome del gruppo è stata trovata l'XSS. La sua particolarità era che il vettore non si attivava immediatamente, non durante la visualizzazione dell'elenco delle regole, ma durante la cancellazione del gruppo:
Cioè, lo scenario era il seguente: l'aggressore crea una regola del firewall con un "payload" nel nome, l'amministratore, dopo un po', se ne accorge e avvia il processo di cancellazione. E qui il JS malevolo entra in azione.
Per proteggersi dall'XSS nelle immagini SVG caricate (se non ci si può rinunciare), il team di Digital Security ha raccomandato agli sviluppatori di MCS di:
- Archiviare i file caricati dagli utenti su un dominio separato, che non ha nulla a che fare con i "cookie". Lo script verrà eseguito nel contesto di un altro dominio e non rappresenterà una minaccia per MCS.
- Nel response HTTP del server restituire l'intestazione "Content-disposition: attachment". In questo modo i file saranno scaricati dal browser e non eseguiti.
Inoltre, ora per gli sviluppatori ci sono molti modi per mitigare i rischi di sfruttamento dell'XSS:
- utilizzando il flag "HTTP Only" si possono rendere gli header di sessione "Cookies" inaccessibili a JavaScript malevolo;
- complica notevolmente lo sfruttamento dell'XSS da parte di un aggressore;
- moderni motori di templating, come Angular o React, puliscono automaticamente i dati degli utenti prima di mostrarli nel browser dell'utente.
Vulnerabilità dell'autenticazione a due fattori
Per aumentare la sicurezza degli account, si consiglia sempre agli utenti di abilitare la 2FA (autenticazione a due fattori). Infatti, è un modo efficace per impedire a un aggressore 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 della 2FA ci possono essere problemi di sicurezza:
- Tentativi di brute forcing del codice OTP (codici usa e getta). Nonostante la semplicità di sfruttamento, errori come l'assenza di protezione contro il brute force dell'OTP si riscontrano anche nelle grandi aziende: , .
- 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 accaduto in Shopify.
Nel caso di MCS, la 2FA è implementata sulla base di Google Authenticator e . Il protocollo stesso è già testato nel tempo, ma vale la pena verificare l'implementazione della verifica del codice lato applicazione.
In MCS, la 2FA è utilizzata in diversi luoghi:
- Durante l'autenticazione dell'utente. Qui c'è una protezione contro i tentativi: l'utente ha solo un numero ristretto di tentativi di inserimento della password temporanea, dopo di che l'inserimento viene bloccato per un certo periodo. Questo blocca la possibilità di eseguire un attacco di tipo brute force sull'OTP.
- Durante la generazione di codici di backup off-line per l'esecuzione del 2FA, così come per la sua disattivazione. Qui non è stata implementata alcuna protezione contro i tentativi, permettendo così, in presenza della password dell'account e di una sessione attiva, di rigenerare i codici di backup o disattivare completamente il 2FA.
Considerando che i codici di backup si trovavano nello stesso intervallo dei valori delle stringhe generate dall'app per l'OTP, la probabilità di indovinare il codice in breve tempo era notevolmente più alta.
Il processo di indovinare l'OTP per disattivare il 2FA utilizzando lo strumento "Burp: Intruder"
Risultato
In generale, MCS si è rivelato un prodotto sicuro. Durante l'audit, il team di penetration tester non è riuscito ad accedere alle VM dei clienti e ai loro dati, e le vulnerabilità trovate sono state rapidamente risolte dal team di MCS.
Tuttavia, è importante sottolineare che la sicurezza è un lavoro continuo. I servizi non sono statici, si sviluppano costantemente. Creare un prodotto completamente privo di vulnerabilità è impossibile. Ma è possibile individuarle in tempo e ridurre al minimo la possibilità di ripetizione.
Attualmente tutte le vulnerabilità menzionate in MCS sono già state risolte. E per mantenere al minimo l'emergere di nuovi problemi e ridurre il tempo di esistenza di quelli esistenti, il team della piattaforma continua a fare quanto segue:
- effettuare audit regolari da parte di aziende esterne;
- sostenere e sviluppare la partecipazione;
- occupaarsi di sicurezza. 🙂
Fonte: habr.com
