Malware Evasion e Containerizzazione

Malware evasion, Sandboxing e Containerizzazione le tematiche della terza tappa del viaggio attraverso i principali aspetti della sicurezza informatica.

Mario Raciti (tsumarios)

17 nov 2019 • 7 min read

Awareness without action is worthless. - Phil McGraw

Introduzione

Quando parliamo di sicurezza informatica l'idea più semplice che potremmo avere in mente potrebbe essere quella di associarla ad un "gioco" - in effetti è possibile utilizzare la Teoria dei Giochi per analizzare e risolvere alcune problematiche di cybersecurity - in cui si fa a gara tra chi tenta di difendere e chi tenta di attaccare e bypassare le protezioni. Nel corso delle sezioni di questa serie vedremo che c'è molto di più, ma in questo preciso momento vi chiedo di prendere per buona la precedente analogia - la ritengo utile ad introdurre l'argomento di cui parleremo adesso. La tecnologia non dorme mai e si evolve continuamente. Tra le tante cose che la accompagnano nel suo cammino, ritroviamo purtroppo i malware. Infatti, tanto più si tende a sviluppare sistemi di protezione "impenetrabili", tanto più vengono sviluppate tecniche che mirano a scavalcare tali muri, continuando il ciclo di difesa-attacco. In questa gara, un ruolo molto importante è giocato da una parte (attacco) dalle tecniche di evasione dei malware, dette malware evasion, e dall'altra (difesa) da metodologie di sandboxing e contenimento.

In questa sezione spiegheremo in cosa consiste il concetto di malware evasion, esponendone le principali tecniche, e proporremo una soluzione che, sebbene abbia alcune similitudini con il sandboxing, apporta delle aggiunte molto utili a contrastare il problema: la containerizzazione.

Problema

Iniziamo con il definire meglio il concetto di malware evasion. In maniera molto concisa potremmo pensarlo come un sinonimo del termine "reverse Turing test". Si tratta di tecniche relativamente recenti che consistono nell'evitare che il sistema target - qui intendiamo l'intero ambiente/contesto in cui l'esecutivo malevolo è eseguito - sia in grado di rilevare ed analizzare l'attività del malware. Il perché riguardante l'anti-rilevamento è abbastanza naturale, ma l'aspetto dello sfuggire all'analisi potrebbe aver bisogno di una breve precisazione. Esistono infatti appositi ambienti - si veda la virtualizzazione - costruiti ed utilizzati allo scopo di isolare e studiare un determinato malware. Un tale meccanismo viene detto sandboxing ed offre altre funzioni che riguardano, ad esempio, il testing di applicazioni ancora in fase di sviluppo ed in fase - abbiamo parlato delle fasi SDLC nella prima sezione - immediatamente precedente al deployment. Se abbiamo conoscenze del concetto di virtualizzazione, allora risulterà immediata la comprensione del funzionamento di base del sandboxing: isolare un eseguibile - nel nostro caso un malware - in modo da avere un ambiente protetto all'interno del quale sia possibile analizzare e testare il malware senza rischio di contrarre danni "reali" al calcolatore o all'infrastruttura che si sta utilizzando. Le tecniche di sandboxing sono oggi ampiamente utilizzate anche per l'implementazione di honeypot o, più in generale, di honeynet: meccanismi che mirano ad attirare potenziali attaccanti mostrandosi come, appunto, dei "barattoli di miele", ma che in realtà hanno lo scopo di rilevare - vedremo nella prossima sezione l'importanza del rilevamento -, deviare o in certi casi contrastare tentativi non autorizzati di utilizzo dei sistemi. Nel caso in questione, gli honeypot tendono a rilevare il codice malevolo sfruttando le repliche e i vettori di attacco dei malware conosciuti.‌‌ Tuttavia, i malware diventano col tempo sempre più "intelligenti" grazie ad algoritmi di Machine Learning - del quale tratteremo alcuni aspetti positivi nella sezione avvenire - che hanno lo scopo di aiutare gli eseguibili malevoli a discernere il loro contesto di esecuzione, reale o virtuale. Fra le varie tecniche di malware evasion, molte sono prevalentemente basate sull'individuazione di interazioni, che siano esse svolte da utenti o dal sistema, o sul riconoscimento dell'ambiente:

Interazioni utente: tipicamente gli utenti premono tasti sulla tastiera, cliccano con i tasti del mouse. In un ambiente sandbox non vi sono tali comportamenti, pertanto è possibile istruire il malware ad eseguire azioni solo dopo questo tipo di eventi. Le interazioni più comuni riconosciute sono lo scroll di un documento e il movimento/click del mouse;
Interazioni di sistema: alcune funzionalità di sistemi reali non sono presenti negli ambienti virtualizzati, come per esempio il conteggio dei core - in caso di VM Linux è sufficiente interrogare /proc/cpuinfo per ottenere eventuali discrepanze tra core reali e core virtualizzati - o il tipo di programmi installati - se vi sono antivirus installati - o ancora il numero di riavvii del sistema. Dunque il malware può essere istruito in base a tali eventi;
Riconoscimento dell'ambiente: il malware può essere programmato in modo da riconoscere eventuali chiamate dell'hypervisor, nomi di file, processi tipici di un sandbox quali vmusrvc.exe, boxservice.exe, vmtoolsd.exe.

