Security Warning Over Web-Based Android Market

An anonymous reader writes "Security researcher Vanja Svajcer is warning that cybercriminals may be particularly interested in stealing your Google credentials, after discovering a way of installing applications onto Android smartphones with no interaction required by the phone's owner. The new web-based Android Market retrieves the details of Android devices registered to the Google address, and automatically installs software onto the associated smartphones with no user interaction required on the phone itself. Svajcer summarizes: 'Google should make changes to the remote installation mechanism as soon as possible. As a minimum, a dialog should be displayed on the receiving device so that the user must personally accept the application that is being installed.'"

Comments

Minimum

[Spad]

Surely as a minimum you should just be able to turn off the ability to install apps remotely.

Re:Minimum

[icebike]

Installing apps remotely is a convenience factor that has a lot of merit.
A simple confirmation on the phone should suffice.

Perhaps, but a more sensible approach than turning it off is to make for a more secure environment by having
better password management, and encrypted connections throughout the Google infrastructure.

At a minimum everything you do on Google should be done over https, (the market is, but its not real clear how
secure C2DM really is. It relies on your 'Google Talk' connection, and I simply have not had the time
to sniff that traffic to see if its encrypted or not. Google Talk maintains some pretty resilient connections over
3G,Edge,WIFI, etc.

Its the WIFI ones you have to worry about, especially if you frequent open WIFI routers.

old debacle: convenience vs security

[Superken7]

This is nothing new (the part about no user intervention), its called C2DM. Your google account would need to be compromised for an attacker to remotely install software on your phone.

IMHO this sounds like the old convenience vs security debacle. I prefer convenience in this case, since if someone compromises my goog account, I have much more important things to worry about. (like services trusting the ownership of my email account, private information, etc..)

"As a minimum, a dialog should be displayed on the receiving device so that the user must personally accept the application that is being installed."
Again, I don't agree. I don't care about that, I want CONVENIENCE. However, the point that he makes that your compromised account is now more valuable is still valid. I just don't agree on the solution.
Why not just opt out of remote phone installs? At least make the user validation of remote installs optional, for the ones who are more concerned about that?

Re:old debacle: convenience vs security

[Dexter Herbivore]

Open devices are like a girl with open legs, convenient but they have their own risks.

Re:old debacle: convenience vs security

[geekoid]

A pop would indicate to you that someone has compromised your account.

Of course, in the end you say exactly what the person you are replying to suggested.

Re:old debacle: convenience vs security

[node 3]

"As a minimum, a dialog should be displayed on the receiving device so that the user must personally accept the application that is being installed."
Again, I don't agree. I don't care about that, I want CONVENIENCE.

This seems a bit much. A dialog box saying, "Install: [list of new apps]?", seems convenient enough to me. It's not even saying you need to type in your password, just accept new apps. You can even have a "Don't ask me again." checkbox if you really just want binaries from the Internet to be automatically installed.

This is Security 101. Prompting should be default, and if it's to be allowed to be disabled at all, it should require some level of user acceptance.

You talk about "your password is compromised already, you have worse things to worry about!", what about some guy hacking into a girl's gmail account and remotely installing some stalker malware? Or phishers hacking into your parent's account to do the same, but for banking fraud purposes?

This is a bad default decision, but it's reasonable that there will be some mistakes when rolling something new out like this. It seems to me like you're only defending it because to do otherwise would require admitting a security weakness in Android.

Re:old debacle: convenience vs security

[xiando]

This is nothing new (the part about no user intervention), its called C2DM. Your google account would need to be compromised for an attacker to remotely install software on your phone.

The "account" part is less important. What really matters is that Google can remotely install software on your phone. Google itself may be compromised in one way or another. It should simply not be possible to install anything on any device without notifying the user on that device.

Re:old debacle: convenience vs security

[bemymonkey]

Agreed, it's a feature implemented for our convenience. This so called researcher is blowing things way out of proportion...

Re:old debacle: convenience vs security

[node 3]

What malware? The only apps that are installable are the ones on the Android Market, where any malware will be flagged by users right away...

You just said, "What malware? The malware that's on the Android Marketplace?"

Yes, that malware.

The bigger security issue

[Mike Buddha]

The bigger security issue that aflicts all Android phones is that of pocket-based or belt-holder-based security. The vast majority of Android users falsely secure their devices by carrying them in their pockets or on belt holders. If a hacker were able to remove the phone from the pocket or belt, they could covertly install malicious apps, make phone calls, check call log, spam sms messages, etc.

Google needs to address this gaping hole in Android security.

Re:Really?

[geekoid]

True, but who is looking at their status bar 24/7?

Especially if the program being maliciously installed is designed to remove itself from the status bar.
Seriously, root kits have been removing themselves from lists and logs since 1984.