di SeerLight
Costruire qualsiasi servizio implica necessariamente un lavoro costante sulla sicurezza. La sicurezza è un processo continuo che include l'analisi e il miglioramento costanti della sicurezza del prodotto, il monitoraggio delle notizie sulle vulnerabilità e molto altro. Compresi gli audit. Gli audit vengono eseguiti sia internamente che da esperti esterni, che possono aiutare radicalmente con la sicurezza perché non sono immersi nel progetto e hanno una mente aperta.
L'articolo riguarda il punto di vista più diretto degli esperti esterni che hanno aiutato il team di Mail.ru Cloud Solutions (MCS) a testare il servizio cloud e ciò che hanno scoperto. Come “forza esterna”, MCS ha scelto la società Digital Security, nota per la sua elevata esperienza negli ambienti della sicurezza informatica. E in questo articolo analizzeremo alcune interessanti vulnerabilità rilevate nell'ambito di un audit esterno, in modo da evitare la stessa commissione quando crei il tuo servizio cloud.
Описание продукта
è una piattaforma per la creazione di infrastrutture virtuali nel cloud. Include IaaS, PaaS e un marketplace di immagini di applicazioni già pronte per gli sviluppatori. Tenendo conto dell'architettura MCS, è stato necessario verificare la sicurezza del prodotto nei seguenti ambiti:
- proteggere l'infrastruttura dell'ambiente di virtualizzazione: hypervisor, routing, firewall;
- protezione delle infrastrutture virtuali dei clienti: isolamento reciproco, compresa rete, reti private in SDN;
- OpenStack e i suoi componenti aperti;
- S3 di nostra progettazione;
- IAM: progetti multi-tenant con un modello di ruolo;
- Visione (visione artificiale): API e vulnerabilità quando si lavora con le immagini;
- interfaccia web e attacchi web classici;
- vulnerabilità dei componenti PaaS;
- API di tutti i componenti.
Forse questo è tutto ciò che è essenziale per la storia futura.
Che tipo di lavoro è stato svolto e perché era necessario?
Un controllo di sicurezza ha lo scopo di identificare le vulnerabilità e gli errori di configurazione che potrebbero portare alla fuga di dati personali, alla modifica di informazioni sensibili o all'interruzione della disponibilità del servizio.
Durante il lavoro, che dura in media 1-2 mesi, gli auditor ripetono le azioni dei potenziali aggressori e cercano vulnerabilità nelle parti client e server del servizio selezionato. Nell’ambito dell’audit della piattaforma cloud MCS sono stati individuati i seguenti obiettivi:
- Analisi dell'autenticazione nel servizio. Le vulnerabilità in questo componente aiuterebbero a entrare immediatamente negli account di altre persone.
- Studio del modello di ruolo e del controllo degli accessi tra diversi account. Per un utente malintenzionato, la possibilità di accedere alla macchina virtuale di qualcun altro è un obiettivo desiderabile.
- Vulnerabilità lato client. XSS/CSRF/CRLF/ecc. È possibile attaccare altri utenti tramite collegamenti dannosi?
- Vulnerabilità lato server: RCE e tutti i tipi di iniezioni (SQL/XXE/SSRF e così via). Le vulnerabilità dei server sono generalmente più difficili da trovare, ma portano alla compromissione di molti utenti contemporaneamente.
- Analisi dell'isolamento del segmento utente a livello di rete. Per un utente malintenzionato, la mancanza di isolamento aumenta notevolmente la superficie di attacco contro altri utenti.
- Analisi della logica aziendale. È possibile ingannare le aziende e creare macchine virtuali gratuitamente?
In questo progetto, il lavoro è stato svolto secondo il modello “Gray-box”: gli auditor hanno interagito con il servizio con i privilegi degli utenti ordinari, ma possedevano parzialmente il codice sorgente dell'API e hanno avuto l'opportunità di chiarire i dettagli con gli sviluppatori. Questo di solito è il modello di lavoro più conveniente e allo stesso tempo abbastanza realistico: le informazioni interne possono ancora essere raccolte da un utente malintenzionato, è solo questione di tempo.
Vulnerabilità riscontrate
Prima che l'auditor inizi a inviare vari payload (il payload utilizzato per effettuare l'attacco) in luoghi casuali, è necessario capire come funzionano le cose e quali funzionalità vengono fornite. Può sembrare un esercizio inutile, perché nella maggior parte dei luoghi studiati non ci saranno vulnerabilità. Ma solo la comprensione della struttura dell’applicazione e della logica del suo funzionamento consentirà di individuare i vettori di attacco più complessi.
È importante trovare luoghi che sembrano sospetti o che in qualche modo sono molto diversi dagli altri. E fu così trovata la prima pericolosa vulnerabilità.
IDORO
Le vulnerabilità IDOR (Insecure Direct Object Reference) sono una delle vulnerabilità più comuni nella logica aziendale, che consente all'uno o all'altro di ottenere l'accesso a oggetti ai quali l'accesso non è effettivamente consentito. Le vulnerabilità IDOR creano la possibilità di ottenere informazioni su un utente con vari gradi di criticità.
Una delle opzioni IDOR è eseguire azioni con oggetti di sistema (utenti, conti bancari, articoli nel carrello) manipolando gli identificatori di accesso a questi oggetti. Ciò porta alle conseguenze più imprevedibili. Ad esempio la possibilità di sostituire il conto del mittente dei fondi, attraverso il quale è possibile rubarli ad altri utenti.
Nel caso di MCS, i revisori hanno appena scoperto una vulnerabilità IDOR associata a identificatori non sicuri. Nell'account personale dell'utente, gli identificatori UUID venivano utilizzati per accedere a qualsiasi oggetto che, come dicono gli esperti di sicurezza, sembrava straordinariamente insicuro (cioè protetto da attacchi di forza bruta). Ma per alcune entità, si è scoperto che vengono utilizzati numeri prevedibili regolari per ottenere informazioni sugli utenti dell'applicazione. Penso che tu possa immaginare che fosse possibile cambiare l'ID utente di uno, inviare nuovamente la richiesta e ottenere così informazioni aggirando l'ACL (lista di controllo accessi, regole di accesso ai dati per processi e utenti).
Falsificazione della richiesta lato server (SSRF)
L'aspetto positivo dei prodotti OpenSource è che dispongono di un numero enorme di forum con descrizioni tecniche dettagliate dei problemi che si presentano e, se sei fortunato, una descrizione della soluzione. Ma questa medaglia ha un rovescio della medaglia: anche le vulnerabilità conosciute vengono descritte in dettaglio. Ad esempio, ci sono meravigliose descrizioni delle vulnerabilità sul forum OpenStack и , che per qualche motivo nessuno ha fretta di risolvere.
Una funzionalità comune delle applicazioni è la possibilità per l'utente di inviare un collegamento al server, sul quale il server fa clic (ad esempio, per scaricare un'immagine da una fonte specifica). Se gli strumenti di sicurezza non filtrano i collegamenti stessi o le risposte restituite dal server agli utenti, tale funzionalità può essere facilmente utilizzata dagli aggressori.
Le vulnerabilità SSRF possono favorire notevolmente lo sviluppo di un attacco. Un utente malintenzionato può ottenere:
- accesso limitato alla rete locale attaccata, ad esempio, solo attraverso determinati segmenti di rete e utilizzando un determinato protocollo;
- pieno accesso alla rete locale, qualora sia possibile il downgrade dal livello applicativo al livello trasporto e, di conseguenza, gestione a pieno carico a livello applicativo;
- accesso in lettura ai file locali sul server (se lo schema file:/// è supportato);
- e molto altro.
In OpenStack è nota da tempo una vulnerabilità SSRF, che è di natura “cieca”: quando si contatta il server, non si riceve risposta da esso, ma si ricevono diversi tipi di errori/ritardi, a seconda dell'esito della richiesta . In base a ciò è possibile effettuare un port scan sugli host della rete interna, con tutte le conseguenze che ne conseguono da non sottovalutare. Ad esempio, un prodotto potrebbe avere un'API di back-office accessibile solo dalla rete aziendale. Con la documentazione (non dimenticare gli addetti ai lavori), un utente malintenzionato può utilizzare SSRF per accedere ai metodi interni. Ad esempio, se in qualche modo riuscissi a ottenere un elenco approssimativo di URL utili, utilizzando SSRF puoi esaminarli ed eseguire una richiesta - relativamente parlando, trasferire denaro da un conto all'altro o modificare i limiti.
Questa non è la prima volta che viene scoperta una vulnerabilità SSRF in OpenStack. In passato era possibile scaricare immagini ISO VM da un collegamento diretto, il che portava anche a conseguenze simili. Questa funzionalità è stata ora rimossa da OpenStack. Apparentemente la comunità considerava questa la soluzione più semplice e affidabile al problema.
E in rapporto disponibile pubblicamente dal servizio HackerOne (h1), lo sfruttamento di un SSRF non più cieco con la capacità di leggere i metadati dell'istanza porta all'accesso root all'intera infrastruttura Shopify.
In MCS, le vulnerabilità SSRF sono state scoperte in due luoghi con funzionalità simili, ma erano quasi impossibili da sfruttare a causa dei firewall e di altre protezioni. In un modo o nell'altro, il team MCS ha comunque risolto il problema, senza aspettare l'intervento della comunità.
XSS invece di caricare le shell
Nonostante centinaia di studi scritti, anno dopo anno l'attacco XSS (cross-site scripting) è ancora il più diffuso vulnerabilità web (o ?).
I caricamenti di file sono il luogo preferito da qualsiasi ricercatore di sicurezza. Spesso si scopre che è possibile caricare uno script arbitrario (asp/jsp/php) ed eseguire comandi del sistema operativo, nella terminologia dei pentester: "carica shell". Ma la popolarità di tali vulnerabilità funziona in entrambe le direzioni: vengono ricordate e vengono sviluppati rimedi contro di esse, tanto che recentemente la probabilità di “caricare una shell” tende a zero.
La squadra attaccante (rappresentata da Digital Security) è stata fortunata. OK, in MCS sul lato server è stato controllato il contenuto dei file scaricati, erano consentite solo le immagini. Ma SVG è anche un'immagine. In che modo le immagini SVG possono essere pericolose? Perché puoi incorporare snippet JavaScript al loro interno!
Si è scoperto che i file scaricati sono disponibili a tutti gli utenti del servizio MCS, il che significa che è possibile attaccare altri utenti del cloud, ovvero gli amministratori.
Un esempio di attacco XSS su un modulo di accesso di phishing
Esempi di sfruttamento degli attacchi XSS:
- Perché provare a rubare una sessione (soprattutto da quando ora i cookie solo HTTP sono ovunque, protetti dal furto utilizzando script js), se lo script caricato può accedere immediatamente all'API della risorsa? In questo caso, il payload può utilizzare le richieste XHR per modificare la configurazione del server, ad esempio aggiungere la chiave SSH pubblica dell'aggressore e ottenere l'accesso SSH al server.
- Se la politica CSP (content Protection Policy) impedisce l'iniezione di JavaScript, un utente malintenzionato può farne a meno. Utilizzando HTML puro, crea un modulo di accesso falso per il sito e ruba la password dell'amministratore tramite questo phishing avanzato: la pagina di phishing per l'utente finisce allo stesso URL ed è più difficile per l'utente rilevarla.
- Infine, l'attaccante può organizzare — impostare cookie di dimensioni superiori a 4 KB. L'utente deve solo aprire il collegamento una volta e l'intero sito diventa inaccessibile finché l'utente non pensa a pulire appositamente il browser: nella stragrande maggioranza dei casi, il server web si rifiuterà di accettare un simile client.
Diamo un'occhiata ad un esempio di un altro XSS rilevato, questa volta con un exploit più intelligente. Il servizio MCS consente di combinare le impostazioni del firewall in gruppi. Il nome del gruppo era quello in cui è stato rilevato l'XSS. La sua particolarità era che il vettore non si attivava immediatamente, non durante la visualizzazione dell'elenco delle regole, ma durante l'eliminazione di un gruppo:
Cioè, lo scenario si è rivelato il seguente: un utente malintenzionato crea una regola firewall con "load" nel nome, l'amministratore se ne accorge dopo un po' e avvia il processo di eliminazione. Ed è qui che funziona il JS dannoso.
Affinché gli sviluppatori MCS possano proteggersi dagli XSS nelle immagini SVG caricate (se non possono essere omesse), il team di sicurezza digitale ha consigliato:
- Posiziona 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 dominio diverso e non rappresenterà una minaccia per MCS.
- Nella risposta HTTP del server, invia l'intestazione "Content-disposition: attach". Quindi i file verranno scaricati dal browser e non eseguiti.
Inoltre, ora ci sono molti modi a disposizione degli sviluppatori per mitigare i rischi dello sfruttamento XSS:
- utilizzando il flag "Solo HTTP", puoi rendere le intestazioni "Cookie" della sessione inaccessibili a JavaScript dannoso;
- renderà molto più difficile per un utente malintenzionato sfruttare XSS;
- i moderni motori di modelli come Angular o React disinfettano automaticamente i dati dell'utente prima di inviarli al browser dell'utente.
Vulnerabilità dell'autenticazione a due fattori
Per migliorare la sicurezza dell'account, si consiglia sempre agli utenti di abilitare 2FA (autenticazione a due fattori). Si tratta infatti di un modo efficace per impedire a un utente malintenzionato di accedere a un servizio se le credenziali dell'utente sono state compromesse.
Ma l’utilizzo di un secondo fattore di autenticazione garantisce sempre la sicurezza dell’account? Esistono i seguenti problemi di sicurezza nell'implementazione della 2FA:
- Ricerca a forza bruta del codice OTP (codici monouso). Nonostante la semplicità del funzionamento, anche le grandi aziende riscontrano errori come la mancanza di protezione contro la forza bruta OTP: , .
- Algoritmo di generazione debole, ad esempio la capacità di prevedere il codice successivo.
- Errori logici, come la possibilità di richiedere l'OTP di qualcun altro sul tuo telefono, come questo da Shopify.
Nel caso di MCS, 2FA viene implementato sulla base di Google Authenticator e . Il protocollo stesso è già stato testato nel tempo, ma vale la pena verificare l'implementazione della verifica del codice sul lato dell'applicazione.
MCS 2FA viene utilizzato in diversi luoghi:
- Durante l'autenticazione dell'utente. Esiste una protezione contro la forza bruta: l'utente ha solo pochi tentativi per inserire una password monouso, quindi l'immissione viene bloccata per un po'. Ciò blocca la possibilità di selezione forzata di OTP.
- Quando si generano codici di backup offline per eseguire 2FA, oltre a disabilitarlo. Qui non è stata implementata alcuna protezione dalla forza bruta, il che ha permesso, se si aveva una password per l'account e una sessione attiva, di rigenerare i codici di backup o di disattivare completamente 2FA.
Considerando che i codici di backup si trovavano nello stesso intervallo di valori stringa di quelli generati dall'applicazione OTP, la possibilità di ritrovare il codice in breve tempo era molto più alta.
Il processo di selezione di un OTP per disabilitare 2FA utilizzando lo strumento "Burp: Intruder".
risultato
Nel complesso, la MCS sembra essere un prodotto sicuro. Durante l'audit, il team di pentesting non è stato in grado di accedere alle VM client e ai relativi dati e le vulnerabilità rilevate sono state rapidamente corrette dal team MCS.
Ma qui è importante notare che la sicurezza è un lavoro continuo. I servizi non sono statici, sono in continua evoluzione. Ed è impossibile sviluppare un prodotto completamente privo di vulnerabilità. Ma puoi trovarli in tempo e ridurre al minimo la possibilità che si ripetano.
Ora tutte le vulnerabilità menzionate in MCS sono già state corrette. E per mantenere il numero di nuovi al minimo e ridurne la durata, il team della piattaforma continua a farlo:
- condurre regolarmente audit da parte di società esterne;
- sostenere e sviluppare la partecipazione;
- impegnarsi nella sicurezza. 🙂
Fonte: habr.com