Implementation flaws make LoRaWAN networks vulnerable to attack
LoRaWAN, a long-range wireless communications technology for low-powered devices such as sensors, has been gaining popularity worldwide in smart city, industrial internet of things (IioT) and smart home projects. Even though the protocol uses built-in encryption, implementation errors are common, and they enable attacks that are hard to detect.
In a new paper published today, researchers from security consultancy firm IOActive highlight the type of mistakes commonly made by device manufacturers, network operators and users when building and deploying LoRaWAN devices as well as the risks associated with those errors. To help combat the issues, the researchers developed and released an open-source framework that can be used to audit such networks.
What is LoRaWAN and how does it work?
LoRaWAN is a communications protocol that allows low-power devices to exchange data with Internet-enabled applications over long-range (LoRa) wireless connections that travel many miles and are not using the licensed wireless spectrum. This makes LoRaWAN a low-cost solution for IIoT networks when compared to cellular technologies that require more expensive components, such as cellular modems, and are regulated.
LoRaWAN has many applications from automating parking, lighting and traffic management in cities, to weather monitoring, automated electricity meter reading, asset tracking, climate control, alarm systems, home automation, smart agriculture and more. According to the LoRa Alliance, the non-profit technology association that oversees the protocol, there are currently LoRaWAN deployments in 143 countries, with 133 public network operators in 58 countries. In fact, some cellular carriers such as KPN in the Netherlands, Orange in France and Telekom in South Korea offer LoRa coverage as a service.
LoRaWAN traffic is sent over the LoRa physical wireless communications layer between end devices and gateways, and then from gateways to a network server using the Internet Protocol (IP). The network server routes incoming messages received from the various devices to the appropriate application servers developed by the customer depending on the intended purpose of the network.
There are two layers of encryption. The traffic between end devices and the network server is encrypted with a Network Session Key (NwkSKey), while the traffic between end devices and the application servers that ultimately receive the data is end-to-end encrypted with an Application Session Key (AppSKey). The protocol also uses message counters to prevent replay attacks, as well as unique device and network identifiers and message integrity codes to protect the integrity of communications.
Security depends on good key management
For deployments that use the LoRaWAN 1.0.x version of the protocol – this is the case of the majority of devices deployed today – the session keys are either hard-coded in the device firmware or are derived when first joining the network from an AppKey – a device-specific root key that is different from the AppSKey – in the case of over-the-air activation.
Like in the case of all encrypted communications, the confidentiality of the keys that are used to derive session keys, or the session keys themselves, is paramount. However, in practice and often for usability reasons, device vendors and network operators make implementation choices that can compromise the security of those keys.
“Common problems that face LoRaWAN implementations are related to the keys and their management,” the IOActive researchers said in their paper. “Once the keys are compromised, the LoRaWAN network becomes vulnerable, as the keys are the source of the network’s only security mechanism, encryption. After reviewing vendor documentation, one may quickly realise that it is not difficult to obtain credentials for devices that are physically accessible.”
A new version of the protocol, LoRaWAN 1.1, has added security enhancements, including separating the session key from the network server and moving it to a separate joining server, adding a root key to the protocol, increasing the number of session keys for different purposes, and strengthening the message counters.
While this version of the protocol offers better security, it is still not impervious to implementation errors and poor key management practices, according to IOActive. Furthermore, its adoption will take time and many existing devices are unlikely to be upgraded to use it due to hardware limitations.
Attackers can obtain the keys they need to launch attacks against LoRaWAN devices and networks in several ways. For one, hard-coded keys can be extracted from devices or from publicly available firmware using reverse engineering methods, the researchers said.
Many devices also come with printed tags that have a QR code or text with the device’s DevEUI unique identifier, AppKey and more. If those tags are not removed before deploying devices in the field, attackers could use the information they contain to generate valid session keys.
Vendor-owned open-source repositories and websites sometimes contain hard-coded device-specific keys or application and network session keys that are intended to be changed before deployment. Unfortunately, in many cases those keys are never replaced, but even when they are changed, the new keys often do not have sufficient randomness and are generated using guessable patterns from device information that is accessible to attackers.
“If an attacker obtains a single device’s AppKey by guessing the logic used to generate AppSKeys or by brute-force, the attacker might gain access to the entire LoRaWAN network,” the researchers warn.
Another common problem is that LoRaWAN network servers, which have access to keys by virtue of their role in the network, are using weak or default administrative credentials. Searchers on Shodan revealed LoRaWAN network servers that are connected directly to the Internet, which is poor security practice, especially since the software running on those servers could have other vulnerabilities that enable unauthorised access.
Device manufacturers are often in charge of flashing the firmware on devices and setting the keys, so they can be an appealing target for hackers because their production systems could hold the keys for thousands of devices. Keys are also often shared with customers via e-mail, USB sticks and other methods, exposing them to additional people, including infrastructure technicians who might be storing them on their computers.
Finally, service providers sometimes handle the operation of LoRaWAN gateways and network servers on behalf of customers and need access to device-specific keys to accept them on the network. Those keys are likely to also be stored in backups and databases for easier management and could be exposed if those infrastructure providers ever get breached.
It is also possible to crack keys by using offline brute-force dictionary attacks after capturing encrypted network packets. The IOActive researchers present several techniques for doing this in their paper. They have also found cases where the same AppKey was shared my multiple devices, so cracking a key for a single device can be used to control, spoof and launch denial-of-service (DoS) attacks against a group of devices. To make things worse, the keys for some devices cannot be changed, so a compromise could last until those devices are physically replaced.
What can attackers achieve?
LoRaWAN attacks are easy to perform over the air and over great distances due to the nature of the technology, requiring only an antenna, and their impact on the business or operations of the device owners depends on the purpose of the targeted devices.
First, attackers could trigger DoS attacks. If they have the session keys, they can send messages to the network server impersonating real devices but using message counters greater than the normal values. This forces the server to start ignoring messages from the real devices which have the correct, but lower message counter values.
Attackers could also impersonate devices by sending rogue JoinRequest messages to negotiate new session keys. This would force subsequent messages from the real devices to be ignored by the server. Impersonating the server is also possible, in which case the attackers could send rogue commands to devices to change their radio frequency (RF) synchronisation settings, which would desynchronise them from the network.
Finally, attackers could impersonate devices or groups of devices to send fake data to the applications in charge of collecting the network data and acting on it. Depending on the purpose of the spoofed devices, such an action could have serious consequences.
“Imagine a LoRaWAN device measuring the pressure of a critical gas pipeline, which needs to be under constant monitoring,” the researchers said. “An attacker with valid session keys could craft and send LoRaWAN messages with normal behavior data for the pipeline pressure, masking any anomaly and hiding a physical attack against this pipeline. If not caught in time, such an attack could lead to an environmental, economic, or, in a worst-case scenario, lethal disaster.”
LoRaWAN devices include smart energy meters deployed by utilities; sensors for monitoring CO2 levels, temperature, pressure and leakage in industrial facilities; sensors for street lighting, smart waste management, gunshot detection, public transportation signs, flood and seismic monitoring in residential areas; alarms, smart locks, smoke detectors in homes; smart irrigation systems; and much more.
A need for LoRaWAN auditing and monitoring tools
Because the LoRaWAN protocol uses encryption and is advertised as a secure protocol, users and developers have quickly embraced it and its popularity is expected to grow because it also offers other benefits such as lower cost and easy installation and maintenance. However, through their new paper, the IOActive researchers want to highlight that many such networks are exposed to security risks and should be audited and monitored for weaknesses and attacks.
“When we started this investigation, we found out that there were no tools available for testing LoRaWAN networks,” Cesar Cerrudo, CTO of IOActive, tells CSO. “So, we built our own tools and are releasing this new framework that’s very useful because it allows you to capture the traffic, analyse it, try to crack the keys, inject fake data, and more. An auditor can use these tools to assess the security of a LoRaWAN network.”
There are also no tools for protecting such networks, so people running them are completely blind, Cerrudo says. “They can’t know if someone is trying to hack their networks or has already hacked their networks.”
Fortunately, some attacks do leave traces and IOActive’s open-source LoRaWAN Auditing Framework (LAF) can be used to discover existing compromises. It will not help block new attacks, but it can serve as a passive detection tool. For example, it can be used to set up checks for duplicate messages or for messages counters that are lower than expected, which could be signs of device spoofing.
The use of devices with hard-coded session keys should be avoided because they are at greater risk of being compromised. These are known as activation-by-personalisation (ABP) devices and LAF can be used to discover them so they can be flagged for replacement. The framework can also be used to uncover weak keys so they can be regenerated and replaced. IOActive’s paper includes recommendations on how to protect keys, including using devices with hardware secure elements (SE) and servers with hardware security modules (HSMs).
“The best approach to preventing attacks is holistic, where the complete LoRaWAN ecosystem is secured,” the researchers said. “This can only be achieved if all of the technology that is part of the ecosystem (devices, gateways, network servers, join servers, application servers, and applications) is properly security audited. This way, possible security problems are identified and fixed. This should be done at least twice a year, as the ecosystem is not static. LoRaWAN networks are very dynamic with new components being added regularly.”
IDG News Service
Subscribers 0
Fans 0
Followers 0
Followers