Tester simplement la confidentialité des flux d’une application mobile

Dans le cadre des audits réalisés par Intrinsec sur des applications mobiles, nous avons constaté que de nombreux défauts permettent de mettre à mal la confidentialité des échanges HTTP malgré l’utilisation de flux chiffrés SSL  (cf ici).

Les smartphones et tablettes peuvent être amenés à communiquer à travers des réseaux WiFi publics sur lesquels l’interception de trafic est aisée, le risque de fuite d’informations volontaire ou non est bien réel (cf. ici)

Les défauts dans la validation des certificats sont parfois dus à une erreur de développement, à un oubli suite à la création d’un cas de test ou bien à l’utilisation d’une bibliothèque externe. Dans tous les cas, il n’est pas toujours aisé de valider, lors de l’analyse du code, que la confidentialité des flux HTTP d’une application mobile est garantie.

Aussi, à travers cet article, nous souhaitons nous adresser aux développeurs d’applications mobiles et expliquer comment, en réalisant un test simple, il est possible de valider qu’une application Android ou iOS assure ce niveau de confidentialité.

Pour cela plusieurs outils sont nécessaires :

Par la suite nous utiliserons Burp Proxy.

Etape 1 : Paramétrage du proxy d’interception Burp

Ce proxy va nous permettre d’intercepter les flux HTTPS pour valider le comportement de l’application en cas d’attaque.

Par défaut, Burp va ouvrir une socket sur le port 8080 de la « loopback » de la machine, si ce port est déjà utilisé il faudra alors en utiliser un autre en paramétrant l’application comme suit :

Image_article_proxy1

En cas d’utilisation au sein d’un réseau d’entreprise il peut être nécessaire de proxyfier la sortie du proxy d’interception, cette manipulation peut se faire comme indiqué ci-après :

Image_article_proxy2.png

La dernière étape consiste à désactiver l’interception des requêtes HTTP car le but ici n’est pas de modifier à la volée les requêtes réalisées par l’application :

Image_article_proxy3.png

A la fin de cette étape nous obtenons donc un proxy coupant les flux SSL et en écoute sur le port 8080 (ou un autre si vous l’avez modifié) de la loopback.

Etape 2 : « Proxyfication » des émulateurs.

Le but est donc de faire transiter le trafic des émulateurs au travers du proxy d’interception Burp pour étudier le fonctionnement de l’application en cas de coupure SSL. Il faut donc pour cela paramétrer les émulateurs pour rediriger le trafic  au sein de ce proxy.

Proxyfier l’émulateur Android est une chose aisée puisque la commande « emulator » chargée de lancer un émulateur possède une option « -http-proxy ». Il suffit donc d’utiliser cette option avec « localhost :8080 » comme paramètre, il est également possible d’ajouter cette option directement dans la configuration de debug ou d’exécution d’Eclipse :

Image_article_proxy4.png

L’émulateur iOS quant à lui ne possède pas d’option permettant de le proxyfier directement, aussi, il est nécessaire de paramétrer le proxy au niveau du système MacOs :

Image_article_proxy5.png Image_article_proxy6 Image_article_proxy7

Etape 3 : Analyse du comportement de l’application

Le comportement de l’application une fois proxyfiée permet de vérifier s’il est toujours possible de l’utiliser normalement en cas de coupure du flux de chiffrement.

L’analyse des requêtes dans Burp permet d’identifier plusieurs défauts éventuels :

  • La présence de requête HTTP sans chiffrement qui pourrait permettre l’interception d’informations sensibles (authentifiants, cookies, données métier, etc.).
  • La présence de requête chiffrées interceptées sans que l’application ne cesse de fonctionner ou ne lève d’alerte auprès de l’utilisateur.

Image_article_proxy8

Nous vous recommandons d’effectuer ce test simple pour valider le fonctionnement d’une bibliothèque externe ou avant la mise en production d’une nouvelle application. En cas d’identification de défauts, une revue du code devra être effectuée pour identifier et corriger les défauts au sein du code.