Détection d’anomalies sur Android

Enjeux de la détection de logiciels malveillants sous Android

Les domaines d’utilisation des smartphones dans la vie de tous les jours sont très variés. Ceux-ci suivent leurs utilisateurs partout et peuvent contenir énormément de données à leur sujet, que ce soit dans le cadre de leur vie privée ou professionnelle. En effet, on peut tout connaître des projets d’un cadre en ayant accès à ses mails, tout comme on peut facilement tracer les grandes lignes de ses habitudes de consommation en observant ses déplacements à l’aide d’un GPS. Qui plus est, le téléphone lui-même stocke qu’on le veuille ou non des informations telles que le numéro de téléphone de l’utilisateur, qui pourraient intéresser des démarcheurs peu scrupuleux.

Pour toutes ces raisons, les smartphones sont des cibles privilégiées pour les programmes malveillants. N’importe quel utilisateur peut être affecté par un malware qui tente de récupérer des données personnelles ou d’appeler un numéro surtaxé, ce qui rend la publication d’une telle application très lucrative. Qui plus est, l’impact sur l’utilisateur est direct. Outre l’intrusion dans la vie privée, qui est un problème rencontré de manière récurrente sur internet, les envois de SMS surtaxés lui font perdre de l’argent directement et peuvent donc poser de gros problèmes si ils ne sont pas détectés rapidement.

Réalité de la menace 

La menace de trouver des logiciels malveillants sur Google Play est bien réelle [2]. Le premier cas d’application suspicieuse retirée du marché par Google date de Janvier 2010. Il s’agissait d’un spyware, programme destiné à collecter à l’insu de l’utilisateur des données personnelles, en l’occurrence des informations bancaires. En Août 2010 fut découvert le premier Trojan (cheval de Troie) destiné à envoyer des SMS à l’insu de l’utilisateur, répondant au nom de Fake Player. Le programme se fait passer pour un lecteur de vidéo et envoie à l’insu de l’utilisateur des SMS vers un numéro surtaxé, pour un coût de 5 dollars par message. Il s’agit du premier exemple de programme malveillant sur Android qui ne se contente pas d’espionner l’utilisateur et lui fait perdre de l’argent directement. Depuis ces premiers exemples et en particulier à partir de 2011, le nombre de programmes malveillants détectés sous Android a fortement augmenté, de paire avec l’utilisation de cette plate-forme. Les rapports parlent d’une « augmentation de 400% des application malicieuses Android depuis l’été 2011 »[5]. Si les marchés d’applications alternatifs en sont la première source, on voit régulièrement Google annoncer qu’il vient de retirer des programmes suspicieux de son Google Market. Des antivirus sont disponibles pour essayer de limiter les dégâts, mais il faut reconnaître que leur efficacité est limitée. Ils sont en particulier totalement inefficaces pour détecter de nouveaux malwares, qui ne sont pas présents dans leurs bases de données.

Comportement des logiciels malveillants et méthodes de diffusion

Les logiciels malveillants utilisent différentes méthodes pour se dissimuler, que ce soit aux yeux de l’utilisateur ou des logiciels de détection. La méthode la plus courante de diffusion est le repackaging : l’auteur du logiciel malveillant désassemble une application connue, y ajoute du code, puis publie le programme modifié sur un marché alternatif en le faisant passer pour le programme d’origine. Pour éviter d’être détecté par les antivirus, l’auteur du logiciel malveillant va souvent éviter de mettre directement toute sa payload, c’est à dire le code qui va mener l’attaque, dans son application. En effet, les payload contiennent en général des attaques permettant de briser la sécurité mise en place par Android. Ces attaques sont peu nombreuses et possèdent donc des signatures qu’un antivirus peut détecter. Pour éviter cela, l’auteur n’injecte pas directement la payload dans l’application, mais fait en sorte que l’application la télécharge ultérieurement. À ce jour, plusieurs familles de malwares implémentent une variante de cette attaque, parmi lesquelles on peut citer BaseBridge, DroidKungFu, Plankton, BadNews et Anserverbot. Les quatre premiers ont par ailleurs déjà été détectés sur Google Play d’après rapports de Lookout. Chaque variante a son propre scénario d’attaque et on peut imaginer que de nouvelles ferontleur apparition dans le futur. Une application infectée par BaseBridge attend qu’une nouvelle mise à jour soit disponible. Lorsque l’application doit afficher une fenêtre invitant à effectuer cette mise à jour, BaseBridge détourne celle-ci [6]. Au lieu de télécharger la vraie mise à jour, le programme installe une fausse mise à jour, déjà présente sur le téléphone sous la forme de ressource du programme infecté, contenant la payload. En évitant d’inclure celle-ci dans le code de l’application infectée dès le départ, les chances d’être détecté pour BaseBridge sont réduites.

