A friend asked me to find out why his connected lightbulb app was asking for his location, so I ducked out to Australia’s favourite hardware store, Bunnings, and grabbed one to check out.
The Android grid connect app has 500k+ downloads.
Let’s take a quick look! 🧵
(1/n) https://t.co/RGZDjga8xE
The app has a feature where it can auto discover your BLE devices. Is locations permission needed here? It depends. From Android API SDK v31 things have improved where fine location is not needed for BLE scanning.
The app is forcing this even though we are on v31.
(2/n) https://t.co/6xaV1lV1xf
Let's allow it "for science". The device is paired. We also have the option to enter our Wifi credentials. I assume this is so the light can be remotely controlled over the Internet. It's automatable too. One condition is "when location changes". Let's not touch these.
(3/n) https://t.co/yL5QgZJZEJ
Time to fire up trusty #mitmproxy to look at the network traffic. Traffic is going to http://tuyaeu.com. Familiar domain. I came across Tuya used in a Mirabella Genio Smart light I got at a supermarket.
Tuya is an IoT OEM found everywhere.
postData is encrypted.
(4/n) https://t.co/OuNOulw8nl
Let's pull the .apk from the device and take a look at the manifest. We could of course grab it from APK Pure.
https://m.apkpure.com/grid-connect/com.arlec.gridconnect
Yikes! recording audio, access to camera, location..
Assume there is a legitimate functional use for all of this. Trust but verify?
(5/n) https://t.co/jDPPrTBbuA
Our focus here is what is happening with location permission other then BLE scanning. We need quick wins as this app isn't trivial and is obfuscated. Crypto routines related to the postData appear to implemented in native arm64 within a shared library.
(6 / n) https://t.co/opGU9Y4NO1
Dynamic instrumentation with #frida will really speed things up. JADX can emit a boiler plate hooking .js snippet to use in Frida. We just need to modify to to convert the plaintext byte array passed into encryptPostData from signed integers into a readable string.
(7/n) https://t.co/wE46YPtW46
Looks like it worked! We have visibility on any data that is passed as a parameter to encryptPostData().
No need to reverse the encryption function to figure out how to decrypt the data - we have it before it's encrypted and sent over the wire.
MASSIVE TIME SAVER. 🙏
(8/n) https://t.co/tbJDwjlFao
So far no location data. Are we looking in the right place?
Remember we are after "quick wins". The minimum time investment possible to answer my friend's question "what's it doing with my location" ?
The developer's logging class seems perfect to hook into -… https://twitter.com/i/web/status/1676457124384354310 https://t.co/RocbDYlOW4
You beauty - it worked. We now have visibility into what is encrypted in the postData form field.
We can account for the data in HTTP post towards the Tuya cloud API endpoint.
But what are we exactly looking for?
(10/n) https://t.co/CbRBeiCR0t
Probably these parameters? "lat" and "lon".
hmm.. KEY_IMEI and KEY_IMSI are probably worth looking into too at some point. 🧐🧐
But alas, we must stay on track. KEY_LAT and KEY_LON it is for now.
Live tweeting this enquiry keeping me on track🤣
(11/n) https://t.co/9J3qIyUpoL
ok, we got a match. GPS co-ordinates of where I am - although this was data *received* from the cloud server. How did my location get there in the first place? Perhaps when the application was first installed? Back to square one - but this time we know what to log.
(12/n) https://t.co/mMhF7FQlyE
Application reinstalled.
Boom! we see the exact packet where our GPS co-ordinates are sent to Tuya's remote server over the Internet.
We can identify this in packets that have the "a" field "b.m.sys.location.get".
(13/n) https://t.co/FU4u0qSqmJ
So what do we make of all this?
The developer discloses on the app store that the precise location data collection is optional.
Is this misleading?
What we have discovered in this Twitter thread is that if you try to pair one of their devices via Bluetooth scanning, the app… https://twitter.com/i/web/status/1676491528053870593 https://t.co/2IPhlaum0D
Going to wrap up the live tweeting on this one.
If you found this interesting/helpful, feel free to like/retweet. We need as many people as we can to be encouraged to discover and call out companies that harvest location data from their devices. 15/15
https://twitter.com/haxrob/status/1676416949499338752
It doesn't feel complete with out a map.
Coverage map using advertised BLE device name "TY" and the mac address prefix A8:80:5 (Tuya Smart Inc.) - beaconed out from my lightbulb.
This is why Google (rightfully so) considers Bluetooth scanning "location data"
(..16/15) https://t.co/y6hmXvdC6s
Well this thread certainly took off! In some replies people have asked about the behavior of other similar devices.
I've gone ahead and purchased a few and will live tweet tearing them apart.
Tomorrow this one should arrive in the mail. It's app has 1M d/loads.
Stay tuned! https://t.co/O9fQSegUQY
If you are looking for an accessible summary of this Twitter thread, @hxmonsegur presents well articulated take on the @HackerAndTheFed podcast @ the 7:10 mark:
https://open.spotify.com/episode/6NBHIggsiQe6YZH7Ok6B3E?si=u5e2C_LPQL-vxxSh-WVIRQ&t=429&context=spotify%3Ashow%3A4uze2AoxrCv0dRjvElUpTy