
More than 1k Android apps harvest data even after you deny permissions - spacemanspiffy
https://www.cnet.com/news/more-than-1000-android-apps-harvest-your-data-even-after-you-deny-permissions/
======
alvern
[0] from the researchers pdf:

• We designed a pipeline for automatically discovering vulnerabilities in the
Android permissions system through a combination of dynamic and static
analysis, in effect creating a scalable honeypot environment.

• We tested our pipeline on more than 88,000 apps and discovered a number of
vulnerabilities, which we responsibly disclosed. These apps were downloaded
from the U.S. Google Play Store and include popular apps from all categories.
We further describe the vulnerabilities in detail, and measure the degree to
which they are in active use, and thus pose a threat to users. We discovered
covert and side channels used in the wild that compromise both users’ location
data and persistent identifers.

• We discovered companies getting the MAC addresses of the connected WiFi base
stations from the ARP cache. This can be used as a surrogate for location
data. We found 5 apps exploiting this vulnerability and 5 with the pertinent
code to do so.

• We discovered Unity obtaining the device MAC address using ioctl system
calls. The MAC address can be used to uniquely identify the device. We found
42 apps exploiting this vulnerability and 12,408 apps with the pertinent code
to do so.

• We also discovered that third-party libraries provided by two Chinese
companies—Baidu and Salmonads— independently make use of the SD card as a
covert channel, so that when an app can read the phone’s IMEI, it stores it
for other apps that cannot. We found 159 apps with the potential to exploit
this covert channel and empirically found 13 apps doing so.

• We found one app that used picture metadata as a side channel to access
precise location information despite not holding location permissions.

