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)
salesforce-marketingcloud.github.io/MarketingCloud…
Would I still recommend this brush/app? 👎
🚫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.
(22/n)
play.google.com/store/apps/det…
Share this Scrolly Tale with your friends.
A Scrolly Tale is a new way to read Twitter threads with a more visually immersive experience.
Discover more beautiful Scrolly Tales like this.