Blog: Internet Of Things
Yet another vulnerability in the Smarter Wi-Fi Kettle
Nearly two years after our first findings in the iKettle and this morning we’ve just found another!
I demo the wireless kettle bug as an example of how to get IoT security badly wrong. It’s a visual walk through mobile app code, hardware reversing and RF fails, a great way to get IoT app developers and manufacturers to understand the issue and start securing their products.
However, the bases to the iKettle that contain the wireless module don’t last that long. Of the 4 I originally bought, one is in pieces and the other three have died an IoT death.
So, I bought some replacements last week second hand online. The iKettle 1.0 is out of production (thank goodness) replaced with the iKettle 2.0 which has its own set of security bugs.
One arrived this morning. It was used, so was already configured as a client on the users Wi-Fi network. Whilst I could have looked for client probe requests with a Pineapple etc, I wanted it for demos, so simply reset it back to factory defaults. Press the 65 degrees button until it beeps twice, power off, power on.
As expected, the SSID went back to ‘iKettle’ default.
Making sure it was all working, connect to the AP, set IP address to the link local subnet (169.254.1.x) and telnet to the kettle.
Auth with the default PIN of ‘000000’ and here’s the problem:
WTF? The factory reset blanks the SSID, but not the users Wi-Fi PSK!
Not much use if I can’t find my victim though. However, http://wigle.net comes to the rescue.
The seller had of course included their address, and here they are, redacted obviously:
Resetting to factory should mean RESETTING TO FACTORY, not leaving sensitive customer data exposed
Existing customers – if you plan to sell your kettle DON’T.
If you insist, manually change your Wi-Fi key by first resetting it, then change the KEY to something else using the AT+KEY command.