Low Powered and High Risk: Possible Attacks on LoRaWAN Devices
Long Range Wide Area Network (LoRaWAN) devices have been hacking targets for quite some time. We dive into attacks that malicious actors can use against vulnerable LoRaWAN devices, and review the state of LoRaWAN security. This is the first in a three-part series.
The deployment of internet of things (IoT) devices allows large-scale operations and wide-ranging services in smart cities, industrial facilities, and connected agricultural areas to run smoothly and efficiently. Many organizations are turning to affordable technologies that allow for extensive and stable IoT deployments. One example is the LoRa (long-range) protocol, which helps companies connect low-powered IoT devices to the internet using a wireless connection. Long Range Wide Area Network (LoRaWAN) is a radio-based technology that works in conjunction with LoRa. LoRaWAN devices scattered across large areas can wirelessly connect to the internet via radio waves. This technology can be used in monitoring sensors (weather or tracking), asset management, controlled automation, climate control, and more.
The LoRaWAN infrastructure provides opportunities for organizations that want to deploy IoT solutions at a much lower cost than existing cellular infrastructure solutions allow. Various cities around the world have already adopted LoRaWAN technology to manage utilities and services. It is already well established in Taiwan, after Taipei’s local government encouraged private businesses to use the LoRa platform as early as 2016. For over two years, the city of Tainan has used LoRaWAN devices to monitor garbage trucks and also monitor the water levels of rivers. Other cities across Taiwan deploy LoRaWAN in many different use cases: to manage dams, deliver fresh food, and even monitor bikes on the road. In 2019, China’s leading internet-access service provider, Tencent, collaborated with The Things Network to expand the country’s LoRaWAN ecosystem. In the United Kingdom, new funding in 2020 ensures broader nationwide LoRaWAN networks and infrastructure in the future. And in Germany, digital water meters using LoRaWAN technology are also being installed across different cities.
According to the LoRa Alliance, a global group of over 500 companies dedicated to LoRaWAN development, there are LoRaWAN network operators in 162 countries, and that number is expected to grow. However, while many different sectors across the globe have adopted this technology, security for it has not been fully explored or developed yet. Because of these factors, LoRaWAN devices have been hacking targets for quite some time. This blog post covers a few attacks that malicious actors can use against vulnerable LoRaWAN devices, followed by a review of the state of LoRaWAN security.
Attacks against LoRaWAN
Organizations that use LoRaWAN are mostly large-scale industrial or agricultural facilities, utility providers, or local governments. The devices that use the technology are low-powered and often distributed widely across different areas, and organizations may not be inclined to secure the devices or network comprehensively. However, compromised LoRaWAN devices could be used in attacks that could result in stalled operations, leaked data, or falsified information.
For example, if communication between a smart water meter and the network is compromised, actors could manipulate the billing for the utilities. Likewise, an attack on a highway monitoring sensor could affect motorists’ safety and security.
In 2018, researchers from the Netherlands released a report outlining several attacks on LoRaWAN. One involved LoRa 1.0, stemming from the fact that the counter in FRMPayload is only 16 bits long. They demonstrated that it was possible to replay a captured packet; wait until the counter overflows and replay this packet to realize a denial-of-service (DoS) attack:
Session keys stay the same until they are changed manually or with a firmware update/upgrade. LoRaWAN has two ways to connect devices to the network: Over the Air Activation (OTAA) or Activation by Personalization (ABP). ABP is more vulnerable to a cryptanalysis attack compared to OTAA.
Regardless of the version, the integrity of LoRaWAN messages are protected by the Message Integrity Code (MIC), which prevents intentional tampering and encryption. Nevertheless, the messages decrypted by the network server and sent to the application server are no longer protected:
Protecting communication is a complicated task because the message terminates early. Securing it would require designing the network to use an SSL tunnel (preferably with a client SSL certificate) or another MIC field inside the MAC Layer Payload computed by the AppSKey.
An acknowledgment mechanism was introduced in LoRaWAN to maximize battery life by reducing the time the radio needs to be powered up. But as highlighted by Xueying Yang, Evgenios Karampatzakis, Christian Doerr, and Fernando Kuiper in their paper, the ACK message does not state which message it is confirming.
To illustrate this issue, the researchers proposed to selectively jam the downlink when an end-device sends a confirmed message to the receiving gateway. The end-device will never receive the confirmation message, and it will retransmit the confirmed message seven times. It will then consider this message as lost or refused, raising a status “mac_err”.
But during the jamming session, the attacker can capture the downlink message for the confirmation and play the confirmation for the first message when the end-device sends a second confirmation message.
Most setups use the LoRaWAN class A mode, which specifies that downlink traffic must/can follow an uplink. Class B tends to reduce the amount of energy spent by telling end-devices to wake up periodically to wait for any incoming messages during a receiving time window.
The durations of the receiving windows are specified by beacon broadcast messages comprised of a PHY layer header followed by a beacon payload:lowed by a beacon payload:
The researchers showed that an attacker could easily compute the different publicly known fields with malicious parameters to:
- Find the location of a LoRa gateway (thanks to GwSpecific field with an InfoDesc subfield containing GPS coordinates).
- Drain the battery by sending crafted beacons framed with an extreme wake-up time value.
According to their paper (as well as another LoRaWAN security evaluation paper by Frank Hessel, Lars Almon, Flor Álvarez) and the LoRaWAN v1.1 specifications, the integrity of beacon frames is still an issue, and it would be better to use a MIC instead of a CRC to check time’s field integrity.
On top of all the previously discussed security mechanisms, the management of keys is also integral to security. Root keys are used in OTAA devices; they derive session keys when the OTAA device executes a Join Procedure with the network.
Because the backend is exposed to the internet, a malicious actor could use critical weaknesses and vulnerabilities (LFI, SQL injection, deserialization vulnerability, etc.) to get the secret key, read the data, craft downlink packets, and conduct other illicit activities.
To mitigate these risks, here is a list of points to check in a LoRaWAN setup:
- Use randomly generated keys
- Avoid the exposition of key management servers and services (exposed key management service accessible on the internet)
- Preferably use HSM (Hardware Security Module) to keep the keys
- Preferably use OTAA mode and LoRa version 1.1.
The State of Security for LoRaWAN
Security tools for LoRaWAN technology released in 2020 are few and far between. Researchers from IOActive released a framework called LAF (LoRaWAN Auditing Framework) and provided a tool that can parse, send, craft, analyze, and audit a setup and crack some LoRaWAN packets using weak/default keys. The researchers also released a paper presenting attacks in LoRaWAN 1.0.3, mainly using their tool.
Nevertheless, this framework still has some limitations to overcome:
- It only works with a Gateway
- It can only listen to uplink packets
- It can only listen to 8 out of 64 channels
- Generation and fuzzing depends on LoRaWAN (Go) using an inflexible format such as JSON
In the same period, another type of tool called “LoRa Craft” was released to intercept packets using Software Defined-Radio, and craft packets using dedicated LoRaWAN v1.0 and v1.1 Scapy layers developed for the purpose of this tool. But this tool is mainly do-it-yourself and needs much more assistance than those already released, like crypto helpers for Join-Accept payloads and MIC to help crack weak keys.
In May, SEEMOO Lab released a framework called ChirpOTLE that demonstrated two attacks affecting the availability of LoRaWAN networks like time drifting in LoRa class B, and a novel ADR spoofing attack to manipulated frame metadata. But still, researchers were limited in their setup by choosing only a few default channels to demonstrate their attack with each node.
This shows that while security solutions are being developed, comprehensive and easily accessible protection for LoRaWAN still has a long way to go. To learn more about LoRaWAN attacks and the other topics discussed above, download the full technical brief.
This is the first of a three-part series. The next article will discuss how to overcome the limitations encountered by the researchers. We look into the use of Software-Defined Radio (SDR) and optimization when attacking both uplink and downlink on multiple channels, as well as multiple spreading factors using a very cheap SDR device. We will also introduce tools that would help analyze LoRa PHY as well as LoRaWAN radio communications. The final article will describe hardware attacks and security mechanisms concerning LoRa end-devices.