What Can Android Learn From Symbian's Security Model?
android mobile security symbian · 2 comments · 300 words · read ~598 times.
More bad news for Android owners. A huge Russian malware operation is infecting Android apps in the the Google Play Store. The malware - hopefully now removed - hijacks your personal details, and sends premium rate text messages to drive profits for its owners.
Nasty.
This is the price we pay for Android's open access policy. iPhone users can smirk all they want - but I like being able to run anything I desire on my phone, rather than be restricted to the puritanical walled garden of Apple's App Store.
The late lamented Symbian OS did many things wrong - but it had an interesting approach to keeping users secure from malicious apps.
The first time an app wanted to access a feature - like Internet, SMS, phonebook - the phone would prompt the user to grant the app permission.
Now, the Symbian model wasn't without flaws. It would often forget that you'd granted an app permission or repeatedly ask annoying questions.
Is this what is needed for Android? the first time an app tries to access, say, the dialer - should Android say "Are you sure you want Angry Birds to make a phone call?"
Or, should Android take a leaf out of BlackBerry 10? When installing the app, the user can choose whether to grant certain permissions.
Finally, what about personal responsibility? The Android permission model is quite opaque to most users, it's true, but there are some basic precautions users can take.
I was recently hit by a "drive by installation". A malicious website automatically downloaded an app to my Android phone. When I clicked on it to install, this is what I got:
<a href=https://twitter.com/edent/status/162836273168527360">
If you think a Battery app needs all those permissions... I'm not sure encasing you in bubble-wrap is enough to keep you safe from yourself!
The price of freedom is eternal vigilance. Android needs to do more to allow users to enjoy their freedom.
Going down the Symbian path of insisting every app be signed by a third party and repetitively interrupting the user is probably not the right way to do things. What is clear from the current crop of malware is that simply telling the user of the permissions an app is requesting at installation time is insufficient.
Until Google makes things better for its users, it's worth installing an app like Permissions Denied which will allow you to see which apps have more access than they need - and restrict them if necessary.
Security is one (important) issue, but when comes to Android, I'd like to be warned before installation when an app: (1) installs services, and most notably (2) installs services that keep running after the app exists or, worse, start running with the system no matter the app has never been started in the current session or ever! Battery lifetime, to only mention one concern with the gazillion of services installed by apps. It SHOULD HAVE BEEN a permission for services!
So the rub here is that a strict permissions based security model probably wouldn't have helped. Yes common sense should always apply, if Tetris wants to access your contacts then its probably up to no good.
However In the case of this piece of malware the key permissions it asked for were:
Phone state - Almost every AD enabled app asks for this. Permission to access the network - Almost every AD enabled app asks for this. Permission to access filesystem - Almost every AD enabled app asks for this.
The reason we spotted it was because 1. we keep an eye on applications that catch our attention (strangely popular yet terrible apps, apps with weird characteristics etc) and 2. It was build using 70% of the code from an older known piece of malware.
Even still we weren't sure because they laid low for months doing nothing after infecting devices. Then suddenly it was pushing out SMS toll fraud malware.
The problem here isn't just the SMS malware that was their endgame, its that these guys basically built a dropper disguised as an evil ad network that wouldn't be detected unless someone was continuously monitoring it like we were.
Its also that by adopting the "evil ad network" cover they would also be able to sell/give their ad network SDK to innocent app devs.
Its sneaky, its evil, and it means we have to be EXTRA vigilant in the future.
1) If you are an app dev, dont add ANY third party SDK unless you know FOR SURE that you can trust it with your reputation. Because if it turns evil, its your app and your account that gets kicked out of the app store.
2) If you are an end user don't uncheck the "trusted sources" option to enable sideloading. The endgame was SMS toll fraud malware, if you only allow trusted sources, it cant even ask you to for permission to install.
3) Use Antivirus. Antivirus helps. It blocks the known threats out there, and because malware authors are lazy it blocks almost all the new threats too. Our AV (Yes, I work for Lookout) was detecting this malware from the moment it appeared because it contained 70% evil code from an earlier piece of malware.
Cheers
Marc