Dans cette présentation, vous apprendrez les bases de l'analyse de protocole cryptographique, et quelques pistes pouvant aider à détecter une faille au sein de ces protocoles. Aucune connaissance crypto n'est nécessaire a priori (il ne s'agit pas ici de briser des protocoles éprouvés, mais de voir comment leur mauvaise utilisation peut les rendre inefficaces). On fera par le fait même un survol des outils utiles pour la rétro-ingénierie réseau, comme "Wireshark". La présentation sera basée sur un exemple réel d'un protocole VoIP brisé et corrigé récemment.

1. Rétro-ingénierie de
protocole crypto
un "starter pack"
par
Maxime Leblanc
OWASP Québec

2. À propos de moi
• Éducation
• B.Sc. informatique: Université de Sherbrooke
• M.Sc. sécurité informatique: Université Laval
• MBA affaires électroniques: Université Laval / Koç University
• Emploi
• Sécurité informatique chez Poka
• Autres
• Club de Hacking de l'Université Laval

3. • Notions de cryptographie
• Étude de cas VoIP
• Indices d'un protocole inefficace
• Toolbox de rétro-ingénierie open-source
• Résultats
• Conclusion
• Références
Plan

4. • Quatre grandes notions en sécurité informatique
• Intégrité
• S'assurer que les données n'ont pas été altérées
• Confidentialité
• S'assurer que les données ne sont accessibles que par leur destinataire
• Authentification
• S'assurer de l'identité d'un agent
• (Non-répudiation)
• S'assurer qu'un agent ne puisse renier l'origine d'une transaction
• L'utilisation de la cryptographie est en mesure d'assurer ces propriétés
Notions de cryptographie

5. • S'assurer que les données n'ont pas été altérées
• Algorithme cryptographique approprié: Le hash
• Fonction mathématique asymétrique
• On ne devrait pas pouvoir trouver la valeur originale à partir de son "hash"
• Exemple: hash_md5('owasp') == 'e0aca2fe8231010480c521fa93bc7ee6'
• La sécurité d'un algorithme de hash tient à sa non-réversibilité
• Une faille commune est l'utilisation d'un algorithme faible comme md5
Intégrité des données

6. • S'assurer que le contenu des données n'est accessible que par
leur destinataire
• Algorithme cryptographique approprié: le chiffrement
• Deux principaux types:
• Chiffrement symétrique: Une seule clé
• Chiffrement asymétrique: Clef publique et clef privée
• Attaque possible: clé mal protégée
• Mots de passe: cas spécial
• Attaque possible: hashs mal protégés
• Attaque possible: Rainbow tables lorsque le hash est non-salté
Confidentialité des données

7. • Une seule clé sert à chiffrer et déchiffrer
• La longeur des clés est relativement petite
• Typiquement de 128 à 256 bits
• Typiquement plus rapide que le chiffrement asymétrique
• Suppose que les deux parties connaissent la clé a priori
• Exemple: WiFi WPA2-PSK: Pre-Shared Key
Confidentialité:
Chiffrement symétrique

8. Confidentialité:
Chiffrement symétrique

9. Confidentialité:
Chiffrement asymétrique
• Clés différentes pour le chiffrement et le déchiffrement
• Message chiffré avec la clé publique du destinataire
• Message déchiffré avec sa clé privée
• Les clés publiques ne sont pas secrètes, mais les clés privées oui
• Exemple: SSL/TLS Utilise un chiffrement asymétrique pour transmettre
une clé de session jetable symétrique
• Nécessite une infrastructure de distribution de clés

10. Confidentialité:
Chiffrement asymétrique

11. Authentification
• S'assurer de l'identité d'un agent afin de lui attribuer les droits
appropriés sur un système
• Plusieurs facteurs d'authentification
• Quelque-chose que l'on sait
• Un mot de passe
• Quelque-chose que l'on a
• Un téléphone
• Quelque-chose que l'on est
• Biométrie

12. Non-répudiation
• S'assurer qu'un agent ne peut nier sa participation dans un échange
• Exemple: Signature électronique
• Combinaison de deux algorithmes cryptographiques
• Hash du message
• Chiffrementasymétrique du hash avec la clé privée de l'envoyeur(qui pourra donc être
déchiffré avec sa clé publique)
• Assure à la fois l'intégrité du message et l'identité de son envoyeur