[0]
[https://www.ftc.gov/system/files/documents/public_events/141...](https://www.ftc.gov/system/files/documents/public_events/1415032/privacycon2019_serge_egelman.pdf)

~~~
Avamander
Ban. These. Apps. And. Devs. Permanently.

It's hypocricy if they let these malicious devs keep publishing but keep
harassing non-malicious developers with things like "How dare you have a
Donate button in your app".

~~~
Ajedi32
It seems like at least some of these apps might be using these vulnerabilities
without even being aware of it, as the offending code is in third party
libraries. Game devs grabbing mac addresses via Unity's API, for example, may
not know that that information is supposed to be restricted on Android.

~~~
Avamander
Some might be using them without being aware of but the rest can be nicely
permabanned.

~~~
mandelbrotwurst
How would you go about reliably and efficiently determining which category
each falls into?

~~~
Avamander
They aren't reliably determining violations of current absurd rules and
people's apps get hit all the time for no good reason, so basically they could
just continue doing what they've done so far.

------
rkachowski
By what set of mechanisms is it possible for the app to access data that
you've denied the app access to? It seems the flaw is in Android allowing this
to happen.

The example given (app accessing photo with embedded gps coords) seems very
specific and doesn't deal with the general notion of data harvesting.

And wrt mac address lookups - for this reason it's not possible to list the
available wifi access points on android without requiring the location
permission. It's pretty absurd that "list the access points that I have
recently received wifi beacons for" is equal to "locate where I am on earth",
but that's the world we live in now.

Whether it's just location data or a larger set of data is unclear from the
article.

~~~
sschueller
Android does not ask for permission to read certain things like the clipboard.
So an app can intercept anything added to the clipboard such as passwords
copied in by password managers.

~~~
imtyler
Wow. The password manager I've been using for the past few years has dedicated
buttons/gestures for copying the password to the clipboard (like many others,
I'd assumed.)

I feel like the expectations in this case are clear: a copied password should
only accessible when the user "pastes" it. (The app even clears the clipboard
after a certain amount of time, making it seem like the only weak point in the
system is the paste functionality.)

To find out that this is not the case is pretty mind blowing. Does anybody
know of any good reasons why the clipboard _shouldn 't_ be secure?

~~~
kalleboo
> _Does anybody know of any good reasons why the clipboard shouldn 't be
> secure?_

Seems like a UI issue to me. Right now apps themselves invoke the paste
command (e.g. they can put a "paste" button in their UI). If you remove
clipboard access from programs, the UI would have to be presented by the OS.

Requiring paste to be initiated by the OS may work alright for text boxes (but
you'd now have to sandbox all the text boxes to avoid the app simulating
taps), but it wouldn't work for say, pasting images.

Another option is to add a dialog box every time asking the user "did you
REALLY want to paste?", but that will quickly get annoying.

~~~
etherealG
I can imagine something along the lines of checking whether user interaction
was the root cause of getting access to the clipboard as a middle ground...
e.g. on web, popup blockers work this way. If a user interacts with a button,
and that javascript series of functions opens a popup, it is allowed. If a non
user interaction function in javascript, say a running ad, tries to open a
popup, it is blocked. Could try the same approach, where only if the user
initiated the current running series of functions, would it be allowed to
access the clipboard. Or even ask for elevated user interaction functions, so
that security teams would have an explicit list of elevated functions that are
allowed to access sensitive data, allowing for easier manual checks. Anything
else would have the annoying confirmation.

------
panpanna
> The update will address the issue by hiding location information in photos
> from apps and requiring any apps that access Wi-Fi to also have permission
> for location data, according to Google.

The great minds at Google have done it again!!

This craziness (Bluetooth requires location) was the reason I never bought a
smartwatch. I guess now I should stop using internet too.

~~~
wartijn_
According to Google Bluetooth requires location, because it van be used to
find your location. So there is some reasoning behind this decisions, although
I wwould be mutch happier with something like: Location (Bluetooth), location
(GPS), location (WiFi)

>A location permission is required because Bluetooth scans can be used to
gather information about the location of the user. This information may come
from the user's own devices, as well as Bluetooth beacons in use at locations
such as shops and transit facilities.

[https://developer.android.com/guide/topics/connectivity/blue...](https://developer.android.com/guide/topics/connectivity/bluetooth.html#Permissions)

~~~
panpanna
Please take a step back and look at this again.

What is the cause and what is the effect here? Is Google's solution making it
better or worse from a practical privacy point of view?

(Also, don't buy Google's explanation that this is just to inform users of
potential misuse - they actually log your location and even wait for a GPS
lock when you pair a new device)

~~~
the_jeremy
Why shouldn't I buy Google's explanation?

If an app that uses bluetooth can get my location via beacons or etc., then
bluetooth should be wrapped in location privileges. An app that I do not want
having my location should not be allowed to use bluetooth, and I have to
accept that any app that does use bluetooth could get my location.

While it does mean that apps that use bluetooth now have a slightly easier way
of getting location (i.e., via phone GPS, not just bluetooth), we shouldn't
obfuscate that bluetooth is another way to get that information. In the end,
you are trusting the app developer with the privilege of knowing your
location. If you don't trust them with that, then they can't be allowed to use
bluetooth, full stop.

~~~
altfredd
> Why shouldn't I buy Google's explanation?

Because Google is notorious for coming up with bogus explanations whenever
they get caught red-handed. Every month there is a bunch of news articles,
where high-ranked Google employee claims to spy on everyone to "protect people
from electric pigs", "lower the danger of Confucian Jihad", "enrich e-mail UX
with hefty data-harvesting" or something along those lines.

> If an app that uses bluetooth can get my location via beacons or etc., then
> bluetooth should be wrapped in location privileges.

There is no reason why apps have to be able to "get location from beacons" in
order to connect with another phone over Bluetooth. Same for P2P Wi-Fi API —
pairing with another device already requires exchanging tokens via graphical
dialog with explicit user approval on both devices. Removing ability to read
scan results from API would be enough to fix the underlying data leak. Once
two devices are paired, they should be able to exchange data without need for
any permissions or user actions.

Instead Google forces users to keep Location enabled long after initial
connection is made. Even if there is no underlying bad intention, they should
be ashamed of forcing such garbage UX upon people.

------
newscracker
_> Egelman said the researchers notified Google about these issues last
September, as well as the FTC. Google said it would be addressing the issues
in Android Q, which is expected to release this year._

A whole year to get a solution out?! Google is clearly demonstrating where it
stands when it concerns privacy.

With the usual low penetration of the latest release of Android, this will
probably be “solved” for the majority of the devices in four years from now.
Sigh!

Edit: Why not crack down on apps through updates to the Play Store policies
and rules? Apple seems to use that tactic sometimes.

~~~
izacus
> Edit: Why not crack down on apps through updates to the Play Store policies
> and rules? Apple seems to use that tactic sometimes.

Google has been doing that a lot lately and has created the appropriate amount
of heavy complaining from the side of developers. Still, auditing source code
for every one of those things is pretty much impossible - even iOS apps use a
lot of such tricks to fingerprint users and Apple has a hard time keeping on
top as well.

------
DoofusOfDeath
Would any/all of these methods be violations of U.S. criminal laws against
unauthorized computer access?

They seem to contravene the computer owner's explicit choices about allowed
access.

~~~
hedora
I think this behavior is covered by existing criminal law. If not, the law
needs to be updated.

Replace “phone“ with “web server”, and you will find legal precedents showing
that much of the behavior is criminal.

In particular, it is clearly not legal to walk the file system tree to obtain
access to private data you were explicitly denied access to, and then directly
profit from the data you illegally harvested.

Failing to strip exif location data, even though gps access was denied? That’s
a gray area, at worst.

(I am not a lawyer.)

------
driverdan
Why do they have to wait for Android Q? Couldn't they pull the apps now?

~~~
izacus
They can pull the apps, but Android Q will add several additional security
features - e.g. scoped storage (no more SD card access without user consent),
EXIF location stripping (accessing EXIF from photos will require additional
permissions) and plugging of several possible fingerprinting sidechannels.

~~~
antpls
This really feels like a cat and mouse game, with Google not actually trying
to solve the issue. The proposed additional security "features" will give a
false sense of security.

Any way for 2 apps to communicate together will be exploited for the same
purpose in the future. Google would have to fix the issue in a more
fundamental level, which requires better understanding of users habits and
wishes in term of privacy.

But obviously, privacy-oriented users are the worst users for an ad network
machine...

------
z3t4
By default apps should not be able to call home, in order to save battery and
data plan, ohh and also privacy.

~~~
VectorLock
So don't let them.

Doesn't work so well on apps that by their very nature and a variety of
contrived reason have to call home.

------
HillaryBriss
The Android platform and Play Store place too much trust in the integrity of
app developers who are forced to occupy an intentionally low-profitability app
ecosystem. Google will never expend the effort to filter out all of the
malware. It's too expensive. Google is too inefficient and the dev teams are
too loosely managed.

------
unfoldedCravat
There certainly is a way to make it so an app can ‘add photos only’ on iOS. I
have only seen it used a handful of time and some apps like Facebook Messenger
where I’ve somehow got that permission setting set in the past actually ignore
it and demand full access despite just trying to save a photo.

[https://stackoverflow.com/questions/46341694/detect-add-
phot...](https://stackoverflow.com/questions/46341694/detect-add-photos-only-
permission)

------
m-p-3
> Google said it would be addressing the issues in Android Q, which is
> expected to release this year.

How nice that many of the phones out there will never see this vulnerability
fixed.

------
colechristensen
Phones and web browsers are not secure, not even a little tiny bit.

It is problematic that it is nearly impossible to go unidentified and
untracked, constantly. IoT makes this so much worse because now nearly
everything around you is constantly harvesting data, I am somewhat personally
embarrassed about how little attention I have paid.

------
VectorLock
Sandboxes are never safe.

But man some of these bypasses are getting into evil genius level of shady
cleverness.

~~~
jjakque
Is it tho? or is the OS just too relaxed on security?

Think old Windows that people always ridicule, the publicity was rare on
calling out bad practice/intentions, it has always been the fault of the OS.

~~~
VectorLock
We're asking the sandbox to be perfect and that'll never be a thing. It's
always a race between the sandbox makers and those trying to escape it.

------
Causality1
"Google says a fix won’t come until Android Q."

Meanwhile Android Q is going to gut a number of power user features, like any
ability to wardrive or create a decent signal strength map of your home or
workplace.

