Blog: Internet Of Things

Hacking wireless house alarms

Andrew Tierney 05 Jun 2017

30 years ago alarms were all hard wired, with discrete components, and operated by key switches. 20 years ago, they have evolved to use microcontrollers, LCDs and keypads, but were still hard wired. 10 years ago, wireless alarms started to become common, along with bags of added functionality.

Today we have alarms with Internet connectivity, mobile apps, home automation integration, and video verification – where the detectors have integrated video cameras, installed in your home.

Alarms systems have grown up, but the degree to which manufacturers, installers, operators and users understand them hasn’t.

Local attacks

Wireless alarms opened up a whole new attack surface. Wired systems used open/closed circuits, with all of the wiring inside the protected area. Wireless systems broke that boundary, allowing an attacker outside the premises to tamper with an alarm’s signal.

There are a number of techniques to attack the wireless side of alarms.

Some alarms are “graded”. That means they comply with the EN 50131-1 standard. It ranges from grade 1 (least secure) to 4 (most secure). The alarm here is not graded. The highest grade in the UK for wireless alarms is grade 2.

Jamming

Despite what the marketing says, a significant number of wireless alarms can be jammed, preventing alarm signals from getting through, and allowing an attacker to enter the premises.

Let’s look at the standards around wireless alarms – EN 50131-5-3. We’re going to concentrate on grade 2, as that is the highest grade of wireless alarm available in the UK. Grade 2 means that it is suitable for domestic premises and lower risk commercial.

We can’t link to the standard, because you need to pay for it unfortunately.

This states two important figures on jamming (or “intentional interference”):

  • “Requirement for the detection of a failure of periodic communication” i.e. how long can the panel not receive a detector’s signal for. This is 120 minutes. 2 hours without a signal getting through.
  • “Requirement for the detection of interference” i.e. jamming. This allows for 30s out of every 60s to be jammed. That gives us a big window to play with.

