Android Master Key Vulnerability Checker Now Live

darthcamaro writes "Last week, Rain Forrest Puppy (aka Jeff Forristal) first disclosed the initial public report about an Android Master Key flaw. Code was released earlier this week for attackers to exploit the flaw — but what about users? Google has claimed that it has patched the issue but how do you know if your phone/carrier is safe? Forristal's company now has an app for that. But even if your phone is not patched, don't be too worried that risks are limited if you still to a 'safe' app store like Google Play. 'The only way an Android user can be attacked via this master key flaw is if they download a vulnerable application. "It all comes down to where you get your applications from," Forristal said.'"

Even the Android fanboys know

[MoronGames]

That most phones that are "in the wild" will probably never receive this patch unless they are current flagship devices. That said, do not download things from untrusted sources! That goes for not only smart phones, but computers as well!

Re:Even the Android fanboys know

[h4rr4r]

1. People seem to not care. This is why I only buy Nexus devices though.
2. Totally correct.

I wish google would use their leverage over the android trademarks, not the software, to force updates for X amount of time and a longer amount of time for security patches. The real issue here is the whole carrier model. If you bought your PC from your ISP and they provided all the software for it you would be in the same boat there.

Re:

[jeffmeden]

1. People seem to not care. This is why I only buy Nexus devices though.
2. Totally correct.

I wish google would use their leverage over the android trademarks, not the software, to force updates for X amount of time and a longer amount of time for security patches. The real issue here is the whole carrier model. If you bought your PC from your ISP and they provided all the software for it you would be in the same boat there.

Except, that is exactly what Google is doing. This vulnerability is being patched by pushing updated apps directly to the phones via the shadowy Google "remote control", and the carriers don't need to do anything about it. My handset was patched as soon as the Google updates started rolling out, and my carrier could care less.

Re:

[h4rr4r]

I more meant for vulnerabilities in the phones non-writeable partitions. /system is normally mounted read only. So if you need to patch something more basic to the OS, I would assume a carrier would be standing in the way.

Re:

[h4rr4r]

What do you think root exploits often are?

Any APK could contain one and use that to do anything it likes. The only trick would be getting users to install it. Which for most users just means telling them their is a shiny bunny or sexy woman in the application.

Re:

[h4rr4r]

RageAgainsttheCage was one it, used an adb setuid exhaustion attack, and there was a udev exploit. These were patched in AOSP a long time ago, but some devices never got updates that closed these holes.

The android app store keeps these things from being put in apps from there, but nothing stops them from ending up in alternative (read pirate) app stores.

Sure the fact that most people never enable third party apps and stick to the google store keeps them mostly safe. It simply would be better to go ahead and

Re:

[Dishevel]

What do you think root exploits often are?

Any APK could contain one and use that to do anything it likes. The only trick would be getting users to install it. Which for most users just means telling them their is a shiny bunny or sexy woman in the application.

I am very ok with those people getting infected.

Re:

[Beardo the Bearded]

Sexy bunny woman? Where do I click?

WHAR LINK WHARE?

Re:

[h4rr4r]

You are basing this on what exactly?
What OS version are you running?

Re:

[Anonymous Coward]

I am basing the fact that I am vulnerable on the Bluebox Security Scanner app linked in this article. My Nexus 7 is running Android 4.2.2

Re:

[Rob Y.]

Ditto. My Nexus 4 has never received an OS update (unless it does this silently, which My old Nexus One never did).

Anyway, it's running 4.2.2 with a build date back in January.

Re:

[Rob Y.]

That said, and even though I'm rooted (hey, is that why I haven't gotten any updates - I'm still on the stock ROM), I don't believe I've been hit by this exploit. Has anyone?

Re:

[h4rr4r]

So the mere risk of something bad happening means you have to give up control to someone else? It's almost like personal responsibility is totally dead!

Re:

[h4rr4r]

That hot coffee lawsuit was not frivolous. This is an urban legend, they had been cited many times since it was too hot to safely drink. She suffered serious burns and required skin grafts.

