22 gennaio 2020

Alla fine dello scorso anno, tramite la funzione di rilevamento delle modifiche nell'area di sistema, sui dispositivi di alcuni dei nostri utenti è stata registrata una modifica nel file di sistema /system/lib/libc.so. Questa è una delle principali librerie dei sistemi operativi basati su Linux che si occupa delle chiamate di sistema e delle funzioni di base. Un esame dettagliato di questo caso ci ha permesso di rilevare nuovi campioni della famiglia di trojan Android.Xiny che conosciamo dal 2015.

Nei campioni di questa famiglia abbiamo per la prima volta visto l'impostazione dell'attributo "non modificabile" a file, il che rendeva molto più difficile la rimozione dei trojan da dispositivi.

Si vedeva piuttosto divertente: al file apk di un'applicazione installata veniva impostato l'attributo indicato, il tentativo di rimuovere questa applicazione sembrava completato con successo, i relativi dati venivano rimossi, ma il file apk stesso rimaneva al suo posto. Dopo il riavvio del dispositivo l'applicazione "sbucava" di nuovo. Abbiamo parlato di uno dei simili trojan nel 2016. Per contrastare tali minacce, abbiamo aggiunto al nostro antivirus la funzionalità di reset degli attributi di file che funziona a condizione che l'utente abbia fornito all'antivirus i permessi di root.

In questo articolo vediamo un altro interessante metodo di auto-protezione utilizzato dalle nuove versioni di Android.Xiny.

Android 5.1? Nel 2019?

Il trojan esaminato in questo articolo funziona sui sistemi operativi Android fino alla versione 5.1 inclusa. Può sembrare strano che sia ancora attivo un programma malevolo progettato per le versioni così "antiche" di Android (la 5.1 è stata rilasciata nel 2015). Ma nonostante la loro età, le versioni superate sono ancora in uso. Secondo i dati di Google del 7 maggio 2019, il 25,2% dei dispositivi ha Android 5.1 e precedenti. Le statistiche dei nostri utenti mostrano una cifra leggermente più grande — circa il 26%. Ciò vuol dire che circa un quarto di tutti i dispositivi Android è potenziale bersaglio, il che non è una cifra proprio piccola. Tenendo presente che i dispositivi indicati sono suscettibili a vulnerabilità che non verranno mai risolte, non è una sorpresa che le vecchie versioni del sistema operativo Android rappresentino ancora interesse per gli autori di virus. E va ricordato che i permessi di root che possono essere ottenuti tramite lo sfruttamento delle vulnerabilità menzionate sciolgono le mani agli autori di virus — utilizzandole è possibile fare qualsiasi cosa sul dispositivo. Anche se il più delle volte si tratta di semplici installazioni di applicazioni.

Funzioni principali del trojan

Sin dalle prime versioni, la funzione principale di Android.Xiny è quella di installare sul dispositivo applicazioni arbitrarie senza autorizzazione dell'utente. Grazie a ciò, i malintenzionati possono guadagnare partecipando a partner program che pagano per installazioni. Per quanto si può giudicare, questa è una delle principali fonti di guadagni per i creatori di questa famiglia. Dopo l'avvio di alcuni dei campioni, si può in pochi minuti avere un dispositivo quasi non operativo su cui sarà installato e avviato un grande numero di svariate applicazioni innocue, ma inutili per l'utente. Oltre a ciò, questi trojan possono installare anche software malevoli — dipende dal comando ricevuto dal server di gestione.

La cosa più interessante che mette in rilievo le nuove versioni di Android.Xiny è la protezione dalla rimozione. Se ne occupano due componenti. Vediamoli più in dettaglio.

Installer

• sha1: f9f87a2d2f4d91cd450aa9734e09534929170c6c
• rilevamento: Android.Xiny.5261

Questo componente si avvia dopo l'ottenimento dei permessi di root. Sostituisce con sé i file di sistema /system/bin/debuggerd e /system/bin/ddexe per garantire il proprio avvio automatico e salva gli originali sotto nomi con il suffisso _server agendo come classico virus di tipo companion. Copia inoltre nella partizione di sistema alcuni altri file eseguibili dalla cartella tramessa nei parametri della riga di comando. Inoltre, il trojan può aggiornare i componenti che ha installato nella partizione di sistema, se viene avviato con parametri speciali e viene indicata la cartella in cui sono locate le nuove versioni.

Android.Xiny.5261 contiene un'impressionante lista dei file da rimuovere. Include i percorsi caratteristici dei campioni precedenti della famiglia, nonché delle famiglie di trojan concorrenti che si installano nella partizione di sistema. Come ad esempio, Triada.

Oltre a ciò, Android.Xiny.5261 rimuove alcune applicazioni preinstallate — probabilmente, per liberare spazio. Infine, rimuove le note applicazioni di gestione dei permessi di root – come ad esempio, SuperSU, KingRoot ecc. In questo modo priva l'utente della possibilità di usare i permessi di root e quindi di rimuovere i componenti trojan installati nella partizione di sistema.

Libreria di sistema libc.so modificata

• sha1: 171dba383d562bec235156f101879223bf7b32c7
• rilevamento: Android.Xiny.5260

Questo file ci ha interessati particolarmente e da esso è iniziata questa indagine. Scorrendolo a colpo d'occhio in hiew, si può accorgersi della presenza di codice eseguibile verso la fine nella sezione .data, una cosa che suscita sospetti.

Apriamo il file in IDA e vediamo che tipo di codice è.

Scopriamo che in questa libreria sono state modificate le seguenti funzioni: mount, execve, execv, execvp, execle, execl, execlp.

