fiddler logo

Vous saviez que la majorité des applications mobiles sont sensibles aux attaques de type "Man in the middle" ? La majorité des développeurs oublient de vérifier l'authenticité du certificat SSL utilisé et peuvent ainsi permettent à des systèmes tiers d'écouter les flux échangés entre l'application mobile et son serveur malgré l'utilisation du HTTPS.

Voici un moyen simple en mode boite noire qui permet de vérifier le comportement d'une application mobile à une attaque de type "Man in the middle" sur une connexion HTTPS.

Si vous ne connaissez pas Fiddler, il s'agit d'un analyseur de trames HTTP disponible gratuitement sous Windows et sur Mac OS. Il vous permet d'analyser toutes les trames HTTP qui entrent et sortent de votre ordinateur.

Sachant que la majorité des échanges réalisés réalisés par les applications mobiles sont réalisés via le protocole HTTP, lorsque Fiddler est configuré en mode proxy HTTP, il permet d'analyser les échanges réseau qu'une application mobile peut entreprendre avec son serveur.

Pour vérifier la sécurité de la connexion SSL d'une application mobile, cela se fait en 6 étapes simples :

  • Configurez Fiddler afin qu'il fonctionne en mode proxy

fiddler network

  • Configurez Fiddler afin qu'il déchiffre les trames SSL

fiddler ssl

  • Redémarrez Fiddler.
  • Installez le certificat Root généré par Fiddler sur votre terminal mobile en naviguant sur l'URL suivante depuis le navigateur de votre terminal mobile :
http://<ip de la machine fiddler>:8888/FiddlerRoot.cer
  • Configurez votre terminal mobile afin qu'il se connecte au proxy initialisé par Fiddler.
  • Lancez l'application et vérifiez si elle accepte ou rejette la connexion SSL générée par Fiddler.

À l'issu de ce test, deux résultats sont possibles :

  1. L'application fonctionne correctement et vous voyez le détail des trames HTTPS dans Fiddler : cela signifie que l'origine de la clef n'est pas vérifiée par l'application mobile, l'application accepte n'importe quel certificat dans la mesure où un certificat root reconnu est présent sur le terminal. Dans ce cas, supprimez le certificat Root et refaites un nouveau test pour voir si l'application accepte des certificats non signés ...
  1. L'application plante ou s'arrête : cela signifie que le développeur a correctement réalisé son travail de sécurisation de la connexion HTTPS.

Vous voilà prêt à tester la sécurité de vos applications mobiles !

  • Clone carte RFID Mifare

    Hacking : Comment cloner une carte RFID ?

    Les cartes RFID Mifare 1K possèdent deux protections principales : Le block 0 est en lecture seule, seul le constructeur de la carte peut initialiser ce block. Les données écrites sur les cartes sont encryptées. Il existe cependant des solutions pour outrepasser ces protections et permettre de créer des copies exactes. Cet article détaille la procédure pour cloner une carte RFID Mifare 1k sous Linux.

  • Tutoriel Backtrack 5 : Comment cracker un réseau Wifi protégé avec du WPA

    Voici un tutoriel intéressant sur les outils de bruteforce WPA mis à disposition dans la distribution Linux Backtrack 5.

1. Le , 18:19 par Quentin
22e591d0d0c9948817b69afd17258228

Hello,
Je ne suis pas professionnel du sujet mais la conclusion de l'article me semble erronée.
Du moment que le certificat CA root de Fiddler est ajouté à la liste des CAs de confiance, il est normal et attendu* d'accepter le certificat proposé par le proxy. Le principe de confiance est à la base de la liste des CAs et se propage aux certificats qu'ils signent. Pour les mêmes raisons, la navigation web ne devrait pas afficher d'erreur de certificat sur les adresses HTTPS.
Ça ne représente qu'un risque de sécurité faible car les CAs présents sur cette liste n'émettent de certificats que pour les domaines dont la possession est prouvée (ils échouent parfois, ce qui leur attire de graves problème, comme avec Diginotar ou Wosign). Ils sont audités et surveillés par les compagnies qui utilisent ces listes (de ce que j'ai vu les navigateurs avec Google et Mozilla et les OS).
Ici c'est l'utilisateur qui est à blâmer, pas l'application. La connexion SSL est bien passée par la vérification du certificat, qui n'est positive que par l'action volontaire de l'utilisateur.
Si, par contre, le certificat CA root n'est pas ajouté à la liste de confiance et que l'application fonctionne quand même, alors à ce moment on pourra dire d'elle qu'elle est codée avec les pieds (et je pense que là est le véritable test que cet article devrait proposer).
*Dans certains cas (rares de ce que j'en ai vu), il est possible de ne pas accepter ce certificat malgré tout, par exemple en utilisant la technique du key pinning : le certificat attendu est connu et comparé à celui proposé, ce qui permet une validation plus stricte. Mais c'est une technique qui a plusieurs désavantages importants et que je n'ai vu appliqué qu'une fois, à l'application mobile d'une banque (et pour le seul sous-domaine qui transférait des données personnelles).
Aussi, il est important de préciser qu'il faut supprimer le certificat CA root après avoir fait ces tests, sa présence dans la liste est un problème de sécurité non négligeable.
Quentin

2. Le , 23:02 par Ludovic
9ab09dd3e305f924f8930e20e1a35843

Merci Quentin, tu as raison la conclusion n'est pas tout à fait correcte ...

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.