Personal health insurance mandates are personal responsibility. You not having insurance and using the ER then skipping on the bill costs me and other insured folks money.

Unemployment does not last forever, and employed folks are paying for it. I sure as hell expect to be able to collect from an insurance policy I buy.

Re:

[Dishevel]

It was frivolous. People got that coffee BECAUSE it was that hot. We got it because it lasted the commute. I knew it was really fucking hot. It was not her first time getting coffee there. She made the decision to purposely buy that coffee having already known how hot it was. They coffee temperature did not come as a surprise to her. If I buy something that I know is really hot and decide to buy it anyway then I spill it, it would be my fault. Only in the last 20 - 30 years have we been so ingrained as a pe

Re:

[h4rr4r]

The coffee was undrinkable, it would have cooked your insides.

You can't sell a product not fit for purpose. Personal responsibility would have been McDonalds covering all her bills and giving her a nice settlement with no lawsuit. Instead McDonalds wanted someone else to cover their debts.

Re:

[Dishevel]

So you are saying that she did not ever have McDonalds coffee before? That she had no knowledge of the fact that their coffee was considerably hotter than that sold by most other chains? Or. Are you saying that regardless of the fact that she made an informed decision, it still must be the rich guys fault.

Re:

[sjames]

With great power comes great responsibility.

Re:

[RaceProUK]

Engilsh

Re:Even the Android fanboys know

[somersault]

It's in a dialect of English usually known as Careless Autocorrect

Re:

[Beardo the Bearded]

Your smart phone IS a computer, FFS.

My new G3 has a dual-core 1.5GHz processor, 2G RAM, and 80G of SSD on a 720-line display.

My old netbook has a dual-core 1.5GHz processor, 2G RAM, 256 SSD and a 600-line display. (Until a month ago, it was my primary computer.)

They both run Linux (CM and Ubuntu, respectively). They both play movies. The phone will play better games than the netbook. I can carry the phone around and have it track my bike rides and runs.

They aren't phones. They're socially acceptable co

Split-screen

[tepples]

I agree that an Android smartphone is a personal computer. But when you plug your smartphone into an HDMI cable, how many windows can you keep open on the screen at once? Like you, I own an Android device and an Ubuntu netbook, in my case a Dell Inspiron mini 1012. When I'm programming on my netbook while riding the bus to and from work, I routinely split the screen down the middle to see the source code on the left and the output, another source code file, or documentation on the right. I imagine that even

Re:

[Beorytis]

That said, do not download things from untrusted sources!

Especially a thing claiming to be "Vulnerability Checker".

Re:

[bill.e.gloat]

