Hack NFC - Proxmark3 : Différence entre versions
(→Partie 3 : Sniff de l'échange entre une carte NFC et la borne des portes) |
(→Journal de bord) |
||
| Ligne 23 : | Ligne 23 : | ||
17/09/2013 | 17/09/2013 | ||
| − | Discussions avec nos encadrants pour | + | Discussions avec nos encadrants pour comprendre les enjeux du projet. |
| + | Prise en main du système Proxmark3, et essais de différents logiciels. | ||
| + | L'utilitaire proxmark3 (Client Software) peut être téléchargé à cette addresse: "proxmark3.com/downloads.html". Il contient les pilotes pour permettre à un système Windows de reconaitre le matériel, ainsi que le logiciel client Proxmark3 qui permet de communiquer avec le périphérique grâce à une invite de commandes. | ||
LF = Low Frequency (125 kHz, 132.5 kHz) | LF = Low Frequency (125 kHz, 132.5 kHz) | ||
HF = High Frequency (13.56 MHz) | HF = High Frequency (13.56 MHz) | ||
UHF = Ultra High Frequency (860 MHZ, 960 MHz) | UHF = Ultra High Frequency (860 MHZ, 960 MHz) | ||
| + | Essais de lecture d'une carte RFID. | ||
| − | + | 04/10/2013 | |
| + | Première lecture d'une carte monéo, grâce à l'antenne HF. | ||
| + | Commande "hf mf chk *1 ? t" pour tenter l'acces aux blocks de la carte en utilisant des clefs de base. | ||
| + | Si le secteur X utilise la clef Y, la commande : "hf mf nested X 1 A Y d" permet de cracker l'ensemble des clés de la carte, et de les enregistrer dans un fichier "dumpkeys.bin". | ||
| + | La commande "hf mf dump" permet ensuite de lire l'ensemble des blocks de la carte, et les enregistre dans le fichier "dumpdata.bin". | ||
| − | + | Les données lues peuvent être observées facilement avec le logiciel HxD. Si on veut comparer deux relevés, le logiciel HexCmp sera plus pratique. | |
| + | Voici les données présentes sur la carte Monéo utilisée : | ||
| + | [[Fichier:30.17 euros.png|200px|thumb|left|Relevé d'une carte Monéo]] | ||
| − | + | Les données sont écrites sous forme hexadécimale sur la carte, et sont traduites par le logiciel. Certaines données sont compréhensible, comme le nom ou le numéro d'étudiant, mais la plupart des données sont cryptées. | |
| − | |||
| − | + | 17/10/2013 | |
| − | + | ||
| − | + | Découverte de la commande "hf mf wrbl" permettant d'écrire un block de données sur une carte, et de la commande "hf mf restore" permettant de restaurer les données sur une carte à l'aide d'un ancien relevé. | |
| − | + | ||
| − | + | Pendant le mois d'octobre, nous avons effectué de nombreux relevés d'une carte Monéo étant utilisée régulièrement pour le paiement de repas. | |
| + | Nous avons pu effectuer de nombreuses comparaisons comme la suivante, en effectuant un relevé avant et un relevé après le paiement d'un repas de 3.15€. | ||
| − | + | [[Fichier:Comparaison_gauche_30,17e_droite_33,32e.png|200px|thumb|left|Gauche: 30,17 euros, Droite: 33,32 euros]] | |
| − | + | Les secteurs surlignés sont ceux qui sont modifiés, on remarque que peu de secteurs sont modifiés lors de ce prélèvement. | |
| − | |||
| − | |||
| − | + | Comme représenté ci-dessous, une dizaine de relevés différents nous a permis de repérer les secteurs qui ne sont jamais modifiés, ceux qui le sont parfois (encadrés en vert) et ceux qui le sont toujours (encadrés en rouge). | |
| − | |||
| − | + | [[Fichier:Elements modifiés après échange (48 euros 67).png |200px|thumb|left|Relevé de la carte CROUS contenant 48,67€, avec en rouge les bytes qui changent systématiquement et en vert ceux susceptibles de changer]] | |
| − | |||
| − | + | 6/11/2013 | |
| − | + | ||
| + | Recherches sur l'organisation des données dans sur une carte. Le fichier [[MF1ICS50FunctSpec.pdf]] nous a aidé dans cette recherche. | ||
| + | Nous avons compris que chacune de nos cartes est constituée de 16 secteurs de données. Chaque secteur est constitué de 4 blocks, chaque block étant lui constitué de 16 paires d'octets. | ||
| + | Sur nos relevés, chaque ligne constitue un block. | ||
| + | Le dernier block de chaque secteur gère les autorisations d'accès à ce secteur. Il peut être représenté sous la forme suivante: | ||
| + | AA AA AA AA AA AA KK KK KK XX BB BB BB BB BB BB ou les 12 premiers octets constituent la clé A, les 6 suivants les conditions d'accès et les 12 derniers la clé B. | ||
| + | L'accès à chaque secteur est donc contrôlé par deux clefs, et les conditions d'accès qui définissent si un block peut être lu, s'il peut être écrit, et avec quelle clé. L'interprétation des 6 octets de conditions d'accès peut être faite grâce au logiciel MiFaRe Acces Conditions téléchargeable ici: http://www.sendspace.com/file/o3frc9 | ||
| + | Sur une carte, tous les blocks dont l'adresse se termine par 3,7,B ou F sont donc réservés aux droits d'accès. Il est donc nécessaire de porter une attention particulière à la modification de ces blocks, car en fonction des autorisations attribuées un secteur peut être interdit en lecture, et dans ce cas il ne sera plus du tout utilisable, et ni modifiable. | ||
| + | |||
| + | D'autre part il est important de noter que les 12 premiers octets de chaque carte représentent l'identifiant de la carte, (4E 46 7E 16 60 88 sur la carte utilisée ici) et qu'ils ne sont pas modifiables (mis à part pour certaines cartes MFC chinoise destinées à ce genre d'opération). | ||
| + | |||
| + | Après avoir compris tout cela nous avons pu copier les données de la carte Monéo sur une autre carte MFC, exactement à l'identique, mis à part pour l'identifiant de la carte. Cependant, lors d'un essai de paiement avec cette autre carte, il y a eu une erreur, la carte n'étant pas reconnue du fait de son identifiant. | ||
= Partie 1 : Hack des données = | = Partie 1 : Hack des données = | ||
Version du 28 novembre 2013 à 11:36
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 comprendre les enjeux du projet. Prise en main du système Proxmark3, et essais de différents logiciels. L'utilitaire proxmark3 (Client Software) peut être téléchargé à cette addresse: "proxmark3.com/downloads.html". Il contient les pilotes pour permettre à un système Windows de reconaitre le matériel, ainsi que le logiciel client Proxmark3 qui permet de communiquer avec le périphérique grâce à une invite de commandes. LF = Low Frequency (125 kHz, 132.5 kHz) HF = High Frequency (13.56 MHz) UHF = Ultra High Frequency (860 MHZ, 960 MHz) Essais de lecture d'une carte RFID.
04/10/2013
Première lecture d'une carte monéo, grâce à l'antenne HF.
Commande "hf mf chk *1 ? t" pour tenter l'acces aux blocks de la carte en utilisant des clefs de base. Si le secteur X utilise la clef Y, la commande : "hf mf nested X 1 A Y d" permet de cracker l'ensemble des clés de la carte, et de les enregistrer dans un fichier "dumpkeys.bin". La commande "hf mf dump" permet ensuite de lire l'ensemble des blocks de la carte, et les enregistre dans le fichier "dumpdata.bin".
Les données lues peuvent être observées facilement avec le logiciel HxD. Si on veut comparer deux relevés, le logiciel HexCmp sera plus pratique.
Voici les données présentes sur la carte Monéo utilisée :
Les données sont écrites sous forme hexadécimale sur la carte, et sont traduites par le logiciel. Certaines données sont compréhensible, comme le nom ou le numéro d'étudiant, mais la plupart des données sont cryptées.
17/10/2013
Découverte de la commande "hf mf wrbl" permettant d'écrire un block de données sur une carte, et de la commande "hf mf restore" permettant de restaurer les données sur une carte à l'aide d'un ancien relevé.
Pendant le mois d'octobre, nous avons effectué de nombreux relevés d'une carte Monéo étant utilisée régulièrement pour le paiement de repas.
Nous avons pu effectuer de nombreuses comparaisons comme la suivante, en effectuant un relevé avant et un relevé après le paiement d'un repas de 3.15€.
Les secteurs surlignés sont ceux qui sont modifiés, on remarque que peu de secteurs sont modifiés lors de ce prélèvement.
Comme représenté ci-dessous, une dizaine de relevés différents nous a permis de repérer les secteurs qui ne sont jamais modifiés, ceux qui le sont parfois (encadrés en vert) et ceux qui le sont toujours (encadrés en rouge).
.png)
6/11/2013
Recherches sur l'organisation des données dans sur une carte. Le fichier MF1ICS50FunctSpec.pdf nous a aidé dans cette recherche. Nous avons compris que chacune de nos cartes est constituée de 16 secteurs de données. Chaque secteur est constitué de 4 blocks, chaque block étant lui constitué de 16 paires d'octets. Sur nos relevés, chaque ligne constitue un block. Le dernier block de chaque secteur gère les autorisations d'accès à ce secteur. Il peut être représenté sous la forme suivante: AA AA AA AA AA AA KK KK KK XX BB BB BB BB BB BB ou les 12 premiers octets constituent la clé A, les 6 suivants les conditions d'accès et les 12 derniers la clé B. L'accès à chaque secteur est donc contrôlé par deux clefs, et les conditions d'accès qui définissent si un block peut être lu, s'il peut être écrit, et avec quelle clé. L'interprétation des 6 octets de conditions d'accès peut être faite grâce au logiciel MiFaRe Acces Conditions téléchargeable ici: http://www.sendspace.com/file/o3frc9 Sur une carte, tous les blocks dont l'adresse se termine par 3,7,B ou F sont donc réservés aux droits d'accès. Il est donc nécessaire de porter une attention particulière à la modification de ces blocks, car en fonction des autorisations attribuées un secteur peut être interdit en lecture, et dans ce cas il ne sera plus du tout utilisable, et ni modifiable.
D'autre part il est important de noter que les 12 premiers octets de chaque carte représentent l'identifiant de la carte, (4E 46 7E 16 60 88 sur la carte utilisée ici) et qu'ils ne sont pas modifiables (mis à part pour certaines cartes MFC chinoise destinées à ce genre d'opération).
Après avoir compris tout cela nous avons pu copier les données de la carte Monéo sur une autre carte MFC, exactement à l'identique, mis à part pour l'identifiant de la carte. Cependant, lors d'un essai de paiement avec cette autre carte, il y a eu une erreur, la carte n'étant pas reconnue du fait de son identifiant.
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 /!\
