Infecter et contrôler des appareils Android

An english description is available at the end of the article.

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

 

Rappel du contexte

 

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.

 

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 ne 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):

https://www.youtube.com/watch?v=ekvdO8tdJ34

 

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.

 

====================================================

English version

 

In order to facilitate the quiet installation of a malware, there exists a functionality in the Android API which could allow multiple activities to be overlaid.

 

Technically, it is possible to exploit this method on all kind of Android devices whatever the version is.

Indeed, the authorization « android.permission.SYSTEM_ALERT_WINDOW » exists since the 1st version of the developer API and the last version of the application « Google Play Store » is affected by this behavior.

This kind of windows (WindowManager.LayoutParams.TYPE_SYSTEM_ALERT) which can be created from this permission is actually widely used by the system itself to notify some events to the user (such as a low battery level for example).

By combining this functionality with handling event methods, we will be able to drive the users to another application download, without them being aware of it.

 

Indeed, it is possible to modify the windows of our application so that they always stay on top of the screen, adding the fact that they are not « touchable ». Therefore, we only have to use the 3 following parameters on our windows:

LayoutParams.FLAG_NOT_FOCUSABLE (the window can’t receive the focus)

LayoutParams.FLAG_NOT_TOUCHABLE (touch events will never be transmitted to this window)

LayoutParams.FLAG_NOT_TOUCH_MODAL (touch events will automatically be transmitted to the underlying activity)

 

To sum up, we can obtain a window which will be always on top of the screen and that will let the touch events be communicated to the underlying window.

The attacker must place buttons and images at the right location so that his victims touch this specific location.

 

Note: This phishing method can be done in games or any other kind of application.

Indeed on the Google Play Store the permission won’t be displayed to the user (and even if it was it wouldn’t be really explicit).

The exploitation technique used is « Tapjacking » and it can be used to drive the users to download a malware without them being aware of it.

All versions are potentially impacted by this issue (it is more a conceptual security issue than a « security bug »).

This exploit has been tested with:

– Nexus 4 under Android 4.3, Android 4.4

– Nexus 5 under Android 4.4

 

 

Article rédigé par: Christophe GARRIGUES

This page as PDF

1 Réponse a "Infecter et contrôler des appareils Android"

Laissez un commentaire