google-play-logo

It seems a couple of academics from Columbia Engineering in the US have found a fairly major flaw in apps on the Google Play Store, and it’s perhaps not what you might have guessed. Professor Jason Nieh and PhD candidate Nicolas Viennot might have been looking elsewhere, but they found something that has the potential to be fairly serious:

Nieh and Viennot discovered all kinds of new information about the content in Google Play, including a critical security problem: developers often store their secret keys in their apps software, similar to usernames/passwords info, and these can be then used by anyone to maliciously steal user data or resources from service providers such as Amazon and Facebook. These vulnerabilities can affect users even if they are not actively running the Android apps. Nieh notes that even “Top Developers,” designated by the Google Play team as the best developers on Google Play, included these vulnerabilities in their apps.

According to reports, Google is already working with the researchers and Play Store developers to make sure that any security implications are minimised. Viennot says that his team has been working closely with Google, Amazon, Facebook and others to minimise the risk and to make the Play Store safer than it already is.

The Play Store already has security checks in place to prevent malicious apps from gaining traction, such as continual scanning of apps for malware even after installation to keep users to safe.

There were some other findings, which probably aren’t too surprising, such as up to a quarter of free apps on Google Play being clones (or fairly direct copies) or other apps. If you’re interested in the full study, hit the source link below.

Analysis: All apps that make use of API calls from big providers generally require secret keys to access; Twitter’s API for example requires that an app authenticate itself with a secret key and token — with these two pieces of information, the app can read tweets, messages, and the like, on behalf of users who have authenticated against that app. Gaining access to a Twitter app’s secret key and token won’t get you too far though; to do any real damage, you’d also need to have a copy of a given user’s secret key and token as well, which are generated per app and per user.

Someone who had access to your phone, for example, could theoretically extract the secret keys and tokens used by an app to authenticate the app and any user accounts you’ve connected to that app, and with those, they could do some damage. It is possible that a piece of malware could grab these identifiers off your phone, but Android’s permission model would make this rather impossible, unless you’ve rooted your handset and granted the malware root permissions without knowing what it was trying to do.

In short, the chances of this kind of finding being exploited by malware are pretty slim, and even then, would really only be of practical concern for a small number of users. Let’s face it, users who are sufficiently technically inclined to root their handsets are probably going to be pretty careful about installing questionable apps, much less granting those questionable apps root access.

These findings are a flaw in the process, but not a critical one. Not from my perspective, anyway. A few other places in Android space have picked up this story and run with it as a super security flaw… but it just isn’t.

The same vulnerability exists on Apple devices, as it would with Windows Phone and even Blackberry; it stems from API access requirements, not the Android platform. On other platforms, though, the risk of these secret tokens being exploited might be ever so slightly less, but it’s still pretty miniscule.

Source: TheLoop.
Via: phys.org.
    2 Comments
    newest
    oldest
    Inline Feedbacks
    View all comments
    bob

    Another problem, users who comment before reading the entire article.

    Still, clickbaity misleading headline…

    bob

    This is not a flaw in Android at all. The same problem (clueless devs) exists in all ecosystems, so why not say iTunes etc. too?