LORAWAN la sécurité est compromise.
Une nouvelle recherche d’IOActive a révélé que faire confiance «aveuglément» au chiffrement du protocole de l’appareil largement adopté peut conduire à des DDoS, à l’envoi de fausses données et à d’autres cyberattaques.
(…)
En réalité, les chercheurs ont découvert que les clés de chiffrement LoRaWAN sont facilement obtenues par un pirate averti pour mener des attaques DDoS et envoyer de fausses données aux réseaux. De plus, il est actuellement impossible pour les organisations de savoir si un réseau LoRaWAN est attaqué ou si une clé de chiffrement a été compromise, ce qui rend la défense de ces attaques périlleuse, ont-ils déclaré.
En effet, c’est la perception que LoRaWAN est intrinsèquement sécurisé qui le rend si dangereux, a noté Cesar Cerrudo, CTO chez IOActive, l’auteur principal du rapport, «Les réseaux LoRaWAN sensibles au piratage: problèmes de cybersécurité courants, comment les détecter et les prévenir. «
« Le protocole LoRaWAN est annoncé comme ayant un » cryptage intégré « le rendant » sécurisé par défaut « , écrit-il dans le rapport. «En conséquence, les utilisateurs font aveuglément confiance aux réseaux LoRaWAN et ne prêtent pas attention à la cybersécurité; cependant, les problèmes de mise en œuvre et les faiblesses peuvent rendre ces réseaux faciles à pirater. »
Dans la version 1.0. du protocole, quatre éléments clés façonnent une implémentation LoRaWAN.
Le protocole LoRaWAN définit deux couches de sécurité: une au niveau du réseau et une au niveau de l’application, ont décrit les chercheurs dans le rapport.
La sécurité au niveau du réseau garantit l’authenticité de l’appareil dans le réseau, assurant l’intégrité entre l’appareil et le serveur réseau, ont-ils écrit. La sécurité de la couche application est responsable de la confidentialité avec un cryptage de bout en bout entre l’appareil et le serveur d’applications, empêchant les tiers d’accéder aux données d’application transmises.
Chaque couche de protection dépend de la sécurité de deux clés de chiffrement – la clé de session réseau (NwkSKey) et la clé de session d’application (AppSKey), qui ont toutes deux une longueur de 128 bits. Ces clés sont «la source du seul mécanisme de sécurité du réseau, le chiffrement», et ainsi, une fois piratées, elles invitent fondamentalement les pirates aux appareils et réseaux protégés par eux, ont noté les chercheurs.
Touches et fonctions de session dans LoRaWAN v1.0.3
Le problème avec cette architecture est que les clés sont étonnamment faciles à obtenir pour les personnes qui ne sont pas censées avoir accès au réseau ou aux appareils, ont découvert les chercheurs, qui décrivent de nombreuses façons dont les mauvais acteurs peuvent obtenir les clés des réseaux LoRaWAN.
Ces méthodes comprennent: l’utilisation de l’ingénierie inverse pour «renifler» les clés des périphériques; obtenir des clés à partir de balises de périphérique affichant le code que les administrateurs ont oublié de supprimer avant qu’un périphérique ne soit placé à son emplacement final; voler le code source d’un appareil dans des référentiels open source ou des sites Web de fournisseurs; deviner les clés qui montrent un manque d’aléatoire suffisant; ou casser un réseau avec des informations d’identification par défaut ou faibles ou d’autres vulnérabilités de sécurité et voler les clés de ces serveurs.
Les pirates peuvent également obtenir des clés de chiffrement sur les réseaux LoRaWAN en compromettant le système du fabricant de l’appareil responsable de l’installation du micrologiciel avec les clés de l’appareil; piratage des appareils ou des ordinateurs des techniciens chargés du déploiement des appareils sur lesquels les clés pourraient être stockées; obtenir les clés des clés USB ou des e-mails des clients ou des fabricants d’appareils où elles ont été divulguées et partagées; violer un fournisseur de services qui avait des clés stockées dans leurs sauvegardes ou bases de données; ou obtenir une AppKey dans un dictionnaire ou une attaque par force brute, ont écrit les chercheurs.
AppKey Cracking avec JoinRequest et JoinAccept
Une fois que les mauvais acteurs obtiennent les clés de chiffrement d’un réseau LoRaWAN, ils disposent d’un certain nombre d’options d’attaque «pour compromettre la confidentialité et l’intégrité des données circulant vers et depuis les appareils connectés», ont écrit les chercheurs d’IOActive. Il s’agit notamment de mener des attaques DDoS qui peuvent perturber les communications entre les appareils connectés et le serveur réseau afin que les entreprises ne puissent recevoir aucune donnée.
Les attaquants peuvent également utiliser les touches pour intercepter les communications et les remplacer par de fausses données, telles que de faux capteurs et des relevés de compteur. De cette façon, les mauvais acteurs peuvent cacher une activité malveillante ou causer des dommages aux équipements industriels, ce qui pourrait non seulement perturber l’entreprise mais potentiellement détruire les infrastructures ou les installations si cela se produit dans une centrale électrique ou à l’emplacement d’autres infrastructures critiques, selon les chercheurs. .
Le potentiel de ces attaques est particulièrement troublant car les entreprises n’ont aucun moyen de les détecter actuellement, ont noté les chercheurs. Pour aider à résoudre ce problème, IOActive a publié un cadre d’audit LoRaWAN sur GitHub pour aider les administrateurs de sécurité à auditer et à tester la sécurité de leurs implémentations LoRaWAN.
Surtout, les chercheurs recommandent à ceux qui mettent en œuvre des réseaux LoRaWAN de faire de la protection des clés de sécurité une priorité absolue dans la sécurité de leurs implémentations. Pour ce faire, vous pouvez facilement remplacer les clés fournies par les fournisseurs par des clés aléatoires; utiliser différentes clés pour différents appareils; auditer les clés racine utilisées pour détecter les clés faibles; et en veillant à ce que les fournisseurs de services suivent les meilleures pratiques de sécurité et disposent d’une infrastructure sécurisée, ont-ils déclaré.
[NDLR] Pour la version LORA 1.0 attention également à la non reception de l’ACK de la gateway par l’objet qui provoque une boucle dans le code de l’objet en l’absence de watchdog
Source
