Introduzione
Questo articolo ha lo scopo di rilevare delle vulnerabilità, più o meno gravi sul layer SSL/TLS. In molti degli esempi pratici proposti, analizzeremo HTTPS
(perchè è quello più semplice da trovare in rete), ma teniamo presente che molti altri servizi utilizzano questo layer di cifratura, come ad esempio SSH,
RDP o POP3S.
Nato nei primi mesi del 1995 e sviluppato dalla società Netscape, SSL 2.0 si è rilevata una grande novità per quanto riguarda il mondo delle
telecomunicazioni private. Il protocollo TLS ha invece fatto il suo esordio nel 1999 come sostituto dell' SSL 3.0.
Le vulnerabilità
In questa sezione cercheremo di descrivere, in parole semplici, alcuni degli attacchi possibili contro SSL/TLS.
-
Padding Oracle (2002, Veudenay): si tratta di un metodo per decifrare parte del testo cifrato che sfrutta il pattern MAC-then-encrypt. Può essere mitigato utilizzando il pattern encrypt-then-MAC. Una variante di questo attacco è stata diffusa nel 2014
con il nome di POODLE. -
BIAS (2007, Paul & Maitra): tutti i cifrari basati su RC4 sono passibili di decodifica perché considerato un metodo di cifratura
debole per la potenza di calcolo dei computer d'oggi. -
SSL Stripping (2009, Marlinspike): l'attaccante cerca di impedire al browser vittima di connettersi in HTTPS, qualora il sito sia
altrettanto raggiungibile in HTTP. Uno dei metodi per mitigare questo attacco è l'uso di HTTP Strict Transport Security (HSTS). -
Browser Exploit Against SSL/TLS (BEAST) (2011, Rizzo & Duong): sfruttando una debolezza del Cipher Block Chaining (CBC) sotto TLS 1.0, è possibile decifrare parte del contenuto della richiesta (soprattutto l'header dei cookies –
spesso utilizzati per mantenere una sessione loggata nel sistema). -
PFS (Perfect Forward Secrecy): Più che una vulnerabilità, è un metodo che garantisce
la riservatezza delle comunicazioni a fronte di un'eventuale compromissione della chiave privata del server.
Gli strumenti
Quali strumenti possiamo utilizzare quindi per identificare le vulnerabilità sul nostro server casalingo o su un sito che utilizziamo spesso? In questo
articolo ne vedremo principalmente due: sslscan (pre-installato sulla distribuzione Kali Linux) e ssl-cipher-suite-enum.
Ricordiamo che l'enumerazione dei cifrari disponibili sul servizio SSL/TLS non è un'operazione illegale, in quanto è come chiedere al server quante lingue
conosce per poter iniziare una conversazione. In questo esempio analizzereremo l'home banking di una banca Italiana (che si presuppone debba mantenere la
massima segretezza sui dati in transito).
Uso di sslscan
Questo tool si connette ad un servizio e ne enumera protocolli e cifrari abilitati mettendoli in risalto con i classici colori rosso-arancione-verde. Per
visualizzare le opzioni disponibili, si può utilizzare il comando seguente:
sslscan --help
Avviamo quindi una semplice enumerazione con:
sslscan --show-certificate --no-heartbleed <URL>
Dai risultati possiamo capire che l'SSLv3 non dovrebbe essere abilitato (perché considerato insicuro) e che fra i cifrari preferiti, cioè quelli con cui il
server tenta inizialmente di stabilire una connessione, ci sono gli RC4-MD5 (“crackabili” in un tempo relativamente breve per la potenza di calcolo di farm
di media dimensione). Ci sono poi tre cifrari in rosso sull'SSLv3, perché vulnerabili a POODLE.
Uso di ssl-cipher-suite-enum
Come sslscan, anche questo tool enumera protocolli e cifrari, ma in più si dedica all'analisi dei risultati mostrando un sommario alla
fine della scansione con tutti i tipi di vulnerabilità rilevati. In aggiunta, esegue dei controlli su cifrari "non-standard", come ad esempio quelli a
192bit (cosa che sslscan non fa). Inspiegabilmente, ssl-cipher-suite-enum non si trova già installato in Kali e dobbiamo scaricarlo dal sito del progetto.
Si tratta di un semplice script in Perl; possiamo visualizzare la lista dei comandi con:
perl ssl-cipher-suite-enum.pl
Avviamo l'enumerazione come segue:
perl ssl-cipher-suite-enum.pl <URL>
Nell'immagine vediamo il sommario delle vulnerabilità descritte in precedenza, e si può notare che alcuni cifrari a 192bit sono stati inclusi, cosa che con
sslscan non avremmo potuto constatare.
Il risultato finale delle enumerazioni è che la banca è vulnerabile a POODLE, BEAST e BIAS, ed inoltra non ha abilitato il PFS.
Un server Debian appena installato, senza personalizzazioni, ne avrebbe di meno.
Andamento ed uso dei protocolli oggi
Come abbiamo già visto tutti i protocolli SSL sono considerati insicuri, eppure quasi il 53% dei siti li supporta ancora (insieme alla nuova generazione
TLS, ovviamente).
Si può dare un'occhiata all'andamento dei protocolli dai report della Trustworthy, aggiornati
mensilmente.
Conclusioni
Avendo letto questo articolo forse vi sarete chiesti come mai un servizio necessita l’abilitazione di così tanti cifrari SSL/TLS, invece di usarne solo una
che abbia abbastanza robustezza da non essere attaccabile. La risposta è semplice: retro-compatibilità. Purtroppo non tutti gli utilizzatori di un servizio
cifrato hanno un client o un sistema operativo specifico. C'è quindi la necessità di avere compatibilità con il maggior numeri di client che si connettono
al servizio.
In Italia la questione della riservatezza delle telecomunicazioni è ancora molto sottovalutata. Soprattutto una banca, come nel caso che abbiamo
analizzato, dovrebbe avere certificazioni di PCI-DSS, che però sembrano ancora rappresentare un costo superfluo ai più. Come spesso accade, è probabile che
ci si renderà conto della gravità della situazione solo “a fattaccio avvenuto”.
