Vous utilisez des applications tous les jours, c’est devenu une habitude, entre deux métros, de consulter Facebook, de jouer quelques niveaux à Candy Crush… Pourtant, ces applications, vous ne pouvez pas leur faire confiance, vous savez qu’en échange de leurs services, elles collectent des infos sur vous.

C’est le deal, vous l’acceptez, ça reste gratuit et somme toute inoffensif en apparence. Plus sérieusement, parlons d’argent maintenant. Faites-vous confiance à l’application de votre banque ?

Voici le résultat d’un an d’analyses d’une centaine d’applications, françaises et internationales, sous Android (mais la situation est semblable sous iOS…). Révélations.

Par Paul Irolla
Laboratoire (C + V) O – Laboratoire de Cryptologie et Virologie Opérationnelles – Esiea

Dans le monde de l’application mobile, on pourrait penser que les applications bancaires sont exemptes de problème de sécurité. Pouvons-nous leur faire confiance pour gérer notre argent ? Cette question j’y réponds après un an passé à analyser les applications bancaires nationales et internationales sur Android.

Chaque application est passée sous le crible d’outils de rétro-ingénierie, d’analyse dynamique et d’analyse des communications réseau afin de détecter les erreurs ou les failles dans leur implémentation. Ce qui suit détaille les vulnérabilités les plus intéressantes que j’ai pu découvrir sur un panel d’environ une centaine d’applications bancaires :

Une petite boulette, une porte grande ouverte pour les hackers

La première application bancaire que j’ai analysée a été Budgea, une application française d’agrégation de comptes bancaires. C’est-à-dire qu’avec un seul identifiant et mot de passe, il est possible d’accéder aux données de l’ensemble de ses comptes venant de différentes banques.

Cette application utilise une connexion sécurisée, https, pour s’identifier au serveur et c’est indispensable. Cependant la vulnérabilité se niche dans les détails, elle utilise en effet l’option ALLOW_ALL_HOSTNAME_VERIFIER.

Cette option permet de passer la vérification du nom de domaine, contenu dans le certificat, que le site contacté présente au client. Plus directement, l’application accepte n’importe quel certificat valide et donc un attaquant capable de se positionner entre l’application et le serveur – Man In The Middle attack – peut rediriger la connexion sur son serveur et récupérer les identifiants de la cible.

Cette option est censée être utilisée uniquement lors de la phase de développement de l’application, pour permettre de faciliter les tests de fonctionnalités. Les responsables ont été avertis du problème et la faille est maintenant corrigée.

Ce genre de cas de mauvaise implémentation de la connexion sécurisée ou de la gestion de comptes entre l’application et le serveur est très rare. Les banques savent depuis longtemps gérer ce genre de choses. Mais l’application en question ne provient pas d’une banque. On se rend compte que les problèmes commencent lorsque les banques ne sont pas directement impliquées dans le développement, c’est ce que nous allons voir tout de suite avec l’application de la BNP.

Quelqu’un d’autre ne peut pas le faire ?

Par exemple, la BNP promeut ses divers services additionnels – assurances, systèmes d’alarme, prêts, etc. – via des publicités à travers son application. Le problème est de confier ce travail de distribution de publicités à une société externe, Ad4Screen.

Le développement d’Android n’est pas encore mature, mais ce genre de développement est bien maîtrisé pour des sites web. Une pratique répandue est donc d’utiliser l’application comme un navigateur web. Mais comment ça marche ?

Pourquoi ne pas réutiliser sur Android le code html, css et JavaScript que nous avons l’habitude d’utiliser ? Il suffit de le charger dans une WebView et le tour est joué. On peut même contrôler l’API Android par le JavaScript avec la fonction addJavascriptInterface de la WebView !
Encore mieux, afin de pouvoir facilement mettre à jour le framework, on télécharge dynamiquement ce code web depuis notre serveur ! En http ! La sécurité avant tout, n’est-ce pas ? Si on ne peut plus faire confiance à des sociétés qui font du business sur la collecte d’informations personnelles, mais où va le monde !

