A la fin de l'année dernière, à l’aide de la fonction de détection de modifications dans la zone système, chez certains de nos utilisateurs, une modification du fichier système /system/lib/libc.so a été détectée. . C'est l'une des bibliothèques principales des systèmes d'exploitation basés sur Linux, qui est responsable des appels système et des fonctions principales. Une étude détaillée de ce cas nous a permis de révéler de nouveaux échantillons de la famille de Trojans Android.Xiny que l'on connait depuis 2015.

Pour la première fois dans les représentants de cette famille de malwares, nous avons vu l'attribut " non modifiable" installé sur des fichiers, ce qui rendait la suppression des malwares plus compliquée.

L’attribut était installé sur le fichier apk d'une application installée sur un appareil, de sorte que la suppression de l'application semblait réussie, alors que le fichier apk restait intact. Après un redémarrage de l'appareil, l'application réapparaissait. Nous avons déjà décrit un malware de ce type en 2016. Pour lutter contre ces menaces, nous avons ajouté à notre antivirus une fonction permettant de retirer les attributs des fichiers qui est opérationnelle à condition que l'utilisateur donne à l'antivirus l'accès root.

Dans cet article, nous examinerons une autre méthode d'autoprotection utilisée par les nouvelles versions d'Android.Xiny.

Android 5.1? En 2019 ?

Le Trojan que nous examinons dans cet article fonctionne sous Android jusqu'à la version 5.1 incluse. Il peut paraître bizarre qu’un logiciel malveillant conçu pour des versions si anciennes d'Android soit toujours actif (la version 5.1 a été publié en 2015). Mais, malgré leur ancienneté, ces versions sont encore utilisées. Selon les estimations de Google, vers le 7 mai 2019, 25,2% des appareils fonctionnaient sous Android 5.1 et des versions plus anciennes. Nos statistiques donnent un chiffre légèrement plus élevé - environ 26%. Cela signifie qu'environ un quart des appareils Android sont des cibles potentielles de ces malwares. Étant donné que ces dispositifs sont soumis à des vulnérabilités qui ne seront jamais corrigées, il n'est pas surprenant que les anciennes versions de l'OS Android soient encore intéressantes pour les auteurs de virus. L'accès root obtenu via ces vulnérabilités leur permet de faire tout ce qu'ils veulent sur l'appareil, alors qu’il sert normalement à l’installation d’applications.

Fonctions principales du Trojan

Depuis ses premières versions, la fonction principale du cheval de Troie Android.Xiny est l'installation d’applications sur l'appareil sans aucune autorisation de l'utilisateur. Les attaquants peuvent ainsi par exemple gagner de l'argent en participant à des programmes d'affiliation qui les rémunèrent pour l'installation d'applis. Il semble que ce soit l'une de leurs principales sources de revenus. Après le lancement d’un de ces malwares, il est possible de rendre un appareil complètement inutilisable en quelques minutes seulement, avec une multitude d'applications inoffensives mais inutiles en cours d'exécution. De plus, ces chevaux de Troie peuvent installer des logiciels malveillants, en fonction des instructions reçues du serveur de gestion.

La chose la plus intéressante qui distingue les nouvelles versions du cheval de Troie Android.Xiny des anciennes est son mécanisme de protection contre la suppression. Deux composants sont responsables de cette fonction. Examinons-les en détail.

Installateur

• sha1: f9f87a2d2f4d91cd450aa9734e09534929170c6c
• Détection: Android.Xiny.5261

Ce composant est lancé après l'obtention de l'accès root. Il se met à la place des fichiers système /système/bin/debuggerd et /système/bin/ddexe pour assurer son lancement automatique. En ce qui concerne les originaux, il les enregistre sous des noms avec le suffixe _server, en agissant comme un virus compagnon classique. Il copie également vers la partition système quelques fichiers exécutables du dossier indiqué dans les paramètres en ligne de commande. De plus, lancé avec certains paramètres et avec l'indication du dossier où se trouvent de nouvelles versions, le Trojan est capable de mettre à jour des composants qu'il a installés dans la partition système.

Android.Xiny.5261 contient une liste impressionnante de fichiers à supprimer. Elle comprend les chemins vers les anciens représentants de la famille ainsi que vers des familles de Trojans « concurrents » qui s'installent dans la partition système, comme Triada.

