A smart Wi-Fi power plug that almost killed me (literally)
Exploring a Smart Wi-Fi plug when something goes very wrong ..
TLDR; it does leak the Wi-Fi access point SSID directly from the device. Also, it's incredibly dangerous to open these things up, do not recommend.
5:00 PM · Jul 9, 2023
A twitter user mentioned the mobile app for their “smart” wifi connected power plug was requesting their location.
The app has more then 1 million downloads.
Curious, I ordered the ‘Meross’ branded device and it’s just arrived.
What will we find? Let’s dig in
5:55 PM · Jul 9, 2023
Let's see how we can pair with the minimum amount of granted permissions.
Discover "nearby devices" with Bluetooth enabled is a mandatory. It then prompts for precise and approx. location.
Hit deny.
We have to manually connect to the device - it's turned into a wifi AP.
6:16 PM · Jul 9, 2023
I'm impressed. It looks like it's following Google's improvements for Bluetooth scanning on Android SDK API v31+.
Later we will grant location permissions which would be required on an older Android versions. Or if we wanted to auto-setup the pairing.
6:28 PM · Jul 9, 2023
When we tested the Tuya Grid Connect light bulb, it ignored that it was on a new version of Android and forced ACCESS_FINE_LOCATION to use Bluetooth. It then abused the privilege and sent my GPS co-ordinates to their cloud servers.
The Meross app so far is behaving correctly (if you don't use it's auto-pair functionality).
We have much more to explore though. Let's continue on.
6:47 PM · Jul 9, 2023
Next it wants our home Wifi login details to provision into the device so it can connect out to some cloud servers (?)
Let's MITM the traffic to see what's happening.
Problem though - to pair, the app needs to disconnect from our network. BurpSuite looses connectivity.
7:09 PM · Jul 9, 2023
There are a few options.
1) Bridge an inline, transparent proxy between two Wifi access points.
2) Instrument the running code on the phone and hook into http/net functions.
Let's try with 2. I have a feeling it will be quicker.
Decompilation isn't obfuscated
JADX:
Alright, this seems to work - hook into okhttp3.RequestBody to obtain the URL and retrofit2.ServiceMethod for the POST parameters.
I'm sure there is better ways - whatever works though, right? Here is the Frida .js for those that want to play along:
8:28 PM · Jul 9, 2023
This is looking good.
In addition to data sent to the cloud servers, we have visibility of messages from the phone app to the Wifi plug device on our home LAN.
For example, turning power on and off from the mobile app:
8:54 PM · Jul 9, 2023
Messages appear to be signed - mental note to figure how to generate a signature so we can speak directly to the device without an app - later.
I've deleted the pairing of the device and will repair it.
Although it keeps pressuring me...
Click?
Not yet.
10:27 PM · Jul 9, 2023
The content of most HTTP POST requests have the 'params' field base64 encoded. Rather the copy and paste each string by hand, we can decode them in Frida for each HTTP POST request.
Worth the effort? Maybe..
click to enlarge
10:53 PM · Jul 9, 2023
Wifi network ssid (name), bssid (mac address) and passwd are sent to the plug device when it's being bootstrapped from the mobile app.
Also we see credentials to an MQTT server hosted in Tokyo provisioned into the device.
Need to figure out what the device is sending.
click to enlarge
11:38 PM · Jul 9, 2023
Our next move is to try to observe what the plug device is sending to the mqtt server(s).
There are few options here, one being old school ARP spoofing to trick the plug and Wifi gateway to forward all layer 2 traffic to via the Linux box.
A rough diagram of the setup:
12:07 AM · Jul 10, 2023
As a test we tell the Android phone the mac address of the plug is the Linux box and tell the plug the mac address of the Android phone is also the Linux box.
The tcpdump from the Linux box confirms it can see the conversations between the Android and plug, aka MITM.
1:38 AM · Jul 10, 2023
With MITMproxy in transparent mode, intercepted packets can be forwarded to a custom handler.
Someone has written one for MQTT over TLS.
The pre-condition for success now is there is no mutual TLS or certificate pinning involved.
If there is mTLS then we would have to rip the cert out of the firmware. Fingers crossed this isn't the case.
nikitastupin2:24 AM · Jul 10, 2023
... and it worked!
We see the BSSID of the home Wifi router is being sent from the embedded plug device to the MQTT server in AWS (Japan).
Recall we have not once given any location permissions to the mobile app (yet)..
Of course the embedded plug device knows our Wifi access point address - because it's connected to it for Internet connectivity.
Wifi BSSIDs are generally considered "location data". I wonder if there is a genuine use case for the device to report the access point it's connected to?
Oh and interesting, we see the SoC reported is a Realtek RTL8710cf
Time to wrap up for today. The adventure will continue on later.
10:14 PM · Jul 18, 2023
A hesitant update - I offer a cautionary tail of what can go wrong when dealing with mains voltages. The plug decided to seek revenge and a PC has been destroyed with anywhere between 0 to 230v AC sent into a USB port via a ground pin on a FTDI cable.
⚡⚡️How did this happen?
10:25 PM · Jul 18, 2023
On the rtl8710cf there are four GPIO ports. Measuring the voltages on these pads and ground there is a maximum of 3.3v - standard. Safe right?
Not quite - and it has to do with the design of the plug - specifically how the voltage is stepped down.
10:32 PM · Jul 18, 2023
I connected up a logic analyzer which was powered by the USB port on a Macbook Air (this is an important point).
Everything looked fine - actually excellent - we have UART at 115200 baud. Pretty exciting to see a login prompt!
The excitement would not last long.
10:39 PM · Jul 18, 2023
I connected up a bus pirate via the mac air's USB to the plug's UART to try to log in. RX was flaky. A bad connection? The bus pirate?
A FTDI serial to USB cable in arms reach was plugged into a desktop PC. Why not try that? Connecting the ground pin and..
B-A-N-G
10:58 PM · Jul 18, 2023
You see, the plug did not include an isolation transformer.
It used a simple, low cost capacitive power supply design to convert AC mains voltage to a lower DC voltage.
They are particularly dangerous to mess with.
Something similar to this:
11:09 PM · Jul 18, 2023
A huge voltage potential difference was introduced on the ground pin between the desktop PC USB port which blew up the computer. That smell.
This did not occur with the macbook. Why? Take a look at the Apple charger design, courtesy @kenshirriff
11:23 PM · Jul 18, 2023
Ground to mains was isolated thanks to the transformer in the Macbook Air's charger.
A separate isolation transformer should have been used or even better, remove and power the Realtek rtl8710cf off 3.3v.
You win this time connected IoT plug, but I will be back.
12:08 AM · Jul 19, 2023
"There be dragons here "
