Viaggio nei malware Android: l’incubo Ransomware – Parte 2

Questa serie di articoli è dedicata all’analisi dei ransomware su dispositivi Android. Nella prima parte, viene fornita una panoramica generale delle famiglie di ransomware Android, suddivise in Locker, che bloccano l’accesso al dispositivo, e Crypto, che criptano file specifici dell’utente e venivano descritte le modalità operative e le tecniche utilizzate per estorcere pagamenti dalle vittime, confrontandole con i ransomware per desktop.

In questa seconda parte invece viene esplorata l’analisi di un ransomware Android attraverso l’uso combinato di tecniche statiche e dinamiche per comprendere il comportamento delle app dannose. Analizzeremo quindi la struttura delle applicazioni, con un focus sul file AndroidManifest.xml e i permessi richiesti dai malware, fornendo dettagli pratici sull’uso di strumenti come ApkTool per disassemblare e studiare il codice di tali app.

I ransomware Android: analisi statica e dinamica delle app

Nel primo articolo di questa serie dedicata ai ransomware Android ci siamo concentrati sull’elencare le caratteristiche salienti di tali malware, fornendo anche una prima distinzione di base fra le varie famiglie. A partire da questa e nelle prossime parti, decisamente più tecniche, si vuole fornire un’analisi tecnica di base di un ransomware, al fine di mostrare più in dettaglio le varie azioni da questo compiute.

Esistono due modi fondamentali per analizzare un’applicazione Android. Queste tecniche, direttamente ereditate dalla disciplina del reverse engineering (e, pertanto, applicabili in linea di principio a qualunque applicazione anche Windows o Linux), prendono il nome di analisi statica e analisi dinamica.

Cos’è l’analisi statica di un’applicazione Android

L’analisi statica consiste nell’esaminare il codice dell’applicazione senza che questa venga eseguita. Questo consente di avere un’idea rapida delle azioni principali da essa svolte: in particolare, è possibile ad esempio capire quali funzioni vengono invocate, o quali stringhe vengono utilizzate. Il tutto è effettuato attraverso una procedura di disassembling, dove il codice compilato viene disassemblato in linguaggio macchina (ad esempio Assembly X86 per applicazioni Windows) o in un formato bytecode intermedio (come nel caso di Android).

Naturalmente, sebbene questo tipo di analisi consenta di fornire dei risultati in un tempo ragionevolmente ridotto e con un basso uso di risorse computazionali, è purtroppo spesso complicata da interpretare, soprattutto se l’attaccante confonde intenzionalmente il codice per renderlo meno leggibile (tecnica anche conosciuta come offuscamento).

Cos’è l’analisi dinamica di un’applicazione Android

L’analisi dinamica, invece, consente di estrarre informazioni sul comportamento dell’applicazione attraverso la sua esecuzione. Spesso vengono utilizzati degli ambienti virtualizzati che consentono di eseguire l’applicazione senza comprometterne l’ambiente di esecuzione.

Questo ha l’enorme vantaggio di ridurre lo sforzo di analisi da parte dell’operatore, dato che spesso le informazioni sono espresse in termini di funzioni realmente chiamate dall’applicazione, elementi del sistema operativo modificati, o indirizzi web contattati. Viceversa, tale analisi può richiedere molto tempo ed un grosso consumo di risorse computazionali, risultando pertanto poco appetibile se si desidera ottenere dei risultati in un tempo rapido.

Combinare analisi statica e dinamica per un’app Android

Dal punto di vista strettamente tecnico, il modo migliore per analizzare un’applicazione è quello di combinare i due tipi di analisi. Naturalmente, questo presuppone una conoscenza approfondita del tipo di linguaggio macchina o del bytecode relativo all’applicazione che si va ad analizzare.

Per analizzare il nostro ransomware Android si applicherà, in maniera molto semplificata, l’analisi statica. E’ importante sottolineare come il reverse engineering sia una disciplina ricca di complessità, e come tali tipi di analisi richiedano una grande esperienza da parte dell’operatore per poter essere effettuate in dettaglio. Per gli scopi di questa serie, l’analisi proposta sarà tutt’altro che esaustiva, ma vuole essere una possibile introduzione ad un argomento dalle molteplici sfaccettature.

Esempio pratico di analisi statica su un ransomware Android

In questa serie di articoli, verrà analizzato il ransomware avente hash md5 1a62aebaf963d800dd44791699baac55. Prima di analizzarlo, è necessario prima fornire una panoramica sulla struttura delle applicazioni Android.

Una applicazione Android è, in generale, un file compresso in formato .apk che contiene i seguenti elementi:

• Un file eseguibile dex, che contiene il codice dell’applicazione in formato bytecode Dalvik .dex;
• Un file xml, che definisce i componenti fondamentali dell’applicazione, ed in particolare da dove l’applicazione inizia la sua esecuzione. Nelle app Android, infatti, non è prevista una funzione “main”, ma viene molto spesso usata la funzione onCreate dal componente principale. Il Manifest, inoltre, definisce i permessi richiesti dall’applicazione, i quali stabiliscono le risorse del telefono che l’applicazione può utilizzare (es. accedere ad internet).
• Un insieme di file .xml che definiscono il layout dell’applicazione;
• Un insieme di risorse esterne (ad esempio, altri file dex, immagini, librerie native in C, etc.)

