With the (fake) toothbrush botnet story still fresh, Colgate's connected Bluetooth toothbrush caught my eye on discount at the local supermarket.
"Hi there, let's get to know each other"
Sure, let's do this. What will we learn? (1/n) 👇
Happy to see that the Android app has responsibly requested the minimum permissions for BLE scanning. I kind of was expecting it to request my location for this which it didn't. (2/n)
Pulling the .apk off the device, the AndroidManifest.xml indicates a few permissions that warrant further investigation. Let's assume (for now) location perms (when granted) are only for BLE scanning on older Android releases.
Still this doesn't feel quite right. (3/n)
It look's like you can't continue to use the app unless signing up first. The privacy policy looks well written with very specifics of what data will be shared.
@mitmproxy has been running in the background. Wonder what the app has sent so far? (4/n)
Pretty standard stuff so far - Notably employing Salesforce's Marketing Cloud platform SDK and Instabug.
I guess it's time to signup... And yes if you were wondering, you can brush your teeth without doing so.🥹
(5/n)
Ok, well not quite - One is informed that they must now update the toothbrush's firmware before continuing to use the brush.
This of course presents the ideal opportunity to grab the firmware to look at later. (6/n)
Well not really great: The app reports back the toothbrush's Bluetooth device address to a backend REST API (which is Kolibree - the smart toothbrush OEM vendor).
The BLE MAC/device addresses could be considered to be location data.
Do they really need this data?
(7/n).
Scanning BLE advertisement beacons with bettercap confirms this is the toothbrush's mac.
Will certainly be looking into the BLE interface more later. Now, time for some dinner.
(8/n)
It's looking pretty straight forward to reverse the "toothbrush protocol" between phone and brush. It's apparent there is no hand baked crypto over what the BLE stack offers. Static member variable names were not stripped out allowing us to work backwards a bit easier.
(9/n)
We can now communicate with the toothbrush as we like... But I'm left thinking - where are we even going with this? (10/n)
(video has 🔊)
Next up, Home Assistant integration for Colgate toothbrushes..... Or not.
Calling it a night. It's been fun folks.
(11/n)
If you want a map of some people's house's in Australia where this brush is a resident, search with the the MAC '18:7a:3e', network name LC_
is aggressively restricting BT API lookups for new accounts so your milage may vary. (12/n)wigle.net wigle.net
If you were having any thoughts of stealing someone's toothbrush, you better think again... 🥷
(13/n)
If anyone had expressed doubt that Bluetooth device addresses could be considered 'location data', here is a list/map of same model toothbrush scattered around 🇦🇺
(14/n)
Other toothbrush model/brands from the same connected toothbrush OEM:
(15/n)
I've come to the conclusion that the developer behind this Toothbrush app has been somewhat responsible, minimising what permissions the user has to grant in order to use the device. Unlike most of the Bluetooth IoT rubbish out there, they only ask for what they need:
(16/n)
That said, there is unpleasant location + geofencing code in the embedded Salesforce Marketing Cloud SDK.
This looks unused, although due diligence mandates that we need to observe how the app behaves on older Android SDK releases with ACCESS_FINE_LOCATION granted.
(17/n)
Well this is interesting.
Slapping together a quick and dirty Frida script, it's observed that at run time, the Salesforce SDK explicitly checks if the toothbrush app had been granted fine location permissions (granting access to user's GPS coordinates).
Why?
(18/n)
After modifying the manifest and hooking into a method to request FINE_LOCATION on toothbrush pairing (simulate behaviour on older device), so far no location data has been sent by the app. That said, it does inform Salesforce that location permissions have been granted.
(19/n)
The app does not call any method to enable location based geofencing or beaconing with the Salesforce Cloud SDK.
While the functionality exists, Colgate's brush app appears not to harvest GPS data. It behaves responsible in this regard.
(20/n)
🚫Sends broadcasted Bluetooth device address to an OEM brush vendor cloud (location data)
🚫Sends analytics to Salesforce marketing cloud
🚫Sends brushing behaviour to Colgate
It's a solid toothbrush though. Just don't pair it. (21/n)
Given the observed telemetry to four separate companies/cloud services, the "No data shared with third parties" may not be so accurate.
App store privacy/data handling disclosures should never be taken at face value.
When pairing your mobile phone to that Wifi / Bluetooth device and it forces you to grant it location permissions, pause for a moment to think who may be the beneficiaries of this information.
Case in point:
The Dyson app refuses to pair to their devices such as this fan/heater/air purifier - unless you give in and give them your location data.
This is a premium product at a high price point. Surely they are not monetising this ?
What’s the privacy policy say? …
Dyson disclose in the fine print that the app will continue to “collect and use data about your location in order to provide you with more relevant and personalised information.”
Checking the archived APK listing for "Onavo Protect" from 2019, likely just before it was pulled from the Play store, the description discloses some information on what they are up to, but then proceeds to gaslight the user.
I recently found two very interesting Linux binaries uploaded to Virustotal.
I call this malware 'GTPDOOR'.
GTPDOOR is a 'magic/wakeup' packet backdoor that uses a novel C2 transport protocol: GTP (GPRS Tunnelling Protocol), silently listening on the GRX network (1/n) 🧵
One version uploaded from 🇨🇳 has zero detections on VT. The other, uploaded from 🇮🇹 has just one detection.
These were uploaded 4 to 5 months ago.
(2/n)
As they binaries were not stripped, they contain some artifacts that give us an idea of the intended platforms they were to be run on - Very outdated Red Hat Linux machines.
Someone hasn't been keeping their systems up to date .. 🤔
The Chinese APT contractor leak contained a few interesting files; namely:
- CDRs (Call Detail Records)
- LBS (Location Based Services) db records
Threat actors compromise telcos with the aim to obtain subscriber metadata to support IC objectives.
Some background: (1/5)🧵
CDRs are primarily used for postpaid billing and reporting purposes. They are generated in various network elements and consolidated in mediation systems.
It's these central databases that are often targeted. Data for a subscriber is generated in many systems:
(2/5)
Looking at the leak data: For example, this one is from old school circuit switched 2G voice calls.
What's of value from an intelligence perspective is is who talked to who and from where. Origin of data likely from MSC CDRs.