Libraesva, bisogna ripensare le sandbox in modo pragmatico

Libraesva, bisogna ripensare le sandbox in modo pragmatico

Rodolfo Saccani, Security R&D Manager di Libraesva, mette in luce il valore di un approccio pragmatico alla sicurezza e all’utilizzo delle sandbox.

Il 2016 ha visto nascere circa 100 nuove famiglie di ransomware, ogni famiglia dà origine ad una grande quantità di varianti. Questo succede grazie all’ormai consolidato “terziario” del ransomware-as-a-service, che fornisce anche a chi è privo di competenze tecniche la possibilità di confezionare il proprio ransomware. Troviamo ormai anche su YouTube video pubblicitari di questi kit di sviluppo e il marketing del ransomware ha già adottato le tecniche del multilevel e dei programmi di affiliazione. Business is business.

Se la sicurezza oggi dipende soprattutto dalla capacità di intercettare malware ancora non conosciuto, è altrettanto vero che il problema della sicurezza richieda a nostro avviso un approccio pragmatico, senza cedere alle sirene del marketing.

Una sandbox che analizza gli allegati all’interno di una macchina virtuale e ne osserva il comportamento è un sistema ancora più complesso di quello che cerca di difendere: è una vera e propria installazione di windows che gira in un ambiente virtuale (di norma in cloud), con l’aggiunta del software specifico per monitorare quello che succede. Questo software aggiuntivo è agganciato intimamente al sistema operativo che cerca di nascondere la propria presenza al programma che sta analizzando.

Gli sviluppatori di malware usano lo stesso identico software (le sandbox sono prodotti open source a disposizioni di tutti) per produrre malware in grado di comportarsi in modo “innocente” in una sandbox, oppure semplicemente ritardare la “detonazione” sapendo che le sandbox hanno un vincolo inderogabile: non possono permettersi di analizzare un file per più di pochi minuti. Chi sviluppa sandbox implementa continuamente nuove difese contro queste strategie e chi attacca inventa nuovi artifici tecnici.

Stiamo spostando l’eterna competizione tra attaccante e difensore all’interno di un ambiente più complesso, senza però alterarne le dinamiche. Il difensore oltretutto qui è svantaggiato avendo solo pochi minuti per dare un verdetto, mentre il malware non ha alcuna fretta, una volta raggiunto il computer della vittima ha tutto il tempo che vuole.

Per fare tutto questo gli allegati alle mail vengono trasferiti in un servizio cloud di una terza parte per essere analizzati, con implicazioni non trascurabili ai fini della riservatezza e protezione dei dati aziendali. Oltretutto il tempo di analisi impatta sui workflow aziendali: la consegna della mail viene ritardata oppure l’allegato viene consegnato in un secondo momento con procedure variabili.

L’approccio pragmatico al problema degli allegati pericolosi incomincia chiedendoci se abbiamo veramente bisogno di allegati eseguibili nelle mail in entrata verso la nostra azienda. L’esperienza di oltre un miliardo di mail al mese gestite dai nostri sistemi ci dice di no, gli eseguibili non servono. Rimuoviamo quindi dalle mail tutto quello che è eseguibile, direttamente sul gateway. Una soluzione estremamente semplice che riduce significativamente la superficie d’attacco rimuovendo la maggior parte dei vettori di infezione. Per il tecnico del reparto IT che vuole ricevere gli eseguibili basta inserire una eccezione, in fondo è la stessa logica che oggi applichiamo ai firewall: tutto è vietato tranne quello che è espressamente consentito. Anni fa si faceva il contrario, è bastato questo passaggio logico per aumentare la sicurezza.

Abbiamo bloccato tutto quello che è eseguibile, però restano i documenti i quali (anche i file PDF) possono contenere anche del codice ormai in grado di fare qualunque cosa. Di nuovo, l’approccio pragmatico è il seguente: di quale codice abbiamo bisogno? Blocchiamo tutto tranne quello di cui abbiamo bisogno.

