Hack NFC - Proxmark3 : Différence entre versions
(→Présentation) |
|||
Ligne 162 : | Ligne 162 : | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | = Partie 3 : Sniff de l'échange entre une carte NFC et la borne des portes = | ||
+ | |||
+ | Pour ce faire on a utilisé les commandes | ||
+ | "hf 14a snoop" pour sniffer et enregistrer l'échange | ||
+ | "hf 14a list" pour avoir accès à l'enregistrement | ||
+ | |||
+ | proxmark3> hf 14a snoop | ||
+ | #db# cancelled by button | ||
+ | #db# maxDataLen=3, Uart.state=0, Uart.byteCnt=1 | ||
+ | #db# Uart.byteCntMax=20, traceLen=12d, Uart.output[0] | ||
+ | proxmark3> hf 14a list | ||
+ | recorded activity: | ||
+ | ETU :rssi: who bytes | ||
+ | ---------+----+----+----------- | ||
+ | + 0: 0: TAG 02 | ||
+ | + 152797: 0: TAG 00! | ||
+ | + 289126: 0: TAG 02 | ||
+ | + 147123: 0: TAG 01 | ||
+ | + 147462: 0: TAG 05! | ||
+ | + 147290: 0: TAG 02 | ||
+ | + 441954: 0: TAG 02 | ||
+ | + 441954: 0: TAG 02 | ||
+ | + 531882: 0: TAG 04 00 | ||
+ | + 746: 0: TAG 4e 46 7e 16 60 | ||
+ | + 2048: 0: TAG 08 b6 dd | ||
+ | + 120402: 0: TAG 02 | ||
+ | + 21846: 0: TAG 04 00 | ||
+ | + 744: 0: TAG 4e 46 7e 16 60 | ||
+ | + 2052: 0: TAG 08 b6 dd | ||
+ | + 142234: 0: TAG 04 00 | ||
+ | + 746: 0: TAG 4e 46 7e 16 60 | ||
+ | + 2048: 0: TAG 08 b6 dd | ||
+ | + 142220: : 26 | ||
+ | + 4752: : 26 | ||
+ | + 142579: : 26 | ||
+ | + 4751: : 26 | ||
+ | + 142578: : 26 | ||
+ | + 4750: : 26 | ||
+ | + 142576: : 26 | ||
+ | + 4752: : 26 | ||
+ | + 142579: : 26 | ||
+ | + 4751: : 26 | ||
+ | |||
+ | ATQA+UID+SAK = 0004 4e467e16 08: On a donc retrouvé l'UID de la carte NFC qui vaut 4e467e16 | ||
+ | |||
+ | L'ETU : elementary time unit (ETU) est la durée nominale des bits utilisés dans la trame | ||
+ | |||
+ | Le "rssi" est l'intensité du signal, il reste à 0. Nous avons contacté des développeurs de Proxmark qui nous ont confirmé que c'était le même cas pour eux et qu'il ne fallait pas en tenir compte. | ||
+ | |||
+ | Les échanges au début de l'enregistrement ne signifient rien et ils ne sont pas à prendre en compte. | ||
+ | |||
+ | Dans ce cas, l'antenne de la Proxmark était placée à moins de 5 cms de l'échange, Le but étant de pouvoir faire ce genre d'opération à au moins 1 mètre. | ||
Version du 28 novembre 2013 à 10:49
Sommaire
Présentation
Contexte:
La technologie RFID est de plus en plus utilisées, notamment pour les cartes bancaires ou les cartes Monéo.
Plus directement, les cartes RFID sont présentes sur le campus de Lille 1, pour le paiement des repas au Restaurant Universitaire, ou pour l'ouverture de portes sécurisées.
Leurs fiabilité est donc un enjeu crucial. Il existe cependant des techniques de hackage de ces cartes : http://www.youtube.com/watch?v=7BQDgPMF_fo
Objectif :
L'objectif de ce PFE est d'étudier la vulnérabilité de ces cartes sans contacts, et de trouver un moyen de renforcer leur sécurité.
Ennoncé :
En utilisant des systèmes Proxmark 3 (http://proxmark3.com/index.html) vous commencerez par une simple copie de carte MiFare. Cela vous permettra de prendre en main l'environnement. Vous travaillerez ensuite sur les différents aspects suivants : - Amélioration des antennes pour permettre la capture de cartes à "longues distance" (entre 2 et 10 m) - Packaging de l'appareil et des nouvelles antennes dans un sac à dos - Description de procédures de mise en oeuvre automatique - Mise en place de contre-mesure Quelques liens : http://bigbrotherawards.eu.org/Le-GIE-cartes-bancaires https://code.google.com/p/readnfccc/source/browse/#svn%2Ftrunk%2FNFCCreditCardTool
Journal de bord
17/09/2013
Discussions avec nos encadrants pour développer les grands enjeux de ce projet. LF = Low Frequency (125 kHz, 132.5 kHz) HF = High Frequency (13.56 MHz) UHF = Ultra High Frequency (860 MHZ, 960 MHz)
18/09/2013
24/09/2013
25/09/2013
Note : les cartes de cantines sont a utilisé avec l'antenne HF
Procédure : brancher la proxmark3 sans antenne, hw tune puis brancher l'antenne hw tune
puis hf 14b read (pour une carte du CROUS)
Commande pour regarder si des secteurs utilisent la clef du fabriquant : "hf mf chk *1 ? t"
Si le secteur 0 utilise la clef X, lancer la commande : "hf mf nested 0 1 A X d" Cette commande lance une attaque de type "Nested Attack"; Puisqu'on connait une clef (celle du bloc 0 par exemple), cette commande va nous permettre de connaitre les clefs des autres secteurs et donc de découvrir les données de la carte.
Ensuite pour créer un fichier bin contenant les data, il faut lancer la commande : "hf mf dump", qui va en associant les clefs aux blocs concernés, créer un fichier contenant les données.
Pour lire ces datas, il faut utiliser le logiciel HxD
17/10/2013
Aujourd'hui, en cherchant à copier une carte sur une autre nous avons trouvé la commande "hf mf restore" qui nous a permis d'effacer une carte. La commande "hf mf wrbl" doit permettre d'écrire un block de données sur une carte, si on connait le numéro du block et ses clés. Nous pourrons peut-être écrire un script exploitant cette commande afin de copier l'ensemble d'une carte sur une autre.
Partie 1 : Hack des données
Contenu de la carte
Voici les données cryptées et non cryptée présentent sur la carte étudiant :
Comparaison après rechargement
Ici la comparaison des données de la carte avant et après rechargement.
On observe que seules 3 lignes sont partiellement modifiées (surlignée en rouge)
Documentation
[CEPS Technical Specification]
Partie 2 : Analyse des données
Après une dizaine de relevés à la suite de chargements et d'utilisation de la carte CROUS, nous pouvons affirmer que dans le document suivant :
=> Les bytes encadrés en vert sont des bytes qui sont succeptibles de changer après un échange => Les bytes encadrés en rouge changent systématiquement après échange
Partie 3 : Sniff de l'échange entre une carte NFC et la borne des portes
Pour ce faire on a utilisé les commandes "hf 14a snoop" pour sniffer et enregistrer l'échange "hf 14a list" pour avoir accès à l'enregistrement
proxmark3> hf 14a snoop
- db# cancelled by button
- db# maxDataLen=3, Uart.state=0, Uart.byteCnt=1
- db# Uart.byteCntMax=20, traceLen=12d, Uart.output[0]
proxmark3> hf 14a list recorded activity:
ETU :rssi: who bytes
+----+----+-----------
+ 0: 0: TAG 02 + 152797: 0: TAG 00! + 289126: 0: TAG 02 + 147123: 0: TAG 01 + 147462: 0: TAG 05! + 147290: 0: TAG 02 + 441954: 0: TAG 02 + 441954: 0: TAG 02 + 531882: 0: TAG 04 00 + 746: 0: TAG 4e 46 7e 16 60 + 2048: 0: TAG 08 b6 dd + 120402: 0: TAG 02 + 21846: 0: TAG 04 00 + 744: 0: TAG 4e 46 7e 16 60 + 2052: 0: TAG 08 b6 dd + 142234: 0: TAG 04 00 + 746: 0: TAG 4e 46 7e 16 60 + 2048: 0: TAG 08 b6 dd + 142220: : 26 + 4752: : 26 + 142579: : 26 + 4751: : 26 + 142578: : 26 + 4750: : 26 + 142576: : 26 + 4752: : 26 + 142579: : 26 + 4751: : 26
ATQA+UID+SAK = 0004 4e467e16 08: On a donc retrouvé l'UID de la carte NFC qui vaut 4e467e16
L'ETU : elementary time unit (ETU) est la durée nominale des bits utilisés dans la trame
Le "rssi" est l'intensité du signal, il reste à 0. Nous avons contacté des développeurs de Proxmark qui nous ont confirmé que c'était le même cas pour eux et qu'il ne fallait pas en tenir compte.
Les échanges au début de l'enregistrement ne signifient rien et ils ne sont pas à prendre en compte.
Dans ce cas, l'antenne de la Proxmark était placée à moins de 5 cms de l'échange, Le but étant de pouvoir faire ce genre d'opération à au moins 1 mètre.
/!\ TWIKI EN COURS DE MISE A JOURS /!\