RF Replay Attacks: Hacking Christmas Tree Lights

Background

How would a threat actor begin to hack your IoT device, and what type of equipment would they need? Embedded engineers are getting better at hardening the obvious attack points, such as physical and network connections. But we’ve heard from many that think more obscure communication methods, such as RF, are too complex for the average hacker to interact with so they don’t bother implementing strong controls.

While hacking devices over RF used to be much more involved and require complex software-defined radio (SDR) process flows, that is no longer the case. We’ll explore the traditional SDR-based attack and demonstrate a new tool that makes RF hacking much more accessible.

We’re going to demonstrate a common replay attack on a set of off-the-shelf Christmas tree lights to keep the example simple, but we’ve also executed this exact attack on commercial lighting devices, home security systems, and industrial IoT systems. The lights come with a remote control that sends an RF signal to the base unit. Each press of the button turns the lights on, cycles through various modes, and finally turns the lights off. It’s a pretty simple device, but the concept carries over to all RF communication.

We’re going to break this down into a few different steps:

The ‘Hard’ Way

• Capturing the RF Signal
• Replaying the Signal

The ‘Easy’ Way

• Automated Attack Using the Flipper Zero

Mitigations

• How to Prevent an RF Replay Attack

Let’s try this the hard way first

Capturing the RF Signal

Our equipment list is simple: we will use the powerful HackRF One device to capture and replay the signal.

What’s the frequency?

Before we can capture the RF signal, though, we need to know what frequency the device uses. The easiest way to start is to pull up the FCC’s Equipment Authorization Search to view schematics, test reports, and user manuals for the device. In our case, it clearly states the device communicates over 433.92 MHz.

Let’s verify this using the Gqrx software. This step isn’t necessary, but it helps to visualize the signal before we start messing with it. We’ll mostly use the default settings except for the following:

1. Set I/Q input | Input rate to 2000000
2. Set the frequency to 433.920.000 to match the FCC documentation
3. Set the offset to 300.000 kHz so we can capture a bit away from the center
4. Enable Input controls | DC remove to remove the DC spike, even though we’ve set an offset
5. Set the Receiver Options | Squelch to an appropriate value to match your noise floor. For us, it was -68.0 dB. The idea is to clear the FFT waterfall and Audio Spectrum display. This will help us isolate the remote’s signal.

Now we’ll press the button a few times to generate a signal to check how well we can isolate it.

We can clearly see the transmission, so let’s move on to capturing the signal.

Raw Signal Capture

We’ll be capturing the signal using GNU Radio. We won’t be diving deep into GNU Radio in this post, but you can find some great walkthroughs in the Software Defined Radio with HackRF series from Great Scott Gadgets.

We created a very simple flow to capture the signal from the HackRF to a file. We added a GUI Frequency sink just to help us visually ensure we captured the signal successfully, but it’s not necessary.

Now we just need to run this flow, hit the button on the remote, and stop the flow.

Replaying the Signal

For many IoT security assessments, we’ll need another step before this to analyze the capture so we can demodulate and decode the transmission. This is useful if we need to change the data payload to spoof another device or make the device perform an action it wasn’t intended to perform. But for simple replay attacks, we don’t need to know the modulation type or decode the data. We can simply replay the original message as it was captured.

To do this, we’ll create another simple flow in GNU Radio. You might need to mess with the amplification (Multiply Const block), but remember to be respectful of the spectrum and transmit only as loudly and frequently as necessary.

This flow is set to repeat indefinitely and since we don’t have any type of pause built into, my Christmas tree is now rapidly cycling between the different modes. We can now control the lights without the remote!

And now the easy way

Automated Attack Using the Flipper Zero

Okay, so that wasn’t all that difficult, but when dealing with straight replay attacks, there are tools that can simplify the process for us. We’re going to use the new Flipper Zero device for this attack. The Flipper Zero has built-in Sub-GHz capture and replay capabilities so no other computers or antennaes are required.

The steps are very simple:

1. Click on Sub-GHz
2. Click on Read RAW
3. Click on REC
4. Push the button on the remote
5. Click on Stop
6. Click on Save to save it for future use or just press Send to replay the transmission

That’s all it takes! Once again, the lights cycled without using the remote.

How to Prevent an RF Replay Attack

Why does this replay attack work? Well, the message being sent is the same every time so the receiver has no way of knowing if this message originated from an authorized sender or was replayed or spoofed from something else. Let’s walk through how some engineers attempt to solve this problem.

Adding an incremental value and remembering the last n values

While this approach makes each transmission unique (to a point, up until the sender restarts or the values rotate back to the beginning), it does little for security. It might prevent basic replay attacks as we performed above, but adding a step in GNU Radio to modify the payload before transmitting it is not difficult.

Encrypting the payload

Unfortunately, we see this quite a bit. Encrypting the payload is actually a great control, but encrypting a static payload will result in the same encrypted value every time. This means a standard replay attack will work without modification. We’ve seen this used by home security sensors to indicate the status of door, window, and motion sensors. We simply saved the transmissions of “all clear” status and then replayed them at a fast rate and strong power level to drown out any motion alarms. The following picture demonstrates the demodulation and decoding of a static message (although the payload was modified to “Fracture Labs” to protect the guilty!).

Combine both approaches

The best approach is to combine both of these techniques. Add a nonce (preferable) or an incrementing value to the payload and encrypt it before sending. The receiver should maintain a list of previously-acknowledged IDs and not act upon anything it has already seen. The sender could also include a timestamp so the receiver can ignore old messages. This prevents simple replay attacks as well as message modification or spoofing attacks.

Secure Your IoT Products

We offer free threat modeling to help you zero in on the biggest risks your devices pose to you and your customers. Please reach out to us if you have any questions on how to secure your products, would like us to perform threat modeling on your systems, or are ready to take the next step by performing a penetration test against your IoT devices!