Hello Everyone,
I am working on a project related to the security of LoRaWAN. One of the attack’s vector which I am testing is based on the below article:
Security_Issues
The proof of concept for this attack (described in detail in paragraph 3A in the above article) is whether a LoRaWAN packet with the same FCnt field in the uplink message but with different frame counter (thus different MICs) would be accepted by Network Server (NS).
I am testing this with TTN NS as suggested in the article and The Things Node device (TTN uses 32-bit Frame Counter). The prerequisite of this test is MiTM between the gateway and NS (an unsecure connection) which I have already successfully implemented.
Main steps for this attack’s vector:
- Capture LoRaWAN packet with data (f.e with FCnt = 19)
- Send packet with FCnt = 20 and valid MIC (guard packet), to prevent for NS to interpret future packets as repetitions.
- Send packet with unchanged FCnt = 19 and with changed FCntUp = 19 + MAX_FCNT_GAP in calculated MIC (DoS packet) (based on LoRaWAN specification 1.0.2 chapter 4.4). This should make NS server DoSed for the number of MAX_FCNT_GAP packets or until the manual reset.
At this point I have below questions related to this matter:
a) in the mentioned article it is not stated that the attacker is in possession of NwkSKey. However, choosing brute-forcing MIC is not very sufficient (with 2^32 possibilities). In your opinion, how the attacker can prepare a valid MIC based on captured previous packet’s LoRaWAN fields? Is it possible to achieve without NwKSKey? How would you manage to replicate this attack?
b) Assuming that the attacker has needed key (inputted directly into code), I have been able to send one packet (step 2). It is the packet with counter = 7 in the attached screenshot. But unfortunately, I was not able to send a packet from step 3.
I have tested the MAX_FCNT_GAP with many values { 400, 16384, 65536}. In each case, I didn’t see the packet with provided FCntUp. Additionally, I have also tested this vector where step 3 is replaced with duplicated step 2 - still no luck.
In both steps, I was using the same JSON from the captured packet (step 1) - I only put an incremented ID of the IP packet. To your knowledge, in the aforementioned case what field the TTN NS is using to determine that incoming data is not valid? Am I missing something important which doesn’t allow me to send the packet from step 3?
Maybe Someone here has been testing the LoRaWAN protocol and could help me to move forward in my tests.
Thank you All in advance 
Kriss
