Comme nous avons pu le constater dans la première partie de cette enquête, de très nombreuses applications bancaires n’intègrent aucune (ou un niveau très bas) sécurité. Mais notre analyse très fine nous a aussi permis de faire d’étonnantes (disons même, inquiétantes) découvertes à propos de l’application de JP Morgan. Cache-t-elle une backdoor ?

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

Le cas de l’application de gestion des comptes de la JP Morgan a été de loin le plus intéressant a étudier.
Lors de son initialisation, elle envoie des requêtes au serveur de la banque et une réponse du serveur soulève des questions. L’application reçoit une variable nommée signature, qui se présente sous la forme d’une donnée qui semble être une empreinte encodée en base 64. Cependant elle est visiblement trop longue pour être une empreinte de hash et trop courte pour être une clef publique RSA. J’ai donc pensé qu’il pouvait s’agir d’un message compressé ou chiffré.

Afin d’en savoir plus j’ai utilisé un outil, APImonitor, qui permet d’instrumenter l’application, c’est-à-dire de modifier son code pour ajouter des fonctions de surveillance. Ces fonctions de surveillance peuvent permettre d’écrire dans des fichiers de log n’importe quelle fonction exécutée en temps réel par l’application, avec les paramètres utilisés et les valeurs de retour.

Cela a confirmé mon intuition : après avoir reçu cette « signature », une fonction de déchiffrement est appelée et le message est déchiffré. Il contient plusieurs sous-messages séparés par des motifs.
Les premiers sous messages sont effectivement des signatures, puis vient une liste de noms d’applications qui utilisent les droits root. La recherche du motif employé pour séparer ces sous-messages a permis de savoir où ils étaient utilisés dans le code source.
Cela a mis en lumière une découverte intéressante, un de ces sous-messages est utilisé et exécuté comme une commande shell si il est présent. De plus si le téléphone est rooté, cette commande est exécutée avec les droits root, ce qui en augmente considérablement la portée.

Ces informations sont en fait utilisées par un framework de sécurité qui va vérifier par exemple si le téléphone est rooté, ce qui pourrait indiquer qu’un malware est présent. La possibilité d’exécuter des commandes shell pourrait lui permettre de réagir rapidement en cas de nouvelles menaces en faisant des tests supplémentaires. Cependant ce dispositif peut tout aussi bien être utilisé pour prendre le contrôle du téléphone à distance et de manière ciblée. C’est pourquoi il doit être considéré comme une backdoor.

Quelques mois après que JP Morgan ait été informé de cette découverte, l’application a reçu une mise à jour tout aussi intéressante, qui corrigerait la backdoor. J’ai analysé cette nouvelle application :

– Mon outil d’analyse des communications https n’est plus fonctionnel sur cette version. Impossible donc de savoir si l’application reçoit encore des messages chiffrés.

– L’outil APImonitor ne marche plus lui non plus, l’application le fait crasher.

– Le code Java relatif à ce framework de sécurité a disparu, mais une librairie native (code c cross-compilé pour Android) est apparue. Le code de « sécurité » a été déporté dans la librairie, la rendant plus difficilement lisible.

La rétro-ingénierie de la librairie n’a rien donné de significatif, cependant il est difficile d’être sûr à 100 % que la backdoor n’ait pas pris une autre forme. Beaucoup d’efforts ont été fournis pour m’empêcher d’analyser cette application, ce qui entretient le doute. Personnellement, je ne l’installerais pas sur mon téléphone, chacun se fera son avis.

(in)Sécurité des applications mobile, le bilan

Il est quand même bien plus intéressant de parler d’une application vulnérable que d’une application bien implémentée et bien sécurisée. Qui s’intéresse à ces banques qui font bien leur boulot, d’ailleurs ? Il est évident qu’ici les moutons noirs du monde bancaire ont tendance à jeter l’opprobre sur une population d’applications dont la sécurité est irréprochable.

Au niveau de la répartition géographique, je constate globalement une légère victoire des banques asiatiques par rapport aux banques européennes et américaines, en effet j’ai pu constater plus régulièrement chez les banques asiatiques :

– Une obfuscation du code plus poussée avec par exemple du déchiffrement de code contenu dans des ressources externes et exécuté à la volée.

– Un chiffrement additionnel pour le mot de passe. Habituellement le seul chiffrement utilisé est celui de la communication https.

