ZitMo (ZeuS-in-the-Mobile) è uno dei più vecchi e conosciuti Trojan mobile. Viene installato (o la sua installazione viene suggerita) sui dispositivi mobili dai computer infetti da ZeuS. Dopo l'installazione, ZitMo e ZeuS lavorano fianco a fianco al fine di rubare denaro dai conti bancari delle vittime. Sostanzialmente, ZitMo è usato per intercettare tutti i messaggi SMS in arrivo e inoltrarli a un C&C Server, al fine di eludere l'autenticazione a due fattori basata su SMS. Questo è un classico esempio di attacco Man-in-the-Mobile.

Nella tabella sottostante sono elencati alcuni dei sample analizzati che corrispondono ad alcune delle numerose varianti di ZitMo.

MD5	PACKAGE	NOME APP	ICONA
ECBBCE17053D6EAF9BF9CB7C71D0AF8D	com.systemsecurity6.gms	Truesteer Rapport
B1AE0D9A2792193BFF8C129C80180AB0	com.android.security	Android Security Suite Premium
E98791DFFCC0A8579AE875149E3C8E5E	com.android.security	Zertifikat

In tutte le sue varianti, ZitMo si presenta con skin (più o meno) diverse in cui pretende sempre di essere una app di sicurezza o correlata a dei certificati, ma in realtà ruba i messaggi SMS in arrivo. Infatti, in quasi tutte le sue varianti per Android, richiede sempre almeno le seguenti due autorizzazioni:

• android.permission.RECEIVE_SMS
• android.permission.SEND_SMS

La prima viene utilizzata per monitorare/memorizzare i messaggi SMS in arrivo, mentre la seconda viene utilizzata per inviare messaggi SMS.

Ricordiamo che è sempre buona norma LEGGERE ATTENTAMENTE i permessi che una app richiede prima di installarla!

Come si può notare dalla tabella precedente, tutti i sample di ZitMo analizzati usano sempre uno dei due seguenti package:

• com.systemsecurity6.gms
• com.android.security

E uno dei seguenti tre nomi per l'app:

• Trusteer Rapport
• Android Security Suite Premium
• Zertifikat

Come già detto, una volta lanciate, tutte le varianti di ZitMo mostrano un'interfaccia utente piuttosto simile in cui, in modo da sembrare un'app di sicurezza o correlata a dei certificati, viene visualizzato un "codice di attivazione". In tutte le sue varianti eccetto l'ultima analizzata, ZitMo utilizza come "codice di attivazione" l'ID del dispositivo (cioè l'IMEI per i telefoni GSM e il MEID o l'ESN per i telefoni CDMA), con adeguate translazioni e alterazioni al fine di camuffarlo.
Tutti le varianti di ZitMo, eccetto l'ultima analizzata, provano a connettersi e a inviare gli SMS rubati a uno dei seguenti URL, tramite HTTP POST requests:

• http://android2update.com/aapl.php
• http://android2update.com/biwdr.php
• http://androidversion.net/2/biwdr.php
• http://androidssafe.com/biwdr.php
• http://getupdateandroid.com/biwdr.php
• http://updateandroid.biz/update/biwdr.php
• http://softthrifty.com/security.jsp

[Si noti che tutti questi domini non sono più attivi.]

L'ultima variante di ZitMo analizzata, rilevato da Vir.IT eXplorer come Android.Zitmo.H, utilizza come codice di attivazione una stringa cablata a codice nel malware stesso e non si connette a nessun URL.

Infine, la maggior parte delle varianti di ZitMo presentano caratteristiche tipiche delle botnet, in particolare l'abilit di ricevere comandi da un C&C Server (generalmente via SMS). In generale, sono quasi sempre implementati almeno il comando per abilitare/disabilitare il malware e quello per cambiare il numero di telefono del C&C Server.

Ora diamo uno sguardo più approfondito ad alcune delle varianti ZitMo!

Android.Zitmo.A

