Blog: Android
Hacking kettles & extracting plain text WPA PSKs. Yes really!
Following our recent demonstration at the Infosecurity Show and with Rory Cellan-Jones on the BBC here’s a write up and more technical detail on the Smarter iKettle hack.
First, kudos is due to Mark Cox (@iamamoose) who managed to reverse the default telnet PIN, detailed in his earlier blog, saving us some brute forcing.
There’s a lot more to this though, detail we didn’t have time to share at the Show or on the TV.
For those of you who haven’t seen the demo in person, here’s how it works.
The brief version:
De-auth kettle from its usual access point. Use aireplay-ng
Create fake AP with same SSID
Kettle joins
Connect to telnet service, authenticate using default PIN of ‘000000’
Enter ‘AT-KEY’
Plaintext WPA PSK is then disclosed
Yes, it’s that easy
The detailed version:
The Smarter Wi-Fi Kettle is a relatively simple device; after a set-up process one can control the kettle from a mobile app. It’s Wi-Fi only, there doesn’t appear to be a mobile data option, so it’s only controllable from devices on the same access point. Unless you’re prepared to set up your own remote access etc, then remote control of the kettle from a distance isn’t an option. Mark has written up a how-to for controlling the kettle without a mobile device, but that’s not what we were trying to do.
Opening up the kettle base, we find a TLGUA06 Wireless Transparent Transmission Module UART Wifi AP Module
This isn’t perhaps the most secure or configurable Wi-Fi module available. But cost is king with the Internet of Things!
An over the air update is possible according to the documentation, but I’m still to work out how that would work in the context of the iKettle. It supports an update over serial and ‘via IE browser’.
How one would use Internet Explorer from the kettle to carry out an update is currently beyond me.
One of the failings here is that it doesn’t verify the Wi-Fi access point by anything other than SSID. This opens it up to ‘evil twin’ attacks, unlike recent desktop & mobile operating systems that look for the correct Wi-Fi encryption key too.
Silly PIN authentication
When using iOS, the default PIN of ‘000000’ is changed on first use to something else with 6-digits. This is obviously more secure than Android.
When configuring the kettle with Android, the PIN is left default. This is silly, though may be partly the result of a coding flaw, as the app appears to generate a random PIN, but fails to push it to the kettle.
One can simply sit outside the victim’s house & grab their PSK. There’s a fair chance their Wi-Fi router admin password would be default, so you’ve then got control over their DNS, or could MITM all their traffic.
Even with the iOS-configured kettle, a brute force of the PIN is practical. We’re working on a multi-session attack with Hydra and will update this blog once we’ve got it optimised. Even at only 1 attempt per second, a crack is only a matter of days.
Kettle death and DoS
Other than 0wning the users network, other interesting attacks include keeping it continually warm, thereby consuming the victim’s electricity. One could also deploy a rogue firmware upgrade, bricking it.
I haven’t investigated it’s resilience to continual boiling; it has overheat protection like any kettle though.
Fixing this
#1 the Android app needs to be updated by the manufacturer of the iKettle. In the meantime, here’s how you can do it yourself
Change the PIN on the kettle using the AT+PASS command
Change the PIN in your mobile app by editing case 2 in com.venturelane.ikettle.a.q class
Or if that sounds complicated, you could do it by altering the raw dalvik bytecode in the APK, using something like APKTOOL.
We’re not certain yet why the Android application fails to change the default password on the kettle.
The code for making the change is present in the mobile app, but doesn’t appear to be called:
{
private static final Random a = new Random();—–case 10:
paramr = j.a(6);
this.b.a(“AT+PASS=” + paramr);
return;
Showing that a random 6-digit value CAN be generated and changed on the kettle using AT+PASS, but isn’t.
#2 the app PINs for both iOS and Android apps need more digits! Given the user is never involved in the PIN exchange, make it much longer to make brute force much harder
For the future
The iKettle appears to operate only on the local Wi-Fi network. Mark identified that NATting it could be quite flaky. An obvious feature upgrade has to be making it available over mobile data, so the kettle can be boiled remotely.
As soon as that is possible, then there are a whole host of other attack vectors to consider…
In the meantime, Smarter are producing a similarly equipped coffee machine that I like the look of. I hope they come with enormous cups and drip trays, as I can foresee a continuous request for coffee coming overnight. Denial of Coffee Service.
