À la fin de l'année dernière, en utilisant la fonction de détection des modifications dans la zone système, certains de nos utilisateurs ont enregistré une modification dans le fichier système /system/lib/libc.so. C'est l'une des principales bibliothèques de systèmes d'exploitation Linux qui est responsable des appels système et des fonctions de base. Un examen détaillé de cette affaire a révélé de nouveaux échantillons de la famille de chevaux de Troie
Android.Xiny , connus de nous depuis 2015.
Pour la première fois, nous avons vu l'installation de l'attribut «
immuable » sur les fichiers de ses représentants, ce qui a grandement compliqué la suppression des chevaux de Troie des appareils.
Cela avait l'air assez amusant: l'attribut spécifié a été placé dans le fichier apk de l'application installée, une tentative de suppression de cette application a réussi, ses données ont été supprimées, mais le fichier apk lui-même est resté en place. Après avoir redémarré l'appareil, l'application "est apparue" à nouveau. Nous avons
parlé de l'un de ces chevaux de Troie en 2016. Pour lutter contre ces menaces, nous avons ajouté une fonction de réinitialisation des attributs de fichier à notre antivirus, qui fonctionne à condition que l'utilisateur ait accordé des privilèges root à l'antivirus.
Dans cet article, nous considérerons une autre méthode intéressante d'autodéfense, utilisée par les nouvelles versions d'Android.Xiny.
Android 5.1? En 2019?
Le cheval de Troie considéré dans cet article fonctionne sous Android OS jusqu'à la version 5.1 incluse. Il peut sembler étrange que des logiciels malveillants conçus pour de telles versions «anciennes» d'Android soient toujours actifs (la version 5.1 est sortie en 2015). Mais malgré leur âge, les anciennes versions sont toujours utilisées. Selon
Google, au 7 mai 2019, 25,2% des appareils fonctionnaient sous Android 5.1 et versions antérieures. Les statistiques pour nos utilisateurs donnent un nombre légèrement plus élevé - environ 26%. Cela signifie qu'environ un quart de tous les appareils Android sont des cibles potentielles, ce qui n'est pas si petit. Étant donné que ces appareils sont sensibles à des vulnérabilités qui ne seront jamais corrigées, il n'est pas surprenant que les anciennes versions du système d'exploitation Android intéressent toujours les auteurs de virus. En effet, les droits root, qui peuvent être obtenus en exploitant les vulnérabilités mentionnées, délient les mains des auteurs de virus - avec leur aide, vous pouvez tout faire sur l'appareil. Bien que cela se résume le plus souvent à l'installation banale d'applications.
Les principales fonctions du cheval de Troie
À partir des versions les plus anciennes, la fonction principale du cheval de Troie Android.Xiny est d'installer des applications arbitraires sur l'appareil sans autorisation de l'utilisateur. Ainsi, les attaquants peuvent gagner de l'argent en participant à des programmes d'affiliation qui paient l'installation. Pour autant que l'on puisse en juger, il s'agit d'une des principales sources de revenus pour les créateurs de cette famille. Après avoir lancé certains de ses représentants, vous pouvez obtenir un appareil pratiquement inopérant en quelques minutes, sur lequel de nombreuses applications utilisateur inoffensives mais inutiles seront installées et lancées. De plus, ces chevaux de Troie peuvent également installer des logiciels malveillants - tout dépend de la commande reçue du serveur de gestion.
La chose la plus intéressante qui déclenche de nouvelles versions du cheval de Troie Android.Xiny est la protection contre la suppression. Deux composantes en sont responsables. Examinons-les plus en détail.
Installateur
sha1: f9f87a2d2f4d91cd450aa9734e09534929170c6c
Détecter: Android.Xiny.5261
Ce composant démarre après avoir obtenu les privilèges root. Il remplace les fichiers système / system / bin / debuggerd et / system / bin / ddexe pour assurer son lancement automatique et enregistre les originaux sous les noms avec le suffixe _server, agissant comme un virus compagnon classique. Il copie également plusieurs fichiers exécutables supplémentaires sur la partition système à partir du dossier transmis dans les paramètres de ligne de commande. De plus, le cheval de Troie peut mettre à jour les composants qu'il a installés dans la partition système si vous l'exécutez avec des paramètres spéciaux et spécifiez le dossier dans lequel se trouvent les nouvelles versions.
Android.Xiny.5261 contient une liste impressionnante de fichiers à supprimer. Il inclut des chemins caractéristiques des membres plus âgés de la famille, ainsi que des familles concurrentes de chevaux de Troie installés dans la partition système. Comme, par exemple, Triada.
De plus, Android.Xiny.5261 supprime certaines applications préinstallées - éventuellement pour libérer de l'espace. Enfin, il supprime les applications de gestion des droits root bien connues - telles que SuperSU, KingRoot et autres. Ainsi, il prive l'utilisateur de la possibilité d'utiliser les droits root et, par conséquent, supprime les composants cheval de Troie installés dans la partition système.
Bibliothèque système modifiée libc.so
sha1: 171dba383d562bec235156f101879223bf7b32c7
Détecter: Android.Xiny.5260
Ce dossier nous a le plus intéressé, et cette recherche a commencé avec lui. Un rapide coup d'œil dans hiew révèle la présence de code exécutable vers la fin dans la section .data, ce qui est suspect.
Ouvrez le fichier dans l'IDA et voyez de quel type de code il s'agit.
Il s'avère que les fonctions suivantes ont été modifiées dans cette bibliothèque: mount, execve, execv, execvp, execle, execl, execlp.
Code de fonction de montage modifié:
int __fastcall mount ( const char * source , const char * target , const char * filesystemtype , unsigned int mountflags , const void * data )
{
unsign __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 , cible , type de système de fichiers , indicateurs de montage , données ) ;
if ( mountflags & 1 ) // MS_RDONLY
return call_real_mount ( source , cible , type de système de fichiers , indicateurs de montage , données ) ;
if ( getuid_ ( ) ) // pas root
return call_real_mount ( source , cible , type de système de fichiers , indicateurs de montage , données ) ;
memCopy ( systemPath , ( unsigned __int8 * ) off_73210 + 471424 , 8 ) ; // / système
décrypter ( systemPath , 8 ) ;
if ( memCompare ( ( unsigned __int8 * ) target , systemPath , 8 ) || ! isBootCompete ( ) )
return call_real_mount ( source , cible , type de système de fichiers , indicateurs de montage , données ) ;
* ( _DWORD * ) errno_ ( ) = 13 ;
retour - 1 ;
}
Au début, le paramètre mountflags est vérifié pour la présence de la valeur «magique» 0x7A3DC594. Si cette valeur est transmise à la fonction, le contrôle est immédiatement transféré à la fonction de montage réel. Ensuite, il est vérifié si une tentative est faite pour remonter la partition / system pour l'écriture et si le démarrage du système d'exploitation est terminé. Si ces conditions sont remplies, la fonction de montage réel n'est pas appelée et une erreur est renvoyée. Ainsi, la fonction de montage modifiée par le cheval de Troie ne permet à personne de remonter la partition système pour l'écriture, à l'exception du cheval de Troie lui-même, qui l'appelle avec le paramètre «magique».
Le code de la fonction execve modifiée (dans le reste des fonctions exec *, tout est le même):
int __fastcall execve ( const char * filename , char * const argv [ ] , char * const envp [ ] )
{
int v3 ; // r3
if ( targetInDataOrSdcard ( filename ) > = 0 ) // renvoie -1 si vrai
{
sub_7383C ( ) ;
v3 = call_real_execve ( nom de fichier , argv , envp ) ;
}
d'autre
{
* ( _DWORD * ) errno_ ( ) = 13 ;
v3 = - 1 ;
}
return v3 ;
}
int __fastcall targetInDataOrSdcard ( const char * path )
{
char buf [ 516 ] ; // [sp + 8h] [bp-204h]
if ( isDataOrSdcard ( chemin ) )
retour - 1 ;
if ( * path == '.' && getcwd_ ( buf , 0x200u ) && isDataOrSdcard ( buf ) )
retour - 1 ;
retourner 0 ;
}
Ici, il est vérifié si le chemin d'accès au fichier lancé commence par "/ data /" et s'il contient "/ sdcard". Si l'une des conditions est remplie, le démarrage est bloqué. Rappelons que le long du chemin / data / data / se trouvent les répertoires d'application. Cela bloque l'exécution des fichiers exécutables de tous les répertoires dans lesquels une application standard peut créer un fichier.
Les modifications apportées à la bibliothèque système libc.so perturbent les applications conçues pour obtenir les privilèges root. En raison des changements dans les fonctions de exec *, une telle application ne pourra pas lancer d'exploits pour augmenter les privilèges du système, car les exploits sont généralement des fichiers exécutables qui sont téléchargés du réseau vers le répertoire de l'application et exécutés. Si vous avez quand même réussi à augmenter les privilèges, la fonction de montage modifiée ne vous permettra pas de remonter la partition système pour l'écriture, ce qui signifie qu'elle n'y apportera aucune modification.
En conséquence, l'auto-défense du cheval de Troie se compose de deux parties: son programme d'installation désinstalle les applications de gestion des droits root et la bibliothèque libc.so modifiée empêche sa réinstallation. En outre, cette protection fonctionne également contre les «concurrents» - d'autres chevaux de Troie qui obtiennent des privilèges root et sont installés dans la partition système, car ils fonctionnent sur le même principe que les «bonnes» applications de privilèges root.
Comment faire face à un tel cheval de Troie?
Pour se débarrasser d'Android.Xiny.5260, l'appareil peut être flashé - à condition qu'il y ait un firmware en accès libre pour cela. Mais est-il possible de supprimer le malware d'une autre manière? Difficile, mais possible - il existe plusieurs façons. Pour obtenir les privilèges root, vous pouvez utiliser des exploits sous forme de so-bibliothèques. Contrairement aux fichiers exécutables, le cheval de Troie ne bloquera pas leur téléchargement. Vous pouvez également utiliser le composant du cheval de Troie lui-même, qui est conçu pour fournir des droits root sur ses autres parties. Il reçoit des commandes via le socket le long du chemin / dev / socket / hs_linux_work201908091350 (le chemin peut varier selon les différentes modifications). Quant au contournement du verrou de montage, vous pouvez utiliser la valeur "magique" du paramètre mountflags, ou appeler directement l'appel système correspondant.
Bien sûr, je ne mettrai pas cela en œuvre.Si votre appareil détecte un tel cheval de Troie, nous vous recommandons d'utiliser l'image officielle du système d'exploitation pour le flasher. Cependant, n'oubliez pas que cela supprimera tous les fichiers et programmes utilisateur, alors assurez-vous de créer des sauvegardes à l'avance.