13. Protocole cryptographique
• Dans cette présentation, on définit un protocole cryptographique
comme un protocole qui utilise la cryptographie pour assurer l'une ou
l'autre des propriétés montrées précédemment
• Pour le cas d'étude présenté, nous supposerons qu'il n'existe pas de
failles dans les algorithmes cryptographiques
• Il sera seulement question de leur utilisation inappropriée, créant des failles
dans les protocoles les utilisant

14. Étude de cas - Contexte
• Nous utilisons un système téléphonique dont le provisioning se fait via une
VM hébergée sur nos serveurs AWS
• Afin de pouvoir provisionner des téléphones répartis géographiquement,
nous avons dû ouvrir le port de communications du contrôleur sur le net
• J'ai voulu vérifier si le tout était sécuritaire
• Disclaimer: Je ne veux pas viser cette compagnie en particulier, ils font
généralement de bons produits que nous utilisons tous les jours. Ils s'agit
d'une expérience dont l'intérêt est avant-tout "scientifique"
• La faille présentée a été corrigée par une mise à jour vers Novembre 2016

15. État initial
• Serveur de provisioning Web
• Protocole HTTP (a contrario de HTTPS)
• Données chiffrées à la couche applicative (Wireshark)
• Je n'ai pas eu à entrer de clé ou de mot de passe pour que le
téléphone se connecte au contrôleur et se "provisionne"
• Conclusion préliminaire: Sans PSK, la clef doit être hardcodée quelque-
part (ou au moins déterministe)

16. Toolbox: Wireshark
• Permet d'intercepter tous les paquets passant par une carte réseau
• Le premier outils d'analyse à utiliser lors de la phase de "découverte"
dans la plupart des cas.
• Multiples fonctionnalités
• HTTP/HTTPS (si on possède le certificat)
• Décompression GZIP
• Analyse VoIP et extraction du son
• Reconstruction d'objets HTTP, SMB, etc...

17. Toolbox: Wireshark

18. Toolbox: Google
• Google est un outil à ne jamais négliger lorsqu'on investigue un
protocole
• Dans le cas qui nous occupe, quelqu'un a déjà fait une partie du travail et l'a
posté sur GitHub
• Ce n'est pas exactement le même protocole, mais il a été fait par la même
compagnie et on peut identifier des ressemblances
• That's a start!
• La personne en question ne s'est pas attardée à l'aspect sécurité,
mais donne de bons indices sur la structure des données échangées

19. Toolbox: JD-GUI
• Le contrôleur est disponible sous Linux, sous la forme d'un
package .deb
• Il s'agit d'un serveur Web Java (JSP)
• Du coup il existe plusieurs outils pouvant décompiler du Java
• Ce n'est jamais parfait, mais c'est toujours mieux que du Bytecode :-)
• À l'aide de JD-GUI, il est possible de comprendre comment le serveur
de provisioning interprète les paquets reçus
• On remarque par ailleurs que le code semble avoir été légèrement
obfusqué

20. Toolbox: JD-GUI

21. Toolbox: JD-GUI
• Avec JD-GUI et Google, on peut comprendre la structure des paquets
échangés
• <MAGICBYTES><ID><ENCR.PAYLOAD>
• JD-GUI nous donne aussi l'algorithme de chiffrement utilisé
• Avec JD-GUI, on peut identifier le "constructeur" de l'objet téléphone,
qui se fait attribuer une clé par défaut s'il n'est pas déjà "connu" de la
base de données.
• Note: J'ai aussi essayé d'installer le plugin Eclipse "bytecode-viewer",
mais sans succès.

22. Résultat intermédiaire
• La clé par défaut est un hash md5 d'un mot simple, trouvé facilement
via Google
• Possible d'utiliser Google comme une grosse "rainbow table"
• Dans ce cas-ci, le fait de "décrypter" le hash n'est pas important, puisqu'il s'agit
de la clé de chiffrement
• Afin de déchiffrer le payload échangé, j'ai tenté de simplement copier-
coller la plupart du code généré par JD-GUI et copier en "input" un
payload capturé par Wireshark
• Ça n'a pas fonctionné; Ça nécessitera un peu plus d'investigation

23. Toolbox: apktool
• Les téléphones roulent sous un système d'exploitation android
• Les applications Android sont codées en Java et peuvent aussi être
décompilées :-)
• L'outil permet de générer des fichiers de format ".smali", qui se
rapprochent un peu de l'assembleur
• Plusieurs outils permettent de "recompiler" le code smali vers du Java
plus classique
• Un simple "grep" nous permet de confirmer que la même clé trouvée
avec JD-GUI est aussi présente dans le code APK du téléphone.

