(Parte 2)
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.
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:
Dal punto di vista dell’organizzazione del codice, le app Android si articolano in quattro componenti fondamentali [1]:
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].
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:
Inoltre, l’applicazione richiede un grosso insieme di permessi per la manipolazione delle funzionalità del telefono. I permessi sono i seguenti:
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.
[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
Nel panorama odierno della sicurezza informatica, la protezione degli endpoint rappresenta un obiettivo imprescindibile per…
I numeri dell’evento Oltre 1000 ospiti, 42 relatori, 20 interventi tematici e 5 Tavole Rotonde:…
Group-IB è un fornitore, con sede a Singapore, di sistemi ad elevata attendibilità per il…
Le interazioni di natura digitale, su rete pubblica o all’interno di reti private, hanno assunto…
La Commissione Europea ha di recente ricordato come “Artificial intelligence (AI) is not science fiction;…
Di seguito il programma della Cyber Crime Conference 2024, che avrà luogo a Roma nei…