Androrat was published on GitHub in November 2012 as an open source tool for remote administration of Android devices. Packaged as a standard Android application (in an APK file), Androrat can be installed as a service on the device that launches at start-up or as a standard “activity” application. Once it’s installed, the user doesn’t need to interact with the application at all—it can be activated remotely by an SMS message or a call from a specific phone number.

The app can grab call logs, contact data, and all SMS messages on the device, as well as capture messages as they come in. It can provide live monitoring of call activity, take pictures with the phone’s camera, and stream audio from the phone’s microphone back to its server. It can also post “toasts” (application messages) on the screen, place phone calls, send text messages, and open websites in the phone’s browser. If it is launched as an application (or “activity”), it can even stream video from the camera back to the server.

Hackers have taken Androrat’s code and run with it. Recently, underground marketplaces for malware have begun to offer Androrat “binder” tools, which can attach the RAT to the APK files of other legitimate applications. When a user downloads what appears to be a harmless app that has been bound to Androrat, the RAT gets installed along with the app without requiring additional user input, sneaking past Android’s security model. Symantec reports that analysts have found 23 instances of legitimate apps that have been turned into carriers for Androrat. The code has also been incorporated into other “commercial” malware, such as Adwind—a Java-based RAT that can be used against multiple operating systems.

Lelli said that Symantec has detected “several hundred” cases of Androrat-based malware infections on Android devices, mostly in the US and Turkey. But now that binders are available to anyone willing to pay for them, the potential for infection to spread is growing rapidly.

Share this story

Sean Gallagher
Sean is Ars Technica's IT and National Security Editor. A former Navy officer, systems administrator, and network systems integrator with 20 years of IT journalism experience, he lives and works in Baltimore, Maryland. Emailsean.gallagher@arstechnica.com//Twitter@thepacketrat

I personally would rather have the permissions up-front, I don't want to install something to then later find out it's asking for permission for something I'm not happy with. Also you can't necesarily expect an app to run if it has some permissions denied. For example, an SMS app would need access to SMS, address book etc. It would be pointless without them. AFAIK you don't get these sorts of app on the iOS platform, so it's not an issue there.

An SMS app under the per-API permission model would function without access to the address book: you would simply have to enter in phone numbers manually. You could always later grant it permission to access your contacts, but that would be your choice at any time.

The point is that any app should run perfectly fine under the most limited set of permissions. As soon as you need the app to do something more sensitive, you are able to grant or deny that permission.

If you install something and it later asks for permission to do something you are unhappy with then you can deny that permission. The app will work without it. If it really bothers you, then you can just delete the app — no harm done.

The problem with up-front permissions is that most people don't read them, and it's an all-or-nothing approach. For example, I always deny push notifications, almost always deny contacts access, and sometimes deny location services — all these apps work fine despite having restricted permissions.

I see your point, and Android could easily just show the app an empty address book (I beleive CM does this). However the developer should have a way of saying, don't bother using this app without this permission. If I developed an app, I would want to retain some control of how it's used.

Not to mention ad supported apps, what will happen to them if you deny them network access? I know some people would like to see the end of them (myself too - I prefer to pay for ad-free versions), they are extremely popular, and make more money for the developer than the paid for version.

The way I envision it working (and I am not a developer so keep that in mind) is that every permission is user-revokable. The app needs to handle the lack of permissions gracefully (aka, not simply crash). If a critical permission is missing (i.e. SMS needs to be able to send SMS messages) the app will simply throw up a message that it cannot operate without that specific permission and give the user the option to turn it on and try again. If the user chooses not to allow that permission, the app will politely refuse to function (with a clear explanation of what is going on).

With regard to ad supported apps, the developer could simply decide to do the same thing. If it cannot get to the ads it needs, pop up the description of of the permission it needs just like before. And if the permission is denied, politely refuse to run.

That gives people the ability to fine tune their comfort levels with any particular app and it allows an app to gracefully decide what to do based on how many permissions it has.

The only valid security model is to allow the user to control all forms of access, be able to modify the permissions at any time, and without any restrictions from either the app or the OS. The apps and vendors should have no role in security at all, other than as the targets.

This isn't realistic, and here is why:

(1) Applications need permissions to perform various functions. Users don't have a clear understanding of this relationship.

(2) Most users would have a poor understanding of the permissions list even if they read it.

(3) most people are too impatient to care about security or privacy.

