Slashdot Mirror
Researchers Find Methods For Bypassing Google's Bouncer Android Security
Trailrunner7 writes "Google's Android platform has become the most popular mobile operating system both among consumers and malware writers, and the company earlier this year introduced the Bouncer system to look for malicious apps in the Google Play market. Bouncer, which checks for malicious apps and known malware, is a good first step, but as new work from researchers Jon Oberheide and Charlie Miller shows, it can be bypassed quite easily and in ways that will be difficult for Google to address in the long term. Oberheide and Miller, both well-known for their work on mobile security, went into their research without much detailed knowledge of how the Bouncer system works. Google has said little publicly about its capabilities, preferring not to give attackers any insights into the system's inner workings. So Oberheide and Miller looked at it as a challenge, an exercise to see how much they could deduce about Bouncer from the outside, and, as it turns out, the inside."
..Is that what they call themselves these days?
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
This is why I hate Android in the corporate environment. While I love open technology for personal uses, trying to manage corporate security with Android in the mix is a nightmare. I can have a nice pretty policy that makes upper management happy but I have no really good way of enforcing it. For the pain in the butt that Blackberry is, it was designed around corporate security. Apple is a step above Android in this regard, but it is still not designed with corporate use in mind.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
And here I thought researchers were looking for a way to break into the secret google night clubs. Everyone knows that's where all the cool nerds are.
Keeping this analogy, it does seem about as effective as an actual bouncer. While most drunken retards are being thrown out on the streets, the dangerous, more vile types get to stay inside and ultimately take drunk chicks home. I suppose it's nice to have less people throwing up on you, but getting stabbed at a nightclub is still getting stabbed at a nightclub. I suppose you could draw the argument that there's a pat-down and weapons check at the door, but let's be real, if you were going to bring a weapon to hurt someone in the first place, you'd be smart enough to hide it and get in.
If that didn't make sense to you (lack of cars, etc...), basically this means bouncer will only affect poor malware writers and the big-boys will just skirt around the security anyways. Which really means little, because I'd rather get rid of the big players and be stuck with a bunch of obvious annoyances than to remove the annoyances and have a false sense of security about my apps. I should give google credit though, at least it's a start. Hopefully by this time next year they'll have managed to match common sense 2014 in terms of malware protection.
While browsing the Google Play store, I have started to notice a number of apps that have 1000+ good reviews, all rather pithy like "Amazing", or "!!!".
You then tap "Download" to look at the permissions, and the app asks for everything under the sun, even though the app might be a game or a utility that does one thing, and has zero need to be able to read and write contacts.
Of course, for users who know what they are doing, stuff like this is as close to a Trojan as one can get, or at best some basic game coupled with a malware payload. However, for novice users who just want to use a phone and who think permissions are something to obtain from their teacher so they can go use the bathroom, the phrase, "babe in the woods" comes to mind.
I hate lobbing brickbats at Google since I like the Android ecosystem and Android phones. Android even has a stronger security model than iOS. However, Apple does one thing which precludes the need for that much security in iOS, and that is to be an active and stern gatekeeper. iOS devs don't get their app stomped, then one hour later turn up again with the same app under a different name.
Google needs to get on the ball and make two tiers of their Play Store. The first (default) tier would be like Amazon, where all apps are not just sent past a rudimentary scanner, but are actively vetted. This includes not just the original version of the app, but any updates, so malware can't be slipped in.
To boot, a higher fee is charged to play in this game, partially to offset the cost of the enhanced filtering, and partially to discourage people from making accounts and trying to palm off the same malware-ridden app under different names.
In the top tier, Google would need have some very stringent policies. For example, if an app gets rejected by account "A", submitting the exact same app under account "B" with slight changes mean that account "B" gets suspended for the first offense, and closed down for good after the second.
Of course, Google can keep their second tier (which would be the same as Google Play now), but maybe put up some sort of warning for a user that once they exit the vetted tier, they are essentially on their own, so do what is needed at their own risk. This tier is one step up from just downloading an app via a website and sideloading it, but it is better than no security.
Google needs to do something here, because the malicious apps are causing issues, not just in China, but here in the US. Already, Android's reputation is being tarnished by something that is not the OS's or hardware maker's fault, and Google needs to step up to the plate and do the role of active gatekeeper unless they want to see customers abandon the platform for ones with a better gate guardian, even though it means people buying far locked down devices.
Bouncer just isn't going to cut it.
The problem is one of accountability. Apple, through iOS maintains a very interesting relationship with developers - should someone manage to sneak an app through, they can "out" that developer very easily because they have full billing details of that developer. If you know you're not anonymous in the App Store, you're a lot less likely to write malware when it can be traced back to you.
It's the foundation for Gatekeeper in Mountain Lion - here Apple will not vet the app, but they will request a small fee for a signing certificate. If you write malware and distribute it that way (because it's default on OS X), again it's easy to know who did it (or who didn't protect their keys).
Sure OS X will have the "full open" option as not default for open-source (though some non-GPLv3 projects are getting certs as well, e.g., Firefox) or developers (who would hopefully not try to break their own machines...).
Google's a $25 one-time fee. Buy a gift card, use a fake address, done. Account closed down? Reopen another one..
That's the big difference - Apple takes care of a social problem via social means (do you really want to be credited with creation of malware?), Google's using technology to do it (via scanners and such).
It's also why SVN's "blame" tool is quite handy at keeping dud checkins from happening - build breaks are much less frequent and usually due to inadvertently missing a file or three rathe rthan checking in without compiling or testing (and yes, I've seen it happen. Someone checks in a quick fix without seeing a syntax error...).
The problem is that they are so vague about why the permission is needed. When presented with a list of things the app has permission to do, it should also list why the app needs this and what specifically the app is going to do with those permissions.
As an example I pulled up a free flashlight app, it needs the following permissions.
Storage: modify/delete sd card contents.
System Tools: prevent phone from sleeping
Your Location: Coarse (network-based) location, fine (GPS) location
Phone Calls: Read phone state and identity
Network Communication: Full internet access
Hardware Controls: Take Pictures and videos
Since this is an app that turns on the flash on your phone as well as any other available lights so it does not need really any of the permissions it asks for, and you have no idea what it is going to use those permission for.
In this case since it is just a flashlight app it is very easy to tell it is asking for permission for things it should not be doing, but what do you do when the app you want asks for permission for things it would technically need, but you have no idea if it is going beyond what is needed for functionality vs more nefarious operations?
Don't know something? Look it up. Still don't know? Then ask.
Preventing phone from sleeping is to avoid the phone going dark in 10-30 seconds.
Phone calls is to gracefully terminate on a call so you are not holding up a beacon to the side of your head.
hardware controls (take pictures, videos) is for access to the actual flash ahrdware which is part of the camera 'permission'.
The issue is way too coarse permission groups in order to make it "easy" to handle.
"boy they are nice, but it sure is easier for administrators to have a mainframe or at least a bunch of diskless workstations with a Novell box"