Sarebbe opportuno osservare che ognuna delle precedenti tecniche ha in comune con le altre il riconoscimento, nel senso più generale del termine. In aggiunta citiamo l'esistenza di metodologie di evasione basate sul tempo - torneremo sull'importanza della temporalità nell'ultima sezione -, come ad esempio le bombe logiche (logic bombs), e sull'offuscamento dei dati. Ciò aiuta a comprendere come sia possibile raggiungere l'obiettivo di evasione in molteplici modi.

Esempio

A sostegno dell'esistenza di svariate tecniche di malware evasion che rendono inefficace l'utilizzo del sandboxing - per tale motivo si parla anche di sandbox evasion - illustriamone adesso alcuni esempi significativi:

Locky Ransomware: rilasciato nel 2016, consiste in un malware che si diffonde attraverso codice JavaScript infettato con file DDL cifrati. Poichè esso necessita dell'utilizzo del processo run32dll.exe - il quale non è presente in ambienti sandbox - viene eseguito solamente in ambienti reali, in cui un altro malware chiamato KeRanger inizia ad agire solamente dopo tre giorni dal download sul sistema. Locky, pertanto, utilizza la tecnica di malware evasion del riconoscimento dell'ambiente;

Shamoon: scoperto nel 2012, rappresenta un esempio di malware che utilizza una tecnica di evasione basata sul tempo. Fu infatti programmato ad azionare la "bomba logica" solo in certe date e orari;
Trojan Upclicker: basato sulla metodologia di malware evasion di interazione degli utenti, opera solamente dopo che sia stato premuto e rilasciato il tasto sinistro del mouse. In questo modo, in assenza di interazioni utente esso rimane inattivo.

Soluzioni

La virtualizzazione a livello di sistema operativo (OS-level virtualization) si riferisce ad un paradigma del sistema operativo in cui il kernel consente la coesistenza di più istanze isolate dello spazio utente. Tali istanze vengono chiamate in vari modi: partizioni, ambienti virtuali, container. È d'obbligo, a questo punto, fissare alcune importanti premesse: il concetto di macchina virtuale (VM) non coincide - ulteriori chiarimenti qui - con quello di container; container non è sinonimo di (assoluta) sicurezza. Sebbene la containerizzazione sia utile a molteplici finalità, miriamo in questa sezione a proporla come contromisura al malware evasion. In particolare esponiamo le considerazioni presenti in un articolo di ricerca - i cui autori sono Douglas Hellinger, Lee Ming Xuan e Prakhar Gahlot, consultabile qui - circa un possibile miglioramento al sandboxing tradizionale. Osserviamo che, così come esistono tecniche di sandbox evasion, esistono meccanismi di container evasion, di cui forniamo ora qualche esempio riportato dagli autori e la loro soluzione.‌‌Il namespace di un PID (Process ID) permette ad un container di eseguire un solo processo, il quale nella fase di avvio avrà il valore 1 come PID assegnato all'interno del container. Ricordiamo che in Linux il processo avente PID 1 rappresenta il primo processo eseguito dal kernel, pertanto:

[...] querying the process name of PID 1, and finding it's not one of those processes, can reliably reveal the execution environment to be a container. [...]

sarà sufficiente cioè interrogare - in modo analogo a quanto abbiamo sottolineato per il sandboxing - la prima linea di /proc/1/sched. Altre metodologie si basano invece sulla presenza di eventuali file riconducibili alla containerizzazione, quali /.dockerenv o /.dockerinit.‌‌Per queste ragioni si può eseguire una patch del kernel Linux in modo da forzare in modo arbitrario il nome del processo ed il PID del processo genitore di PID 1, così come hanno dichiarato gli autori dell'articolo:

[...] Our example kernel patch hard-codes the process name as "systemd" and host PID as 1.

È stata effettuata anche un'hardenizzazione del container, dovuta alla considerazione che la virtualizzazione a livello OS debba godere della proprietà di resilienza alle tecniche di validazione hardware. Questo obiettivo è stato raggiunto utilizzando innanzitutto un Linux Container (LCX) e le sue API a livello utente. Per ottenere l'isolamento del container, in modo che questo si presenti come un ambiente di sandboxing sicuro e "realistico", senza far uso di un kernel separato ci si è affidati al kernel namespacing e alle policy di sicurezza (SELinux e CGroups).

Poiché questa soluzione non è priva di vulnerabilità legate a particolari tecniche di container evasion, un'ulteriore strategia - precisano gli autori dell'articolo - potrebbe consistere nell'utilizzo degli Unikernel, particolari componenti che girano sopra l'hypervisor e forniscono una minore superficie di attacco.

Conclusioni

Abbiamo evidenziato l'esistenza di moltissime tecniche di sandbox evasion che hanno lo scopo di nascondersi o, comunque, di rendere difficile l'analisi ed il comportamento dei malware nel caso in cui si utilizzino dei tradizionali sandboxing environment. Tuttavia per l'estrema importanza che acquisisce lo studio di un malware - come abbiamo evidenziato - è necessario ricercare nuove metodologie che permettano di stare al passo con i meccanismi antitetici. Una buona alternativa, come abbiamo visto, è rappresentata certamente dalla containerizzazione hardenizzata.