SlideShare une entreprise Scribd logo
Rétro-ingénierie de
protocole crypto
un "starter pack"
par
Maxime Leblanc
OWASP Québec
À 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
• 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
• 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
• 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
• 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
• 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
Confidentialité:
Chiffrement symétrique
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
Confidentialité:
Chiffrement asymétrique
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
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
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
É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
É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)
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...
Toolbox: Wireshark
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
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é
Toolbox: JD-GUI
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.
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
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.
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" .
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 :-)
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
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
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...
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
• 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
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
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
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/

Contenu connexe

Similaire à Rétro-ingénierie de protocole crypto: Un "starter pack"

Hacking your home
Hacking your homeHacking your home
Hacking your homelaurenthuet
 
Etat des Lieux DANE (DNS Based Authentication of Named Entities)
Etat des Lieux DANE (DNS Based Authentication of Named Entities)Etat des Lieux DANE (DNS Based Authentication of Named Entities)
Etat des Lieux DANE (DNS Based Authentication of Named Entities)Afnic
 
Partagez votre code et non vos secrets
Partagez votre code et non vos secretsPartagez votre code et non vos secrets
Partagez votre code et non vos secretsOpen Source Experience
 
Javascript as a first programming language : votre IC prête pour la révolution !
Javascript as a first programming language : votre IC prête pour la révolution !Javascript as a first programming language : votre IC prête pour la révolution !
Javascript as a first programming language : votre IC prête pour la révolution !VISEO
 
chap 4 Sécurité des accès.pdf
chap 4 Sécurité des accès.pdfchap 4 Sécurité des accès.pdf
chap 4 Sécurité des accès.pdfdepinfo
 
La Quete du code source fiable et sécurisé - GSDAYS 2015
La Quete du code source fiable et sécurisé - GSDAYS 2015La Quete du code source fiable et sécurisé - GSDAYS 2015
La Quete du code source fiable et sécurisé - GSDAYS 2015Sebastien Gioria
 
Perfug BOF devoxx2017.pptx
Perfug BOF devoxx2017.pptxPerfug BOF devoxx2017.pptx
Perfug BOF devoxx2017.pptxMarc Bojoly
 
Toutes les raisons d'adopter MongoDB
Toutes les raisons d'adopter MongoDBToutes les raisons d'adopter MongoDB
Toutes les raisons d'adopter MongoDBContent Square
 
802.1X filaire, un monde idéal illusoire? (Olivier Bilodeau)
802.1X filaire, un monde idéal illusoire? (Olivier Bilodeau)802.1X filaire, un monde idéal illusoire? (Olivier Bilodeau)
802.1X filaire, un monde idéal illusoire? (Olivier Bilodeau)Hackfest Communication
 
Elasticsearch 5.0 les nouveautés
Elasticsearch 5.0 les nouveautésElasticsearch 5.0 les nouveautés
Elasticsearch 5.0 les nouveautésMathieu Elie
 
Virtual Private Network
Virtual Private NetworkVirtual Private Network
Virtual Private Networkmalekoff
 
Orchestrez vos projets Symfony sans fausses notes
Orchestrez vos projets Symfony sans fausses notesOrchestrez vos projets Symfony sans fausses notes
Orchestrez vos projets Symfony sans fausses notesXavier Gorse
 

Similaire à Rétro-ingénierie de protocole crypto: Un "starter pack" (20)

Usine Logicielle 2013
Usine Logicielle 2013Usine Logicielle 2013
Usine Logicielle 2013
 
Hacking your home
Hacking your homeHacking your home
Hacking your home
 
Etat des Lieux DANE (DNS Based Authentication of Named Entities)
Etat des Lieux DANE (DNS Based Authentication of Named Entities)Etat des Lieux DANE (DNS Based Authentication of Named Entities)
Etat des Lieux DANE (DNS Based Authentication of Named Entities)
 
Partagez votre code et non vos secrets
Partagez votre code et non vos secretsPartagez votre code et non vos secrets
Partagez votre code et non vos secrets
 
Javascript as a first programming language : votre IC prête pour la révolution !
Javascript as a first programming language : votre IC prête pour la révolution !Javascript as a first programming language : votre IC prête pour la révolution !
Javascript as a first programming language : votre IC prête pour la révolution !
 
chap 4 Sécurité des accès.pdf
chap 4 Sécurité des accès.pdfchap 4 Sécurité des accès.pdf
chap 4 Sécurité des accès.pdf
 
Hackerspace jan-2013
Hackerspace jan-2013Hackerspace jan-2013
Hackerspace jan-2013
 
La Quete du code source fiable et sécurisé - GSDAYS 2015
La Quete du code source fiable et sécurisé - GSDAYS 2015La Quete du code source fiable et sécurisé - GSDAYS 2015
La Quete du code source fiable et sécurisé - GSDAYS 2015
 
Perfug BOF devoxx2017.pptx
Perfug BOF devoxx2017.pptxPerfug BOF devoxx2017.pptx
Perfug BOF devoxx2017.pptx
 
Toutes les raisons d'adopter MongoDB
Toutes les raisons d'adopter MongoDBToutes les raisons d'adopter MongoDB
Toutes les raisons d'adopter MongoDB
 
802.1X filaire, un monde idéal illusoire? (Olivier Bilodeau)
802.1X filaire, un monde idéal illusoire? (Olivier Bilodeau)802.1X filaire, un monde idéal illusoire? (Olivier Bilodeau)
802.1X filaire, un monde idéal illusoire? (Olivier Bilodeau)
 
Elasticsearch 5.0 les nouveautés
Elasticsearch 5.0 les nouveautésElasticsearch 5.0 les nouveautés
Elasticsearch 5.0 les nouveautés
 
ReST API Security
ReST API SecurityReST API Security
ReST API Security
 
ReST API Security
ReST API SecurityReST API Security
ReST API Security
 
Implémentation d'openvpn
Implémentation d'openvpnImplémentation d'openvpn
Implémentation d'openvpn
 
Virtual Private Network
Virtual Private NetworkVirtual Private Network
Virtual Private Network
 
Vpn
VpnVpn
Vpn
 
Vpn
VpnVpn
Vpn
 
Orchestrez vos projets Symfony sans fausses notes
Orchestrez vos projets Symfony sans fausses notesOrchestrez vos projets Symfony sans fausses notes
Orchestrez vos projets Symfony sans fausses notes
 
Presentation
PresentationPresentation
Presentation
 

Rétro-ingénierie de protocole crypto: Un "starter pack"

  • 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
  • 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
  • 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...
  • 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é
  • 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/