Ho comprato APT Blocker ma ho comunque preso Crypt0l0cker! Perché?

Mi è capitata a dicembre questa domanda di un'azienda precedentemente soddisfatta delle soluzioni Watchguard ma che si è trovato davanti ad una situazione sicuramente… scomoda.

Crypt0l0cker e tutta la sua discendenza di virus che cadono nella miserabile categoria di “crypto ransomware”, ovvero quei virus che cifrano i dati di un computer per chiederne un successivo riscatto, continuano a mietere vittime come se nulla fosse. Sulla base di manovre sociali ben studiate e phishing, cadere nel tranello di questo virus è piuttosto giustificabile: alla fine diciamocelo, nella necessità di svolgere rapidamente un lavoro, un ufficio logistica potrebbe aprire erroneamente un’e-mail con allegata un documento di trasporto. Colpa dell’utente? Non sono totalmente d’accordo, ammetto che alcuni documenti o link sono parecchio credibili.

Il mercato della sicurezza ha risposto con una valanga di nuovi prodotti che “difendono” dal problema e sono proposti o promossi come la soluzione di tutti i mali dell’umanità. Tra prodotti di endpoint security, che hanno sostituito il classico “antivirus” ormai sempre meno efficace, alle difese perimetrali come i firewall UTM (Unified Threat Management) il mercato ha una proposta piuttosto ampia di soluzioni più o meno efficaci. Watchguard sui propri sistemi propone APT Blocker, un componente che aggiunge funzionalità evolute per bloccare le minacce di tipo, appunto, APT (Advanced Persistent Threat). Rientrano in queste minacce i virus (o malware come è più di moda dire oggi) che si insediano su un sistema e cercano di occultare la propria presenza più a lungo possibile con la finalità di portare maggiori “benefici” possibili a chi li manovra. Avevo già scritto sull’argomento in un mio blog precedente nel quale facevo notare che APT Blocker non fosse la panacea di tutti i mali. È uno strumento di eccezionale efficacia, ma non è sufficiente comprare la sua licenza perché intercetti tutte le minacce possibili, così come un XTM fine a sé stesso, se non opportunamente configurato, potrebbe essere inefficace.

APT Blocker è un’estensione del servizio Gateway Antivirus, pertanto interviene laddove è attivo quest’ultimo. Se un file che viene scaricato da Internet non è sottoposto ad una scansione anti virus del firewall, questo di sicuro non verrà analizzato dal APT Blocker.

Ho riscontrato, in realtà, tre circostanze principali nelle quali mi è stato richiesto supporto perché il servizio APT Blocker ha – apparentemente – fallito il suo lavoro:

1. Il servizio era stato attivato a livello di Feature Key ma non nelle singole policy
2. Il servizio era attivato nelle varie regole, ma nessuna condizione scatenava il funzionamento dell’antivirus
3. Il servizio era attivo e configurato nelle policy, ma l’infezione è pervenuta via posta elettronica (TLS)

I primi due problemi sono – chiamiamole – sviste che possono accadere. Diciamo che il secondo caso è stato quello più frequente, nel quale la navigazione non prevedeva mai l’intervento del sistema Antivirus e, di conseguenza, di quello di APT Blocker. In un paio di casi mi è capitato di sentire una storia simile:

“abbiamo attivato il Gateway Anti Virus su tutto il traffico, ma era diventato così lento che abbiamo preferito disattivarlo”.

Pensateci: analizzare ogni singolo file scaricato da Internet… facciamo un esempio. Il mio sito Internet ha una homepage che è composta sì e no da grosso modo 41 file, quindi richieste. Sono 41 file che dovrebbero essere analizzati quando si accede al mio sito. La homepage di Google, nella sua più assoluta semplicità è fatta da circa 30 file, e degli utenti che conosco forse un 10% ha una homepage che non sia quella di google. Ma andiamo sul corposo:

• La homepage di Reuters è formata da circa 190 richieste
• La homepage di YouTube ne fa 105
• La mia timeline di Facebook ne fa 218 solo per dire “buon giorno”

Stiamo parlando di una sola pagina, di una sola persona. Moltiplicate tutto per gli utenti di una rete nel corso della giornata. Sono migliaia e migliaia di file che vengono analizzati dal firewall. Il suo sovraccarico è inevitabile, e onestamente non tutto ha motivo di essere analizzato. Morale: il Gateway Antivirus non deve necessariamente scansionare tutti i file che lo attraversano, ma solo quelli che potenzialmente possono costituire una minaccia. E se un file è una potenziale minaccia, allora ha motivo di essere analizzato anche da APT Blocker.

Abbiamo quindi determinato che GAV e APT Blocker vanno opportunamente configurati. Eppure, e torno all’oggetto del titolo, la crypto-porcheria è comunque riuscita ad eludere il sistema. Come?

HTTPS. Un protocollo “sicuro”.

Anche di questo avevo fatto una breve disquisizione: HTTPS è un protocollo che rende confidenziali le comunicazioni, non il loro contenuto. Ed è bastato questo per poter consentire ad un crypto-ransomware di penetrare il perimetro con una discreta facilità. Questi non necessitava di collegarsi ad una botnet per poter fare il suo sporco lavoro, e infatti lo ha fatto (peraltro eludendo anche il endpoint security dell’utente).

Risultato: un cliente che ha investito in una soluzione tecnologica che non ha funzionato.

Colpa del Vendor? No.

Errore di configurazione? Ni.

Non è stato un errore di configurazione, in quanto il servizio era attivo e funzionante, sia sulla navigazione che sul traffico di posta elettronica dell’Exchange interno all’azienda. Ma solo per i protocolli non cifrati.

Perché APT Blocker dia il proprio meglio andrebbe attivato anche sui protocolli cifrati, oltre ad essere abbinato correttamente a tutti gli altri motori che ne possono ulteriormente potenziare le funzionalità:

• WebBlocker riducendo il rischio di accedere a siti compromessi o di phishing
• Reputation Enabled Defence che verifica e controlla la reputazione dei siti
• BotNet Detection che si assicura che non vengano effettuate connessioni a botnet o sistemi compromessi
• Application Control per appurare che all’interno delle connessioni effettivamente passi ciò che ci si aspetta che passi

Ciò non di meno, attivare una procedura di ispezione del traffico HTTPS si lega una consistente serie di problemi non solo di carattere tecnico che è necessario affrontare anche in virtù delle sempre più stringenti e complesse regolamentazioni sulla privacy.

Nulla toglie, alla fine di tutto il discorso, che sia possibile sfruttare tutte le funzionalità a pieno di un sistema, esclusivamente conoscendo le potenzialità e (soprattutto) limitazioni del funzionamento dei sistemi stessi al fine di ridurre il rischio di inciampare in situazioni quantomeno scomode da gestire (come il ripristino di dati a seguito di un’infezione di un crypto ransomware).

Nota di chiusura.

Nota non dolente dell’incidente è quella in cui l’azienda coinvolta avesse implementato una efficace politica di backup dei dati grazie alla quale è stato possibile ripristinare tutti i dati riducendo al minimo il danno verificatosi. Questo in aggiunta ad un discorso più ampio secondo il quale la protezione dei dati non è data da un singolo prodotto “buttato lì” che fa sicurezza, ma il risultato di un’equazione di più elementi che permettono di evitare che i dati vengano compromessi (e butto lì anche un altro riferimento su tutte le cose che devono andare storte per essere colpiti da Cryptowall, che dopo più di due anni dalla sua pubblicazione, ancora rimane invariato per i suoi punti elencati – con mio perverso piacere).