Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 





















Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Infecter et contrôler des appareils Android

mars 2015 par NES

L’existence de malwares et d’applications volant bon nombres de données confidentielles sur nos smartphones ne sont plus un secret depuis longtemps. Un des mécanismes de protection essentiel à la sécurité de l’écosystème Android est le système de permissions autorisées pour chaque application téléchargée sur le Google Play Store.

Une démonstration, montrant comment infecter un appareil Android, est disponible en fin d’article.

Dès lors, les utilisateurs sont à peu près sensibilisés à ces concepts d’autorisations qui seront attribuées à une application Android. En effet, si une application tente d’accéder aux contacts, aux SMS, aux photos, etc. un utilisateur le saura lors de son téléchargement.

Dans cet article, rien de bien nouveau en ce qui concerne la partie « développement de malware », nous avons simplement développé une application cliente se connectant à un serveur une fois que l’appareil télécharge l’application malicieuse.

Le problème est que cette application affiche à l’utilisateur les nombreuses permissions qui sont requises pour accéder aux données de la victime : SMS, Contacts, …

android

Le challenge pour un attaquant est alors de mener (voire forcer) notre victime à télécharger discrètement l’application malicieuse.

Présentation du touchjacking

Afin d’optimiser le téléchargement discret d’une application malveillante, il existe des fonctionnalités dans l’API Android permettant de superposer plusieurs applications pour ensuite laisser passer les évènements.

Techniquement, il est possible d’exploiter cette méthode sur tout type d’appareil Android quelle que soit sa version. En effet, l’autorisation android.permission.SYSTEM_ALERT_WINDOW existe depuis la 1ère version de l’API développeur et la dernière version de l’application « Google Play Store » est affectée par ce comportement.

Ce type de fenêtres (WindowManager.LayoutParams.TYPE_SYSTEM_ALERT) qui découle de cette permission est en réalité largement utilisé par le système lui-même pour notifier à l’utilisateur certains évènements tel qu’un niveau de batterie faible par exemple.

Une fois cette fenêtre affichée à l’écran, si l’application ne se termine jamais ou si celle-ci est impossible à arrêter, cela peut tout à fait être utilisé afin de développer un ransomware. Ce sujet n’étant pas l’objectif de cet article nous ne détaillerons pas plus ce point, même si cela peut s’avérer évident pour certains.

C’est donc en combinant cette fonctionnalité avec des méthodes de gestion d’évènements que l’on va pouvoir amener nos victimes à télécharger notre application malveillante sans qu’elles s’en doutent.

En effet, il est possible de modifier les fenêtres de nos applications pour que celles-ci restent toujours en premier plan, et qu’elles ne soient pas touchables. Il suffit alors d’utiliser les 3 paramètres suivants lors de la définition des fenêtres applicatives :

 LayoutParams.FLAG_NOT_FOCUSABLE (la fenêtre ne peut être sélectionnée lors du toucher de l’utilisateur)
 LayoutParams.FLAG_NOT_TOUCHABLE (les évènements de toucher ne seront jamais transmis à cette fenêtre).
 LayoutParams.FLAG_NOT_TOUCH_MODAL (les évènements de toucher sont automatiquement transmis à l’activité qui se trouve en dessous).

En résumé, nous obtenons alors une fenêtre qui apparaitra toujours en premier plan et qui laissera passer les évènements à l’application se trouvant en dessous.

L’attaquant n’a plus qu’à placer des boutons et des images au bon endroit afin que ses victimes touchent certaines zones précises de l’écran. En affichant une page Play Store de téléchargement en fond, la victime risquera alors de télécharger un malware à son insu.

Démonstration

Maintenant que le concept a été exposé, place à la démonstration (Nexus 4 avec Android 4.3) :

Ce comportement pouvant amener à la compromission de n’importe quel appareil Android, une alerte a été envoyée à l’équipe sécurité d’Android. Un ticket est ouvert en interne afin de corriger ceci au plus vite.


NB : Pour le moment, cette technique d’exploitation a été testée sur un Nexus 4 avec Android 4.3 et un Nexus 5 avec Android 4.4 mais n’importe quelle version semble impactée puisque le problème est relatif à l’interaction avec l’application Google Play Store.


Voir les articles précédents

    

Voir les articles suivants