Viaggio nei malware Android: l’incubo Ransomware – Parte 2
(Parte 2)
Introduzione
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.
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).
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.
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.
Generalità App
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.
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].
Analisi di base – Manifest
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
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
L’Ing. Davide Maiorca (http://pralab.diee.unica.it/it/DavideMaiorca) ha conseguito presso l'Università degli Studi di Cagliari la Laurea Specialistica in Ingegneria Elettronica (con punti 110/110 e lode) nel 2012, ed il Dottorato (PhD) in Ingegneria Elettronica ed Informatica nel 2016. Nel 2017, la sua tesi di dottorato è stata annoverata dal CLUSIT (Associazione Italiana per la Sicurezza Informatica) fra i migliori lavori a livello nazionale nel campo della sicurezza informatica. Lavora per il Pattern Recognition and Applications Lab (PRALab – Dipartimento di Ingegneria Elettrica ed Elettronica, Università degli Studi di Cagliari - Diretto dal prof. Fabio Roli) dal 2012, dove attualmente ricopre il ruolo di post-doc. I suoi campi di ricerca includono l’analisi di malware all’interno di documenti e applicazioni multimediali (PDF, Microsoft Office, Flash), l’analisi di malware Android, e l’Adversarial Machine Learning. Da novembre 2013 ad aprile 2014 è stato Visiting Student presso la Ruhr-Universität Bochum, nel gruppo System Security guidato dal Prof. Dr. Thorsten Holz, dove ha lavorato a tecniche di reverse engineering per applicazioni Android. Dal 2016, è docente del seminario “Mobile Forensics” presso il Dipartimento di Ingegneria Elettrica ed Elettronica, Università degli Studi di Cagliari. È autore di numerose pubblicazioni su conferenze e riviste internazionali, e fa parte di diversi comitati scientifici internazionali. Svolge, inoltre, attività di consulenza tecnica in ambito legale.