Point 3 is especially true on a device where you are relatively safe from security vulnerabilities if you stick to the built-in app store, and especially since they don't understand how the privacy violations work.

The only realistic solution I see is finding some way to discourage developers from using/requesting additional permissions, or allow users who want to try to protect their information a mechanism to do so. The thing is, many users won't understand or remember that they denied permissions to an app, so they would need something like UAC which confuses users.

It's clearly not an easy problem to solve. However, no one will get anywhere throwing around inaccuracies, as we see in so many of the comments to this article, or pandering to fear-mongering, which is all this arstechnica article does.

The more I think about it, the more I can't understand how this article isn't garbage. You are linking us to a AV vendor which is almost certainly downloading software outside of the accepted and legal avenues and saying there are "hundreds" of infections out of hundreds of millions of phones.

I see your point, and Android could easily just show the app an empty address book (I beleive CM does this). However the developer should have a way of saying, don't bother using this app without this permission. If I developed an app, I would want to retain some control of how it's used.

Not to mention ad supported apps, what will happen to them if you deny them network access? I know some people would like to see the end of them (myself too - I prefer to pay for ad-free versions), they are extremely popular, and make more money for the developer than the paid for version.

As a developer you do have a way of saying that you require a permission. We did this recently on the App Store where a feature of our app relied on having access to your contacts for sharing purposes. If you didn't grant it access you didn't get the ability to share. Attempting to share simply informed the user to grant access from their Settings.

Regarding ad-supported apps, network access is not a permission you need to ask for on iOS. However, Apple does require that all apps work in offline (e.g., airplane) mode. For our ad supported apps on iOS we simply display built-in "house" ads for our other apps when the user is offline, and offer the user the option to pay to remove ads altogether.

One of the big differences between Apple and Google that I find as a developer is the following:

- Apple respects their users

- Google respects their developers

That's not to say that Apple disrespects developers (or that Google disrespects users), but Apple will always view a situation from the user's point of view as the top priority. Google tends to let developers have their way until they do something nasty.

For example, I have had an application rejected from the iOS App Store for not strongly warning the user that it would use up battery life (it was a location tracking app for runners). I really like that Apple forces me to work harder as a developer to create a great user experience.

That said, I also really like the fact that I can release a bug-fix update instantly on the Google Play store, without having to go through a stressful week-long period of review while users deal with the bug.

I think the chosen permission models reflect the above attitudes. Apple's permission model considers the user — if a user rejects a granular permission that your app needs then too bad, developer, deal with it. (And developers do deal with it because they have to.)

Google tries to satisfy developers first by allowing them to know exactly what permissions they will get when their app runs. This makes for easier app design because you don't have to handle use-cases where you lack a particular permission — which comes up a lot in iOS app design.

I prefer Apple's approach more. It has made me change my attitude as a developer to respect my users.

As a developer I feel like Google trusts me to do the right thing, and Apple does not. I prefer not being trusted because that means that all the nasty developers are also not trusted by default. Which means that users can place trust in the store, which means they purchase more freely.

Unless there is somewhere in an iPhone where I can go and revoke the permissions that an application has needlessly asked for, then you are simply trying to unfairly smear Android rather than acknowledging this as a broader problem.

Chances are that such fine grained access controls will see the light of day on Android long before Apple ever considers allowing it as Apple doesn't believe in allowing end users to have control. Both the cause and solution of this particular style Trojan is to empower the user.

May be you should check Settings->Privacy on iOS device?You can revoke Geolocation access, Contacts access, Calendars access, Photos access, Twitter/FB access for every iOS application you allowed such access (application usually asks for such access when it is need to use relevant functionality for 1st time, and you can just refuse to allow access and app will still work)iOS7 has even more in this regard

Unless there is somewhere in an iPhone where I can go and revoke the permissions that an application has needlessly asked for, then you are simply trying to unfairly smear Android rather than acknowledging this as a broader problem.

Chances are that such fine grained access controls will see the light of day on Android long before Apple ever considers allowing it as Apple doesn't believe in allowing end users to have control. Both the cause and solution of this particular style Trojan is to empower the user.

Crippling technology really isn't the answer.

I hate to burst your fandom bubble, but iOS has had this for quite a while now. You can grant or revoke specific permissions for any app at any time. It is unlikely that it will come to Android, as Google wants all that data to flow freely.