I only ever install from the Play Store with the single exception of the Avast Anti-Theft app. While Avast AV itself comes from the Play Store, I have to enable the option for downloading from untrusted sources to get the Anti-Theft portion. Why is that? (It seems poor design, but I assume there's a good reason.) I figure that if I trust Avast for AV than I should be able to trust their instructions for Anti-Theft. I always disable the untrusted sources feature immediately after the install/update, but

Is there an App to check for bogus APKs?

[Jah-Wren Ryel]

For people who are stuck with vulnerable phones it should be possible for an app to scan the .apk you are considering side-loading and checking if it is a trojan using this particular vulnerability.

Re:

[Jerry Atrick]

It should be easy to catch the package installed/updated broadcast and intercept exploits immediately after they install but before they can execute. About 20lines of Java should do it.

The other interesting aspect of this exploit is you could automatically strip the malware payload and recover the safe, original apk, or a close enough facsimile of it.

Re:

[Jerry Atrick]

If they have any sense the built in scanning will detect the malformed APK before allowing it anywhere near the installer service... it is trivially easy to detect.

Re:

[raburton]

I would assume opening the file in your favourite zip tool and checking there is only one classes.dex file should be sufficient.

Master key?

[synackpshfin]

I have no idea what the mentioned 'master key' is supposed to be.
AFAIK the actual exploit is using duplicate filenames which aren't checked against hashes upon installation of apk...

Re:Master key?

[Andy Dodd]

That was the word Bluebox used to describe it... Honestly, their original press release blew this way out of proportion.

Most Android devices now have support for scanning of sideloaded APKs for Malware now (it's a Google Play service), and I'm assuming that while a week or two ago that detector wasn't configured to detect this exploit, it almost surely does by now.

Re:

[jeffmeden]

That was the word Bluebox used to describe it... Honestly, their original press release blew this way out of proportion.

Most Android devices now have support for scanning of sideloaded APKs for Malware now (it's a Google Play service), and I'm assuming that while a week or two ago that detector wasn't configured to detect this exploit, it almost surely does by now.

Why should that get in the way of a good story? "Master key" sounds like something that will grant anyone access to your device, any time they want, without your permission, and plays so well with the "Android devices take months/years to get patched" meme. Which is all much more salacious than the reality, considering that only apps intentionally sideloaded by the user (After deactivating the default protection) can run with unchecked permissions, IF you havent gotten the Google Play Store updates yet, w

Re:

[chowdahhead]

My understanding is that the Play store was patched, so this vulnerability can't be exploited for apps uploaded to and downloaded from there. The AOSP patch addresses the part of Jellybean that verifies the cryptographic signature of sideloaded apps. That has to be updated on the device end--it's the "Verify Apps" option in the security menu. It's not part (yet?) of Google Play Services; it works without GApps installed. However, if you don't download .apk's from the internet, which 99.9% of people don'

Re:

[Andy Dodd]

" The AOSP patch addresses the part of Jellybean that verifies the cryptographic signature of sideloaded apps. That has to be updated on the device end--it's the "Verify Apps" option in the security menu."

Nope. Those are two separate things. The "Verify Apps" operation applies some or all of the same Play Store checks to sideloaded apps, and I believe is only available with gapps installed (I'll poke at that this weekend.)

The signature verification is part of the core Android system (even without gapps) a

MITM

[SirJorgelOfBorgel]

I'm not sure if this is still true, but I do know that last week the Play store was still using HTTP downloads for the actual APK files instead of HTTPS (even though the API calls do use HTTPS). As such, even downloads from Play may be susceptible to man-in-the-middle attacks. I can't possibly explain it better than this group of comments:

http://it.slashdot.org/comments.pl?sid=3950207&cid=44220885 [slashdot.org]

I'm not saying it's likely - but it doesn't seem impossible either. Seeing as it will be a long time before the average Android user will be running a phone with this patch, I would call "crisis averted" too soon. Of course, we don't know if the complete HTTP download is still verified with checksum gotten from the HTTPS API, but somethow I doubt it.

Re:

[PNutts]

I tried Googling this issue, and I couldn't find any sources to back it up. Seems like someone would have mentioned it...

Try Bing. ;)

Re:

[Applekid]

I'm not sure if this is still true, but I do know that last week the Play store was still using HTTP downloads for the actual APK files instead of HTTPS (even though the API calls do use HTTPS). As such, even downloads from Play may be susceptible to man-in-the-middle attacks. I can't possibly explain it better than this group of comments:

http://it.slashdot.org/comments.pl?sid=3950207&cid=44220885 [slashdot.org]

I'm not saying it's likely - but it doesn't seem impossible either. Seeing as it will be a long time before the average Android user will be running a phone with this patch, I would call "crisis averted" too soon. Of course, we don't know if the complete HTTP download is still verified with checksum gotten from the HTTPS API, but somethow I doubt it.

A feature at the request of the NSA or your local union spook agency.

Re:

[Knuckx]

And what prevents you from doing this with any executable file format, be it APK, EXE, ELF or JAR? Diassemblers, unpackers and resource editors exist for all of those file formats. If you can run it, you can edit it, unless the format/architecture is totally undocumented.

Re:

[Jerry Atrick]

The signing isn't meant to stop that, it's meant to stop updates to installed apps being replaced by malware. Re-signing won't let you update an installed app, you have to trick the user into uninstalling first. Which usefully can't be done for system apps by non-rooted users. Can't directly be done by any user.

Ultimately all signing does is verify that your still dealing with the packager of the existing installed copy. The chain of trust still depends on trusting the first install, with this bug you're no

Establishing trust through SSL CAs

[tepples]

The chain of trust still depends on trusting the first install

There are ways to establish trust for the first install even if it is not from Google Play Store. For example, if I download the APK of VLC from https://www.videolan.org/ [videolan.org] then I'm piggybacking on the SSL CA infrastructure, which assures me of one of the following:

• A. The APK is authentic.
• B. Somebody compromised www.videolan.org and uploaded a trojan.
• C. A man in the middle compromised the private key of www.videolan.org and my Internet connection.

How likely are the scenarios other than A?

Conflict of interest?

[140Mandak262Jamuna]

So this flaw affects mostly app stores competing with Google marketplace. Not fixing this bug would give an edge to Google's marketplace. Though it is orders of magnitude different, this was similar to a situation early in the days of IE-vs-Netscape fights in the early days.( IIS and IE would work around each other's bugs making other web servers and browsers appear to be broken). How is Google handling it?

In some strange way Google is having the cake (open and competing app stores, instead of the total lo

Re:

[Merk42]

The flaw doesn't affect 3rd party app stores any more than it does Google's. The issue is that an app store could host an app that takes advantage of said bug. As the Play Store is the most trustworthy to not do this, it is the recommended store.

Re:

[BasilBrush]

Android is a phone for ordinary consumers. 13 year old girls, middle aged builders, grandparents, everybody. Do they all know that "Full Network Access" is a clue that it might be a scam app?

Re:

[Beardo the Bearded]

A lot of people don't read that.

My co-worker has a taxi company's app. They want full permission for everything. I didn't load it.
https://play.google.com/store/apps/details?id=com.appbuilder.u66459p124918 [google.com]

Same with the Cineplex app. Way too many permissions for something that's just showing a ticket:
https://play.google.com/store/apps/details?id=com.fivemobile.cineplex&hl=en [google.com]

Privately

[tepples]

People who choose not to install can always contact the application's developer privately.

Permission rationales

[tepples]

Most of the permissions on the Cineplex app are perfectly justifiable. "Full network access" is needed to contact the payment processor and venue to buy your ticket. "Add or modify calendar events" is to remind you when the event for which you bought a ticket is about to occur. "Take pictures and videos" appears to be needed for scanning barcodes on tickets and related documents. And perhaps "precise location" is used for getting directions to the venue. My only suggestion is to make Google Play Store requi

Re:

[Miamicanes]

> Simple enough, if your app knows what it needs to do, there is no need for "Full Network Access". I smell scam app.

Or an app that, like 98% of the free apps in Android Market, embeds Google's ads in the app. Then it needs full network access, coarse location, and read phone state & identity, among other things. It's the killer flaw in Android's permissions system... to serve ads from any common ad network, you have to practically give the app complete access to everything.

Instead of embedding ad-ha

CM 10.1.1

[Riddler Sensei]

For those running Cyanogenmod this has been patched in 10.1.1 [get.cm].

Re:

[Miamicanes]

Here's the scary part -- 10.1.0rc5 is STILL the latest non-nightly build you can get for d2att (AT&T Galaxy S3), and it's ABSOLUTELY still vulnerable. I just ran the checker app now. :-(

Re:

[Riddler Sensei]

Huh, are these d2att stable builds [get.cm] not what you're looking for?

It is about the appstore you use.

[briancox2]

If it's about the appstore you use, then F-droid has a leg up. Unlike Google's, everything on F-Droid has had human eyes look at what it does.

Re:

[briancox2]

While the only guarantee on Google's is that no one has checked a single line of the code, besides the author.

F-Droid, games, and anti-features

[tepples]

According to this post [f-droid.org], using any of the anti-features [f-droid.org] will hide an application from most users. How should one fund the development of, say, a video game to be distributed to users who have switched to F-Droid without putting in ads (which requires the "Ads" anti-feature) or charging for mission packs after the first (which requires the "NonFreeAdd" anti-feature)?