DriveDroid : a remote execution environment and UI exerciser for Android malware analysis

Android malware authors keep improving their malicious applications, giving them the capability to evade automatic analysis. Evasion mechanism can range from simple emulation-detection techniques, which are fortunately easy to counter-evade, to advanced interaction tests that determine whether a human user or an automated analysis is interacting with the malware, and refuse to execute in the latter case. In contrast, researchers proposed many approaches to enhance malware analysis. An emergent, promising approach consists in exercising the user interface (UI) of an Android application in order to trigger, and thus be able to analyse, as many (malicious) behaviours as possible. The idea is that UI interactions are recorded and automatically re-executed on applications with a similar UI. In our work, we bring this approach one step further, changing the way UI interactions are recorded and re-executed, and engineering the whole system from the ground up. Our main contribution consists in how we model an Android application as a graph and how graphs obtained from an app are used to drive the re-execution of another app with a similar UI. More precisely, we allow graphs obtained by several apps to be combined together to form a "super graph," and we designed a UI-based lookup to find similar apps in a fast way. We developed our approach and we conducted experiments over a dataset of 1,028 applications. The results show that our new approach can reach at least the same code coverage than the state-of-the-art tools and that it allows to overcome some limitations of the state of the art.

Android è senza dubbio il sistema operativo più diffuso nel mercato dei dispositivi mobili (smartphone e tablet): grazie alla sua natura open source e alla sua conseguente adattabilità a diversi tipi di hardware, detiene (dato aggiornato al secondo quadrimestre del 2015) l'82.5% delle quote di mercato. Gli utenti possono scaricare applicazioni destinate a sistemi Android sia dallo store ufficiale di Google, il Play Store, sia da svariati market di terze parti. Il successo della piattaforma ha fin da subito attirato l'attenzione dei malware writers i quali utilizzano svariate tecniche per rendere disponibili le loro applicazioni malevole. Una delle più famose consiste nell'utilizzare strumenti open source pubblicamente disponibili per decompilare applicazioni legittime, inserire codice malevolo, ricompilarle e pubblicarle su uno o più market. Questo metodo si è rivelato più volte efficace per aggirare i controlli di sicurezza che i market, Play Store compreso, effettuano sulle applicazioni prima di avallarne la pubblicazione. Per questo motivo l'analisi di mobile malware è diventata rapidamente un campo di ricerca interessante e, sulla falsa riga dell'analisi di Desktop malware, due sono gli approcci principali: analisi statica e analisi dinamica. L'analisi statica permette di esaminare un'applicazione senza eseguirla e, notoriamente, è apprezzata per gli alti livelli di code coverage raggiunti. Tuttavia in caso di malware "protetti" (tramite compressione, offuscamento, ecc.) l'Analisi Statica è inefficace e applicazioni malevole di questo tipo sono sempre più frequenti. L'analisi dinamica, d'altro canto, avviene durante l'esecuzione vera e propria dell'applicazione, forzando quindi la decompressione/decrittazione e il deoffuscamento delle parti di codice originariamente protette, superando quindi i principali limiti dell'analisi statica, però ha i noti svantaggi di poter mostrare solamente i comportamenti (malevoli o non) derivati dai path del codice effettivamente esplorati. Inoltre necessita sia di un apposito approccio di stimolazione automatica, sia di un ambiente emulato e instrumentato che, a volte, presenta delle discontinuità con l'ambiente hardware su cui le applicazioni sono normalmente eseguite. I malware writers hanno imparato sia a far riconoscere ai propri malware gli ambienti emulati (con tecniche fortunatamente prevedibili e a cui si può facilmente porre rimedio), sia a presentare all'utente, umano o automa che sia, delle "sfide interattive" (come il classico giochino "clicca sul tal oggetto per vincere un premio") che i sistemi di stimolazione automatici non sono in grado di superare. Ciò diventa problematico quando i comportamenti malevoli vengono espletati solamente dopo il superamento di queste sfide. Di conseguenza una delle sfide dell'analisi dinamica è progettare un sistema di stimolazone di applicazioni Android che possano superare questi problemi. Un primo tentativo è stato effettuato con i cosiddetti stress-tools casuali, ovvero degli strumenti che iniettano nell'applicazione da testare una serie di eventi di input (touch ad esempio) generati in modo casuale in posizioni casuali e con pause molto brevi tra ciascuno di essi, in modo da raggiungere un alto numero di eventi in un tempo ragionevole. Il sostanziale problema con questo approccio è la scarsa code coverage dovuta al fatto che, non essendo in grado di imitare i comportamenti umani di fronte ad un'interfaccia grafica, non riescono a cogliere il significato semantico degi elementi visualizzati e interattivi. Di recente è stato progettato un sistema, PuppetDroid che cerca di porre rimedio a questo problema: l'idea di fondo è che un umano stimola un'applicazione più a fondo di un tool automatico, quindi l'approccio di questo lavoro è di sfruttare l'utente umano per stimolare un certo numero di applicazioni, raccogliere gli eventi generati da tale stimolazione e reiniettarli su appliczioni dalla grafica simile a quella dell'applicazione di partenza. Tuttavia PuppetDroid non si preoccupa di costruire un modello dell'applicazione target, né dei dati raccolti dalla stimolazione e ciò può portare all'arrivo in punti in cui è impossibile procedere con la stimolazione o, peggio, in cui l'applicazione smette di funzionare a causa di una serie di input ingestibili. Partendo dall'inutizione alla base di PuppetDroid, ne abbiamo sviluppato un'estensione, chiamata DriveDroid, che costruisce un modello di una applicazione e degli eventi iniettati su di esa da un utente che con essa interagisce. Questo modello è un grafo orientato in cui i nodi rappresentano i vari stati dell'interfaccia grafica dell'applicazione, mentre gli archi le interazioni che consentono le transizioni di stato. Inoltre abbiamo progettato una nuova strategia per "rieseguire" i grafi registrati su applicazioni graficamente simili, ottenute tramite iniziale clustering di un dataset e successivo lookup nei cluster ottenuti, moltiplicando in media di un fattore 5 (ma anche di qualche decina nel migliore dei casi) il numero di applicazioni che possono esere testate al costo della registrazione da parte di un utente di un singolo grafo. Abbiamo validato il nostro approccio su un dataset di 1028 applicazioni Android, dimostrando che in media funziona almeno tanto bene quanto lo stato dell'arte e, in più, permette di superare casi di evasione di analisi dinamica effettuati tramite sfde interattive. I risultati mostrano che l'idea di trasformare DriveDroid in un sistema pubblico che permetta di raccogliere grafi su larga scala, per poi rieseguirli con il nostro approccio, è promettente.