Hacker News new | ask | show | jobs
by alvern 2531 days ago
[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...

4 comments

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".

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.
Who cares how accidental it was? If you don't vet what happens in your application and why, you have no right to put it on someone else's computer.
> some of these apps might be using these vulnerabilities without even being aware of it, as the offending code is in third party libraries

I'll assume by vulnerabilities you meant to say exploits. Given that: True but so what. This is criminal behavior. Using criminal libraries makes you complicit and a co-conspirator.

Vet your dependencies. I have no mercy for people who put crap on my phone.
Some might be using them without being aware of but the rest can be nicely permabanned.
How would you go about reliably and efficiently determining which category each falls into?
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.
If you use a library that engages in criminal activity, you are legitimately a criminal as well and should be held accountable.
If these apps get banned because they use poor dependencies, maybe better dependencies will become popular, and developers will also have a reason to be more aware of what code they are using.
And that excuses them how?

Ignorantia legis non excusat

Thought of the day, collecting certain types of information on people should require posting a bond and an annual audit and disclosure.

No bond, no audit, no disclosure -> felony.

If the app can get around the permission system - it’s a vulnerability in Android itself that Google needs to correct.
Sure. And if an app intentionally exploits that vulnerability to bypass the permission system, its developer should no longer be able to publish in the Play Store.
To be fair, denying application knowledge of _device own_ MAC address is beyond absurd. If Google really wants that, they should buy their own MAC block, and regularly rotate the addresses within it when network is off.

A lot of Android own APIs (such as Wi-Fi P2P and Bluetooth) are built on implicit assumption, that application developer knows MAC address of device it is running on. Instead of fixing those APIs, Google now requires everyone using them to request Precise Location permission from user _and_ enable a Location Toggle in device settings. This is pure harassment.

An app developer being able to uniquely identify a device across applications has been considered a privacy violation for well over a decade. Even Microsoft in the Windows CE days made it hard for an app to uniquely identify a device.
The idea itself isn't bad, but Google's implementation of it is terrible. Good actors are forced to show security prompts, that literally scream "this application is malware!!". Bad actors enjoy ability to share MAC/IMEI/whatever with each other and skip whole "prompt for irrelevant permission" nonsense. They don't even particularly care about reading hardware addresses — why bother, when you can embed something like fingerprint.js and automatically identify every single device in existence!

If Google does not improve their P2P networking APIs, everyone may end up eventually integrating some Chinese spyware library, because it is the only approach that does not suck (and there is apparently no penalty for doing so).

Usually apps that exploit flaws in Android are even labeled malicious and actively removed from all devices, this might be even better than just perma-banning the developers.
> If the app can get around the permission system - it’s a vulnerability in Android

That's the same argument as saying that if someone can use a baseball bat to smash in the window to my car, it's a vulnerability in the auto manufacturers glass manufacturing and should be their fault and not that of the car thief. It's an absurd and ridiculously nonsensical argument in defense of criminals.

There's also the concept of white, grey and black hats. Just because someone finds a vulnerability doesn't make it okay to abuse it. The right thing to do is to disclose it, and businesses like Google do benefit from incentivizing it.
Will google dare to ban alibaba?

Alibaba does no effort to conceal that they target ads by IMEI.

Browse Alibaba app*, search something. Do factory reset, make new account, and the first thing you will see after logging in with new acc will be your products from your last search.

Moreover, Alibaba's app will refuse to work if you block IMEI retrieval, or if they detect some kind of spoofing

edit, made it clear that it is the app, not website that links you by imei to your previous accs and history

You know, maybe they should. Same for LinkedIn (assuming they're still doing dirty tricks). Maybe it's time for major app devs that exploit security holes in released applications to get the ban hammer, and show smaller devs it won't be acceptable and have less excuse if/when it happens to them.
Shadowban them with bogus data to pollute their database.
I am a fan of GDPR to be honest.

Banning will hinder them, but it is just case by case band-aid solution.

Risk of huge fine that can put you out of business seems more logical.

How does that work? None of the methods described in this paper seem like they'd work with _websites_. They all seem to rely on permissions only available to native apps.
My mistake, I meant Alibaba's apps
Maybe someone in EU can file a class action lawsuit base on GDPR?

Per description here, it seems have enough legal, $, evident here to make a few lawyers excited?

Not really unless they are stealing PII.
IP addresses are considered PII, and IMEIs are in every way worse than IP addresses.
The router’s MAC is not PII for example. This is why I write that GDPR only applies in case they collect actual PII.
They should be lifetime banned from every Alphabet property. Others have suffered this fate for lesser offenses.
They don't have the will and the courage to ban Facebook/WhatsApp/Instagram from App Store.
Yes. These are malware. It's disgusting.
Belated edit: Anything that does something that you don't want, while pretending to be something that you do want, is malware. Especially if it goes out of the way to do that, evading limits, and hides what it's doing.
Android and all google properties are malware, we just don't have a lot of good alternatives at the moment.
Even Unity? Their CEO says half of all games are built on that. I imagine users would riot if most games were to simply disappear tomorrow.

Or more likely, since it’s Android, the first thing everybody would do is switch to the App store that has all the software they want, even though they know it’s bad.

[edit after reading more of the PDF]:

Yes, even Unity. Unity goes out of its way to get information that it does not have permission to acquire or transmit. It looks like knowledge of this is limited to a few developers who are "in the know" and I would not be surprised if Unity has given that info out to large licensees who have mentioned a need to uniquely identify players without permission.

There's something a lot of people don't know about Unity the company - they are awful. Difficult to work with, constant rumors about managerial scapegoating, questionable sales tactics.. the recent news about the allegations against the CEO didn't surprise me in the slightest.

I don't work with them closely, but I work with them closely enough that I've recommended that my employer cease all interaction with them, including further license purchases. That's how bad the taste in my mouth is after I deal with them interactively in any capacity.

I absolutely agree, and in my experience your list hardly scratches the surface. And awful not in the normal way that many large companies are awful.
Banning is just a band-aid

We need systematic solu...oh wait GDPR - just hit them with all the fines.

The entire Android ecosystem is about abuse. Banning these apps won't help. Google legitimized surveillance capitalism that is the worst that could have happened.
The picture metadata exploit is interesting. It would be trivial to guess the user's home and work location given enough photos with EXIF data (locations and timestamps).

I'm curious how this works on iOS. Granting complete access to "Photos" always seemed overly broad. It should be possible to limit an app to only save images, and/or limit accessing images to photos from the last 3 days etc, or only the images the app has created.

Allowing an app to grab literally years of time and location information (via photo EXIF data) just to do something as simple as saving a filtered picture or opening a screenshot seems bad.

But as someone who loves metadata, I'd can't see myself disabling it altogether. Does anyone know how this works today on iOS? Can an app wholesale upload thousands of pics (or just the metadata) in the background without the user knowing?

> It should be possible to limit an app to only save images, and/or limit accessing images to photos from the last 3 days etc, or only the images the app has created.

It is, but currently this is something that apps need to use the API for rather than it being something that users can restrict.

On iOS, photo write and read access are granted separately, so you can allow an app to only save photos.

Apps can also import photos without any permissions at all by invoking the system photo picker (where the user manually has to pick the photos one by one).

Is it the case that when the app uses the system photo picker, that the app is only ever presented with the photos the user selects? In other words, the app doesn't have direct read access to the main photo library.
Correct.

This is true on both android and iOS, but on android the 'system' photo picker is an intent which fires up the gallery/google photos and typically has a pretty bad user experience, so not many app developers use it.

> 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.

From the paper, it looks like it stores those in `/sdcard/.googlex9/.xamdecoq0962` and `/sdcard/backups/.SystemConfig/.cuid2`. I wonder what would happen if I simlinked those files to `/dev/null`...

Wow. I'll use this paper as a good reason to encourage usage of a firewall (afwall or netguard) for my non nerdy friends. It can stop a lot of this nonsense being reported back, but sadly not all.

I'm thinking there's probably a reporting vector in how an app might use the download manager to leak data.