Come l’attacco degli ALPACA ai danni dei certificati TLS wildcard ci fa comprendere i flussi https di internet
Da parecchi anni a questa parte, sia per ragioni pratiche, sia economiche, molte aziende hanno deciso di adottare i certificati TLS wildcard per permettere l’accesso ai propri sistemi. Per quale motivo?
Spendiamo prima di tutto due parole su come funzioni un handshake TLS durante l’apertura di un sito come https://www.miamammausalinux.org.
Un certificato è a tutti gli effetti la parte pubblica di una coppia di chiavi asimmetriche, generata lato server, con delle caratteristiche aggiuntive. La cifratura a coppie di chiavi, come quella usata da PGP/GPG o SSH, permette di creare un flusso di dati che viene criptato tramite la chiave pubblica, e che solo il proprietario della corrispondente chiave privata può decriptare. Questo presuppone quindi che la chiave pubblica sia stata preventivamente inviata all’ente con cui siamo interessati scambiare delle informazioni. Un certificato presenta le stesse funzionalità di una semplice chiave pubblica, con delle caratteristiche in più: è verificabile tramite una terza parte, che lo firma e ne garantisce la bontà, è estensibile tramite delle caratteristiche associabili al certificato stesso, ha una scadenza, quindi può smettere di essere valido, e può essere associato ad un servizio tramite il proprio Common Name (CN).
Ad esempio, un certificato può essere valido solo come server certificate, per il CN www.miamammausalinux.org, e solo fino al 20 Dicembre 2022. Quando un browser web contatta il nostro sito in https:// ha luogo un handshake TLS dove client e server effettuano una serie di operazioni, le più importanti delle quali sono il momento di invio al client da parte del server del certificato pubblico, la decisione su quale protocollo di cifratura utilizzare, e la verifica del certificato del server da parte del client. Tale verifica ha luogo tramite un controllo su una delle Certification Authority ufficiali, presenti in bundle sul client, che corrisponde all’issuer, cioè l’ente che ha firmato il certificato del server. A volte la verifica è diretta, più spesso viene fatta tramite una catena di certificati intermedi, ognuno dei quali deve essere a sua volta valido e verificato dal suo issuer corrispondente. Questa granularizzazione permette una maggiore sicurezza, e il poter rimpiazzare facilmente i certificati intermedi nel caso in cui siano compromessi, pur mantenendo intatta la Certification Authority di root, o Root CA. Un certificato si può definire compromesso quando la sua corrispondente chiave privata viene violata: chi è in possesso della chiave privata di un dato certificato può vedere l’intero flusso cifrato di dati come se fosse il destinatario del flusso stesso, perché può, con le giuste tecniche, frapporsi e presentare un altro certificato, generato a partire dalla stessa chiave privata, e fare finta di essere il destinatario originale del trasferimento dati. Questo tipo di attacco è detto man-in-the-middle, o MitM, ed esistono numerosi strumenti che permettono facilmente di provarlo. Va da sé che la violazione della chiave privata di un certificato firmatario, come un Intermediate o addirittura di una root CA, è un evento catastrofico perché compromette tutta la catena a valle del certificato stesso.
Esistono tecniche particolari applicate al mondo delle app, come il pinning, che consiste nel copiare l’intero certificato all’interno dell’app installata sui telefoni, in modo che se avesse luogo un attacco MitM, tramite la generazione di un altro certificato che si presenti con lo stesso Common Name dell’originale, senza aver violato la chiave pubblica, il client si rifiuterebbe comunque di connettersi in quanto l’hashsum sarebbe diverso. Questo però obbliga una pubblicazione di una nuova app ad ogni scadenza del certificato: è possibile fare pinning solo della chiave pubblica contenuta nel certificato stesso, in quanto il suo modulo non cambia mai tra un’emissione e l’altra, ma, nel caso in cui la chiave privata fosse compromessa, sarebbe possibile generare un nuovo certificato avente lo stesso modulo e l’app non se ne accorgerebbe: sarebbe possibile quindi sniffare l’intero traffico dati dell’app, studiarne il protocollo interno e le eventuali vulnerabilità semplicemente redirigendo il traffico tramite un proxy.
L’handshake TLS dall’inizio alla fine. Anche se non ve ne siete accorti, lo avete già fatto per leggere questo articolo!
La chiave privata è quindi il punto di maggiore attenzione e va protetta a tutti i costi: è per questo che esistono degli apparati hardware, detti HSM, dove poter gestire in un perimetro sicuro l’intero ciclo crittografico, e che permettono di annullare il rischio di violazione, anche in caso di accesso fisico al sistema.
Un certificato wildcard è particolare perché valido per tutti i domini che abbiano un match positivo con il Common Name associato al certificato stesso: ad esempio, *.dominio.net è valido e utilizzabile per www.dominio.net, mail.dominio.net, images.dominio.net. Sulla carta, questo è molto utile per aziende grandi, che presentano più host che offrono diverse tipologie di servizi: ad esempio, un server di posta, più server web istituzionali differenziati per nome a seconda della sezione, oppure un ftp server protetto da TLS. Normalmente questo obbligherebbe il detentore del dominio a dover generare più certificati, uno per ogni Common Name richiesto, e farli singolarmente firmare dalla sua Certification Authority, con conseguente aumento dei costi. Inoltre, ogni certificato avrebbe la sua scadenza e dovrebbe essere gestito indipendentemente, su ogni server che offre il servizio. Non tutti hanno a disposizione un HSM per gestire le proprie chiavi, per cui la coppia certificato/chiave privata, diversa a seconda del servizio erogato, verrebbe copiata su ogni server. Ed ecco il problema dei certificati wildcard: dato che sono validi per più domini, la chiave privata corrispondente viene copiata su ogni server afferente a quel dominio: ed è la stessa per tutti i domini. Va da sé che la violazione di una singola macchina che contenesse la coppia di chiavi permetterebbe all’attaccante di poter prendere letteralmente il posto non di uno, ma di tutti i server che eroghino servizi con un Common Name corrispondente a quella wildcard.
L’attacco ALPACA (Application Layer Protocol Confusion) utilizza proprio questa tipologia di vulnerabilità per permettere ad un MitM di ottenere informazioni come cookie di autenticazione, o perfino di inviare dati arbitrari al client, come ad esempio un javascript contenente del codice maligno, e farglielo eseguire in quanto perfettamente valido. La tecnica funziona in questo modo: il client si connette ad un dato sito in https://, scarica il certificato corrispondente, avente il Common Name in wildcard e, dato che il protocollo TLS non protegge l’integrità della connessione TCP stessa (cioè, IP e porta sorgente e destinazione) non si accorge che il MiTM redirige il traffico TLS, originariamente destinato all’endpoint TLS originale, ad un altro endpoint TLS e un altro protocollo/porta. Quest’altro endpoint TLS che parla un altro protocollo potrebbe essere ad esempio un FTP server avente un certificato wildcard con lo stesso Common Name: in molti casi, l’FTP server ignorerebbe gli header HTTP, ed eseguirebbe qualsiasi comando FTP presente nel corpo della richiesta originale. Uno dei comandi FTP, ad esempio HELP, permetterebbe quindi di tornare una stringa arbitraria al client contenente codice javascript che verrebbe eseguito senza alcun problema. In questo caso si parla di attacco di tipo reflection. Esistono altre due declinazioni dell’attacco ALPACA: il tipo upload, in cui l’attaccante riesce a farsi inviare dei cookie contenenti informazioni sensibili, e il tipo download, in cui l’attaccante convince il client a scaricare del codice già predisposto all’interno del server.
Nella pratica questo attacco cross-protocol presenta numerosi prerequisiti che lo rendono di applicazione complicata: ma è anche vero che sarebbe sufficiente avere un server FTP, SMTP o IMAP/POP3, all’interno dello stesso Common Name wildcard di un server HTTP ben protetto, per essere vulnerabili. In un recente scan su tutta l’Internet, ben 1,4 milioni di webserver hanno presentato certificati di tipo wildcard, e presentano vulnerabilità cross-protocol e, di questi, 119 mila presentano una versione di webserver che sono vulnerabili all’ALPACA.
Una possibile contromisura all’attacco ALPACA è l’utilizzare l’estensione ALPN (Application-Layer protocol Negotiation, il successore di NPN, o Next Protocol Negotiation), che permette agli attori coinvolti nello scambio dati TLS di scegliere un protocollo specifico, senza che sia necessario alcun roundtrip per negoziarne uno, e danno la certezza che l’intero scambio dati all’interno della sessione crittografata avverrà soltanto su quello specifico protocollo.
I nomi dei protocolli sono presentati in ASCII e sono assegnati dallo IANA: HTTP, IMAP, POP3 e FTP sono già stati standardizzati, mentre manca ancora SMTP. Per utilizzare l’estensione ALPN occorre che il server supporti il protocollo HTTP/2, e che il webserver sia stato linkato con una versione di OpenSSL maggiore o uguale alla 1.0.2.
Per quanto riguarda invece le fix lato client, Google Chrome nella versione 93 presenta già una mitigation specifica per l’attacco, pertanto buon divertimento ad aggiornare!
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