24. Toolbox: grep
• Un outil très utile mais sous-estimé parce-que trop simple est la
commande Linux "grep"
• Permet de faire une recherche textuelle sur un grand nombre de
fichiers rapidement
• Utile pour récupérer des mots de passe hardcodés, des noms de
fonction particuliers, des mot-clés, etc...
• grep –ir "AES" .

25. Analyse
• On sait que les téléphones se font d'abord attribuer une clé par défaut
lors de leur première communication
• On peut alors supposer qu'il existe un "hand-shake" initial et que les
téléphones se voient attribuer une "meilleure" clé ensuite
• On peut confirmer cette hypothèse en remettant les téléphones à leur
état par défaut ou en les "oubliant" dans le contrôleur; Le
déchiffrement fonctionne alors :-)

26. Toolbox: IPTables
• Une attaque efficace est d'utiliser un "Man-In-The-Middle Proxy"
• Il s'agit d'une technique qui consiste à intercepter, lire et
potentiellement modifier le contenu d'une communication, de manière
transparente
• Pour ce faire, il est possible d'utiliser IPTables, sous Linux

27. Toolbox: IPTables
#!/bin/bash
ifconfig eth0 10.0.0.1 netmask 255.255.255.0
service isc-dhcp-server start
iptables -A FORWARD -o wlan0 -i eth0 -s 10.0.0.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -j MASQUERADE
sysctl -w net.ipv4.ip_forward=1

28. Résultats
• Avec la combinaison de notre Man-In-The-Middle simpliste, de
Wireshark pour intercepter les messages initiaux et de notre
connaissance de la clé initiale, il est possible de déchiffrer le message
qui envoie la "bonne" clé au téléphone
• Celle clé est alors compromise, et les messages subséquents peuvent
être déchiffrés
• WIN! :-)
• Addresse du serveur SIP, Username, Password...

29. Résultats
Mauvaiseutilisation de la cryptographie
• Les hash sont utilisés pour générer des clés
• Plus utile pour vérifier l'intégrité, pas d'ajout à la sécurité dans ce cas-ci
• Algorithme de hash faible (md5) et seed commun dans les dictionnaires
• Le résultat est une clé longue mais pas plus efficace
• L'algorithme de chiffrement symétrique utilise une clé faible
• Un hash md5 trouvable sur Google
• Pas de chiffrement asymétrique (HTTPS) ou de PSK pour protéger
l'échange de clé initial
• Pas de contrôle d'intégrité ni de signature des messages

30. • La technique du "Man-In-The-Middle" offre une panoplie de
possibilités à un attaquant imaginatif
• Étant donné qu'il n'y a ni contrôle d'intégrité, ni signature électronique, un
attaquant pourrait intercepter la clé et pousser sa propre clé
• Il est aussi possible de faire croire au téléphone que le contrôleur ne le connaît
pas et forcer une renégociation
• Pour ce faire, on manipule le statut HTTP
• Même principe que pour une attaque WiFi (deauth)
• "Personnification" d'un téléphone ou d'un contrôleur malicieux
• En changeant le ID (MAC Addresse), on pourrait récupérer les
autres identifiants de la base de données
Travaux futurs

31. Conclusion
• Une "patch" a corrigé le problème en Novembre 2016
• Une PSK est maintenantpoussée au téléphone par un autre canal de communication
plus sécurisé
• Se fier à ses instincts
• Quand ça ne sent pas bon, il y a probablement anguille sous roche
• L'utilisation de protocoles cryptographiques n'assure pas nécessairement la
sécurité de l'application
• Il faut utiliser les bon algorithmes pour assurer les propriétés appropriées
• Notre solution: Ajouter une couche HTTPS par-dessus le protocole normal
• Pas universel: Certains appareils ne le supportent pas

32. Conclusion
• Responsible disclosure
• Afin de respecter le principe de la divulgation responsable, je ne de
mentionnerai pas ici le nom du produit impliqué
• Hackers à Québec

33. Références
• Wirshark: https://www.wireshark.org/
• JD-GUI: http://jd.benow.ca/
• APKTOOL: https://ibotpeaches.github.io/Apktool/
• Club de Hacking ULaval: http://hacking.fsg.ulaval.ca/
• Hackfest: https://hackfest.ca/
• OWASP Québec: https://www.owasp.org/index.php/Quebec_City
• OpenCode Québec: http://www.opencode.ca/