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 transmettreune 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

• Chiffrement asymétrique du hash avec la clé privée de l'envoyeur (qui pourra donc êtredé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 cryptographiquecomme un protocole qui utilise la cryptographie pour assurer l'une oul'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 uneVM 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'agitd'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êmecompagnie 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 serveurde provisioning interprète les paquets reçus

• On remarque par ailleurs que le code semble avoir été légèrementobfusqué

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é facilementvia 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 êtredé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éeavec 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éfautlors 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èretransparente

• 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 notreconnaissance 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ésultatsMauvaise utilisation 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égerl'é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 maintenant poussé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/