Dal punto di vista dell’organizzazione del codice, le app Android si articolano in quattro componenti fondamentali [1]:

• Attività, ovvero le schermate dell’applicazione che vengono visualizzate all’utente;
• Servizi, ovvero delle funzioni applicative che girano in background (es. ascolto di mp3);
• Broadcast Receivers, ovvero funzioni applicative che si attivano alla ricezione di certi messaggi, detti anche Intent;
• Content Providers, ovvero componenti che consentono alle app di accedere a dei dati condivisi (ad esempio, attraverso un Content Provider può essere possibile accedere alla rubrica e ai contatti dell’utente persona).

Tutte le funzionalità delle app Android sono legate all’interazione fra questi componenti.

Funzionamento di un ransomware Android

Quando il ransomware in esame viene eseguito sul dispositivo, prima questo chiede all’utente di accordare alcuni permessi, e poi blocca il telefono mostrando una serie di scritte in lingua russa richiedenti un riscatto, accompagnate da immagini erotiche. La figura sotto mostra la schermata del riscatto:

Per analizzare l’apk, utilizzeremo il tool ApkTool [2], il quale disassembla l’applicazione, decriptando il file AndroidManifest.xml e convertendo il classes.dex in un insieme di file di testo con estensione .smali, che costituiscono una rappresentazione semplificata del bytecode Dalvik. Per procedere al disassemblamento, date questo comando:

java –jar nome_apktool.jar decode app.apk –o outout_folder

Dove nome_apktool.jar rappresenta il nome del file .jar scaricato dal sito di Apktool, app.apk è il nostro ransomware, ed output_folder è una cartella scelta dall’utente dove vengono salvati i file disassemblati.

In questo secondo articolo procederemo ad un’analisi più dettagliata del file AndroidManifest.xml, lasciando alla terza parte di questa nostra serie l’analisi del classes.dex. Per chi non avesse dimestichezza con la struttura di un Manifest, si raccomanda fortemente di dare una lettura a [3].

Componenti principali di un’app ransomware Android

Come precedentemente specificato, dall’analisi del file AndroidManifest.xml è possibile osservare i componenti principali dell’applicazione. Capire come è strutturato il Manifest è pertanto fondamentale per orientarsi dentro l’applicazione, al fine di comprendere quali siano i componenti che vengono avviati per primi. In particolare, in questo ransomware vi sono cinque componenti principali:

• Due attività, (rappresentate dal campo <activity>): zynga.FarmVilleTropicEscape.FarvwewmVill e com.zynga.FarmVilleTropicEscape.FarmVilleTropicEscape. Notate come i nomi dei componenti richiamino una popolare applicazione disponibile per Android, essendo però leggermente diversi. La seconda attività si distingue in particolare per essere quella che viene caricata all’avvio dell’applicazione. Questo può essere dedotto dal campo <intent_filters>, che rappresenta quali messaggi possono essere ricevuti da quel componente. Per la seconda attività, l’azione prevista è android.intent.action.MAIN, che sta proprio ad indicare che l’attività in esame è quella principale.
• Due receiver (rappresentati dal campo <receiver>):
  com.zynga.FarmVilleTropicEscape.FarmVilleTropvicEscape e
  com.zynga.FarmVilleTropicEscape.FarmVillevaTropicEscape. Notate come i nomi siano molto simili, ma comunque diversi, rispetto alle attività. Questo tipo di tecnica, atta a confondere l’analista, è molto frequente nei malware Android in generale. Di particolare interesse è il secondo receiver, per via dei suoi <intent_filters>. Fra questi, spiccano android.intent.action.REBOOT e android.intent.action.BOOT_COMPLETED, che rappresentano il fatto che l’applicazione possa attivarsi all’avvio/riavvio del telefono.
• Un servizio (rappresentato dal campo <service>), denominato zynga.FarmVilleTropicEscape.FarmVvailleTropicEscape

Permessi richiesti dalle app ransomware Android

Inoltre, l’applicazione richiede un grosso insieme di permessi per la manipolazione delle funzionalità del telefono. I permessi sono i seguenti:

• android.permission.RECEIVE_BOOT_COMPLETED
• android.permission.INTERNET
• android.permission.READ_PHONE_STATE
• android.permission.ACCESS_NETWORK_STATE
• android.permission.WAKE_LOCK
• android.permission.GET_TASKS
• android.permission.SYSTEM_ALERT_WINDOW
• android.permission.KILL_BACKGROUND_PROCESSES

In altre parole, questi permessi indicano il fatto che l’applicazione può accedere ad internet, leggere lo stato del telefono, e può anche disattivare dei processi.

Adesso sappiamo da quali componenti della nostra applicazione partire per effettuare l’analisi statica del codice, che verrà proposta nella prossima parte di questa serie.

References:

[1] Google. Application Fundamentals. https://developer.android.com/guide/components/fundamentals.html

[2] ApkTool. https://ibotpeaches.github.io/Apktool/

[3] Google. App Manifest. https://developer.android.com/guide/topics/manifest/manifest-intro.html

 

A cura di: Davide Maiorca