In questa variante di ZitMo, rilevata da Vir.IT eXplorer come Android.Zitmo.A, il "codice di attivazione" mostrato non è nient'altro che l'ID del dispositivo (cioè l'IMEI per i telefoni GSM e il MEID o l'ESN per i telefoni CDMA), ricavato tramite il metodo getDeviceId() della classe TelephonyManager, intervallato da un "-" ogni 4 caratteri.
Inoltre, in background, il BroadcastReceiver SmsReceiver intercetta tutti gli SMS ricevuti (tramite l'azione android.provider.Telephony.SMS_RECEIVED) e, per ogni messaggio intercettato, avvia il servizio MainService.
Per ogni SMS ricevuto, il servizio MainService lancia a sua volta un nuovo thread (SmsBlockerThread) in cui estrae il mittente e il corpo del messaggio. Se i valori estratti sono consistenti (non null), allora, sono elencati in una lista di coppie chiave-valore con uno specifico formato ("f" seguito dal contatore della PDU corrente come chiave per il mittente e "b" seguito dal contatore della PDU corrente come chiave per il corpo del messaggio). Dopo aver elencato tutte le PDU in arrivo, anche anche la coppia formata da "pid" come chiave e l'ID del dispositivo come valore è memorizzata nella lista. Infine, la lista completa è inviata usando HTTP POST request, attraverso il metodo postRequest() della classe ServerSession, all'URL(cablato a codice in maniera "criptata"): http://softthrifty.com/security.jsp.

Se si verifica un'eccezione ClassCastException durante l'invio dei dati, il thread va in sleep per 15 secondi (15000 millisecondi) e poi riprova nuovamente.

Android.Zitmo.B

Anche in questa variante di ZitMo, rilevata da Vir.IT eXplorer come Android.Zitmo.B, il "codice di attivazione" mostrato non è nient'altro che l'ID del dispositivo (cioè l'IMEI per i telefoni GSM e il MEID o l'ESN per i telefoni CDMA), ricavato tramite il metodo getDeviceId() della classe TelephonyManager. Tuttavia, in questa variante, ZitMo prova a camuffarlo aggiungendoci un "1" in testa, prendendo solamente 7 cifre dell'ID del dispositivo (quelle dalla posizione 8 fino alla fine) e, infine, aggiungendoci un "3" in coda.
Inoltre, in background, il BroadcastReceiver SecurityReceiver intercetta tutti gli SMS ricevuti (tramite l'azione android.provider.Telephony.SMS_RECEIVED). Lo stesso BroadcastReceiver intercetta anche l'avvio del Sistema Operativo e tutte le nuove chiamate in uscita.
Per ogni SMS ricevuto, SecurityReceiver estrae le informazioni relative e, se il malware abilitato (valore "AntivirusEnabled" del file "secsuite" nelle SharedPreferences), allora queste informazioni sono inviate all'URL (cablato a codice in maniera "criptata"): http://updateandroid.biz/update/biwdr.php&from=[...]&text=[...]. Dove nel campo "text" ci sarà la stringa "LocalTime: " seguita dal timestamp dell'arrivo del SMS (ricavato tramite il metodo Calendar.getInstance().getTime()) e dal corpo del messaggio.
Tutte le informazioni dei messaggi sono anche salvate in un database SQLite interno.

Questa variante di ZitMo molto più avanzata di quella presentata precedentemente e mostra caratteristiche tipiche delle botnet. Infatti, tramite il metodo AlternativeControl() della classe SecurityReceiver, questa variante è in grado di ricevere comandi da un C&C Server via SMS.
I nomi dei comandi variano per quasi tutti i sample analizzati di questa variante di ZitMo ma, in sostanza, il malware ha la capacità di:

• Inviare informazioni private dell'utente (come ad esempio il modello del dispositivo, il produttore, la versione, ecc...);
• Settare/rimuovere un numero di telefono alternativo per il C&C Server (memorizzato nel valore "AlternativeNumber" del file "secsuite" nelle SharedPreferences);
• Abilitare/disabilitare il malware stesso (attraverso i valori "AntivirusUninstallReq", "AntivirusEnabled" e "AntivirusUninstallComplete" del file "secsuite" nelle SharedPreferences).

Android.Zitmo.H

In questa ultima variante di ZitMo, rilevata da Vir.IT eXplorer come Android.Zitmo.H, il "codice di attivazione" mostrato non nient'altro che una stringa cablata a codice nel malware stesso (ovvero "7725486193").
Inoltre, come al solito, il BroadcastReceiver SmsReceiver intercetta tutti gli SMS ricevuti (tramite l'azione android.provider.Telephony.SMS_RECEIVED).
Anche questa variante di ZitMo mostra caratteristiche tipiche delle botnet. Infatti, tramite il metodo onReceive() della classe SmsReceiver, è in grado di ricevere comandi da un C&C Server via SMS.
Sostanzialmente, il malware ha la capacità di:

• Inoltrare tutti gli SMS ricevuti al numero di telefono del C&C Server (memorizzati nel valore "adminNumber" del file "SecurityService" nelle SharedPreferences). I messaggi SMS sono inoltrati con il corpo del messaggio formato dal corpo del messaggio originale, seguito da ". F:" e dal mittente del messaggio.
• Cambiare il numero di telefono del C&C Server tramite il comando "set admin".
• Abilitare/disabilitare il malware stesso (attraverso il valore "serviceStatus" del file "SecurityService" nelle SharedPreferences) tramite i comandi "on"/"off".

Inoltre, per ogni comando inviato, il C&C Server ricever in risposta un SMS di conferma con differenti codici ("ONOK" se il malware stato abilitato correttamente nel dispositivo, "OFOK" se il malware stato disabilitato correttamente nel dispositivo e "SAOK" se il numero di telefono del C&C Server stato cambiato correttamente). Infine, un'altro messaggio ("INOK") inviato per confermare la corretta infezione del nuovo dispositivo.
Il numero di telefono del C&C Server settato di default cablato a codice nel malware stesso (ovvero: "+46769436094").

---------------------------------
Paolo Rovelli
Mobile Developer & Malware Analyst
CRAM (Centro Ricerche Anti-Malware) di TG Soft