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 think they could only pull this off by coercing user's into installing a system-level trusted CA on the handset?
Things have improved as this is not trivial to do on Android these days - requiring a filesystem to be remounted as writable - on possible on jailbroken devices.
Let’s grab a copy of Facebook’s banned VPN app from 2019 and install it to see how it manages to spy on other apps on the phone.
Note how it guides me to click invasive permissions such as allowing it to appear on top of other applications. A mobile malware technique.
Interesting, the app still manages to establish connectivity back to Facebook's servers. 😡
That said, once it's VPN tunnel comes up, all connectivity is lost on the handset - so it technically the service is down. 🥹
Back onto the permissions: red flags with requests to:
- display over other apps
- access "past+deleted app usage"
- setup a VPN connection
- make and manage phone calls
All under the pretext to "stay safer" ..
We know better right? But would say, your grandmother?
Notice that we did not see any prompt to install a user certificate - this is really required for the claims made against Facebook to be true (intercept other app's traffic).
Decompiling an earlier version of the APK and it's quite apparent the functionality is there:
Here we can see the file names of the certificates which get added to AndroidCAStore and also how it checks later if they were indeed added.
Fortunately this technique of using intents to install certs no longer works thanks to improvements in Android. 👌
Mind you, none of this is new.. Here in Australia, last year the ACCC dished out out a net $20 million dollar fine for this shadiness.
I'm just curious on the technical mechanism the app went about spying on other apps.
I get the impression the Australian fine was more about harvesting usage analytics from other running apps (see: android.permission.PACKAGE_USAGE_STATS)
Did the regulators consider the MITM (wiretapping) which is central to this new antitrust lawsuit in the USA?
More assumptions related to the $20M fine:
If we dump the schema for the sqlite database "spaceship.db" we see what statistics it was collecting.
No need for fancy traffic inspection for the app get this data. Remember this popup ?
So, so far we have evidence of:
- Code related to the functionality to install a certificate likely for performing MITM attacks.
- Code / internal database related to collecting other app's usage
What else can we find?
Device info (nothing special):
For what acceptable reason would they wanted to obtain the mobile subscriber IMSI? This is particularly sensitive data.
This actually wouldn't work with the app's manifest file. Perhaps we are seeing older code not cleaned up.
Still, not a great look.
A correction on the prior post, the Android documentation on the API doesn't state it but elsewhere says the permission READ_PHONE_STATE would have been enough to obtain the subscriber IMSI.
This Android API change was made in 2019. So IMSIs may have been collected?
If these are accurate statistics, that's some serious telemetry Facebook were collecting from this app (10 million downloads)
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.”
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.
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.