Exploiting the eques elf smart plug: Part four

In part three, we finally figured out how to remotely control the smart power plugs (turn them on or off). In this final part, we are going to see how inadequate security controls can be exploited for various purposes. We are also going to look at one more scenario where the smart power plugs have no internet access.

Part four: Predictability, scanners and a hacker

As we have seen in most of the scenarios, all we need is the mac address of a smart power plug to be able to interact with it. So how do we figure out the mac address of a smart power plug if we’re not on the same network?

The thing is, mac addresses aren’t really random.

The first 6 hex bytes are allocated to an organization. The organization then determines the full mac address to allocate to their devices by using the last 6 hex bytes.

Let us look at the mac addresses of two of my smart power plugs:

dc-4f-22-25-0x-xx

dc-4f-22-25-1x-xx

We can use the first 6 hex bytes to identify the manufacturer:

We can see the manufacturer is Espressif, a company that develops bluetooth and Wi-Fi chips for IOT applications.

In our case, we also see that we have an additional two hex bytes that are similar.

We can therefore assume that a lot of the devices have the first eight hex bytes common. It is therefore straight forward to create a list that starts with those eight hex bytes (dc-4f-22-25-). This will result in a list of 65536 mac addresses.

Next step is to query the ikonkek2.com server for details about each of the mac addresses. We of course know if a mac address is valid, it’ll respond with its details.

We just need to tweak our code to create our scanner then leave it running.

So what did I find?

After querying that range of mac addresses, I got 4149 responses with details about devices. Some of them look like bulbs from the names:

Remember that with just the mac address, we can also query for the email address of the device owner. And the results prove it:

We can continue querying for additional details, including whether a device is on, how many devices are linked to an email and so on.

So what Eques says about protecting this information:

We can see that there is a gap with their security measures. I therefore used the contact information on their website to ask about their disclosure process:

As of the writing of this post, a month has passed.

I am still waiting…

I am sure some of you have been wondering – Did I consider the scenario where the plugs were connected to a Wi-Fi network with no internet access?

More so being that what started all this was trying to have full control of my devices, without them communicating to external servers.

Turns out the smart plugs have a failover mode in case they cannot access the internet. What happens is that all communication happens directly between the phone and smart plug on the local network. The phone sends the query/commands to the plug’s IP address on the UDP port 27431, encrypted with the common encryption key.

The commands start with the word (lan_phone) on the local network as opposed to (wan_phone) when going through ikonkek2.com.

Everything happens over UDP port 27431 with no xmpp involved.

It was therefore much easier to code this functionality and control the plugs as desired. Exploiting the devices while on the same network becomes a trivial affair:

Here I check the status of a smart power plug, turn it off and on:

So what would have made my exploitation attempts more difficult?

  • Obfuscate the app? - Would have slowed me down but dynamic analysis would still have worked.
  • Use encrypted channels for all communication? - Would have slowed me further but dynamic analysis would still have worked.
  • Avoid the use of hard-coded keys? - Would have slowed me further but dynamic analysis would still have worked.
  • Use better authentication when querying details from the server? - Would have likely protected querying of device and user details from the server.

A determined attacker is probably going to figure out a way to beat almost every defence measure. Luckily, if enough of these defence measures are applied together, most attackers will be kept out, or consider it not worth the investment of their time and resources.

So what next?

  • Follow up on the disclosure process.
  • Continue hardware tear down.
  • Investigate more devices :)

The project files and code can be found here.

The vulnerabilities have been assigned CVE-ID: CVE-2019-15745 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15745

Till next time, happy hacking!