De plus, Android.Xiny.5261 supprime certaines applications pré-installées, peut-être pour libérer de l’espace. Enfin, il supprime des applications connues pour la gestion des privilèges root, telles que SuperSU, KingRoot et d'autres. Ainsi, il prive l'utilisateur de la possibilité d'utiliser l'accès root, et donc de supprimer des composants du Trojan installés dans la partition système.

La bibliothèque système modifiée libc.so

• sha1: 171dba383d562bec235156f101879223bf7b32c7
• Détection: Android.Xiny.5260

C'est ce fichier qui a particulièrement attiré notre attention et avec lequel notre étude a commencé. Un coup d'œil rapide sur le fichier dans l'éditeur hiew permet de remarquer la présence d'un code exécutable plus proche de la fin, dans la section .data, ce qui éveille des soupçons.

Ouvrons le fichier dans IDA et regardons le code.

Il s'avère que dans cette bibliothèque, les fonctions suivantes ont été modifiées : mount, execve, execv, execvp, execle, execl, execlp.

Le code de la fonction modifiée mount :

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;
}

Au début, une vérification du paramètre mountflags à la recherche de la valeur " magique " 0x7A3DC594 est effectuée. Si cette valeur est transmise à la fonction, la gestion est tout de suite transmise à la vraie fonction mount. Ensuite, on vérifie si une tentative de remonter la partition /système pour écriture est effectuée et si le chargement de l'OS est terminé. Si ces conditions sont satisfaites, la vraie fonction mount n'est pas appelée et une erreur est renvoyée. Ainsi, une fonction mount modifiée par le Trojan empêche l’écriture dans la partition système, seul le Trojan peut le faire en appelant la fonction avec le paramètre "magique".

Le code de la fonction modifiée execve (dans les autres fonctions exec* tout est similaire) :

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;
}

Ici, on vérifie si le chemin vers le fichier exécutable commence par "/data/" et s'il contient "/sdcard". Si une des conditions est satisfaite, le démarrage est bloqué. Rappelons que les chemins /date/data/ sont les chemins vers les répertoires des applications. Ainsi, le lancement de fichiers exécutables de tous les répertoires dans lesquels une application ordinaire peut créer un fichier est bloqué.

Ici, on vérifie si le chemin vers le fichier exécutable commence par "/data/" et s'il contient "/sdcard". Si une des conditions est satisfaite, le démarrage est bloqué. Rappelons que les chemins /date/data/ sont les chemins vers les répertoires des applications. Ainsi, le lancement de fichiers exécutables de tous les répertoires dans lesquels une application ordinaire peut créer un fichier est bloqué.

Ainsi, l'autoprotection du Trojan consiste en deux parties : son installateur supprime les applications pouvant gérer l'accès root, et la bibliothèque modifiée libc.so empêche de les réinstaller. Ceci protège également contre les " concurrents " - d'autres Trojans qui obtiennent l'accès root et s'installent dans la partition système, puisqu'ils fonctionnent de la même manière que les applications " saines " destinées à obtenir l'accès root.

Comment lutter contre ce Trojan ?

Pour se débarrasser d'Android.Xiny.5260, vous pouvez reflâcher le dispositif mais à condition qu'un firmware correspondant soit disponible.

Est-il possible de supprimer ce programme malveillant d'une autre manière ? C’est possible mais difficile. Il existe plusieurs façons de faire.

Pour obtenir l'accès root, il est possible d'utiliser des exploits sous forme de bibliothèques so. Le Trojan ne bloque pas leur téléchargement, contrairement à ce qu’il fait pour les fichiers exécutables. Il est également possible d'utiliser le composant du Trojan qui est destiné à fournir l'accès root à ses autres composants. Il reçoit des commandes via un socket sur le chemin /dev/socket/hs_linux_work201908091350 (le chemin peut être différent en fonction des versions). Pour contourner le blocage mount, il est possible d'utiliser la valeur " magique " du paramètre mountflags, ou d’appeler directement le syscall approprié.

Pour des raisons évidentes, nous n’allons pas le faire.

Si votre appareil a été contaminé par un de ces malwares, nous recommandons d'utiliser une image officielle de l'OS pour reflâcher le firmware. Mais vous ne devez pas oublier que dans ce cas, tous les fichiers et applications seront supprimés, il est donc nécessaire de créer d'abord des copies de sauvegarde.