{"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 su HTTPS e come proteggersi da essi.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Meta met\u00e0 dei siti utilizza HTTPS<\/a><\/noindex>, e il loro numero \u00e8 in costante aumento. Il protocollo riduce il rischio di intercettazione del traffico, ma non esclude le tentativi di attacco. Alcuni di essi \u2014 POODLE, BEAST, DROWN e altri \u2014 e i metodi di protezione, li descriveremo nel nostro materiale.<\/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 sull'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 insieme ai colleghi di Google.<\/p>\n

La sostanza consiste nel seguente: un hacker costringe il cliente a connettersi utilizzando SSL 3.0, emulando interruzioni della connessione. Poi cerca nel traffico crittografato in CBC<\/a><\/noindex>-modalit\u00e0 messaggi speciali e marcatori. Attraverso una serie di richieste fasulle, il malintenzionato riesce a ricostruire il contenuto dei dati di interesse, 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% dei 100.000 siti pi\u00f9 popolari supporta ancora SSL 3.0<\/a><\/noindex>. Inoltre esistono<\/a><\/noindex> modifiche POODLE, mirate a TLS 1.0 e TLS 1.1 pi\u00f9 moderni. Quest'anno sono emerse<\/a><\/noindex> nuovi attacchi di Zombie POODLE e GOLDENDOODLE, che aggirano la protezione di TLS 1.2 (sono ancora collegati 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 \u2014 garantisce che lo scambio di dati utilizzando SSL 3.0 avvenga solo con i vecchi sistemi. I malintenzionati non potranno pi\u00f9 avviare il downgrade del protocollo. Un modo per proteggersi dagli attacchi Zombie POODLE e GOLDENDOODLE \u00e8 disattivare il supporto di CBC nelle applicazioni basate su TLS 1.2. Una soluzione radicale sar\u00e0 il passaggio a TLS 1.3 \u2014 nella nuova versione del protocollo non viene utilizzata la crittografia CBC. Invece, sono usati algoritmi pi\u00f9 robusti come AES e ChaCha20.<\/p>\n

BEAST<\/h2>\n

\nUno dei primi attacchi su SSL e TLS 1.0, scoperto nel 2011. Come POODLE, BEAST utilizza<\/a><\/noindex> fa leva sulle peculiarit\u00e0 della crittografia CBC. I malintenzionati installano sulla macchina client un agente JavaScript o un applet Java, che sostituisce i messaggi durante la trasmissione dei dati tramite TLS o SSL. Poich\u00e9 i malintenzionati conoscono il contenuto dei pacchetti \u2018falsi\u2019, possono utilizzarli per decrittografare il vettore di inizializzazione e leggere altri messaggi destinati al server, come i cookie per l'autenticazione.<\/p>\n

Ad oggi, le vulnerabilit\u00e0 di BEAST sono ancora soggette a una serie di strumenti di rete<\/a><\/noindex>: server proxy e applicazioni per la protezione dei gateway Internet locali.<\/p>\n

Come proteggersi.<\/b> L'attaccante deve inviare continuamente richieste per decrittografare i dati. In VMware leggere<\/a><\/noindex> ridurre la durata del SSLSessionCacheTimeout \u2014 da cinque minuti (raccomandazione predefinita) a 30 secondi. Questo approccio complicher\u00e0 i piani dei malintenzionati, sebbene possa avere un certo impatto negativo sulle prestazioni. Inoltre, bisogna capire che presto la vulnerabilit\u00e0 BEAST potrebbe scomparire da sola \u2014 a partire dal 2020, i principali browser smetteranno<\/a><\/noindex> di supportare TLS 1.0 e 1.1. In ogni caso, con questi protocolli lavora meno dell'1,5% di tutti gli utenti browser.<\/p>\n

DROWN<\/h2>\n

\nQuesta \u00e8 un'attacco cross-protocol che sfrutta le vulnerabilit\u00e0 dell'implementazione di SSLv2 con chiavi RSA a 40 bit. L'attaccante intercetta centinaia di connessioni TLS della vittima e invia pacchetti speciali al server con SSLv2, usando la stessa chiave privata. Utilizzando l'attacco di Bleichenbacher<\/a><\/noindex>, l'hacker pu\u00f2 decrittografare una delle circa mille sessioni TLS del cliente.<\/p>\n

DROWN \u00e8 stata resa nota per la prima volta nel 2016 \u2014 allora risultava vulnerata un terzo dei server<\/a><\/noindex> nel mondo. A oggi, non ha perso rilevanza. Su 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 fornite dagli sviluppatori delle librerie crittografiche, che disabilitano il supporto per SSLv2. Ad esempio, due di queste patch sono state fornite per OpenSSL (nel 2016 erano aggiornamenti<\/a><\/noindex> 1.0.1s e 1.0.2g). Anche aggiornamenti e istruzioni su come disabilitare il protocollo vulnerabile sono stati pubblicati in Red Hat<\/a><\/noindex>, Apache<\/a><\/noindex>, Debian<\/a><\/noindex>.<\/p>\n

\u00abLa risorsa potrebbe essere vulnerabile a DROWN se le sue chiavi sono condivise con un server esterno che utilizza SSLv2, ad esempio un server di posta\u00bb, sottolinea il responsabile dello sviluppo di IaaS-provider 1cloud.ru<\/a><\/noindex> Sergei Belkin. \u2014 Questa situazione si verifica se pi\u00f9 server utilizzano un certificato SSL comune. In questo caso, disabilitare il supporto per SSLv2 \u00e8 necessario su tutte le macchine.\u00bb<\/i><\/p><\/blockquote>\n

\nControllare se \u00e8 necessario aggiornare il sistema \u00e8 possibile utilizzare uno utility<\/a><\/noindex> \u2014 sviluppato da esperti di sicurezza che hanno scoperto DROWN. Maggiori informazioni sulle raccomandazioni relative alla protezione contro questo tipo di attacchi possono essere lette nel post sul sito di OpenSSL<\/a><\/noindex>.<\/p>\n

Heartbleed<\/h2>\n

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

L'attacco si realizza tramite un piccolo modulo Heartbeat dell'estensione TLS. Il protocollo TLS richiede che i dati siano trasmessi in modo continuo. In caso di inattivit\u00e0 prolungata, la connessione si interrompe e deve essere ripristinata. Per affrontare il problema, server e client generano artificialmente \"rumore\" nel canale (RFC 6520, p.5<\/a><\/noindex>), inviando pacchetti di lunghezza casuale. Se risultava pi\u00f9 grande del pacchetto principale, le versioni vulnerabili di OpenSSL leggeva la memoria oltre il buffer assegnato. In questa area potevano trovarsi dati di qualsiasi tipo, incluse le chiavi di crittografia e informazioni su altre connessioni.<\/p>\n

La vulnerabilit\u00e0 era presente in tutte le versioni della libreria tra 1.0.1 e 1.0.1f inclusa, oltre che 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 per questa vulnerabilit\u00e0 sono state rilasciate praticamente subito dopo la sua scoperta, il problema rimane attuale fino ad oggi. Gi\u00e0 nel 2017 quasi 200.000 siti web<\/a><\/noindex>, erano vulnerabili a Heartbleed.<\/p>\n

Come proteggersi.<\/b> \u00c8 necessario aggiornare OpenSSL<\/a><\/noindex> alla versione 1.0.1g o superiore. \u00c8 anche possibile disabilitare manualmente le richieste Heartbeat utilizzando l'opzione DOPENSSL_NO_HEARTBEATS. Dopo l'aggiornamento, gli esperti di sicurezza informatica leggere<\/a><\/noindex> devono riemissionare i certificati SSL. \u00c8 necessaria la sostituzione nel caso in cui le informazioni sulle chiavi di crittografia siano state catturate dai hacker.<\/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 presenta come server legittimo mostrando un certificato valido, permettendo cos\u00ec di effettuare un attacco MITM.<\/p>\n

Secondo uno studio<\/a><\/noindex> Gruppi di Mozilla, Google e diverse universit\u00e0 affermano che quasi l'11% delle connessioni protette in rete viene \"ascoltato\". Questo \u00e8 il risultato dell'installazione di certificati radice sospetti sui computer degli utenti.<\/p>\n

Come proteggersi.<\/b> Utilizzare i servizi di fornitori SSL affidabili<\/a><\/noindex>. Controllare la \"qualit\u00e0\" dei certificati pu\u00f2 essere fatto tramite il servizio Trasparenza del Certificato<\/a><\/noindex> (CT). Anche i fornitori di servizi cloud possono aiutare a scoprire \"ascolti\" \u2014 gi\u00e0 oggi alcune grandi aziende offrono strumenti specializzati per monitorare le connessioni TLS.<\/p>\n

Un altro modo di protezione sar\u00e0 il nuovo standard<\/a><\/noindex> ACME, che automatizza l'ottenimento dei certificati SSL. In questo modo, aggiunger\u00e0 meccanismi aggiuntivi per verificare la propriet\u00e0 del sito. Maggiori dettagli su di esso li abbiamo trattati 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 fiduciosi nel futuro del protocollo. Per la promozione attiva di HTTPS \u00e8<\/a><\/noindex> il creatore del WWW Tim Berners-Lee. Secondo lui, col tempo TLS diventer\u00e0 pi\u00f9 sicuro, aumentando notevolmente la sicurezza delle connessioni. Berners-Lee ha persino ipotizzato che in futuro appariranno<\/a><\/noindex> certificati client per l'autenticazione dell'identit\u00e0. Essi aiuteranno a migliorare la protezione dei server da intrusi.<\/p>\n

La tecnologia SSL\/TLS sar\u00e0 anche sviluppata tramite l'apprendimento automatico \u2014 gli algoritmi intelligenti saranno responsabili della filtrazione del traffico malevolo. Nelle connessioni HTTPS, gli amministratori non possono conoscere il contenuto dei messaggi cifrati \u2014 inclusi i richieste da software nocivo. 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 ai problemi del protocollo stesso, ma al supporto di meccanismi di crittografia obsoleti. L'industria IT inizia gradualmente ad abbandonare i protocolli della generazione precedente e propone nuovi strumenti per la ricerca delle vulnerabilit\u00e0. In futuro, questi strumenti diventeranno sempre pi\u00f9 intelligenti.<\/p>\n

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

<\/p>\n