Hackers in Hot Water. Pwning smart hot tubs, yes really

TL;DR? Video first…

We were given a tip by the awesome Ceri Coburn that something was amiss with the Balboa Water App, a mobile app used for controlling >30,000 hot tubs.

You can remotely control your tub, so you can heat it up for when you’re ready, saving power when you don’t use it. Nice idea!

Ceri had noticed that the mobile app didn’t seem to authenticate users, so pulled apart the mobile app and flagged it to us for further investigation.

So we bought one. That’s the upside and downside of IoT – you can reverse engineer your own stuff, but you need to buy it first.

And here’s the PTP R&D hot tub. That was an entertaining $5,000 conversation with our CFO!

Hot Tub Pwn Machine

The mobile app connects to a Wi-Fi access point on the tub. We bought a few spares for research:

Like most internet of things devices, the Wi-Fi module acts initially as in AP mode. The mobile app can connect as a client and control the tub locally. However, it can also configure the tub controller to be a client on your home network, so remote control from anywhere is possible through an API.

Hence, we can geo-locate hot tubs on https://wigle.net – simply search for : https://wigle.net/search?ssidlike=BWGSpa%25 and you’ll find the tubs that were still in AP mode when geo-located.

The AP is open, no PSK, so anyone can stand near your house, connect their smart phone to your hot tub and control it. Your friendly neighbourhood hacker could control your tub.

But that’s not enough. I want to pwn them ALL, so we’ll come back to wigle in a minute.

Bubble trouble

There was no authentication to the API when remotely controlling the hot tub. So how did it authorise the user?

It uses a cloud service from iDigi for control. Here’s the class in the Android app that deals with the connection to iDigi:

Yes, those are static credentials. Seriously!

And here’s a capture of the request to the service

Note we’ve highlighted the “devConnectwareId” – that’s the device ID. Notice anything familiar about it?

Yep, that’s the MAC address of the Wi-Fi module in the hot tub, with a couple of octets of 0xFF padding

And what can we recover from wigle?

THE MAC ADDRESS OF OUR VICTIMS HOT TUB

You can enumerate all the tubs quickly using the API too, though obviously targeting would be a bit random, as you don’t know where each hot tub is located.

You can also see the data for your own tub by appending your tub ID to the unauthenticated, plain text URL here:

Or you can just visit this path on the API:

Hackuzzi

Changing temperature in Fahrenheit is fairly easy. If you’re metric it’s painful: for some reason the app author decided that ‘Temp in F’ equals twice ‘Temp in C’. It should be 9/5 argh!

Here’s the class that deals with it:

Here’s how to issue commands to the API:

So 12 is the button ID for the blowers. The other parameter sets are:

• SetTemp / 69
• TempUnits / C
• TempUnits / F
• TimeFormat / 12
• TimeFormat / 24
• SystemTime / 01:49
• Filters / <base64 string of bytes dictating the filter cycle>
• Request / <panel request, such as list filter cycles??>

Recovering the hot tub status from the API is a bit of a faff. If you make a request for ‘PanelUpdate.txt’ you’ll get an encoded response:

We’ve written a simple decoder which is on our github repo. It’s called ‘Hackuzzi’ ?

And here’s the decoded response:

Freezing you out

So what, someone can mess around with your hot tub. It’s hardly nation state grade ransomware, but it was damn good fun finding and exploiting this vulnerability on ours and Ceri’s hot tub.

However, there is a more serious side: it’s easy to turn your temperature down so your tub becomes unusable. It’s also easy to heat it continuously, wasting electricity.

Blowers are also only turned on when someone is in the tub, so the hacker can figure out if you’re in the tub at the time. Creepy.

Consumer IoT security is not in a good place. These findings underline that.

Worse, the iDigi service is also used to control smart healthcare appliances. Who is to say if those were correctly secured?

Disclosure

We emailed Balboa Water Group on 28^th November, explaining the flaw and asking for an acknowledgement so that we could start responsible disclosure. We had no reply.

We tried again on 30^th November, asking for an acknowledgement by 10pm GMT on Friday 3^rd December. Again we had no reply.

We then asked the BBC if they could use their influence to elicit a response. They kindly obliged and, as if by magic, we had a response from BWG within an hour of the BBC emailing them.

Why does it have to be like this?

BWG explained to the BBC that they had not implemented user accounts for “ease of use”, and that the static password was also a conscious choice!

BWG also asked for the broadcast to be delayed, for no other reason than they didn’t want to take down the API over the holiday season. Hardly compelling.

They only took action when their brand was at stake, not their customer’s privacy or security, yet were happy to expose users  in the meantime…

It’s because BWG could fix the vulnerability by simply taking down the API, and advise their users to disconnect their tub from the internet without fuss that we decided to disclose publicly.

The consequence of the vulnerability to users is an irritation rather than major security issue, but they simply didn’t engage in a positive, constructive, and customer-focused way.

It’s yet another example of an IoT disclosure train wreck.

Consumer advice

If you’re bothered the potential for others to control your hot tub, don’t use the remote control function until Balboa update the app and API.

It’s possible to reset the wireless module by holding a magnet on the data cable to the side of the module for a few seconds, as per the manual.

That still doesn’t fix the ‘local wi-fi control’ issue though, so you could physically remove the module if you are still concerned. Be careful doing this, as water and powerful electric heaters don’t mix well!