Le macro che fanno calcoli in uno spreadsheet sono utili, difficilmente invece abbiamo bisogno di codice che viene eseguito automaticamente senza l’intervento dell’utente (ad esempio all’apertura del documento) oppure di codice che scarica dati da internet e che va a leggere e scrivere file sul disco.

E’ sufficiente rimuovere dal documento tutto il codice che esegue operazioni diverse da quelle consentite. Il documento arriva al destinatario ma è un normale documento inerte e inoffensivo, senza codice. Inattivo. Disarmato.

Questo è un processo rapido, non introduce ritardi e non impatta sui workflow aziendali, soprattutto non c’è bisogno di consegnare propri documenti a terze parti perché tutto può essere fatto sul gateway. L’esperienza ci insegna che questo approccio non solo è efficace ma non impatta sull’operatività aziendale.

Se a questo punto ne traessimo la conclusione che le sandbox non hanno senso, saremmo giunti alla conclusione sbagliata. Tutto dipende dal rapporto benefici/costi, dove il costo è in questo caso la complessità.

Attacchi Hacker in posta elettronica – Le sandbox hanno senso e sono estremamente utili in determinati contesti, ad esempio per i link contenuti nelle mail.

Un pattern di attacco tipico è il seguente: arriva una mail da un mittente legittimo (lui è a sua volta stato infettato e le mail partono a sua insaputa oppure le credenziali della posta gli sono state sottratte attraverso un phishing). La mail contiene un link ad un sito legittimo, quindi con una buona reputazione, che però è stato compromesso pochi minuti fa e ora viene usato per diffondere malware. Una mail di questo tipo ha qualche probabilità di passare attraverso i filtri e di essere consegnata all’utente. Ecco che la sandbox dei link diventa uno strumento efficace ed utile, che giustifica la propria esistenza (e complessità) in virtù di un vantaggio concreto e tangibile contro le minacce del giorno zero.

Come funziona? Mentre la mail passa dal gateway il link viene riscritto, non punta più all’indirizzo originale ma alla sandbox. Cliccando sul link si passa per la sandbox la quale, solo in questo preciso momento, analizzerà la pagina di destinazione per decidere se è sicura o no. Se non è sicura l’utente viene fermato, se è sicura viene direttamente trasferito.

I vantaggi sono evidenti: l’analisi viene fatta all’ultimo momento utile, che è quello del click. Il sito che aveva una buona reputazione quando la mail è arrivata nel corso della notte, adesso probabilmente è noto come pericoloso, abbiamo guadagnato tempo sull’avversario, ma c’è di più. Questo tipo di sandbox può fare analisi di dettaglio sul comportamento della pagina e stavolta (a differenza della sandbox per i file) è la sandbox ad essere in vantaggio: in una pagina web il malware non può aspettare a manifestarsi, deve farlo subito, prima che l’utente chiuda o cambi pagina. Stavolta è la sandbox e non il malware ad avere il tempo dalla sua parte. Anche sul web il malware adotta tecniche per non farsi rilevare dalla sandbox ma anche stavolta la sandbox è in vantaggio. Il malware per nascondersi ha ben poche alternative: se la visita arriva da una linea consumer (come una ADSL) allora viene fornito il malware mentre se la visita arriva da un datacenter viene fornita una pagina innocua. La sandbox visitando la stessa pagina da più punti evidenzia facilmente queste tecniche di evasione. Può anche controllare se la pagina si nasconde ai motori di ricerca (comportamento necessario per il malware), se carica contenuti da siti che sono già stati compromessi (questa è una tecnica molto usata), la sandbox infine applica una grande quantità di tecniche euristiche per capire se la pagina è un tentativo di phishing o se contiene minacce di altro tipo.

Pragmatismo significa utilizzare lo strumento che offre il miglior risultato con la minore complessità.

Quanto sopra mostra come sia possibile, seppure in un contesto mutevole dove la minaccia è per lo più ignota, intervenire oggi con la scelta giusta per assicurarsi una prospettiva meno rischiosa e più sotto controllo.