Yet another attack against the iKettle wireless kettle. Rumpy pumpy and fire alarms?

Whilst playing around with moosekettle.py, the python client from @iamamoose for driving ones kettle from a desktop, it struck me that there’s a related attack against unconfigured iKettles.

When turned on, before configuring with the mobile app, it runs in Access Point mode and presents the default SSID of ‘iKettle’. Perfect for easy identification when war driving!

Once configured, it flips to being a client on the network. One can tell simply by the SSID whether it’s been configured, or whether someone has plugged it in and not got round to hooking it up to the mobile app yet.

As it hasn’t been configured yet, it runs in link-local wireless mode. The IP address is likely to be in the range 169.254.1.X, but a quick look at the code shows that it’s static:

It’s therefore trivial to connect to by setting your IP address to the same subnet.

And boil their kettle away merrily. Obviously there’s only a limited attack set one can carry out:

• Run up their electricity bill by continually boiling the kettle
• Steam their wallpaper off
• Make it look like there’s something sordid going on in the kitchen. Steamy windows!
• Or perhaps worse, set off their fire alarms?

There remains some potential to upload something more ‘interesting’ to the kettle via the embedded webserver, but that’s for another day.

What should the manufacturer be doing about this?

Probably not very much. Without a local GUI or screen on the kettle, it’s going to be hard to configure without this Wi-Fi access point mode before initial set-up.

But it’s worth reminding users not to leave an unconfigured kettle plugged in.

Think I’m being alarmist? No-one would leave an unconfigured kettle plugged in, would they?

Here’s one. Near Wandsworth Town station in London. Tiny text, but right in the middle of this image: