Bonjour à tous. Je vais commencer par vous donner un peu de contexte sur ce qui m'a poussé à mener cette recherche, mais avant cela, je tiens à avertir : toutes les actions pratiques ont été réalisées avec l'accord des structures de gestion. Toute tentative d'utiliser ce matériel pour pénétrer sur un territoire fermé sans droit d'y être est considérée comme une infraction pénale.
Tout a commencé lorsque, en rangeant mon bureau, j'ai accidentellement placé la clé RFID de l'entrée sur le lecteur NFC ACR122 — quelle ne fut pas ma surprise lorsque Windows a émis un son de détection d'un nouvel appareil et que le voyant s'est allumé en vert. Jusqu'à ce moment-là, je pensais que ces clés fonctionnaient exclusivement selon le standard Proximity.
Mais puisque le lecteur l'a détectée, cela signifie que la clé répond à l'un des protocoles au-dessus du standard ISO 14443 (également connu sous le nom de Near Field Communication, 13,56 MHz). J'ai rapidement oublié le nettoyage, car j'ai vu une opportunité de me débarrasser complètement de mes clés et de garder la clé de l'entrée sur mon téléphone (mon appartement est déjà équipé d'une serrure électronique). En me plongeant dans l'étude, j'ai découvert qu'une étiquette NFC Mifare 1k se cachait sous le plastique — le même modèle utilisé dans les badges d'entreprise, les cartes de transport, etc. Mes premières tentatives pour accéder au contenu des secteurs n'ont pas été fructueuses, et lorsque j'ai finalement réussi à craquer la clé, j'ai découvert que seul le 3ème secteur était utilisé, et qu'y était dupliqué l'UID de la puce elle-même. Cela semblait trop simple, et il n'y aurait pas d'article si tout s'était passé exactement comme prévu. J'avais désormais les entrailles de la clé, et il n'y avait aucun problème pour copier la clé sur une autre identique. Mais l'objectif était de transférer la clé sur un appareil mobile, ce à quoi je me suis donc attelé. C'est là que les choses ont commencé à devenir intéressantes — j'avais un téléphone — iPhone SE avec installé iOS 13.4.5 Beta build 17F5044d et certains composants personnalisés pour faire fonctionner le NFC librement — je ne vais pas m'attarder sur ce point pour des raisons objectives. Si vous le souhaitez, tout ce qui suit est également applicable au système Android, mais avec certaines simplifications.
Liste des tâches à accomplir :
- Accéder au contenu de la clé.
- Mettre en œuvre la possibilité d'émuler la clé par l'appareil.
Si la première version était relativement simple, j'ai rencontré des problèmes avec la seconde. La première version de l'émulateur n'a pas fonctionné. Le problème a été rapidement identifié : sur les appareils mobiles (tant iOS qu'Android) en mode émulation, l'UID est dynamique et, peu importe ce qui est intégré dans l'image, il varie. La seconde version (exécutée avec des droits de superutilisateur) fixait de manière stricte le numéro de série choisi - la porte s'ouvrait. Cependant, je voulais que tout soit parfait et j'ai finalement assemblé une version complète de l'émulateur capable d'ouvrir des dumps Mifare et de les émuler. Sous l'effet d'un élan soudain, j'ai modifié les clés des secteurs en des valeurs arbitraires et j'ai tenté d'ouvrir la porte. Et elle... S'EST OUVERTE ! Après un certain temps, j'ai compris que s'ouvraient n'importe quelles portes avec cette serrure, même celles pour lesquelles la clé d'origine ne fonctionnait pas. En conséquence, j'ai dressé une nouvelle liste de tâches à accomplir :
- Déterminer quel contrôleur gère les clés
- Comprendre s'il y a une connexion au réseau et une base de données commune
- Découvrir pourquoi une clé en fait illisible devient universelle
Après avoir discuté avec un ingénieur de la société de gestion, j'ai appris que des contrôleurs simples Iron Logic z5r sont utilisés sans connexion à un réseau externe.
Lecteur CP-Z2 MF et contrôleur IronLogic z5r
On m'a remis un kit de matériel pour les expériences :
Comme on peut le comprendre ici - le système est entièrement autonome et extrêmement primitif. Au début, j'ai pensé que le contrôleur était en mode d'apprentissage - le principe étant qu'il lit la clé, l'enregistre en mémoire et ouvre la porte - ce mode est utilisé lorsque toutes les clés doivent être enregistrées, par exemple lors du remplacement d'une serrure dans un immeuble. Mais cette théorie ne s'est pas confirmée - ce mode est désactivé par logiciel, le cavalier est en position de fonctionnement - et pourtant, lorsque l'appareil est approché, nous voyons ce qui suit :
Capture d'écran du processus d'émulation sur l'appareil
… et le contrôleur signale que l'accès est accordé.
Cela signifie que le problème réside dans le logiciel soit du contrôleur, soit du lecteur. Vérifions le lecteur - il fonctionne en mode iButton, donc nous allons connecter la carte de sécurité Bolid - nous aurons la possibilité d'examiner les données de sortie du lecteur.
La carte sera connectée plus tard via RS232
En utilisant la méthode de plusieurs essais, nous découvrons que le lecteur transmet le même code en cas d'échec d'autorisation : 1219191919
La situation commence à s'éclaircir, mais à ce stade, je ne comprends pas pourquoi ce code est positivement répondu par le contrôleur. Il y a une hypothèse — que lors du remplissage de la base de données, une carte avec d'autres clés de secteur ait été accidentellement ou spécifiquement approchée — le lecteur a envoyé ce code et le contrôleur l'a enregistré. Malheureusement, je ne dispose pas du programmateur officiel de IronLogic pour examiner la base de clés du contrôleur, mais j'espère avoir attiré l'attention sur le fait que le problème existe. Une démonstration vidéo de cette vulnérabilité est disponible. .
P.S. Contre la théorie de l'ajout aléatoire, le fait qu'il m'a également été possible d'ouvrir la porte de cette manière dans un centre d'affaires à Krasnoïarsk militent.
Source : habr.com
