Depuis plusieurs mois, nous nous penchons sur les risques ainsi que les précautions à prendre quant à l’utilisation des terminaux mobiles (smartphones et tablettes sous iOs, Android, Windows Mobile, BlackBerry OS, etc.), ainsi que sur la sécurité des applications sur ces environnements.
Ce travail passe notamment par la déclinaison de nos démarches et le développement d’un outillage adapté pour évaluer une application mobile – y compris en boîte noire ou via du reverse engineering (que l’objet soit le test d’intrusion, l’audit applicatif, la revue de code ou une analyse d’une application suspecte).
Dans le cas particulier de l’analyse dynamique d’une application Android, notre démarche fut, dans un premier temps, d’utiliser un émulateur passant par un proxy local (ZAP, Burp, WebScarab ou autre), de la même manière que nous pourrions le faire pour un test d’intrusion web classique.
Nous nous sommes rapidement heurtés à un problème de coupure SSL, Android ne reconnaissant pas le certificat du proxy.
Les applications Android rencontrant des exceptions de ce type considèrent en général que l’accès à Internet est indisponible ou quittent purement et simplement.
Le système d’exploitation de Google possède pourtant un magasin de certificats interne lui permettant d’accepter les connections SSL venant de sources fiables (/system/etc/security/cacerts.bks).
Nous avons donc tenté de l’extraire, d’y insérer le certificat racine de notre proxy, ce qui en théorie, aurait pu nous permettre d’observer les flux HTTPS. Néanmoins, le système a besoin de redémarrer pour prendre en compte le nouveau certificat, mais Android dispose d’un mécanisme de gestion de l’intégrité de son magasin et supprime les certificats ajoutés manuellement à chaque démarrage, la manœuvre se révélant donc inefficace.
Au cours de nos recherches, McAfee a alors publié un white-paper décrivant comment contourner la vérification des certificats lors des communications SSL sous Android ![1]
Les connections HTTPS dans l’API Android s’effectuent habituellement en instanciant un des objets suivant :
- org.apache.http.impl.client.DefaultHttpClient ;
- javax.net .ssl.HttpsUrlConnection ;
- android.webkit.Webview.
Deux méthodes sont alors proposées pour contourner l’étape de validation des certificats :
- On dispose des sources : on insère manuellement du code Java permettant le contournement de la vérification de validité des certificats ;
- On ne dispose pas des sources, auquel cas il faut désassembler l’application et y insérer le même code avant de recompiler l’application.
Quelque soit la méthode utilisée, nous obtenons une version « patchée » de l’application ne vérifiant plus la validité des certificats SSL.
Le désavantage majeur réside dans le fait de devoir faire ces manipulations manuellement, potentiellement pour chaque application testée.
N’étant pas assuré de disposer du code source des applications à analyser, nous avons donc opté pour la modification du code après décompilation.
Apktool[2] est utilisé pour les opérations de décompilation et de recompilation de l’application, et le code proposé par McAfee est inséré dans le code de l’application.
Nous avons donc écrit un script python « intrinsec-android-ssl-patch » (intrinsec-android-ssl-patch @ googlecode), qui se charge d’automatiser les actions suivantes :
- Décompilation de l’application ;
- Insertion des fichiers décompilés permettant le contournement de la vérification au sein de l’application ;
- Recherche des appels initiant des connections HTTPS et insertion du code de contournement ;
- Recompilation de l’application ;
- Réinsertion des ressources de l’application originale (images, layouts, etc.), qui peuvent pâtir des opérations de décompilation.
Cet outil permet d’automatiser le contournement de la vérification des certificats SSL lors des échanges HTTPS dans les applications Android.
L’observation, l’interception et le rejeu des requêtes émises étant les actions majeures de l’analyse applicative, l’utilisation de cet outil sur les applications à tester devrait permettre la réalisation de tests complets.
N’hésitez pas à nous contacter si vous avez des commentaires ou souhaitez discuter de ce sujet !
Merci à Marc Lebrun pour son travail de recherches et le développement du script !