DroidKungFu [1] agit d’une manière similaire, mais au lieu de stocker la « mise à jour »dans les ressources de l’application, celui-ci fait en sorte de la télécharger depuis le réseau. Pour cela, la notification de mise à jour est effectuée par une librairie tierce [6] qui permet d’effectuer des mises à jour de manière légitime. Cependant, cette librairie permet de télécharger les mises à jour depuis d’autres marchés d’application que Google Play : la mise à jour téléchargée est en fait une fausse mise à jour qui contient la payload. Ces deux exemples nécessitent au moment de la mise à jour l’accord explicite de l’utilisateur. En effet, celui-ci reçoit une notification et il peut très bien refuser la mise à jour si il suspecte quelque chose en regardant par exemple les nouvelles permissions demandées. Les familles Plankton et Anserverbot se montrent en revanche plus discrètes [6]. Celles-ci téléchargent un fichier .jar contenant la payload, qui est exécuté dynamiquement par le système. Ceci permet d’échapper à l’analyse statique [7, 8]. Le dernier exemple en date, BadNews, a également eu un fort impact, puisque 32 applications infectées par ce dernier ont été téléchargées entre 2 et 9 millions de fois sur Google Play, selon les statistiques de ce dernier. BadNews se fait passer pour un réseau de publicité dans dans une librairie tierce [9]. Les librairies tierces sont des ressources utilisées par les programmeurs qui leur permettent d’implémenter des fonctionnalités classiques sans avoir à les réécrire, en l’occurrence l’intégration de publicités dans leur application. Par conséquent, une application peut être infectée à l’insu même de son développeur, puisqu’il suffit que celle-ci utilise une librairie infectée pour qu’elle soit également contaminée.

Une fois BadNews installé, celui-ci met le téléphone en écoute d’un serveur de contrôle, qui envoie des instructions toutes les 4 heures. Parmi ces instructions, le serveur peut essayer de faire télécharger à l’utilisateur d’autres applications malicieuses telles que AlphaSMS en les faisant passer pour des mises à jour d’applications courantes comme Skype.

Toute ces méthodes peuvent prendre l’utilisateur au dépourvu, puisqu’il a tendance à faire confiance à une application connue téléchargée sur le marché officiel. Les programmes infectés continuent de fonctionner normalement en apparence, mais un grand nombre d’actions nuisibles pour l’utilisateur peuvent avoir lieu à son insu. Très vite, celui-ci peut sans s’en rendre compte avoir envoyé un grand nombre de SMS surtaxés, s’être fait voler toutes ses données personnelles, ou même ses coordonnées bancaires.

Problème visé

Dans notre travail, nous nous intéressons aux mises à jour malicieuses, qui, comme nous venons de le voir, sont largement utilisées par de nombreuses applications malveillantes pour cacher leur activité. Nous partons du constat que, quelque soient les méthodes de dissimulation utilisées par les malwares, celles-ci impliquent à un moment ou l’autre un changement de comportement d’un programme. En effet, toutes ces méthodes suivent une même idée : éviter d’exécuter le code malveillant directement au premier lancement du programme afin d’éviter d’être détecté. Si le programme télécharge sa payload ultérieurement, celle-ci va lui faire exécuter des actions nouvelles. De la même manière, un programme malicieux qui fait un sorte qu’un autre programme totalement bénin effectue une fausse mise à jour change le comportement de ce dernier.

Un exemple commun d’une telle attaque est le suivant : un utilisateur possède sur son téléphone diverses applications, dont Skype. Un jour, il télécharge une application sur Google Play qui s’avère être infectée par BadNews, chose qui est déjà arrivée plusieurs millions de fois [9, 10]. Cette application ne va rien faire de suspect pendant deux ou trois jours. Après ce laps de temps, l’utilisateur reçoit un message lui indiquant que Skype doit effectuer une mise à jour. Se disant que ce programme est connu et ne présente aucun risque, il accepte. Cette mise à jour est en fait une mise à jour malicieuse lancée par l’application malveillante : une fois celle-ci effectuée, Skype va commencer à collecter les données personnelles de l’utilisateur et à les envoyer sur un serveur privé. Dans cet exemple, quelle que soit la faille exploitée par le logiciel malveillant pour lancer une mise à jour de Skype, et quelles que soient les actions malveillantes qu’il lui fait exécuter, nous pensons pouvoir observer un changement de comportement de Skype. En effet, on peut supposer que dans notre exemple, en temps normal, Skype n’envoie aucun SMS surtaxé. Même si Skype offre la possibilité de le faire, l’utilisateur peut très bien n’avoir jamais utilisé cette fonctionnalité. L’application malicieuse AlphaSMS envoie justement un grand nombre de SMS surtaxés [11]. On voit donc le comportement de Skype changer, ce qui peut d’après nous être un bon indicateur d’actions suspicieuses.

L’idée de notre approche est de surveiller ces changements de comportement pour chaque application afin de détecter les actions malveillantes. De cette manière, si une application malicieuse temporise d’une manière ou d’une autre son attaque pour échapper à une détection classique, notre système devrait être à même de détecter le changement de comportement provoqué par l’attaque.