– Un soin plus particulier pour se protéger des outils de rétro-ingénierie et d’analyse dynamique, j’ai pu par exemple constater plus souvent la mise en place de techniques de certificate pinning – excusez ce barbarisme anglo-saxon, mais le terme n’a pas d’équivalent français à ma connaissance. Il s’agit d’un ensemble de stratégies visant à s’assurer que le certificat SSL du serveur contacté est signé par une autorité de confiance reconnue par le serveur et non par une autorité qui aurait pu être implantée malicieusement dans la liste du système client. Ces techniques mettent des bâtons dans les roues des outils que j’ai créé pour intercepter les communications https des applications.

J’ai été surpris de constater ces différences continentales, mais elles sont bien réelles.

Pour les utilisateurs d’iOS qui pourraient penser que leurs applications sont plus sécurisées parce que l’on n’en parle pas dans cet article, je tiens à leur dire ceci : ils se trompent.
La WebView Android a par exemple son équivalent sur iOS, l’UIWebView, et charger du code JavaScript depuis une source non sûre comporte autant de problèmes pour les deux OS. Aux mêmes causes, les mêmes conséquences. Bien souvent les vulnérabilités ne dépendent pas du système d’exploitation, ce sont des erreurs humaines (comme oublier le mode débug) ou des vulnérabilités dans l’architecture de l’application (cf. backdoor JPMorgan), cela n’est pas spécifique à Android.

Quelles sont les solutions ?

Pour ce qui est de la gestion de comptes bancaires, je recommande vivement d’utiliser son ordinateur classique et les services en ligne de la banque. Il faut considérer les téléphones comme un environnement moins sécurisé qu’un ordinateur et donc éviter d’utiliser des services ou des données dont la sécurité est vitale. Les téléphones ne sont pas moins sûrs parce qu’ils sont moins bien pensés, au contraire le système de permissions d’Android n’existe pas sur Linux et il limite beaucoup les capacités d’actions malveillantes. Cependant c’est notre utilisation du téléphone qui le rend moins sécurisé :

– Il est sans arrêt déplacé, oublié et manipulé par d’autres.

– Il concentre énormément d’informations personnelles et suscite donc la convoitise.

– Il y a toujours prétexte à installer des applications là où on pourrait utiliser des services en ligne. À la décharge des utilisateurs, beaucoup de sites n’ont pas de version web adaptée pour mobile.

– Il devient principalement un objet de divertissement et de consommation et reste accessoirement un objet de communication, il subit alors les comportements irréfléchis de ses utilisateurs comme l’installation compulsive d’applications gadget. La fausse impression de gratuité des applications est d’ailleurs un problème en ce sens : le coût réel se mesure ici en octets d’informations personnelles et en temps de cerveau disponible.

Il y a tout de même des solutions techniques pour renforcer la sécurité de notre téléphone :

– Chiffrer son contenu.

– Utiliser des applications alternatives open-source lorsqu’elles existent. Pour les intéressés, il existe un market d’applications Android alternatif appelé Fdroid.

– En terme d’applications gadget et de sécurité, un ascète survivra plus longtemps qu’un libertin. L’application moyenne n’étant pas particulièrement intéressée par les questions de sécurité, et pouvant être le vecteur d’attaques, il est difficile d’attendre une sécurité sérieuse sur un téléphone qui mêle également divertissement, consommation et réseaux sociaux : il faut choisir où sont ses priorités !

Enfin la sécurité doit devenir, plus qu’une normalité, une évidence et vu les échanges que j’ai eu avec les banques nous n’en sommes pas encore là. Cette démarche d’analyse est bien souvent prise comme une agression, ce qui entraîne généralement deux comportements : l’indifférence ou le déni ; quand il est possible ne serait-ce même que de trouver un contact visible à qui rapporter ces vulnérabilités.
Il est important que des systèmes de communication de vulnérabilités soient un processus habituel avec ou sans prime à la clef. Cela est bénéfique pour tous.
Plus qu’un mauvais bug les entreprises craignent une mauvaise campagne médiatique.
Tant que nous vivrons dans un monde connecté, il y aura des failles, autant prendre le taureau par les cornes. Alors la sécurité informatique deviendra une évidence, elle perdra son caractère tabou et avec elle, le scandale qui l’entoure.