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 :
- Le SDK Android et/ou iOS, ou plus précisément l’émulateur associé (en tant que développeur vous devez forcément l’utiliser).
- Un proxy d’interception Web réalisant une coupure SSL tel que Burp Proxy (http://portswigger.net/burp/download.html) ou OWASP Zap (https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project).
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 :
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 :
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 :
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 :
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 :
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.
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.