Travaux précédents : détection d’intrusion par approche comportementale

Comme nous l’avons mentionné auparavant, nous nous sommes inspirés de nombreux travaux effectués dans le domaine de la détection d’intrusion. Le concept de modèle de comportement normal que nous utilisons a été introduit par Forrest et coll. en 1996 [13]. Cette publication décrit comment construire un modèle de comportement normal en se basant sur de courtes séquences de n appels système appelées n-grams. Le modèle est constitué de l’ensemble des n-grams observés lors de la phase d’apprentissage. Lors de la phase de détection, on regarde les séquences d’appels système effectuées par le programme et on compte celles qui ne sont pas présentes dans le modèle, que l’on considère comme anormales. Si le taux de séquences anormales dépasse un certain seuil, on considère que le programme se comporte de manière anormale.

Toute cette approche est destinée à surveiller l’activité de serveurs. Les services accessibles à distance qu’offre un serveur, tels qu’un site web, sont autant de portes d’entrées pour un attaquant. Celui-ci essaie de se servir de failles présentes dans ces services pour leur faire exécuter les commandes qu’il veut, et ainsi faire faire ce qu’il veut au serveur. L’idée de base de l’approche est de considérer que dans le cadre d’un fonctionnement normal, un service n’effectuera qu’un ensemble fini de suites d’appels système. La phase d’apprentissage décrite ci-dessus permet d’obtenir un ensemble le plus proche possible de l’ensemble des suites d’appels système que l’on peut considérer comme normales. Un attaquant prenant le contrôle du service lui fait effectuer des appels système qui sortent de cet ensemble : lors de la phase de détection, les séquences n’ayant pas été enregistrées dans le modèle sont considérées comme anormales.

Depuis ce travail, de nombreuses publications ont repris le concept de modèle de comportement normal en faisant évoluer les critères utilisés pour sa construction [14, 15]. Certaines de ces évolutions portent sur les données utilisées pour la construction du modèle, par exemple pour tenir compte des paramètres utilisés avec les appels système [16]. D’autres publications tiennent compte dans la construction du modèle de la fréquence d’apparition des séquences d’appels système [17, 15] : au lieu de simplement mémoriser les appels système qui apparaissent lors de la phase d’apprentissage, les auteurs comptent leurs apparitions. Un taux d’anomalie inversement proportionnel à la fréquence d’apparition est associé à chaque séquence, ce qui permet d’obtenir un modèle plus précis du comportement du programme, ainsi qu’une tolérance à quelques anomalies lors de la phase d’apprentissage : même si celles-ci sont présentes dans le modèle, elles le sont en faible nombre, et conservent donc un taux d’anomalie important.

D’autres évolutions portent sur la manière dont construire le modèle. Au lieu d’utiliser des n-grams comme dans la publication initiale, des variantes utilisent des algorithmes d’apprentissage automatique comme des modèles de Markov [15, 18], des réseaux de neurones [19, 20], ou des modèles de Bayes [21]. Toutes ces approches essaient de créer un modèle plus précis des données, afin de réduire le taux de faux-positifs engendrés, mais présentent une complexité plus importante. [14] La diversité des expériences et des conditions dans lesquelles elles sont effectuées empêche de pouvoir comparer ces méthodes en se basant uniquement sur les résultats fournis par les études : des implémentations dans un même cadre pour les tester sur un même jeu d’expérimentations est nécessaire. De rares études ont effectué une telle comparaison [14, 15] d’où sont sortis quelques tendances générales. Premièrement, aucun algorithme ne semble prédominer ou se situer en dessous des autres. Le choix des données utilisées pour l’entraînement a une bien plus grande influence sur les résultats que le choix du modèle. Deuxièmement, l’utilisation de méthodes sophistiquées pour la création du modèle engendrent une plus forte complexité, et donc une plus forte surconsommation en ressources.

Table des matières

Introduction
1 Motivations
1.1 Enjeux de la détection de logiciels malveillants sous Android
1.2 Réalité de la menace
1.3 Comportement des logiciels malveillants et méthodes de diffusion
1.4 Problème visé
2 Approche proposée
2.1 Objectifs
2.2 Travaux précédents : détection d’intrusion par approche comportementale
2.3 Travaux précédents : détection de malware sur Android
2.4 Limites de notre approche
2.5 Contraites rencontrées sur Android
3 Notre contibution
3.1 Schéma global
3.2 Extraction des données
3.2.1 Strace
3.2.2 Normalisation
3.3 Création du modèle et scan
3.3.1 Modèle de type Lookahead pairs
3.3.2 Modèle de type arbre de n-grams
4 Tests effectués
4.1 Conditions d’expérimentation
4.2 Validation de l’approche
4.2.1 Motivations
4.2.2 Résultats
4.3 Tests sur des logiciels malveillants
4.4 Tests de surconsommation
4.5 Taille des modèles
5 Discussion
6 Conclusion

Lire le rapport complet