Certifi-gate : portes ouvertes sur Android

Nom : Certifi-gate. Périmètre d’évolution : Android. Levier d’exploitation : les services d’assistance à distance généralement fournis par les constructeurs de terminaux mobiles, les opérateurs télécoms ou encore les départements IT.

L’alerte est lancée autour de cet ensemble de failles exploitables pour accéder discrètement à des appareils, puis en prendre le contrôle.

Les vulnérabilités repérées par les équipes de Check Point – et présentées cette semaine lors de la conférence Black Hat USA 2015 – sont liées à la gestion des autorisations entre les couches basses d’Android et les dénommées mRSTs (« mobile Remote Support Tools »).

Ces applications sont censées faciliter l’accès distant à des terminaux, généralement à des fins de support technique. Certaines de leurs fonctionnalités (installation d’APK, reproduction de l’affichage, émulation du tactile…) ne sont pas sans rappeler celles embarquées dans les mRATs (« mobile Remote Access Trojans », ces logiciels malveillants de type SpyBubble conçus pour obtenir des données non accessibles en temps normal.

Dans l’architecture actuelle d’Android, chaque application est installée et exécutée dans un environnement isolé (« sandbox »). Elle ne peut pas accéder à n’importe quoi : il lui faut déclarer ce dont elle a besoin dans le fichier AndroidManifest.xml. La liste des permissions est présentée à l’utilisateur final, qui accepte ou non de poursuivre l’installation.

Certaines autorisations dites « de haut niveau » ne peuvent être obtenues que par quelques applications : celles signées par un constructeur (OEM) et celles situées dans le dossier /system/priv-app.

Les mRSTs entrent dans cette catégorie de par leur nature même. Ils ont effectivement besoin de fournir un maximum d’informations à la machine avec laquelle ils communiquent : INSTALL_PACKAGES pour installer des apps, READ_FRAME_BUFFER_ACCESS_SURFACE_FLINGER pour accéder à l’écran, etc.

Friture sur la ligne

Les mRSTs sont généralement architecturées autour d’une application principale développée et signée par un éditeur qui conçoit l’interface utilisateur et les connexions réseau. S’y adjoint généralement un plugin signé, mais par l’OEM, pour pouvoir gérer l’obtention des permissions pour le compte de l’appli principale. Le lien entre les deux est fait avec Binder.

Ce schéma peut poser des problèmes. En premier lieu, certains OEM n’ont pas les équipes adaptées pour vérifier les applications tierces et signer les plugins associés. Par ailleurs, Android n’a pas de système de révocation des privilèges : une application peut, dans l’absolu, être « récupérée » telle quelle par un pirate qui peut la rediffuser, par exemple via une campagne de phishing.

C’est sans compter le fait que les fameuses permissions « de haut niveau » ne s’affichent pas dans Google Play. Et que le plugin n’a pas d’icône dans le lanceur. Enfin, Android ne permet pas de vérifier quelles applications envoient des données sur Binder. Chaque éditeur doit donc développer sa propre technique… avec les risques inhérents.

Les test menés par Check Point ont abouti à la découverte de brèches dans TeamViewer Quick Support, RemoteCare de CommuniTake, RSupport et AnySupport.

Le cas de TeamViewer Quick Support (plus de 5 millions de téléchargements sur Google Play) est particulier. Lorsque l’application initialise le plugin, celui-ci charge le certificat de la machine distante et vérifie que le numéro de série est le même que celui implanté dans le code de l’application.

Ce numéro de série est défini en fonction du certificat racine ; en l’occurrence, celui dont les développeurs d’applications peuvent décider. Les cybercriminels n’ont dont qu’à créer eux-mêmes un certificat comportant le même numéro de série que celui figurant dans le plugin. Il leur reste à créer une application signée avec le certificat pour pouvoir commander le plugin.

Sur Communitake, il a été constaté que les principaux paramètres de l’application peuvent être modifiés par SMS. Par exemple, le sous-domaine du serveur de commande et contrôle, suffisant pour lancer des attaques par déni de service (DoS).

Crédit photo : Silatip – Shutterstock.com