More Internet of Things irony: a security alarm with alarming security

One of our last posts of the Old Year was Episode 225 of the Chet Chat security podcast.

In the podcast, we looked back on some of the “problem themes” of 2015, and how we might avoid repeating those problems in 2016.

One of those themes was the Internet of Things, or IoT.

Here’s what we had to say:

CHESTER WISNIEWSKI. It seems like everything is getting an IP address now. Is this a good idea?

PAUL DUCKLIN. Every time we talk about the so-called Internet of Things on the Chet Chat, we get rather woeful tones in our voices, don’t we? It does seem that security [takes] second place, if it’s on the list at all.

And no sooner were the words out of our mouths than we came across an article by a UK-based security researcher, Luca Lo Castro, who took a look at the security programmed into an intruder alarm he’d bought.

As he tells it, the model he investigated offers a fairly high level of claimed intruder security, reaching European Standard EN50131, Grade 3.

EN50131 has four levels, starting at Grade 1 (Low Risk), which is considered sufficient to deter so-called “opportunistic thieves” only – the sort of break-and-enter crooks who rely on tools such as hammers, chisels and screwdrivers.

Grade 4, at the top of the ladder, applies “where security takes precedence over all other factors, [and] intruders are expected to have the ability or resource to plan an intrusion in detail and have access to a full range of tools and equipment, …[including] the means to substitute vital components in the Intruder Alarm System.”

For Grade 4, we’re talking about the sort of security where not only your property is at risk, but also your reputation, as well as the safety of other people: military installations, bullion and cash centres, government research establishments, and so on.

Grade 3 isn’t quite that high, but it covers places such as bonded warehouses, mobile phone shops, computer suppliers, and motor garages: locations with high-value contents where crooks are “likely to spend time planning an intrusion,” and will bring along electronic tools such as laptops.

WHAT LUCA FOUND

Unfortunately, what Luca found in the IoT alarm system he investigated was that a well-practised crook might very well need little more than a laptop, or even just a suitably programmed mobile phone, as his break-and-enter tool of choice.

We won’t repeat the contents of the paper here (it’s brief and commendably clearly written, so check it out for yourself), but merely summarise the findings:

1. The alarm can be connected to the internet.
2. The alarm can “call home” to the vendor’s cloud servers to log status information, such as when an alarm goes off.
3. The alarm’s companion mobile app can receive reports from, and send commands to, the alarm itself.
4. The alarm’s companion mobile app can receive reports from, and send commands to, the vendor’s cloud servers.

The worrying aspects that Luca reports are as follows:

1. The vendor’s documentation recommends opening a firewall port to allow direct access to the alarm from the internet.
2. The alarm “calls home” using neither encryption nor authentication.
3. The mobile app communicates with the control panel, including sending the password, using neither encryption nor authentication.

Amusingly, if that is the right word for it, Luca says that the company claims to provide a mechanism for generating “encrypted passwords.”

Apparently, these are used when you want to give someone access to the alarm panel via the mobile app, but not to tell them the real password, which they could then use at the alarm panel itself, where more features are available.

The “encryption,” however, consists of the base64 algorithm, which is not encryption at all, merely encoding. (Something that is encoded can be decoded without a key, so there is no confidentiality, nor is there supposed to be.)

What to do?

As a workaround, Luca suggests segregating the alarm panel from the internet so it is not directly accessible, using a Virtual Private Network (VPN) to make a secure connection to the alarm network, and then controlling it “from the inside.”

That’s a good idea, but it’s only a workaround.

Without both encryption and authentication, a crook can not only eavesdrop what’s going on, but also modify the traffic in either direction to feed in bogus commands (e.g. turn the alarm off instead of on) or produce bogus results (e.g pretend that an alarm event never happened), or both.

So, if you’re a programmer, and you’re enabling your latest electronic gadget to go online and join the IoT…

…please build in security right from the start, even if you never expect that device to be installed on the public-facing internet.

Alarm bell image courtesy of Shutterstock.