Exploits & Vulnerabilities
Gauging LoRaWAN Communication Security with LoraPWN
This second part of our series on LoRaWAN will discuss the security of LoRaWAN communication and possible attacks on vulnerabilities.
Save to Folio
LoRaWAN technology allows organizations to deploy the internet of things solutions at a much lower cost than existing cellular infrastructure solutions. Because of this, enterprises and smart cities around the world have started using LoRaWAN in their operations. As mentioned in the first article of this series, LoRaWAN technology has been used in infrastructure management, climate monitoring, produce deliveries, safety operations, and more.
However, as this technology becomes more integrated into public and private spaces, security must become a bigger priority. As it stands, these devices do not have comprehensive security structures protecting them or the data they pass along. And unfortunately, LoRaWAN devices have been hacking targets for some time.
Because businesses and local governments rely on this technology, a serious security risk can affect the bottom line of businesses or even the safety of citizens in a smart city. This post will discuss the security of an important facet of LoRaWAN: communication.
To take a deeper look at communication security, we had to prepare a comprehensive testing environment. First, we created a testbed to assess and understand LoRaWAN communication behavior. We also used specific optimization techniques with software-defined radio (SDR) to scan region-specific radio bands, and created a tool to help decode LoRaWAN and even LoRa PHY packets.
The LoRaPWN Tool
To decode LoRaWAN packets for assessing the security of communication in this technology, very few solutions exist. We have chosen to use a LoRa PHY-to-LoRaWAN Scapy layer in pure Python to decode the packets. We chose this method because we are more familiar with it, and it is more flexible when it comes to decoding simple LoRa PHY as well as LoRaWAN packets. Moreover, the Scapy layer can be helpful for fuzzing purposes or for exploits as we simply control every field.
To get the detailed assessment we need, we have improved the LoRa Craft project by including several components and created a tool we call LoRaPWN. This tool allows us to assess the security or LoRaWAN communications further.
The tool can:
- Parse and generate uplink as well as downlink LoRa PHY and LoRaWAN v1.0 and v1.1 packets
- Bruteforce attack the OTAA procedure on the MIC field
- Decrypt Join-accept payloads
- Encrypt Join-accept payloads
- Compute MIC field of a packet using a provided key
- Check MIC of a packet against a provided key
- Check the FRMPayload MIC field for LoRaWAN v1.0 and v1.1
- Decrypt FRMPayload fields
- Bruteforce the FRMPayload MIC
- Capture packets as PCAP
As a result, we can intercept and decode uplink and downlink packets this way:
Attacks on LoRa and LoRaWAN Communications
Our investigation into LoRaWAN communication shows how vulnerabilities and weak points can lead to serious security breaches, such as:
- Denial-of-service
- Compromised data integrity and confidentiality
- Unreliable or unavailable data reporting
- Arbitrary code injection
This section will further describe how these attacks can happen and provide more detail about the security concerns listed in our previous post. Our investigation was mostly facilitated by information from our LoRaPWN tool.
Bruteforcing Session Keys
We can intercept LoRa PHY and LoRaWAN packets with our tool, but some are encrypted. The following packet is an example:
This packet comes from the devkit end-device we used to test these attacks, and it uses default session keys provided by Semtech.
To check if the device is using a weak key to encrypt the communication, we have developed bruteforceDATAMIC_1x() functions (with ‘x’ depending on the version v1.0 or v1.1) to retrieve the session key used to compute the MIC depending on the direction (1: uplink by default, 0: downlink). This function takes a dictionary file path as a parameter. We have filled this dictionary with pre-generated LAF keys. This dictionary can also be filled with the default keys we got from the Arduino sketch for the LoRa shield.
First, we save the packet into PCAP files as follows:
To assess the key, our LoRaPWN tool can be launched into interactive mode, which allows us to load the PCAP with the Scapy rdpcap() function and then test keys against a dictionary as follows:
And as we seen in the above example, the function bruteforceDATAMIC_10() found the keys for more than two recorded packets. So, if we use that key to decrypt these packets with our Python decryptFRMPayload() function we can see the following content:
Bruteforcing OTAA Masterkeys
When intercepting OTAA traffic, we can see some Join procedure messages exchanged between the end-device and the gateway.
The Join procedure and the crypto mechanisms involved have already been explained in the first detailed article. In the case of the Join-accept message, the MIC is inside the encrypted payload.
To bruteforce the AppKey on the Join-request, we have made a bruteforceJoinMIC() function that will bruteforce the MIC:
And so, with the key we can decrypt the Join-Accept message as follows:
This gives us the parameters of the JoinAppNonce value, which will generate the session keys to encrypt and decrypt the FRMPayload fields.
Denial-of-Service in ABP Mode
As gr-lora from rpp0 allows us to only receive LoRa PHY data, we demonstrate the injection part with a Microchip RN2483 devkit. However, any device that allows us to send P2P data can be used as well.
We first sniff ABP packets with an SDR device and then save the capture as a PCAP file:
Then we wait until the counter resets. When the counter reaches its maximum values and overflows, we can replay a packet with a high counter value using the devkit and the loranode Python library.
We can see that the packet we will replay has a counter with a value of “11,” so after sending it to the gateway, we can get the acknowledgment from the network as follows:
The legitimate device will not be able to send its data until it reaches a counter higher than this value.
Conclusion
As we have shown above, the LoRaWAN communication environment is subject to bugs and vulnerabilities (memory corruptions, generally). However, we could not dive into these issues with a normal device due to the level of abstraction. By having the means and techniques to study the entire protocol, illustrated above with SDR and our LoRaPWN tool, manufacturers and users have a better understanding of what is really sent over-the-air and can pinpoint weak spots to strengthen.
Our testing environment allows deeper research into how unsecured communications can adversely affect the organizations using vulnerable LoRaWAN technology. The results of our investigation revealed that these types of vulnerabilities put data at risk, allow for unreliable reporting, expose companies to denial-of-service attacks, and enable arbitrary code injection. This is particularly dangerous when it comes to devices monitoring major infrastructure projects or utilities in smart cities. Although the end devices may be low-powered and small, they continue to open up avenues of risk to organizations using them.
For further insight into these attacks, download the full technical brief.
In the next article, we will look at the hardware attacks applied to LoRaWAN and mechanisms we can use to protect from these attacks.