Carte ou visage: différences fondamentales
L'algorithme de fonctionnement d'un système de contrôle d'accès classique ressemble à ceci:
- la personne apporte la carte au lecteur;
- le lecteur reçoit le numéro de carte et l'envoie au serveur;
- le serveur vérifie les autorisations pour cette clé et, si l'accès est autorisé, renvoie l'état "OK";
- .
Si nous appliquons cet algorithme, en remplaçant le numéro de carte par une image de visage, une apocalypse locale s'ensuivra, car l'image est beaucoup plus grande que le numéro de carte. Cela signifie que son transfert vers le serveur prendra plus de temps et que la correspondance des images dans la base de données sur le serveur est bien plus que la recherche du numéro de clé. S'il y a beaucoup d'employés au bureau qui bougent constamment, il y a une probabilité non nulle que vous deviez sourire à la serrure en attendant que la porte s'ouvre pendant plusieurs minutes.
Pour éviter cela, au lieu d'une simple caméra IP, ils utilisent un appareil intelligent suffisamment puissant pour la reconnaissance faciale, et la base de données des visages est stockée sur l'appareil. Habituellement, un tel appareil est un puissant gadget Android ou un PC compact exécutant Windows ou Linux.
Dans ce cas, le serveur central est utilisé pour synchroniser les bases de données des visiteurs, mettre à jour le logiciel du lecteur et administrer l'ensemble du système.
Le déplacement de la charge de traitement du serveur vers le bord externe élimine le besoin d'envoyer des données sensibles telles que des images pour le traitement. Le temps de réponse devient acceptable et les besoins en bande passante sont réduits.
Cependant, en plus de la puissance de traitement, d'autres tâches se déplacent vers les nœuds périphériques. Ce changement ajoute deux problèmes notables:
- aux nœuds frontières, en plus des opérations primitives de lecture d'une carte et d'ouverture d'une porte, s'ajoute une logique métier à part entière, source de vulnérabilité potentielle;
- , .
Nous voulons aussi être dans le futur le plus tôt possible, où il suffit de sourire au tourniquet pour acheter un billet, mais nous considérons qu'il est nécessaire d'exclure la situation où quelqu'un d'autre a souri et que l'argent vous a été débité.
Comme le montre notre étude Identified and Authorized: Sneaking Past Edge-Based Access Control Devices , les systèmes de contrôle d'accès basés sur le visage présentent de nombreuses vulnérabilités désagréables: ils peuvent être piratés, trompés, présentés avec une photo d'une personne sur l'écran de l'iPhone au lieu du visage d'une personne, et même devenir administrateur et supprimés. tous les patrons de la liste des admis dans les locaux.
Considérez l'un des appareils les plus vulnérables de notre étude - ZKTeco FaceDepot 7B
Système de contrôle d'accès ZKTeco FaceDepot. Source: Trend Micro
L'appareil est livré dans un boîtier métallique robuste avec un écran et une caméra frontale orientée vers le visiteur. La reconnaissance faciale a lieu à l'intérieur de l'appareil. Les photos prises lors de l'authentification ne sont pas envoyées au serveur central - la puissance du processeur de la tablette est tout à fait suffisante pour effectuer la reconnaissance seule.
Un déploiement typique de ZKTeco FaceDepot ACS comprend plusieurs de ces appareils et un serveur central à travers lequel la base d'utilisateurs est synchronisée entre les appareils.
Port USB non sécurisé
Le boîtier métallique protège l'ACS des interférences physiques, mais le port USB ouvert au bas de l'appareil gâche tout. Il est conçu pour réparer l'appareil.
Vulnérabilité n ° 1 - port USB ouvert. Source: Trend Micro
Version Android obsolète
Une autre vulnérabilité mondiale de ZKTeco est le micrologiciel de l'appareil, basé sur Android Lollipop 5.1.1, publié en avril 2016. Aujourd'hui, la version actuelle d'Android est la dixième. Au fil des ans, le système d'exploitation a reçu de nombreuses améliorations liées à la sécurité. Évidemment, dans la cinquième version, rien de tel n'est prévu.
Écran avec version Android sur ZKTeco FaceDepot SKD. Source: Trend Micro
La possibilité d'installer des packages APK
Puisqu'il s'agit d'Android, l'utilisateur peut accéder à l'écran d'accueil et lancer l'application. Par exemple, il peut lancer ApkInstaller et installer n'importe quel package APK Android à partir d'un support connecté à un port USB.
Installateur APK fonctionnant sur ACS. Source: Trend Micro
Le fabricant du périphérique a limité la possibilité d'accéder aux menus et aux applications uniquement pour les utilisateurs disposant de droits d'administrateur, mais comme une enquête plus approfondie sur le périphérique l'a montré, ce n'est pas un problème, car le périphérique communique toujours avec le serveur et le fait via HTTP.
Échange non chiffré avec le serveur
L'appareil communique avec le serveur via HTTP. Toutes les informations sont transmises en texte clair et peuvent être facilement interceptées. Pire encore, les commandes administratives sont transmises en texte clair - enregistrement de l'utilisateur, attribution d'un rôle d'administrateur à un utilisateur, suppression d'un utilisateur et synchronisation.
Un attaquant qui accède au réseau auquel la tablette est connectée pourra écouter le trafic réseau entre l'ACS et le serveur et obtenir les informations nécessaires pour mener des attaques.
Malheureusement, les développeurs de l'appareil ont réussi à renforcer davantage la vulnérabilité associée au manque de cryptage des données: ils ont effectué une procédure d'authentification de l'appareil complètement fuyante.
Authentification des appareils vulnérables
Le seul signe de la légitimité d'un appareil sur le serveur est le jeton qui est passé dans le cookie. Le jeton est installé lorsque l'appareil est enregistré pour la première fois sur le serveur et, selon nos données, ne change jamais.
La valeur du jeton est stockée sous forme de cookie. Source: Trend Micro
Étant donné que le jeton "secret" est transmis en texte clair, tout client HTTP peut se faire passer pour un ACS légitime. Dans nos expériences, nous avons utilisé curl, un simple utilitaire de ligne de commande.
Par exemple, voici comment nous avons enregistré un nouvel utilisateur dans le système et défini une image pour lui:
La première commande enregistre un utilisateur avec le nom Bogus sur le serveur, la seconde définit une photo pour lui. Source: Trend Micro
Le fichier userdata.post contient les données que nous avons envoyées au serveur via POST. Dans notre cas, le fichier contient les données suivantes: Contenu du fichier image
à envoyer au serveur. Source: Trend Micro
Enregistrer un administrateur avec curl
Un administrateur existant peut promouvoir un nouvel utilisateur en tant qu'administrateur à l'aide de la console de l'appareil. L'administrateur actuel doit d'abord se connecter à l'appareil via la reconnaissance faciale, puis accéder à la console système pour démarrer le processus de promotion. Dès que l'utilisateur est promu au niveau administrateur, l'appareil envoie un rapport au serveur, l'informant du changement d'état.
Mais comme tout utilisateur qui possède le jeton peut simuler un trafic réseau légitime entre l'appareil et le serveur, rien ne l'empêche d'exécuter la commande suivante et de faire de n'importe quel utilisateur un administrateur: La
définition de privilège = 14 fait de l'utilisateur un administrateur. Source: Trend Micro
Après la prochaine synchronisation du serveur et de tous les périphériques ACS enregistrés sur celui-ci, le nouvel administrateur sera reconnu dans tout le réseau du bureau.
Télécharger toutes les photos des utilisateurs
Les URL des photos stockées sur le serveur sont prévisibles, donc lister toutes les URL et télécharger les photos est un jeu d'enfant. Aucune authentification n'est requise pour accéder à ces URL.
Par exemple, à l'URL suivante, le serveur enverra une photo d'un utilisateur avec l'ID «11111»:
Pour collecter des images, vous pouvez créer un script simple qui itérera sur les ID d'utilisateur de «00000» à n'importe quel nombre et téléchargera toutes les photos disponibles dans le système.
Fausse injection de serveur
Étant donné que toutes les communications entre l'appareil et le serveur se font via HTTP, il est relativement facile de rediriger tous les appareils CA vers un faux serveur en utilisant l'empoisonnement ARP (Address Resolution Protocol).
Après avoir forcé l'appareil cible à communiquer avec notre faux serveur, nous avons pu envoyer à l'appareil les mises à jour dont nous avions besoin pendant l'une de ses sessions de synchronisation régulières. Cette technique peut être utilisée pour une variété d'attaques. Par exemple, vous pouvez glisser des terminaux avec une photo d'un utilisateur pour lequel vous souhaitez organiser un accès illégal aux locaux d'une entreprise.
Accès par photo d'un visiteur légal
Compte tenu du nombre d'options d'attaque possibles, tester cette méthode était déjà un peu exagéré. Mais compte tenu de la simplicité et de la disponibilité d'une telle attaque même pour une personne éloignée de la technologie, nous avons néanmoins vérifié s'il serait possible de tromper l'ACS en utilisant une photographie d'une personne inscrite dans le système ayant accès au bureau. Et ils ont été très surpris quand, après avoir traversé plusieurs options, l'attaque a fonctionné: la caméra ZKTeco FaceDepot s'est avérée soutenir les photos affichées sur l'iPhone X et l'iPhone XS, mais a refusé de rater la même photo sur l'écran des smartphones iPhone 6, Samsung A10, Samsung S8, Samsung S9 , Samsung S10, Samsung S10 + et Samsung Note 10.
Recommandations aux fabricants
Le dispositif de contrôle d'accès ZKTeco FaceDepot n'est pas le seul testé dans notre étude. Malheureusement, d'autres appareils contenaient également de sérieuses vulnérabilités qui jettent de sérieux doutes sur la possibilité de les utiliser pour créer un périmètre véritablement sécurisé d'accès physique aux locaux de l'entreprise.
Toutes les vulnérabilités trouvées dans les appareils sont incluses dans le Top 10 des risques de sécurité des applications Web , compilé par le projet OWASP:
- pas de cryptage par défaut et désactivation du cryptage côté serveur;
- système d'authentification et de gestion de session vulnérable;
- versions de système d'exploitation obsolètes.
Pour rendre les dispositifs de contrôle d'accès plus sûrs, les fabricants doivent suivre ces directives:
- — , ;
- ;
- — USB- ;
- , .