This blogpost is a direct copy of previous research i have done at PenTestPartners. The original post resides here: https://www.pentestpartners.com/security-blog/burning-down-the-house-with-iot/
This blog post is purely for archive purposes only
For years we’ve been trying to set fire to ‘smart’ things by hacking them. We got some charring on the iKettle, but nothing more.
Then we found some smart hair straighteners. The Glamoriser straighteners were promoted heavily on TV at Christmas; they piqued my interest because of the BLE connectivity to a mobile app,.
You can change temperature and change idle time before shutdown.
These seemed like a much better candidate for our pyromaniac intent; max temp above the flashpoint of paper (233C/451F).
A little research online revealed a UK fire service quoted that up to 650,000 house fires have been caused across the UK by straighteners. Apparently one in three hair straightener users have burnt themselves!
IMAGE CREDIT: Spire FM
Could we start a fire by hacking them? Yes we could!
The app was pretty simple: temperature control and time out.
Googleplay Store: https://play.google.com/store/apps/details?id=com.fenda.diva
The APK decompiles well, with 99% of the code intact. This is helpful later on when we come to look for certain code.
The app can directly interface with Alexa and AWS services. There is a Generic API Key Stored in “Assets” Folder:
The api_key.txt file is in fact a JWT (Java Web Token):
The Android application has backup enabled:
With a BT4 dongle and BLEAH running we can look at the device in more detail:
The generic name for the device is “Bluetooth Styler”. It has its “Peripheral Privacy Flag” disabled and we can “WRITE” to the 0015 Handle…
Let’s look at some code.
Looking at how the app works with the BLE protocol, we can see that just about everything is logged to LOG:
Searching further through the code base we find the status UUID string for the BLE communications:
BES_DATA_CHARACTERISTIC_TX_UUID is the write characteristic from earlier.
There is also code outlining what the BLE commands look like:
From this we can see the command is built of different parts:
The CheckSum value is calculated like this:
So now we know how the BLE commands are sent, lets make sure we are correct.
By looking on the phone’s SD card we can see a number of files and folders created:
The Log.txt file created lists exactly what is going on with the BLE Communications:
2019-02-12 12:43:44V<BleService>---onConnectionStateChanged connected = false 2019-02-12 12:43:44V<BleService>---isHumanDisconnect = false 2019-02-12 12:43:44V<BleService>---quickyDisconnectCount = 0 2019-02-12 12:43:44V<BleService>---totalReconnectCount = 1 2019-02-12 12:43:44V<BleService>---totalReconnectCount < 10 and equels = 1 2019-02-12 12:43:44V<BleService>---totalReconnectCount < 5 and reconnect after 500 2019-02-12 12:43:44V<BleService>---handleMessage msg.what == RECONNECT reconnectMAC= F0:13:C3:00:4B:8C 2019-02-12 12:43:44V<BleService>---onConnectionStateChanged connected = true 2019-02-12 12:43:45V<BleService>---onConnectionStateChanged handle discoverServices 2019-02-12 12:43:45V<BleService>---onServicesDiscovered() + status = 0 2019-02-12 12:43:45V<BleService>---onCharacteristicNotifyEnabled() + status = 0 2019-02-12 12:43:45V<BleService>---READY TO SEND DATA IS = 54,45,eb,50,c8,00,05,f8, 2019-02-12 12:43:45V<BleService>---READY TO SEND DATA IS WRITH TO HAL RET IS = true 2019-02-12 12:43:45V<BleService>---onWritten() + status = 0 2019-02-12 12:43:45V<BleService>---onReceive BES_DATA_CHARACTERISTIC_RX_UUID 2019-02-12 12:43:45V<BleService>---onReceive 54,45,f8,
From this Logfile we can also see there is an acknowledgement transmission sent from the device confirming the command was receives and actioned.
By changing some values on the mobile app and then watching the logs, we are able to see what data is sent:
54,45,eb,50,50,00,05,70, 5 mins 80 °C 54,45,eb,50,5a,00,05,66 5 mins 90 °C 54,45,eb,50,64,00,05,5c, 5 mins 100 °C 54,45,eb,50,96,00,05,2a 5 mins 150 °C 54,45,eb,50,c8,00,05,f8 5 mins 200 °C
Let’s see if we can send some data and get the straighteners to do something. First, we need to calculate the checksum for when we change values.
So, we wrote a Java script:
This Java code calculates the Checksum for us and prints out the value we need to send.
One thing to note! There is no auth on the BLE communications between the device and the phone. Data can be sent to the device at any time as long as it is turned on (via the mains power socket).
bleah -b “f0:13:c3:00:4b:8c” -u “0783b03e-8535-b5a0-7140-a304f013c3ba” -d “0x5445EB50EB0014C6”
Hurrah! We can! Success.
So, we can send commands to the straighteners to change temparature if they are turned on! Great… Now what…
We tested to see if we could overheat the device beyond 235C, sadly that didn’t work, but it didn’t matter particularly.
If you issue temperature requests over 235C or below 50C, it will not register on the device, so I suspect there are local limits to the temperature on the device.
Also, you cannot make them stay on for any longer than 20 mins. There is a physical switch on the straighteners, if it’s not pressed they will turn off regardless.
What you CAN do is override the settings as they are being used. For instance, if somebody was using the straighteners at 120 °C and had a sleep time of say 5 mins after use, you could change that to 235 °C and 20 mins sleep time.
Making it a whole lot easier
Whilst reverse engineering the BLE communications was an interesting challenge, it’s not actually necessary. As there is no pairing or bonding established over BLE when connecting a phone, anyone in range with the app can take control of the straighteners.
The straighteners do not support more than one concurrent phone connection, though I can see a lot of people buying the straighteners and never actually getting round to connecting a phone to them, so they’re exposed.
Also, if the user goes out of BLE range, your local neighbourhood hair straightener hacker can jump in and pump up the temperature.
Hair straighteners can cause house fires and skin burns if not used safely.
We’ve shown that we can tamper with the temperature, so even if used safely by the user, a hacker can make them less safe.
Yes, this attack requires the hacker to be within Bluetooth range, but it would have been so easy for the manufacturer to include a pairing/bonding function to prevent this.
Something as simple as a button to push to put the straighteners in pairing mode would have solved it.
Instead, we now have a method to set fire to houses.