Dans cette configuration, un attaquant qui se place entre l’application et le serveur peut modifier le code JavaScript reçu. C’est là où le bât blesse.
En effet sur nombre de versions obsolètes d’Android (API < 4.2 soit environ 20 % des utilisateurs à l’heure actuelle d’après le dernier rapport Google sur les statistiques des distributions utilisées), la fonction addJavascriptInterface contient une vulnérabilité qui permet au code JavaScript d’exécuter des commandes shell arbitraires ou d’appeler n’importe quelle fonction de l’API Android (Caméra, SMS, Appels, installation d’app et plus si affinité).
En d’autres termes, l’attaquant peut exécuter n’importe quelle commande dans la limite des permissions accordées à l’application. Celles-ci sont plutôt étendues, comme chez toutes les applications bancaires. Après quelques échanges cordiaux, les responsables ont corrigé la vulnérabilité.

Nous avons vu le résultat lorsqu’une partie du développement est confiée à un tiers, maintenant imaginez ce qu’il peut se passer quand une application bancaire est entièrement conçue par une société de services peu scrupuleuse. Impossible ? Vous seriez surpris.

La Palme d’Or

Une des plus anciennes banques indiennes, la banque Canara, surfe sur la vague des applications « passbook / bankbook». Il s’agit d’une application qui va résumer les informations des comptes, en incluant le solde et les derniers mouvements. Elle ne permet pas, par contre, de générer des mouvements bancaires. D’après Google Play, l’application comptabilise entre 100k et 500k téléchargements et la dernière mise à jour date de juin 2014.

Le problème avec cette application est que toutes, absolument toutes les communications sont en clair ! Impensable, mais vrai. N’importe qui surveillant le réseau peut récupérer les identifiants de connexion, entre autres. Encore mieux, lorsqu’on se connecte au serveur il affiche une page de tutoriel qui liste les commandes pour lesquelles le serveur répond, avec les arguments à utiliser et même un petit manuel d’exemple. Les fonctions disponibles vont de « AccountSummary » à « getCreditCardNumbers » en passant « Get_Balance ». C’est parfait pour un pirate désirant automatiser le processus, il suffit de suivre le tutoriel.

Un whois sur l’adresse IP du serveur révèle qu’il n’appartient même pas à la banque, mais à une société de services à Mumbai. Cette société propose des solutions qui vont de la gestion de services sur serveur dédié jusqu’au développement d’applications mobiles.

L’application est en version 5.1, c’est à se demander dans quel état elle était à l’origine. Leur leitmotiv est « Answering needs, Integrating technologies » , je leur propose : « Answering fast, Integrating money ».

Le développement en chaussons, comme à la maison

J’ai eu l’occasion d’analyser la quasi-intégralité des applications bancaires norvégiennes. Elles sont bâties à peu d’exceptions près autour d’une poignée de modèles. Les différences entre plusieurs applications du même modèle sont le logo et l’adresse de connexion au serveur de la banque.

Tous les modèles sont sûrs à l’exception d’un seul utilisé par six applications : Bank2, Vekselbanken, Storebrand, Cultura Bank, Totens sparebank, Drangedal sparebank.

Lors de la connexion au serveur, si il y a une erreur réseau, l’application écrit dans les fichiers de log les informations nécessaires afin que le développeur corrige le problème. C’est à dire l’identifiant, le mot de passe en clair et la clef de chiffrement du mot de passe. Le mode débug activé, c’est pratique non ?

Provoquer une erreur réseau n’étant pas sorcier, la question est de savoir comment récupérer ces données depuis les fichiers de log. Il est possible pour les applications de lire les logs des autres applications sur les versions d’Android inférieures à 4.1.
Pour les autres versions, la vulnérabilité est plus difficilement exploitable, mais pas impossible. Cela demande un accès physique à l’appareil, le plus direct est de flasher le téléphone, installer un accès root (en installant une ROM Cyanogen par exemple) et d’utiliser des outils pour récupérer les fichiers effacés. Une simple recherche web permet de trouver rapidement un outil ou une application qui pourra s’occuper de cette tâche.

Il est vivement conseillé de chiffrer son téléphone pour se protéger contre les attaquants qui peuvent avoir un accès physique à l’appareil (cette option est accessible dans les paramètres de sécurité d’Android).