The Wi-Fi enabled LG air conditioner

[Author credits to Andrew Tierney and Mike Yardley as well]

Whilst at DEF CON 24, we spent most of our time in the amazing IoT Village. We took along stacks of IoT gear for everyone to play with, however one of the main attractions for us is that Independent Security Evaluators bring along ‘smart’ domestic appliances.

This year’s selection included a new Samsung smart fridge, a washing machine and Wi-Fi enabled LG air conditioner. More on the fridge later (after a MITM last year and credential theft via unpinned SSL certs, we had a promising start …).

The air conditioner was a LP1415WXRSM, still available to purchase online. One feature was the ability to use a mobile app to remotely adjust the air temperature and blower speed. A nice feature, particularly if you live somewhere warmer than the UK!

Three of us worked concurrently on it; Mike on the mobile app, Wi-Fi and web service, Andrew on firmware extraction and reversing and I was given the safe spanner-monkey job of dismantling it with extreme prejudice.

Disassembly and firmware

Once we had the back off, we found a really interesting Wi-Fi module – the PCRCUDT3.

Even weirder – it had a USB interface, which cried out to be connected to. Fortunately, we read the manual first  as this is NOT USB and you will likely fry the module if you connect it!

Popping open the casing, we find a nice Atheros module:

Firmware extraction

Finding vulnerabilities often gets easier when we have access to the firmware running on the device.  We often obtain the firmware by downloading readily available updates, or intercepting automated updates. Neither of these were possible with this board. However, the system uses an external serial flash chip to store the firmware. We simply desolder the chip, connect it to a Bus Pirate, and use the open-source tool flashrom to download the firmware. Just like in this image, from a related project:

The firmware unpacks into a filesystem using binwalk, and several of the binaries look like they have interesting functionality in them.

For example, when communicating with the API, the air conditioner needs to send a number of strings before it will interact. These can be discovered in the firmware. Most of these would be fairly easy to derive from other sources, though the ‘x-lgedm-password’ was an interesting find, highlighted below in yellow”

In the second image we can see a few interesting custom binaries that would need more time to investigate thoroughly

We didn’t interact with the API, for obvious reasons.

We’re now a bit stuck as we can’t get the Wi-Fi module back in to the Access Point state without the physical a/c unit. Without that, we can’t continue the research. They’re not on sale over here either…

Mobile app and web service

In default configuration, the Wi-Fi module offers an access point of the format ‘LGE_AC’ and the PSK is ‘lge12345’ – this can be found in the WifiSetting class in the APK:

The IP address is 192.138.1.1, connect on TCP port 9000:

Looking through the mobile app, it’s clear that this is the initial configuration, so that one can connect the mobile app to it and set  up the a/c unit as a client on the users home Wi-Fi network. Pretty standard stuff.

We simply connected to the service and, using clues from the APK, figured out how to control the air conditioner.

Here’s /GetApList being called and generating a list of SSIDs in range:

And /SetDeviceConfig being used to set up the MiFi we were using:

However, there is sufficient functionality to take over an unconfigured air conditioner using calls that can be enumerated from the mobile app. We think that’s a fairly likely occurrence – user buys the a/c unit and (like most IoT devices!) struggles with set up. They give up and simply use it as a dumb device, leaving Wi-Fi running but unconfigured. We’ve seen plenty of examples of IoT devices left in this state, found using http://wigle.net.

So, geo-locate your victim device, connect to the unit, turn it to ‘heat’ on a warm day and cook your victim! Or, if you live in the UK, turn it to ‘cool’ overnight in the winter. Guzzle their electricity too… here’s one in Seattle:

Yes, it’s a silly attack. That’s why we haven’t bothered to go through full disclosure. It’s worth noting that, once correctly configured as a client, the air conditioner to mobile app comms appeared to be reasonably well secured.

Lessons learned

Consumers

Don’t leave your IoT devices in an unconfigured state. Either configure them or switch them off

Manufacturers

We accept that it’s very hard to do SSL on these devices when in an unconfigured state, as it’s hard to get a reliable source of entropy. However, don’t leave full device functionality available in this state.

Give the consumer a physical Wi-Fi button on the unit that they can switch off the RF interface in the event that they decide not to configure it. Make them aware of the issues around leaving IoT devices in default states.

The ‘x-lgedm-password’ is a great example of security by obscurity. A casual hacker attempting to interact with the API would struggle without this value. Without the air conditioner (or at least the firmware) and some reverse engineering skills, they’re not going to find it.

The problem is that someone will eventually find and publish that password. We have it, but we’re not publishing it, to prevent exactly the above.

Obscurity makes things harder, but it doesn’t prevent compromises. It’s important to feature strong security too, in addition to obscurity.