Malwares Android en 2013

Si les travaux de [113] présentés précédemment concernent uniquement les malwares de 2010 à 2011, la récente analye de V. Chebyshev et R. Unuchek dans [33] montre une continuité dans les types d’action menée par les malware. La distribution des malwares se fait toujours via les plateformes de téléchar- gement ou les serveurs de C&C. À cela s’ajoute, l’usage des techniques telles que le drive-by download qui consiste à faire télécharger automatiquement puis installer une application au téléphone lorsque l’utilisateur visite une page web. L’usage de techniques contre les protections anti-malware s’intensifie éga- lement. L’étude montre ainsi que les développeurs de malware continuent leur investissement dans les diverses techniques d’obfuscation de code. Un outil com- mercial d’obfuscation de code aurait été par exemple utilisé sur Opfak.bo et Obad.a [98]. Obad.a est considéré comme le malware Android le plus complexe à ce jour. Parmi les caractéristiques de ce malware, nous pouvons citer l’in- trospection, le chiffrement de chaine des chaines de caractères, l’exploitation de vulnérabilités qui affectent le système Android et dex2jar qui est un outil utilisé pour analyser les applications Android. Plus précisément, cet outil transforme le bytecode dalvik en bytecode Java permettant par la suite d’obtenir un code Java “équivalent“. Selon wikibooks [12], “la réflexion permet l’introspection des classes, c’est-à-dire de charger une classe, d’en créer une instance et d’accéder

2.4. MALWARE ANDROID 29 aux membres statiques ou non (appel de méthodes, lire et écrire les attributs) sans connaître la classe par avance“. Le listing 2.3 présente un bout code en Java utilisant la réflexion et son équivalent sans réflexion. . La deuxième ligne initialise la variable foo en une instance de la classe Foo et est équivalente à la septième ligne. La troisième et la quatrième lignes initialisent récupèrent la méthode hello de foo et l’invoque. Elles correspondent à la huitième ligne.

1 // Avec reflexion

2 Object foo = Class.forName("complete.classpath.and.Foo").

3 newInstance();

4 Method m = foo.getClass().getDeclaredMethod("hello", 5 new Class<?>[0]);

6 m.invoke(foo); 7

8 // Sans reflexion

9 Foo foo = new Foo(); 10 foo.hello();

Listing 2.3 – Exempe de code Java avec et sans réflexion

L’usage des vulnérabilités reste toujours d’actualité au niveau des malware. Les raisons principales de cet usage est la nécessité d’effectuer des actions sen- sibles sans validation de l’utilisateur (ex : installation d’application sur le té- léphone) ou le maintien d’une présence pertinente du malware sur l’appareil (ex : installation d’une application dans la partition system afin d’empêcher sa désinstallation5_{). Parmi les vulnérabilités émunérés par les auteurs, il y a}

la vulnérabilité Master Key [51] et celle liée aux applications avec les droits d’administration sur le téléphone.

La vulnérabilité Master Key permet de modifier une application existante sans que la modification ne soit détectée lors de la vérification de la signature de l’application (section 2.2.2.2). Pour exploiter cette vulnérabilité, le dévelop- peur malveillant ajoute de nouveaux fichiers à l’apk tel que chaque nouveau fichier ait le même nom qu’un fichier existant dans l’apk d’origine. Il peut par exemple ajouter un autre fichier nommé classes.dex. Une fois les nouveaux fichiers ajoutés, il publie l’apk modifié tout en gardant la signature de l’apk d’origine. À cause de la vulnérabilité, le système ne remarque pas l’existence des doublons dans l’apk et vérifie uniquement l’intégrité des fichiers qui étaient présents dans l’apk d’origine tandis qu’à l’installation il installera les fichiers ajoutés par le développeur malveillant. Cette vulnérabilité a deux conséquences directes. La première est le vol de l’identité des développeurs dont l’application a été modifiée. En gardant la signature de l’application originale, le développeur malveillant se cache derrière l’identité des développeurs des applications modi- fiées. Le risque pour ces derniers est d’être accusé à tord comme étant malveillant 5. Un utilisateur ne peut désinstaller les applications dans la partition system car cette partition est montée en lecture seule

et voir toutes leurs applications supprimées des plateformes de téléchargement tels que Google Play. La deuxième conséquence de cette vulnérabilité est la pos- sibilité de contourner toutes les mécanismes de sécurité basées sur les signatures de applications. En plus de servir à la vérification de l’intégrité des applications à leur installation, les signatures servent également à appliquer des contraintes sur certaines demandes des applications. Ils peuvent par exemple servir à res- treindre les applications à qui une permission peut être accordée (tableau 2.1) ou les applications qui ont le droit de partager le même utilisateur. En gardant la signature de l’application qu’il a modifiée, le développeur malveillant s’as- sure ainsi que sa version modifiée de l’application ait les mêmes privilèges que l’application d’origine.

La deuxième vulnérabilité permet de garder une présence persistante sur le téléphone grâce aux droits d’administration. Lorsqu’une application obtient les droits d’administration sur le téléphone, il devient impossible pour l’utilisateur de lui révoquer ces droits ou le désinstaller. Si jamais l’utilisateur tentait de révoquer les droits d’administration, le système se contentait de masquer le fait que l’application possède ces droits mais ne les révoquait pas. L’application reste ainsi installée sur le téléphone avec les droits d’administration sans que l’utilisateur ne soit au courant.

Si les différents types d’attaque présentés dans [113] restent toujours d’ac- tutaité, l’analyse montre cependant une tendance pour les attaques ayant un impact financier sur l’utilisateur. Aux applications abusant des services de SMS en envoyant des messages à des numéros surtaxés s’ajoutent ainsi les applica- tions se faisant passer pour des applications bancaires afin de voler les données bancaires des utilisateurs telles que leur numéro de compte.