Articoli

Unfortunately QNAP does not have Root and Intermediate Certificate Bundles, which means that no system software (such as Curl or Wget) can easily access SSL sites.

The following guide, taken partially by Stefan Wienert, allows you to install the complete bundled root certificates.

Connect via SSH to your QNAP NAS and type the following commands:

# cd /share/
# curl https://curl.haxx.se/ca/cacert.pem -O -k
# mkdir certs
# cat cacert.pem | awk 'split_after==1{n++;split_after=0} /-----END CERTIFICATE-----/ {split_after=1} {print > "certs/cert" n ".pem”}'
# cd certs
# for filename in cert*pem;do mv $filename `openssl x509 -hash -noout -in $filename`.0; done;
# cp *.0 /etc/ssl/certs/

I’ve tried in QTOS 4.2.x firmware released in May 2017 and it works perfectly.

 

Schermata 2016-01-09 alle 09.38.02

Durante l’Epifania ho ripristinato il mio iPad Mini (con la speranza vana di migliorarne le prestazione, dovrò passare al nuovo modello) che quotidianamente uso al lavoro per sfruttare due applicazioni che mi vengono fornite dal colosso internazionale di telefonia e distribuite tramite Wireless AdHoc Distribution, ovvero non sono presenti nell’Apple Store.

Una di queste due applicazioni non può essere utilizzata dopo il ripristino poiché il sistema monitora eventuali re-installazioni, la procedura interna prevede pertanto che l’utilizzatore (io) contatti il Call Center dedicato e comunichi che vuole reinstallare l’applicazione nello stesso o in un nuovo device. Se non si segue tale procedura appare l’errore sottostante.

IMG_0003

Questo è dovuto al fatto che ad ogni nuova installazione l’applicazione genera un tabletid univoco, id che verrà conservato nei database centralizzati e se eseguendo il login con le corrette credenziali il sistema non riconosce anche il Device ID precedentemente associato rigetta l’autenticazione. All’interno dell’applicazione vi sono memorizzate anagrafiche di diversi milioni di clienti ed è quindi un buona procedura per limitare accessi indesiderati.

Buona procedura che però non è stata implementata correttamente a livello tecnico, la comunicazione tra applicativo e server avviene esclusivamente sul canale cifrato SSL. Peccato che il canale sia garantito da un certificato Self Signed e l’applicazione non è stata sviluppata per analizzare e confermare il certificato del server di autenticazione, pertanto potremmo passarli qualsiasi certificato che continuerà ad eseguire le sue procedure a patto di conservare una connessione HTTPS.

Questa è l’ennesima dimostrazione che una comunicazione HTTPS basata su certificati Self Signed se non opportunamente implementata è medesima ad una comunicazione HTTP in chiaro.

L’applicazione è stata sviluppata, almeno dalle evidenze che ho ottenuto analizzando il traffico, dalla famosissima multinazionale di consulenze con sede a Chicago. Se lo sviluppatore voleva correttamente sfruttare un certificato SSL Self Signed, anziché aumentare i costi con l’acquisto di una certificato convalidato da terzi, doveva memorizzare all’interno dell’applicazione il certificato pubblico del server e confrontarlo ad ogni connessione, se il certificato è diverso da quello conosciuto rigettare la connessione. Invece viene accettato qualsiasi certificato, pertanto attraverso un Proxy Software (es. OWSAP Zed Attack Proxy) è possibile intercettare le comunicazioni tra il server e l’applicazione e modificare le stringhe di autenticazione.

Ho quindi eseguito un test sfruttando il mio iPad Mini e un iPad Air riuscendo ad installare e ad eseguire la medesima applicazione su due dispositivi, replicando il tabletid dell’iPad Mini sull’iPad Air. Dall’immagine di apertura potete vedere che il tabletid viene passato nell’header della comunicazione, di seguito la medesima applicazione attiva su due device distinti contemporaneamente.

IMG_8903

L’uso non appropriato del certificato SSL mette a rischio pericolo anche tutte le comunicazioni tra applicativo e server, non è solo possibile vedere in chiaro le credenziali di autenticazione ma anche l’archivio dei clienti e ipotizzando di sfruttare un Fake Access Point durante una riunione/meeting aziendale potrei ottenere le credenziali di diversi colleghi senza che loro si accorgano di nulla.

La comunità The Hacker’s Choice ha recentemente rilasciato uno script in grado di verificare le prestazioni del protocollo SSL e del server ospitante.

Stabilire una connessione SSL richiede l’impiego di più di 15 processi sul WebServer e anche sul Client dell’utente,  questa esosa richiesta di risorse è conosciuta dalla maggior parte dei sviluppatori dal 2003 ed ampiamente discussa in più convegni ma ad oggi non è stata ancora sviluppata una alternativa più performante.

Grazie a questa vulnerabilità è possibile lanciare un attacco SSL-DoS generando un altissimo numero di processi sul Server impiegando poche risorse (un rapporto di 1:15). TCH-SS-DOS è una utility in grado di lanciare un test di DoS a qualsiasi server SSL sfruttando anche la funzione “SSL secure Renegotiation” in grado di innescare migliaia di rinegoziazioni tramite singola connessione TCP.
È possibile scaricare THC SSL DOS attraverso i seguenti link:

L’installazione dello script è avviabile digitando da riga di comando:

./configure; make all install

Infine vi riporto un esempio di utilizzo:

./thc-ssl-dos 127.3.133.7 443
Handshakes 0 [0.00 h/s], 0 Conn, 0 Err
Secure Renegotiation support: yes
Handshakes 0 [0.00 h/s], 97 Conn, 0 Err
Handshakes 68 [67.39 h/s], 97 Conn, 0 Err
Handshakes 148 [79.91 h/s], 97 Conn, 0 Err
Handshakes 228 [80.32 h/s], 100 Conn, 0 Err
Handshakes 308 [80.62 h/s], 100 Conn, 0 Err
Handshakes 390 [81.10 h/s], 100 Conn, 0 Err
Handshakes 470 [80.24 h/s], 100 Conn, 0 Err

Maggiori informazioni sono reperibili sul sito ufficiale di THC: http://www.thc.org/thc-ssl-dos/

Il recente rilascio della versione 3.1.3 di iPhone OS non ha portato con sé alcuna patch riguardante una errata gestione dei certificati SSL.

Continua a leggere