Uno studio realizzato dalla società di analisi Ponemon aveva già sollevato nel 2016 il problema dei rischi per la cyber security nascosti nel traffico dati criptato su Internet suscitando un’ampia eco nel mondo dell’IT security. Il report è uscito in un momento in cui, secondo la ricerca, una media del 39% del traffico web inbound (quello che dai web server acceduti dagli utenti entra nei loro pc di casa oppure aziendali) era criptato, mentre lo era il 33% di quello outbound (ossia quello che dai client va verso il web sotto forma di credenziali di accesso ai siti, messaggi, file in upload e così via). Oggi, dalle statistiche pubblicate dagli sviluppatori dei più importanti web browser, sappiamo che già oltre la metà dei dati scambiati fra end user e internet tramite queste applicazioni (oramai diventate l’interfaccia utente più utilizzata e quasi sempre aperta su un pc) sono soggetti ad encryption tramite il protocollo di crittografia SSL (Secure Socket Layer): o meglio, attraverso il protocollo HTTPS (Hypertext Transfer Protocol Secure), che altro non è che un’estensione di quello HTTP (Hypertext Transfer Protocol) con l’aggiunta delle funzionalità SSL .
Un dilemma da sciogliere
Da anni l’utilizzo della crittografia SSL nelle comunicazioni fra utenti e web è raccomandato per tutelare l’autenticazione, l’integrità dei dati e la confidenzialità di informazioni sensibili come le password, i dati delle carte di credito, quelli di natura sanitaria e così via. Agli end user tale raccomandazione si sostanzia consigliando loro di guardare che, dove si scrive (o appare) l’Url di un sito nella finestra del browser, compaia il simbolo di un lucchetto. Quando appare questa icona, alla sua destra, nel link al sito, la tradizionale scritta http:// è sostituita da quella https://. Questo significa che il sito supporta il protocollo HTTPS, ossia che il suo (o i suoi) web server è in grado di inviare al browser un certificato contenente una firma digitale che il browser può controllare collegandosi, in modo trasparente all’utente, a una Certification Authority (CA). In pratica, la funzionalità SSL in un web browser si comporta come una public key infrastructure (PKI), o infrastruttura a chiave pubblica, che controlla la validità della chiave pubblica del corrispondente e, solo una volta che l’ha validata, la utilizza per iniziare a scaricare dati (inbound traffic) o inviarglieli (outbound traffic).
Oggi è più difficile che un utente possa collegarsi inavvertitamente a un server che non dispone di un certificato poiché nei browser più sicuri compare immediatamente un alert che lo avvisa che il sito è “insicuro”. Se da una parte, però, la crittografia SSL su Internet ha aumentato la possibilità che gli utenti si connettano ai siti giusti e non si vedano sottratte informazioni confidenziali, dall’altra ha iniziato a porre nuovi problemi agli esperti di security aziendale. Sì, perché non si può escludere che le sessioni SSL possano essere sfruttate dai cybercriminali come vettori per compiere azioni malevole che sfuggono ai responsabili It, della security e alle soluzioni tradizionali di cyber security.
A questo punto, per le aziende, si pone il dilemma se investire in soluzioni di SSL inspection on-premises (che non sono fra le tecnologie più economiche, e che dovrebbero essere predisposte a supportare anche i futuri aumenti del traffico web), servizi analoghi offerti in modalità as-a-service e proxy-based da un cloud security vendor, oppure sperare nell’accortezza e nella buona fede degli utenti che utilizzano il web, e nella capacità dei sistemi tradizionali di security di intercettare e contrastare le minacce che arrivano via traffico criptato.
Perché la SSL inspection diventa necessaria
L’ultimo tipo di scelta si rivela rischiosa se si considera, non solo che il traffico web criptato sta già crescendo, secondo alcuni osservatori, fino a raggiungere i due terzi del totale nel giro di poco tempo, ma anche che, sempre secondo fonti attendibili, più di un terzo del malware in circolazione è concepito per utilizzarlo. Già la ricerca Ponemon aveva messo in evidenza che l’80% delle aziende intervistate era stato vittima di un cyber attacco o di una violazione dei sistemi IT dall’interno nei 12 mesi precedenti, e che il 41% di questi incidenti aveva previsto l’utilizzo dell’encryption per evitare l’intercettazione.
Secondo Ponemon, ci sono cinque modi in cui può essere compiuto un attacco sfruttando l’SSL.
- Nel primo, l’attaccante ricorre al phishing, confezionando un messaggio molto credibile in cui si invita ad accedere a un sito descritto come sicuro proprio perché utilizza l’SSL. In questo modo anche un utente informato sull’importanza dell’SSL può cadere nella trappola e connettersi a tale sito che, però, effettua l’upload di un malware che non può essere identificato da un IPS (Intrusion Prevention System) in quanto contenuto in un traffico criptato.
- Nel secondo caso, gli hacker utilizzano il traffico outbound. Siccome sono già riusciti a penetrare nella rete dell’azienda vittima e a prendere controllo di qualche sistema, da qui creano stream di dati sensibili o business critical criptati che inviano all’esterno attraverso porte (connessioni software standard previste nei computer per connettersi ad altri computer) considerate “normali”, “approvate” dai firewall, come le porte 443 e 80.
- Nel terzo, gli attaccanti utilizzano famiglie di malware progettate specificatamente per nascondere, attraverso l’encryption, informazioni di rete come password e altri dati sensibili che stanno inviando a server SSL. In questo modo, i sistemi di monitoring dell’azienda non sono in grado di vedere queste informazioni, anche se riguardano attività di network interne, in quanto sono rese irriconoscibili.
- Il quarto modo utilizza la crittografia SSL per offuscare le comunicazioni fra un malware (worm, virus o botnet) e un server principale, utilizzate per trasferire dati all’esterno (tecnica di data exfiltration) o per inviare istruzioni ai sistemi dell’azienda compromessi (tecnica di command and control).
- Il quinto tipo si basa sulla tecnica del cross-site scripting o XSS. Attraverso l’XSS l’hacker riesce a sottrarre cookies che possono essere utilizzati per una varietà di obiettivi, inclusi il furto di un account, la manipolazione di una sessione, il cambiamento dei setting dell’utente, la modifica degli stessi cookies e la visualizzazione di false pubblicità. Tutte queste operazioni sono possibili grazie all’invisibilità garantita dalla crittografia.
Tutti questi esempi dovrebbero bastare per convincersi che la decrittazione e l’ispezione del traffico SSL è quanto mai consigliabile, pur facendo salve tutte le più possibili norme di tutela della privacy (per esempio, escludendo i traffici con siti sanitari o finanziari).
Controindicazioni e problematiche connesse all’SSL inspection
Come già accennato, le soluzioni di SSL inspection non sono molto utilizzate a causa del loro costo e di alcuni effetti collaterali sulle prestazioni della connettività fra aziende e web o cloud. Per riuscire a decriptare, esaminare, e poi crittografare nuovamente i traffici web inbound e outbound, questi sistemi devono operare come una delle minacce più temute per la sicurezza: il famigerato man-in-the-middle (MITM). Questo attacco consiste nel riuscire a inserirsi in un flusso di dati e, nel caso in cui questo sia crittografato, riuscire a individuare la chiave di decryption attraverso numerosi tentativi (in terminologia tecnica “brute force”). I sistemi più obsoleti che riescono a eseguire questa attività su molteplici comunicazioni SSL, non ai fini di “spiare” gli utenti, ma di applicare policy di sicurezza (che possono prevedere l’autorizzazione, il diniego, e l’esfiltrazione di minacce da traffici dati) e di offrire funzionalità innovative di certificate management, nella maggior parte dei casi pongono problemi di inserimento di latenze, scalabilità e costi elevati. Aumenta, però, sicuramente, il numero di aziende che auspicano soluzioni di questo tipo più performanti, arricchite di nuovi servizi ed economicamente sostenibili.
