Des chercheurs du Georgia Institute of Technology, à Atlanta, ont montré qu’il était possible de piéger presque à coup sûr un utilisateur d’Android pour l’amener à installer une application malveillante. La faute à deux permissions détournées du système, dont l’une est donnée automatiquement par le Play Store.
En septembre 2016, l’équipe de XDA Developers avertissait d’un danger potentiel avec Android 6.0, alias Marshmallow. Les versions précédentes du système mobile avaient fait l’objet de travaux pour bloquer un type d’attaque spécifique, le tapjacking. Le concept était simple : intercaler une fausse fenêtre pour leurrer l’utilisateur et lui faire valider une demande qu’il n’aurait pas acceptée en temps normal.
Avec Marshmallow, les modifications du système de permissions (qui basculait sur un modèle proche de celui d’iOS, avec validation à l’acte) remettaient en partie en cause les progrès précédents. Suite aux travaux d’un chercheur et après des tests réalisés par leurs soins, nos confrères avaient conclu qu’il était théoriquement possible de remettre ces attaques au goût du jour. Ce qui est effectivement le cas.
Des fenêtres superposées
Des chercheurs du GIT d’Atlanta ont prouvé qu’il était tout à fait faisable de piéger un utilisateur pour l’amener à installer une application, qui aurait ensuite tout pouvoir sur l’appareil Android.
Cette attaque, nommée « Cloak and Dagger » (en référence au comics La Cape et l’Épée), fonctionne sur toutes les versions d’Android, jusqu’à la 7.1.2, soit la dernière. Elle se base sur deux permissions standards du système, SYSTEM_ALERT_WINDOW et BIND_ACCESSIBILITY_SERVICE (aussi appelée a11y). La première autorise une application à afficher une alerte au sein d’une petite fenêtre s’affichant au-dessus de ce qui est à l’écran, l’autre permet de déclarer un service spécial d’accessibilité.
C’est bien entendu par la première que viennent les soucis. Puisqu’elle permet d’afficher un message accompagné éventuellement d’une action, il est possible de repérer l’affiche d’une demande de permission légitime pour la recouvrir d’une fausse demande. L’utilisateur croit valider une action, mais donne en fait une autorisation à une application tierce.
La permission SYSTEM_ALERT_WINDOW a un autre problème : elle est donnée automatiquement par le Play Store à une application téléchargée si aucun fonctionnement malveillant n’a été détectée. Mais comme l’indiquent les chercheurs, ils ont pu proposer et faire valider une application par le Play Store, les routines automatiques de détection n’ayant manifestement pas repéré « une fonctionnalité non masquée téléchargeant et exécutant un code arbitraire », indiquent les chercheurs.
Pas de limites à ce que peut accomplir une application malveillante
La conjonction des deux permissions permet aux pirates d’envisager pratiquement tous les scénarios. Celui envisagé par les chercheurs est le plus direct : tromper l’utilisateur pour lui faire autoriser la récupération d’une application franchement malveillante qui, elle, n’aurait jamais passé les sas de validation du Play Store.
Cela étant, la deuxième application n’a pas besoin d’être téléchargée pour que des actions malveillantes soient mises en place. La première permission permet ainsi de demander l’autorisation pour la seconde, qui peut activer de son côté des modules entrainant une surveillance des frappes au clavier et plus généralement des vols d’informations.
Pour les chercheurs, ce cas de figure est d’ailleurs d’autant plus dangereux que durant une étude menée sur vingt « cobayes », aucun ne s’est douté à un quelconque moment qu’une action malveillante était en cours. Les fausses fenêtres d’informations ont rempli leur rôle, et même la récupération d’une deuxième application est passée inaperçue.
Pour Google, la situation est désormais sous contrôle
Le principal danger de cette méthode, outre le fait qu’elle est particulièrement discrète, est qu’elle repose sur des faiblesses du côté de Google. Le système de permissions de Marshmallow étant ce qu’il est, il n’est rien que l’utilisateur puisse faire, en dehors d’une grande prudence dans le choix des applications à installer.
Cependant, puisque le souci peut très bien résider dans une application validée par Google et donc présente sur le Play Store, il faudra redoubler de prudence. Le fait que l’éditeur ait durci le ton sur les permissions pendant la conférence de présentation d’Android O n’est pas un hasard.
C’est d’ailleurs le cœur de la réponse de l’entreprise à Softpedia : « Nous avons été en contact étroit avec les chercheurs et, comme toujours, nous apprécions les efforts pour aider à protéger nos utilisateurs. Nous avons mis à jour Google Play Protect pour détecter et prévenir l’installation de ces applications. Avec ce rapport, nous avions déjà mis au point de nouvelles défenses dans Android O, qui vont encore renforcer notre protection contre ces problèmes ».
Rappelons que Protect est simplement un nouveau nom donné à l’ensemble des services de sécurité du Play Store, sur lesquels Google communique d’ailleurs davantage depuis quelques mois. Mais la vraie solution ne viendra que d’une évolution des permissions, qui n’interviendra qu’avec Android O. Et là, bien entendu, se poseront d’autres difficultés.
Des permissions corrigées dans Android O, oui mais...
Quiconque suit l’évolution du monde mobile sait bien qu’il n’existe aucune garantie pour un smartphone d’obtenir la dernière révision majeure d’Android, à moins d’un appareil raisonnablement milieu ou haut de gamme sorti moins de 18 mois avant. Même si Google publiait une mise à jour spécifique pour Nougat (Android 7.0), seuls 5 % environ des appareils mobiles seraient concernés aujourd’hui.
Notez bien cependant que les travaux des chercheurs sont de type académique et que les informations ont été confiées à Google, qui a pu mettre à jour son Play Store Protect, comme indiqué. Il n’y a pas pour l’instant de signe clair d’une attaque active basée sur ces méthodes, mais rien ne permet non plus d’affirmer le contraire. Comme toujours, la prudence reste de mise : si des chercheurs ont pu mettre la main sur ce type de faiblesse, des pirates ont pu faire de même.
Enfin, on ne sait pas vraiment comment Google a renforcé ses barrières. Les chercheurs ont probablement mis en lumière une faiblesse dans les mécanismes de protection, puisque Protect couvre surtout les actions automatiques côté serveurs. S’il ne s’agissait que de découvrir un détournement de certaines fonctionnalités, on peut considérer le problème comme réglé, en espérant qu’il s’agisse du seul « oubli » sur ces fameuses deux permissions.
