DROWN Attack – Cosa è e come difendersi

Senza titolo-1

 

Buongiorno a tutti. Spesso accade, mentre navighiamo su Internet, di dover inserire i nostri dati all’interno di un form. Vuoi per fare un
acquisto online, vuoi per fare l’accesso a un’area riservata, è una cosa che succede continuamente. Questa operazione è resa sicura dal protocollo SSL, che permette di cifrare i dati in automatico, proteggendoli da malintenzionati di ogni genere.

 

COME AVVIENE LA COMUNICAZIONE SICURA
Come alcuni sanno, tutto questo è possibile tramite il protocollo HTTPS - HyperText Transfert Protocol Secure Soket Layer.
Questo protocollo è la naturale evoluzione del più classico HTTP. Permette infatti lo scambio di pagine web - i cosiddetti ipertesti - come il precedente, ma aggiunge una crittografia a chiave asimmetrica per garantire la privacy dei dati scambiati tra server e client.

 

 

OK, QUALE E’ IL PROBLEMA ALLORA?
Questa vulnerabilità avviene grazie a un attacco misto:

  • Brute Force - attacco a forza bruta (Si provano tutte le combinazioni).
  • CCA2 - Adaptive Chosen-Ciphertext Attack - Attacco complesso in cui l'attaccante invia molti (parecchie migliaia) testi cifrati e cerca di decriptarli per rivelare gradualmente informazioni rigurado alla chiave. È un tipo di attacco teorico, che permette di ridurre il numero di chiavi da tentare a un livello accettabile (e qui che entra in gioco il Brute Force).

La vulnerabilità in se e per se non è “devastante”, il problema è che circa l’11% di tutti i siti che utilizzano https certificati sono passibili di DROWN Attack. Ma non solo. Un altro problema è che i certificati SSL non vengono utilizzati solamente per siti, bensì anche per applicazioni (come ad esempio SSMTP - S sta per ssl...).

 

 

COME FACCIO A SAPERE SE SONO VULNERABILE?
Innanzi tutto, se si utilizza Apache nella versione 2.4 non si hanno problemi, in quanto la versione di SSL incriminata è la 2, mentre Apache2.4 non permette di utilizzare nulla inferiore a SSL v.3. Viceversa se utilizziamo Apache 2.2, abbiamo due possibilità:

  • Se il nostro server ha un dominio puro andiamo a questa pagina e inseriamo l’url del nostro sito.
  • Se non possiamo, vuoi per colpa del firewall, o molto più semplicemente perchè abbiamo un DNS gratuito - che è visto come un sottodominio, e quindi non analizzato - possiamo utilizzare la procedura qui di seguito.

 

 

SCRIPT PYTHON
Lo script che andiamo a vedere funziona per ogni distribuzione Linux. Noi l’abbiamo provato per Debian 8 Jessie. Non avremo bisogno dell’accesso fisico o da remoto al nostro server, dato che il programma permette di inserire l'indirizzo ip. Dato che lo script è scritto in python ci servirà almeno la versione 2.7 e Git. Se non ne siamo provvisti diamo:

sudo apt-get install python2.7 git

Al termine dell’installazione siamo pronti per scaricare dal repository ufficiale lo script con:

git clone https://github.com/tomato42/tlsfuzzer.git

Ci spostiamo ora all’interno della cartella tlsfuzzer con:

cd tlsfuzzer

e all’interno della cartella diamo:

git checkout ssl2

Successivamente installiamo la libreria tlslite-ng dipendentee il suo link simbolico, con:

git clone https://github.com/tomato42/tlslite-ng .tlslite-ng

ln -s .tlslite-ng/tlslite tlslite

Ci spostiamo all’interno della cartella e facciamo ancora una volta il check out:

cd .tlslite-ng/

git checkout sslv2

cd ..

Arrivati a questo punto dobbiamo scaricare la libreria per ECDSA e creare il solito link simbolico:

git clone https://github.com/warner/python-ecdsa .python-ecdsa

ln -s .python-ecdsa/ecdsa ecdsa

A questo punto eseguiamo finalmente lo script con:

PYTHONPATH=. python scripts/test-sslv2-force-export-cipher.py -h -p 443

Dove al posto di inseriamo l’ip della macchina che vogliamo testare o localhost se siamo sulla macchina da testare.

 

 

ALLA FINE
L’output di questo script ci indicherà se il nostro server è passibile di drown attack.
Se il risultato è quello di fallimento, allora dobbiamo imporre a Apache di non utilizzare SSL2 e SSL3.

apriamo quindi la configurazione di apache con:

sudo nano /etc/apache2/apache.conf

e inseriamo:

SSLProtocol All -SSLv2 -SSLv3

 

 

ATTENZIONE
Come abbiamo detto in precedenza, non solo Apache è influenzato da questa vulnerabilità bensì anche tutte le applicazioni che utilizzano SSL. Andrà modificata la configurazione di ognuno di essi per essere veramente protetti.

Al prossimo post 😉

FONTI

Dottore in Informatica. Appassionato di computer fin dal primo PC Olivetti con Windows 95 e la bellezza di 8 MB di RAM.
Utilizzatore Linux da 5 anni, credo profondamente nella filosofia open source.
Dopo tante distro provate sul mio fidato Toshiba, uso Fedora per lo studio e il divertimento.

Lascia un commento