{"id":32603,"date":"2019-10-31T21:47:55","date_gmt":"2019-10-31T18:47:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya\/"},"modified":"2019-10-31T21:47:55","modified_gmt":"2019-10-31T18:47:55","slug":"potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya","title":{"rendered":"Attacchi potenziali a HTTPS e come proteggersi da essi.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La met\u00e0 dei siti web utilizza HTTPS<\/a><\/noindex>, e il loro numero \u00e8 in costante aumento. Il protocollo riduce il rischio di intercettazione del traffico, ma non esclude tentativi di attacco veri e propri. Di alcuni di essi - POODLE, BEAST, DROWN e altri - e dei modi per difendersi, parleremo nel nostro articolo.<\/p>\n

\"Attacchi <\/a><\/noindex><\/a><\/noindex>
\n\/ Flickr \/ Sven Graeme<\/a><\/noindex> \/ CC BY-SA<\/i><\/p>\n

POODLE<\/h2>\n

\nLa prima notizia dell'attacco POODLE<\/a><\/noindex> \u00e8 emersa nel 2014. La vulnerabilit\u00e0 nel protocollo SSL 3.0 \u00e8 stata scoperta dall'esperto di sicurezza Bodo M\u00f6ller e dai suoi colleghi di Google.<\/p>\n

La sua essenza \u00e8 la seguente: un hacker costringe il client a connettersi tramite SSL 3.0, simulando disconnessioni. Poi cerca nei dati crittografati in CBC<\/a><\/noindex>-modalit\u00e0 messaggi speciali e marcatori. Con una serie di richieste contraffatte, l'attaccante pu\u00f2 ricostruire il contenuto dei dati che lo interessano, come ad esempio i cookie.<\/p>\n

SSL 3.0 \u00e8 un protocollo obsoleto. Ma la questione della sua sicurezza \u00e8 ancora attuale. I clienti lo utilizzano per evitare problemi di compatibilit\u00e0 con i server. Secondo alcuni dati, quasi il 7% delle 100.000 pi\u00f9 popolari siti web supportano ancora SSL 3.0<\/a><\/noindex>. Inoltre ci sono<\/a><\/noindex> modifiche di POODLE, che prendono di mira le versioni pi\u00f9 moderne TLS 1.0 e TLS 1.1. Quest'anno sono emerse<\/a><\/noindex> nuovi attacchi Zombie POODLE e GOLDENDOODLE, che aggirano la protezione di TLS 1.2 (sono ancora legati alla crittografia CBC).<\/p>\n

Come proteggersi.<\/b> Nel caso dell'originale POODLE, \u00e8 necessario disattivare il supporto per SSL 3.0. Tuttavia, in questo caso, c'\u00e8 il rischio di avere problemi di compatibilit\u00e0. Una soluzione alternativa potrebbe essere il meccanismo TLS_FALLBACK_SCSV: garantisce che lo scambio di dati tramite SSL 3.0 avvenga solo con sistemi obsoleti. Gli attaccanti non possono pi\u00f9 forzare il downgrade del protocollo. Un modo per proteggersi da Zombie POODLE e GOLDENDOODLE \u00e8 disattivare il supporto per CBC nelle applicazioni basate su TLS 1.2. Una soluzione radicale sarebbe passare a TLS 1.3: nella nuova versione del protocollo non viene utilizzata la crittografia CBC. Invece, vengono utilizzati metodi pi\u00f9 resistenti come AES e ChaCha20.<\/p>\n

BEAST<\/h2>\n

\nUno dei primi attacchi su SSL e TLS 1.0, scoperto nel 2011. Come POODLE, anche BEAST utilizza<\/a><\/noindex> caratteristiche della crittografia CBC. Gli aggressori inseriscono un agente JavaScript o un applet Java nella macchina client, che sostituisce i messaggi durante la trasmissione dei dati su TLS o SSL. Poich\u00e9 gli aggressori conoscono il contenuto dei pacchetti \"falsi\", possono utilizzarli per decifrare il vettore di inizializzazione e leggere gli altri messaggi al server, come ad esempio i cookie per l'autenticazione.<\/p>\n

Ad oggi, le vulnerabilit\u00e0 BEAST continuano a essere presenti in vari strumenti di rete<\/a><\/noindex>: proxy server e applicazioni per proteggere i gateway internet locali.<\/p>\n

Come proteggersi.<\/b> L'attaccante deve inviare richieste regolarmente per decifrare i dati. In VMware La filosofia del DevOps. L'arte di gestire l'IT<\/a><\/noindex> ridurre la durata di SSLSessionCacheTimeout \u2014 da cinque minuti (consiglio predefinito) a 30 secondi. Questo approccio complicher\u00e0 l'implementazione dei piani da parte degli aggressori, sebbene possa avere alcuni effetti negativi sulle prestazioni. Inoltre, \u00e8 necessario comprendere che in un prossimo futuro la vulnerabilit\u00e0 BEAST potrebbe scomparire da sola \u2014 dal 2020 i principali browser cesseranno<\/a><\/noindex> il supporto per TLS 1.0 e 1.1. In ogni caso, con questi protocolli opera meno dell'1,5% di tutti gli utenti dei browser.<\/p>\n

DROWN<\/h2>\n

\nQuesta \u00e8 un'attacco cross-protocol che sfrutta errori nell'implementazione di SSLv2 con chiavi RSA a 40 bit. L'aggressore intercetta centinaia di connessioni TLS della vittima e invia pacchetti specifici a un server con SSLv2, che utilizza la stessa chiave privata. Utilizzando l'attacco di Bleichenbacher,<\/a><\/noindex>l'hacker pu\u00f2 decifrare una delle circa mille sessioni TLS del cliente.<\/p>\n

O DROWN \u00e8 stata conosciuta per la prima volta nel 2016 \u2014 allora era vulnerabile un terzo dei server<\/a><\/noindex> nel mondo. Ad oggi, non ha perso rilevanza. Tra le 150.000 siti pi\u00f9 popolari, il 2% supporta ancora supportano<\/a><\/noindex> SSLv2 e meccanismi di crittografia vulnerabili.<\/p>\n

Come proteggersi.<\/b> \u00c8 necessario installare le patch proposte dagli sviluppatori delle librerie crittografiche, disabilitando il supporto per SSLv2. Ad esempio, sono state presentate due di queste patch per OpenSSL (nel 2016 erano aggiornamenti<\/a><\/noindex> 1.0.1s e 1.0.2g). Inoltre, aggiornamenti e istruzioni per disabilitare il protocollo vulnerabile sono stati pubblicati in Red Hat<\/a><\/noindex>, Apache<\/a><\/noindex>, Debian<\/a><\/noindex>.<\/p>\n

\"Una risorsa pu\u00f2 essere vulnerabile a DROWN se le sue chiavi sono utilizzate da un server di terze parti con SSLv2, come un server di posta, - osserva il capo del dipartimento di sviluppo del fornitore IaaS 1cloud.ru<\/a><\/noindex> Sergey Belkin. \u2014 Questa situazione si verifica se pi\u00f9 server utilizzano un certificato SSL condiviso. In questo caso, la supporto a SSLv2 deve essere disabilitato su tutte le macchine.<\/i><\/p><\/blockquote>\n

\nPer verificare se \u00e8 necessario aggiornare il proprio sistema, \u00e8 possibile utilizzare un apposito utilitario<\/a><\/noindex> \u2014 \u00e8 stato sviluppato da specialisti di sicurezza informatica che hanno scoperto DROWN. Maggiori informazioni sulle raccomandazioni relative alla protezione da questo tipo di attacchi possono essere trovate nel post sul sito OpenSSL<\/a><\/noindex>.<\/p>\n

Heartbleed<\/h2>\n

\nUna delle vulnerabilit\u00e0 pi\u00f9 gravi nel software \u2014 Heartbleed<\/a><\/noindex>. \u00c8 stata scoperta nel 2014 nella libreria OpenSSL. Al momento dell'annuncio dell'errore, il numero di siti web vulnerabili era stimato intorno a mezzo milione<\/a><\/noindex> \u2014 circa il 17% delle risorse protette in rete.<\/p>\n

L'attacco viene realizzato tramite un piccolo modulo di estensione TLS Heartbeat. Il protocollo TLS richiede che i dati vengano trasmessi continuamente. In caso di inattivit\u00e0 prolungata, si verifica un'interruzione e la connessione deve essere ripristinata. Per affrontare il problema, server e client \"falsano\" artificialmente il canale (RFC 6520, pag. 5<\/a><\/noindex>), inviando pacchetti di lunghezza casuale. Se questi pacchetti superano la lunghezza prevista, le versioni vulnerabili di OpenSSL leggevano la memoria oltre il buffer assegnato. In quest'area potevano trovarsi dati sensibili, inclusi le chiavi di crittografia e informazioni su altre connessioni.<\/p>\n

La vulnerabilit\u00e0 era presente in tutte le versioni della libreria da 1.0.1 a 1.0.1f inclusa, cos\u00ec come in diversi sistemi operativi \u2014 Ubuntu fino alla 12.04.4, CentOS superiori alla 6.5, OpenBSD 5.3 e altri. Un elenco completo \u00e8 disponibile sul sito dedicato a Heartbleed<\/a><\/noindex>. Anche se le patch contro questa vulnerabilit\u00e0 sono state rilasciate praticamente subito dopo la sua scoperta, il problema \u00e8 tuttora attuale. Gi\u00e0 nel 2017 erano operativi quasi 200 mila siti<\/a><\/noindex>, vulnerabili a Heartbleed.<\/p>\n

Come proteggersi.<\/b> \u00c8 necessario aggiornare OpenSSL<\/a><\/noindex> alla versione 1.0.1g o superiore. \u00c8 possibile anche disabilitare manualmente le richieste Heartbeat utilizzando l'opzione DOPENSSL_NO_HEARTBEATS. Dopo l'aggiornamento, gli specialisti di sicurezza informatica La filosofia del DevOps. L'arte di gestire l'IT<\/a><\/noindex> debbano riemettere i certificati SSL. La sostituzione \u00e8 necessaria nel caso in cui i dati delle chiavi di crittografia siano stati compromessi.<\/p>\n

Sostituzione del certificato<\/h2>\n

\nTra l'utente e il server viene stabilito un nodo controllato con un certificato SSL legittimo, che intercetta attivamente il traffico. Questo nodo si finge un server legittimo, esibendo un certificato valido, e consente di condurre un attacco MITM.<\/p>\n

Secondo uno studio<\/a><\/noindex> Secondo dati di Mozilla, Google e vari atenei, circa l'11% delle connessioni protette in rete viene 'intercettato'. Questo \u00e8 il risultato dell'installazione di certificati radice sospetti sui computer degli utenti.<\/p>\n

Come proteggersi.<\/b> Utilizzare i servizi di provider SSL<\/a><\/noindex>. Si pu\u00f2 verificare la 'qualit\u00e0' dei certificati tramite il servizio Certificate Transparency<\/a><\/noindex> (CT). Anche i provider cloud possono aiutare nella rilevazione delle 'intercettazioni': gi\u00e0 oggi alcune grandi aziende offrono strumenti specializzati per il monitoraggio delle connessioni tramite TLS.<\/p>\n

Un altro modo per proteggersi sar\u00e0 il nuovo standard.<\/a><\/noindex> ACME, che automatizza il rilascio dei certificati SSL. Introdurr\u00e0 meccanismi aggiuntivi per verificare la propriet\u00e0 del sito. Di pi\u00f9 su questo ne abbiamo parlato in uno dei nostri articoli precedenti<\/a><\/noindex>.<\/p>\n

\"Attacchi
\n\/ Flickr \/ Yuri Samoilov<\/a><\/noindex> \/ CC BY<\/i><\/p>\n

Prospettive di HTTPS<\/h2>\n

\nNonostante diverse vulnerabilit\u00e0, i giganti IT e gli esperti di sicurezza informatica sono certi del futuro del protocollo. Per una diffusa adozione di HTTPS \u00e8<\/a><\/noindex> ha parlato il creatore del WWW, Tim Berners-Lee. Secondo lui, col tempo TLS diventer\u00e0 sempre pi\u00f9 sicuro, aumentando significativamente la sicurezza delle connessioni. Berners-Lee ha persino ipotizzato che in futuro appariranno<\/a><\/noindex> certificati client per l'autenticazione dell'identit\u00e0. Questi aiuteranno a migliorare la protezione dei server dagli attaccanti.<\/p>\n

Lo sviluppo della tecnologia SSL\/TLS sar\u00e0 anche supportato dall'apprendimento automatico: algoritmi intelligenti si occuperanno della filtrazione del traffico malevolo. Negli HTTPS, gli amministratori non hanno la possibilit\u00e0 di scoprire il contenuto dei messaggi criptati - nemmeno di rilevare richieste provenienti da software malevolo. Gi\u00e0 oggi le reti neurali possono filtrare pacchetti potenzialmente pericolosi con una precisione del 90%. (slide 23 della presentazione<\/a><\/noindex>).<\/p>\n

Conclusioni<\/h2>\n

\nGli attacchi su HTTPS sono per lo pi\u00f9 legati non a problemi nel protocollo stesso, ma all'uso di meccanismi di crittografia obsoleti. L'industria IT inizia gradualmente a rinunciare ai protocolli di precedente generazione e offre nuovi strumenti per la ricerca di vulnerabilit\u00e0. In futuro, questi strumenti diventeranno sempre pi\u00f9 intelligenti.<\/p>\n

Link aggiuntivi sull'argomento:<\/h5>\n

<\/p>\n