Pan sur le bec ! Le 28 janvier 2014, les médias – et en particulier Le New York Times, le Guardian et le Pro Public -, révèlent que la NSA et son homologue britannique le GCHQ « obtiennent des informations personnelles sur les utilisateurs comme leur âge et leur sexe. Ces manœuvres d’espionnage ont touché un nombre indéterminé d’utilisateurs et sont en cours depuis 2007, selon le New York Times. La révélation provient de documents dévoilés par l’ancien employé de la NSA, Edward Snowden, en juin 2013 ».
Ces révélations ont pointé du doigt les applications Android et iPhone dont l’une des plus célèbres d’entre elles, Angry Birds. Rovio, la société développant ce jeu, a vite été mise sur le banc des accusés. Même si la plupart des journalistes n’ont pas ciblé directement Rovio, les utilisateurs mal informés vont naturellement accuser (à tort) la société finlandaise. Avec toutes les conséquences économiques désastreuses pour cette société… SecuriteOff revient sur ces révélations et démontre que des supports permettent à la NSA, via Google, de récupérer des informations personnelles…
La première chose que l’on voit lorsqu’on lit la nouvelle sur les révélations d’Angry Birds est l’image « Spying Birds » :
Ainsi, beaucoup de lecteurs sur le Net ont rapidement conclu, sans même forcément lire l’article, que l’éditeur de ce jeu a eu des relations étroites avec les services d’espionnage anglo-saxons. J’avoue avoir été parmi ceux qui ont fait ce rapprochement. Voici un extrait de l’article du <a href= »http://www.theguardian.com/world/2014/jan/27/nsa-gchq-smartphone-app-angry-birds-personal-data »>Guardian</a> : « <em> The National Security Agency and its UK counterpart GCHQ have been developing capabilities to take advantage of « leaky » smartphone apps, such as the wildly popular Angry Birds game, that transmit users’ private information across the internet, according to top secret documents</em>. »
L’auteur précise pourtant très bien le fait qu’Angry Birds est une application parmi les nombreuses qui transmettent des données privées aux agences gouvernementales.
Nous allons voir dans cet article, à travers une analyse technique, qu’en effet Angry Birds n’est qu’une application parmi beaucoup, mais c’est la plus populaire. Loin de là notre envie de blâmer nos confrères journalistes qui ne sont pas forcément très compétents en ligne de code et en sécurité informatique.
Malheureusement, la plupart des lecteurs lisent rarement dans son intégralité un article publié dans un support écrit et encore moins sur le web. Une bonne illustration et un titre accrocheur suffisent à désinformer et à lancer des rumeurs. Cette désinformation peut avoir des conséquences considérables. Dans notre exemple, suite aux révélations, le site web d’Angry Birds a subi des attaques directes (http://www.theguardian.com/technology/2014/jan/30/angry-birds-defaced-nsa-spying-birds-user-data).
Alors, qu’en est-il d’Angry Birds ? Comment les agences récupèrent-elles les données privées par l’intermédiaire de ces applications ?
Afin d’égayer nos propos, nous allons présenter des éléments techniques grâce à des procédés de rétro-ingénierie.Nous avons pris pour exemple l’application « Angry Birds Rio ». C’est une version disponible avant les révélations, il y a donc quelques différences avec les dernières versions. D’ailleurs, dans la dernière version que nous avons analysée, il n’y a pas de publicités même si les librairies sont présentes. Il y a une certaine probabilité que ce soit une stratégie de Rovio suite aux révélations. Dans un premier temps, il suffit de lire le fichier manifeste pour savoir qu’Angry Birds utilise la librairie « Admob » de Google. Nous pourrions carrément arrêter notre analyse ici pour changer de cible et soupçonner le géant du net de passer par ce biais pour récolter les données privées. Mais on peut aller tellement plus loin, et en conclure pas mal de choses…
– L’absence de la déclaration de la permission « Location » pour avoir accès au GPS notamment ;
– La présence de balises « meta-data » avec notamment : « <meta-data android:name= »ADMOB_ALLOW_LOCATION_FOR_ADS » android:value= »true » /> ».
Mais qu’est-ce que cela signifie ? Normalement, une application Android doit déclarer la permission « ACCESS_FINE_LOCATION » pour utiliser le GPS et ainsi obtenir la localisation de l’utilisateur. Dans ce cas, l’utilisateur peut ainsi savoir au moment d’installer une application Android que l’application utilisera l’API (Application Programming Interface) pour récupérer la localisation GPS. Ainsi, l’utilisateur peut décider d’accepter ou de refuser l’installation et/ou l’achat de l’application « en connaissance de cause ». Lorsque l’on installe l’application « Angry Birds Rio » sur le Google Play, il n’y a pas la permission « ACCESS_FINE_LOCATION » ou quoi que ce soit d’approchant. Voyez par vous-même. Il semblerait donc que dans cette version l’application ne récupère pas les coordonnées GPS.
Pour une entreprise telle que Rovio, le meilleur moyen d’être à l’abri consiste à se protéger juridiquement grâce aux fameuses petites lignes que nous ne lisons que rarement. Voici un extrait de la charte de confidentialité de Rovio: « A l’exception des partenaires de Rovio qui fournissent les parties du Service basées sur la localisation, Rovio ne communiquera votre position géographique GPS à des tiers qu’avec votre consentement. » Les partenaires de Rovio étant les publicitaires, dont Google qui fournit le service Admob. Pour « l’exception », il faut se référer aux politiques de confidentialité de Google. Devant la loi, Rovio et Google n’ont bien entendu rien à se reprocher : l’utilisateur accepte l’installation de l’application et par la même les différentes chartes de confidentialité.
Pour en avoir le cœur net, il nous est possible d’aller plus loin en utilisant des méthodes de rétro-ingénierie, notamment grâce à l’outil baksmali. Mais avant de rentrer dans les détails du code, voyons comment se décomposent les sources d’Angry Birds. Il y a plusieurs sous-dossiers qui contiennent des librairies ajoutées par Rovio comme flurry ou google ads. Ce sont des librairies Java (Android) qui permettent à Angry Birds d’utiliser des API pour communiquer avec Facebook ou Admob par exemple. Voici une petite liste exhaustive :
Ces librairies peuvent contenir des fonctionnalités telles que la géolocalisation. Attention cependant, dans du Java (Android), même si le code contient des APIs pour de telles actions, rien n’indique leur utilisation. En l’occurrence, le système de permissions d’Android permet de bloquer ces appels d’API. Ainsi, l’application elle-même ne peut pas contourner le système de permissions, et heureusement. Une recherche dans les sources « smali » (=déssasemblé) du mot clé « admob » suffit à montrer que l’ancienne version d’Angry Birds (4952 hits) utilisait « Admob » alors que la dernière version (1256 hits) ne contient que peu de résultats et uniquement dans ses librairies :
La méthode checkCallingOrSelfPermission() permet à la librairie de tester si l’application qui la contient a la permission pour la géolocalisation. Étant donné qu’Angry Birds Rio ne déclare pas la permission, il est très peu probable que la géolocalisation de l’utilisateur soit remontée. En tous les cas, pour ces deux versions d’Angry Birds Rio c’est le cas. Bien sûr, si vous téléchargez une version en acceptant la permission de la géolocalisation, il ne faut pas s’étonner que les données remontent vers les serveurs de Google, puis ceux de la NSA…
Lorsque l’on se penche un peu plus sur le sujet, on peut rapidement se dire que la librairie native (JNI) inclue dans l’application est le meilleur moyen pour mettre des « Backdoors ».
Pour savoir ce qu’il en est, il n’y a pas trente-six moyens, il faut mettre les mains dans le cambouis. Une analyse avec un désassembleur permet au moins d’y voir un peu plus clair.
On peut trouver des fonctions intéressantes dans la section
Avant de s’emballer et de crier au scandale, il y a une question importante à se poser : pourquoi une application comme Angry Birds aurait-elle besoin d’inclure ces fonctions ?
Il y a une hypothèse à ne pas négliger : il se peut que par facilité et/ou par manque de compétences les développeurs aient décidé d’inclure dans « leur » librairie des fonctions « inutilisées ».
En fin de compte, vu la quantité de fonctions de toutes sortes qui sont dans cette librairie, il parait fort probable que les développeurs aient pris un « package complet » de fonctions et qu’ils ne se servent que de quelques-unes. C’est, à notre avis, l’hypothèse la plus plausible. Il est fort probable que les développeurs prennent une sorte de jeu de sources JNI(Java Native Interface) qui contient beaucoup, beaucoup de fonctions de toutes sortes. Et une fois ces sources compilées, ils peuvent appeler toutes ces fonctions natives depuis le code java sans trop se poser de questions. C’est pour cette raison que nous pensons qu’il ne faut pas tout de suite crier au scandale en voyant de telles fonctions, suspectes, il faut l’avouer.
D’aucuns diront que ces fonctions pourront être appelées plus tard, en cas de besoin. Mais là encore, Android bloque normalement la plupart des tentatives d’accès depuis un code C (JNI) avec son système de permissions. En effet, le contexte d’exécution des fonctions de la librairie est celui de l’application. C’est-à-dire dans une machine virtuelle d’Android (Dalvik Virtual Machine). Plutôt qu’une longue explication, voici un lien stackoverflow qui présente bien le fonctionnement.