Thermostat Ransomware: a lesson in IoT security

At the IoT Village during Def Con 24 we demonstrated how easy it was to create ransomware for IoT devices. We chose a smart thermostat, partly because some had speculated about its potential, partly because others thought ransomware was the scary/amusing consequence of IoT vendor security complacency.

Besides, speculating is not doing. A challenge; could we do it?

Simple answer; yes. We created fully functioning ransomware to take control of a smart thermostat and lock the user out until they paid up. Turn the heating off in winter? Turn it to max in a summer heatwave?

Our intention was to draw attention to the poor state of security in many domestic IoT devices. Also to raise awareness in the security research community that it’s not all about software hacking. Hardware hacking is often an easier vector.

Simple security controls would have stopped this hack working, yet they weren’t present.

How did we do it?

First, we are not disclosing the thermostat vendor name at this point, so don’t ask!

Second, don’t do this yourselves, unless it’s on hardware/software that you own. The only reason we carried out this test was to expose a range of flaws in IoT thermostats and encourage vendors to fix them.

Start with the FCC documentation – use the FCC web site to pull up photos and chipset details before you start. You won’t even need a screwdriver for this:

Our thermostat was ARM and Linux based with plenty of processing power and storage, so looked like there was potential for us to get root. It had a Murata Wi-Fi module and most interestingly an SD card slot. No obvious JTAG port though.

The SD card appeared to be for customers to create their own profiles – custom images, screensavers and heating schedules. These were created in a 120MB Adobe Air application on a PC or Mac

But there, in the Air app, was an interesting function named ‘firmware’

Simply unzip the firmware from the Air app, Binwalk it and you get the filesystem

Nearly all of the functionality is provided by a large, monolithic binary running as ‘root’. That’s not good.

That binary loads a .mxe file which is simply Javascript. Run it through JSBeautify and we get human readable code:

We couldn’t find much evidence of input validation, so plenty of potential for command injection. Note the ‘cp’ and ‘rm’ highlighted above.

How to get root though?

By simply entering ;ping -c 1 x.x.x.x in to every single field, filename and parameter we could find. If we get a ping on our local network, we know something is working.

After a bit of hammering, we got ICMP to 12.12.12.12. it turns out that the name of images in the metafile is injectable when loading settings. BOOM!

So, how about a shell?

First, there was no Netcat on the Busybox install present on the device. Time to cross-compile netcat, and use the command injection vulnerability to copy and run it. The command injection is limited in length, so we download a shell script from a remote server to allow more complex commands to be run.

Test.sh downloads Netcat and runs it listening on port 24. Note that we had to use bzip2 and split the file in order to get it downloaded to the stat.

Persistent shell time

Netcat is great, but we really want telnet. Cross compile busybox and load from the SD Card. We still need persistence, otherwise a reboot of the stat will kill our shell:

Edit inittab/init.d/startgui.sh script to persist. On reboot our telnet shell is reloaded!

Now for ransomware

It’s trivially easy to now modify existing functionality in the firmware to achieve our goal:

First, set a screensaver which pops up the ransomware message

Next, the screen has a lock, which is locked with a PIN. Modify the SQLite database, set a PIN and the user is now locked out.

Run a shell script to change the PIN every 30 seconds or so, so the user hasn’t a chance of guessing it

Turn on the HTTP API, from which you can set the temperature. Maybe zero or 99 degrees.

Or simply echo on/off values to various controls as below:

We used an old IRC bot (Kenny in this case) and modified it a little so that it can run our various malicious scripts or shell commands. From there, we can unlock the stat should the user decide to pay up, not that this was ever our intention!

Cat attacks

The stat has a piezoelectric buzzer that we can take control of. If you want to create havoc in a pet-owners house, set the frequency to 16-18 KHz. Most adults can’t hear this, but it will drive their pets nuts!

Destructive attacks

There are no hardware interlocks on the thermostat control outputs. So, you could turn on the heating and cooling in a house at the same time. Very wasteful of power, very annoying.

Further, you could turn them on and off many times per second. Depending on the boiler/furnace, it may react rather badly to this. Physical damage might be possible

Fixing this

None of this should be possible. Simple firmware security would prevent this from happening, such as

• Encrypting firmware to prevent it being unpacked and analysed
• Signing the firmware to prevent it being modified, then checking the signing at boot

Then, simple principles that apply to most areas of security:

• Never trusting user input, even filenames
• Least privilege – don’t run everything as root
• Simple firewalls to prevent unwanted/unintended connections
• Hardware interlocks to stop repeated on/off switching and concurrent heat/cooling
• Removal of debug information – make the reverse engineer’s life a whole lot harder

But it’s only a thermostat, right?

Well, yes and no. It’s a device on your network that could easily create a pivot point and result in a compromise of personal data. Security professionals understand the risks and know how to mitigate them. Joe Public doesn’t.

Also, this is a local attack, not remote code execution. That said, it’s plausible – social engineering, second hand thermostats and compromised supply chains all lend themselves to this.

This exercise was about demonstrating an issue and encouraging the industry to fix it. Will malicious actors do this in future? Perhaps, though we hope that the IoT industry has resolved these issues way before attacks become a reality.

In the unlikely event that you do get held hostage by thermostat ransomware, disconnect the stat and replace it with a non-smart version. Security pros could also potentially reflash the firmware and remove the bug.