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 <local-ip-addr> -p 443
Dove al posto di <local-ip-addr> 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
Nessun commento:
Posta un commento