(Taken from the paper http://e-collection.library.ethz.ch/eserv/eth:5031/eth-5031-01.pdf)

There are three kinds of jamming attacks we can carry out:

  • Proactive or naïve jamming – we send a signal 100% of the time. No signals at all will get through, but this is easy to detect, and will cause widespread disruption to other devices on the same frequency.
  • Reactive packet jamming – we wait until we detect a signal, and then start jamming the signal. Less easy to detect, but status and alarm messages are both jammed, risking setting the alarm off.
  • Reactive bit jamming – listen to the signal sent, and only jam for long enough to corrupt the signal. The advantage here is that we can listen to the beginning of the packet, and only jam alarm messages, allowing status messages through.

It sounds like alarms should be triggered by proactive jamming, doesn’t it?

Strangely enough, a lot aren’t. This goes from cheap consumer alarms all the way up to graded alarms.

Here we use an RFcat – a simple RF USB dongle – to send a continuous signal on 434MHz. No alarm signals get through at all. The jamming detection doesn’t trigger an alarm (we don’t know why this is the case).

An RFcat is around £30. It can be done cheaper though – A simple OOK transmitter, modulated using a 555 timer would do the job for proactive jamming.

If we want to do reactive packet or bit jamming, then we can use a CC1110 board, and program it with custom code. I’ve found the £29 Ciseco ARF well-priced, and with 500mW of output power, very effective.

Worrying.

Replay attack

There is no provision in the EN 50131-5-3 standard to protect against replay attacks at grade 2. That means we can receive a signal – for example the disarm signal from a keyfob – and play it back later.

But what about rolling codes? And challenge-response algorithms? They have been used in automotive security for years. Not so on home alarms.

This is really easy with software defined radio (SDR). We’re using the $300 HackRF here. We approximately choose the frequency (434.8Mhz), start recording, and capture the disarm signal to a file.

We can view the recorded file in Audacity or similar, and see the simple on-off keyed AM modulation used.

But we don’t need to care about the modulation – we just feed the recorded file back into the HackRF, disarming the alarm for us.

Again, if we want to do this cheaper, we can use a CC1110 based board, although it is significantly more effort as we need to demodulate and decode the signal.

Other attacks

That’s not the only problem we’ve found.

A common technique we use during pen testing is to fuzz protocols. At a very basic level, this means starting with a genuine signal and mutating it, to see how the software handles malformed input. We can do this with RF signals as well.

One alarm, when it receives packets that are longer than expected, hangs entirely. The keypad doesn’t respond; the detectors do nothing. You need to pull the power – including the back-up battery – for it to work again. We don’t know why the microcontroller’s watchdog timer is not used for a safety critical device.

The device sends the PIN number in the clear between the keypad and the panel. It can be sniffed, decoded, and then used.

But it opens up a more interesting attack – can we brute force the PIN?

Nearly every alarm panel will lock you out if you get the PIN wrong more than a few times – and so does this one. So let’s try the RF side.

A simple Python script is used to drive the RFcat, and sends each PIN sequentially. It takes around 1hr 20 minutes to get through all of them. If you focused on common PINs first – 0000, 1111, 1234, 1900-2016 etc., you would likely find the right one sooner.

But these are local attacks?

Yes – they only affect the alarm system you are attacking.

But these attacks should not be possible, at all.

The standards do not adequately specify a system that is genuinely secure, and some manufacturers do no more than meet the standards.

The automotive security world was in the same position 10 years ago. Many were saying electronic techniques were not part of the threat model and weren’t going to be used. Now look where we are:

But more to the point – if the well-established wireless side of things (that is covered by standards) is this bad, what about the Internet side of alarms?

Internet attacks

Denial-of-Service for Alarms

Now we also have internet connected systems that rely on cloud servers to provide functionality. This provides a new, central point for attack; an alarm receiving centre (ARC) or cloud server.

By meddling with a central point you could trigger thousands of alarms, which would divert attention and resource, giving your cover for a genuine attack.

This may sound ridiculous, but what would an ARC do if 1000 domestic alarms went off, alongside a single grade 4 alarm in jewellers?

The researcher Wilco Baan Hoffmann talked about this in 2013, where he analysed the abysmal security of the SIA-HS alarm signalling protocol. The presentation is well worth a read to hear about some of the fundamental flaws made.

We see distributed denial-of-service attacks used all the time to distract resources during a genuine breach.

The standards for alarm receiving centres are oddly quiet on information security requirements.

Changing attacker profile

There’s also a shift in the profile of people who are likely to attack an alarm system. It’s not just burglars anymore; mischief makers all over the Internet love playing with anything connected.

They will quite happily spend a lot more time and effort than you might think to achieve these goals.

From LED traffic signs, to billboards, to heating controllers, to PA systems, to baby monitors. There is no financial gain here. Just the desire to cause trouble for others. You can no longer assume your attacker is unskilled and only has a multimeter at their disposal.

Your wider network is at risk

Along with DVRs and IP cameras, alarms are now often powerful embedded computers. Many of them are directly connected to the Internet by port-forwarding, as well as being connected to your internal networks.

They can be used as ideal pivot points into your internal networks, allowing for further attacks to be mounted, and data exfiltration to take place. They have no anti-virus, no users to disrupt, and no one is going to question huge amounts of traffic coming in and out.

Examples

Now for some specific examples about how this can go wrong.

RSI Videofied broken encryption

http://www.kb.cert.org/vuls/id/792004

RSI make an alarm system which has cameras in the detectors, and takes videos and pictures when triggered. These are sent from the detector to the panel, then the panel to the alarm receiving centre. The alarm receiving centre runs some software called Frontel to receive alarms and images.

RSI Videofied make a big point about encryption between the detector and panel. But when we look at the connection between the panel and alarm receiving centre, it’s not bright.

Each panel uses a fixed encryption key which Is based on the serial number of the panel. This serial number is sent in the clear, so we can just work out the encryption key.

With this, we can then connect to the ARC and spoof and reply signals.

How long did it take us to find this? Just one hour

What should you do?

If you already have a wireless alarm, don’t panic. We are not seeing these attacks carried out in the wild.

If you are looking to get an alarm, think about the following points.

Wired will always be more secure than wireless.

If you can’t install wires, look for several key features:

  • 2-way RF – this means that the panel can communicate with the detector, making jamming attacks much harder, as well as allowing the detectors to sleep whilst the alarm is disarmed, improving battery life.
  • Encrypted RF – some RF links use encryption. Not all are equal though, so be wary.
  • Rolling code – the use of a pseudo-random code makes jamming and replay much harder (though not impossible, as Samy’s RollJam attack showed)
  • Frequency hopping – again, this makes jamming much harder, as well as intercepting signals
  • Grade 2 – although some graded alarms are not great, they all tend to be better than ungraded

Conclusion

Remember that an alarm isn’t just a load of detectors and a panel – it needs to be installed properly. It’s nowhere near as easy as it sounds, and it’s often worth speaking to a professional alarm installer who can do a full risk analysis and get you what you need. It’s a broad statement, but in our experience, alarm security quality usually correlates with price.

None of the issues we’ve raised above are rocket science, it’s all just good security practice.

Many alarm manufacturers don’t seem to be following these good practices, and show no signs of changing. As more and more alarms get connected to the Internet, you need to make sure you aren’t trading your virtual security for your physical security.