I bought some smart power plugs and they were pretty awesome! These are the Eques Elf smart plugs. They can be controlled using an app through a connected Wi-Fi network, and remotely over the internet.
Everything was going on well till I noticed some strange urls on my home network monitoring system. It turns out it was the smart plug constantly communicating with some external hosts.
My smart plugs were not in my full control! Our journey therefore begins. It was time to void some warranties, figure out what was going on, and hopefully gain full control of the plug.
This is a walkthrough of the process I took and will be broken down into the following areas:
- Network traffic analysis
- Android app reversing
- Dynamic instrumentation
- Native library debugging
- Native library reversing
- Custom exploit tools/scripts
- Hardware teardown
The end goal will be to:
- Gain full control of the smart plug
- Discover any security vulnerabilities
- Develop exploitation techniques and tools
Part One: The homesick elf, some packets and an analyst
I set up my network as below:
The app and smart plug are connected to the same WIFI network. All traffic in the network is mirrored and sent to the Raspberry Pi, which has Zeek IDS set up. The logs are then analysed and visualised by a Graylog server.
We will then run the app and analyse the traffic.
First thing I noted were the following hosts communicating with the app:
And the follwoing communicating with the smart plug:
The first communication I noticed were repeated packets being sent to the broadcast address by the app on udp port 27431.
Following the udp stream, we can see that the data is sent repeatedly. The suspicion is that this is the plug discovery process by the app.
The app then starts communicating with ikonkek2.com on port 9123.
Some more of the sample data sent and the responses can be seen here:
We will come to these messages later. For now note that port 9123 is commonly used by Apache Mina Servers.
When we turn the plug on or off from the app, an XMPP connection is initiated. The app first authenticates to the server using DIGEST-MD5 mechanism.
The app then initiates and xmpp chat to firstname.lastname@example.org using the username [email protected]/android. Note that dc-4f-22-25-xx-xx is the mac address of the smart plug while d4-63-c6-8d-xx-xx is the mac address of the phone running the app.
1 2 3 4 5 6 7 8 9
The plug then responds to the message:
1 2 3 4 5 6 7 8
Note that the chat messages start with the prefix encryption:.
What we know so far
The smart plug listens on UDP 27431. The app sends udp broadcast messages on this port to discover the plug and the ommunication looks encrypted/encoded.
The app communicates with the host ikonkek2.com on ports:
9123 (Apache Mina)
-> Communication looks partially encrypted/encoded and happens regularly.
-> Messages follow the format - descriptive prefix:some encrypted/encoded message.
-> Communication is initiated when the plug is turned on/off from the app.
-> Communication looks to be through encrypted/encoded chat messages.
-> The username of the phone is based on the phone mac address with the word eques appended.
-> The username of the plug is just its mac address.
-> Authentication with the xmpp server (ikonkek2.com) is DIGEST-MD5.
-> XMPP Messages follow the format - encryption:some encrypted/encoded message.
In part two we are going to dig further by looking at the android application itself.