Codice della funzione mount modificata:

int __fastcall mount(const char *source, const char *target, const char *filesystemtype, unsigned int mountflags, const void *data)
{
  unsigned __int8 systemPath[19]; // [sp+18h] [bp-1Ch]
  bool receivedMagicFlags; // [sp+2Bh] [bp-9h]
  int v13; // [sp+2Ch] [bp-8h]
  v13 = MAGIC_MOUNTFLAGS; // 0x7A3DC594
  receivedMagicFlags = mountflags == MAGIC_MOUNTFLAGS;
  if ( mountflags == MAGIC_MOUNTFLAGS )
    mountflags = 0x20;                          // MS_REMOUNT
  if ( receivedMagicFlags )
    return call_real_mount(source, target, filesystemtype, mountflags, data);
  if ( mountflags & 1 )                         // MS_RDONLY
    return call_real_mount(source, target, filesystemtype, mountflags, data);
  if ( getuid_() )                              // not root
    return call_real_mount(source, target, filesystemtype, mountflags, data);
  memCopy(systemPath, (unsigned __int8 *)off_73210 + 471424, 8);// /system
  decrypt(systemPath, 8);
  if ( memCompare((unsigned __int8 *)target, systemPath, 8) || !isBootCompete() )
    return call_real_mount(source, target, filesystemtype, mountflags, data);
  *(_DWORD *)errno_() = 13;
  return -1;
}

All'inizio qui viene eseguita la verifica del parametro mountflags per rilevare la presenza del valore "magico" 0x7A3DC594. Se alla funzione è stato passato questo valore, il controllo viene immediatamente trasferito alla vera funzione mount. Quindi viene controllato se viene effettuato un tentativo di rimontaggio per scrittura della partizione /system e se il caricamento del sistema operativo è completato. Se queste condizioni sono soddisfatte, la vera funzione mount non viene richiamata, e viene restituito un errore. Pertanto, la funzione mount modificata dal trojan non consente di rimontare per scrittura la partizione di sistema a nessuno tranne il trojan stesso il quale la richiama con il parametro "magico".

Codice della funzione execve modificata (tutto analogo nelle altre funzioni exec*):

int __fastcall execve(const char *filename, char *const argv[], char *const envp[])
{
  int v3; // r3
  if ( targetInDataOrSdcard(filename) >= 0 )    // returns -1 if true
  {
    sub_7383C();
    v3 = call_real_execve(filename, argv, envp);
  }
  else
  {
    *(_DWORD *)errno_() = 13;
    v3 = -1;
  }
  return v3;
}
 
int __fastcall targetInDataOrSdcard(const char *path)
{
  char buf[516]; // [sp+8h] [bp-204h]
  if ( isDataOrSdcard(path) )
    return -1;
  if ( *path == '.' && getcwd_(buf, 0x200u) && isDataOrSdcard(buf) )
    return -1;
  return 0;
}

Qui viene controllato se il percorso del file avviato inizia con "/data/" e contiene "/sdcard". Se una delle condizioni è soddisfatta, l'avvio viene bloccato. Ricordate che nel percorso /data/data/ sono locate le directory delle applicazioni. In questo modo viene bloccato l'avvio dei file eseguibili da tutte le directory in cui un'applicazione normale possa creare un file.

Le modifiche apportate nella libreria di sistema libc.so interferiscono con il funzionamento delle applicazioni di ottenimento dei permessi di root. A causa di modifiche nelle funzioni exec*, tale applicazione non potrà avviare exploit per aumentare i privilegi nel sistema in quanto normalmente gli exploit sono file eseguibili che vengono scaricati dalla rete nella directory di un'applicazione e vengono lanciati. Se un'applicazione ha potuto comunque aumentare i privilegi, la funzione mount modificata non le consentirà di rimontare per scrittura la partizione di sistema e quindi di effettuarci alcuna modifica.

In fin dei conti, l'auto-protezione del trojan è composta da due parti: il suo installer rimuove le applicazioni di gestione dei permessi di root, e la libreria modificata libc.so ne impedisce ulteriori installazioni. Inoltre, questa protezione funziona anche nei confronti dei "concorrenti" — altri trojan che ottengono i permessi di root e si installano nella partizione di sistema, visto che funzionano sullo stesso principio delle "buone" applicazioni di ottenimento dei permessi di root.

Come combattere i simili trojan?

Per sbarazzarsi di Android.Xiny.5260, è possibile eseguire la reinstallazione del firmware del dispositivo – a condizione che per esso esista un firmware in pubblico dominio. Ma si può rimuovere il programma malevolo in un altro modo? È difficile, ma è possibile – ci sono diversi modi. Per ottenere i permessi di root, possono essere utilizzati exploit sotto forma di librerie so. A differenza dei file eseguibili, il trojan non ne bloccherà il caricamento. È inoltre possibile utilizzare il componente del trojan stesso che è progettato per fornire i permessi di root alle sue altre parti. Riceve comandi attraverso il socket del percorso /dev/socket/hs_linux_work201908091350 (in diverse versioni il percorso può differire). Per bypassare il blocco di mount, può essere utilizzato il valore "magico" del parametro mountflags, o potete richiamare direttamente la syscall corrispondente.

Certo, non andrò a implementare quanto sopra.

Se il vostro dispositivo si prenderà un simile trojan, vi consigliamo di utilizzare l'immagine del sistema operativo ufficiale per eseguire la reinstallazione del firmware. Non dimenticate però che con ciò verranno rimossi tutti i file e i programmi dell'utente, pertanto, pensate in anticipo ai backup.

#Android.Xiny #trojan #antivirus