View Full Version : The Chinese want your Droid
This is "Shirley" just the beginning.
New virus threatens phones using Android (http://news.yahoo.com/s/afp/20101231/tc_afp/usitcrimeandroid/print)
Fri Dec 31, 9:03 am ET
WASHINGTON (AFP) – A virus infecting mobile phones using Google's Android operating system has emerged in China that can allow a hacker to gain access to personal data, US security experts said.
A report this week from Lookout Mobile Security said the new Trojan affecting Android devices has been dubbed "Geinimi" and "can compromise a significant amount of personal data on a user's phone and send it to remote servers."
The firm called the virus "the most sophisticated Android malware we've seen to date."
"Once the malware is installed on a user's phone, it has the potential to receive commands from a remote server that allow the owner of that server to control the phone," Lookout said.
"Geinimi's author(s) have raised the sophistication bar significantly over and above previously observed Android malware by employing techniques to obfuscate its activities."
The motive for the virus was not clear, accoring the Lookout, which added that this could be used for anything from "a malicious ad-network to an attempt to create an Android botnet."
But the company said the only users likely to be affected are those downloading Android apps from China.
The infected apps included repackaged versions sold in China of Monkey Jump 2, Sex Positions, President vs. Aliens, City Defense and Baseball Superstars 2010.
"It is important to remember that even though there are instances of the games repackaged with the Trojan, the original versions available in the official Google Android Market have not been affected," the security firm said.
Irishsquid
03-25-2011, 14:39
This is "Shirley" just the beginning.
New virus threatens phones using Android (http://news.yahoo.com/s/afp/20101231/tc_afp/usitcrimeandroid/print)
Fri Dec 31, 9:03 am ET
WASHINGTON (AFP) – A virus infecting mobile phones using Google's Android operating system has emerged in China that can allow a hacker to gain access to personal data, US security experts said.
A report this week from Lookout Mobile Security said the new Trojan affecting Android devices has been dubbed "Geinimi" and "can compromise a significant amount of personal data on a user's phone and send it to remote servers."
The firm called the virus "the most sophisticated Android malware we've seen to date."
"Once the malware is installed on a user's phone, it has the potential to receive commands from a remote server that allow the owner of that server to control the phone," Lookout said.
"Geinimi's author(s) have raised the sophistication bar significantly over and above previously observed Android malware by employing techniques to obfuscate its activities."
The motive for the virus was not clear, accoring the Lookout, which added that this could be used for anything from "a malicious ad-network to an attempt to create an Android botnet."
But the company said the only users likely to be affected are those downloading Android apps from China.
The infected apps included repackaged versions sold in China of Monkey Jump 2, Sex Positions, President vs. Aliens, City Defense and Baseball Superstars 2010.
"It is important to remember that even though there are instances of the games repackaged with the Trojan, the original versions available in the official Google Android Market have not been affected," the security firm said.
I'm not AS worried about a virus packaged in the software as I am about the vulnerabilities inherant in the majority of apps when all software is user/community developed. What QA criteria are the devs using? I have no clue. I've actually thought about going into business reviewing code for Android market apps for security flaws.
That said, this is still good informations, and an indicator of things to come...
"Once the malware is installed on a user's phone, it has the potential to receive commands from a remote server that allow the owner of that server to control the phone,"
The Manchurian Candidate??? asks Maj Bennett Marco
I'm not AS worried about a virus packaged in the software as I am about the vulnerabilities inherant in the majority of apps when all software is user/community developed. What QA criteria are the devs using? I have no clue. I've actually thought about going into business reviewing code for Android market apps for security flaws.
Sirs,
This part will make you giggle a little. Android apps are 'safe', as in they run inside their own little virtual sandbox on your phone. Therefore one application does not get to 'play' with the resources of another application, unless given 'permission'. Your data's security though, is left to the whims of the developer. Developers can choose declaratively whether or not to allow their applications data to be available for other applications or services.
I am a bit rushed so I'm being very poinient, please forgive me. The important thing here is this; when you download and install an app on your device, the 'rules' of the Android framework specify that you inform the user what services the application requires to work. It will tell you "this application requires the following:
access to the internet,
access to services that cost you money,
access to your location,
etc....
Once you click OK, you acknowledge that any data that you enter into that program is subject to those things which you agreed to.
Can an unscrupulous developer write an app that links to facebook, then on the sly transmit information it has access to, to a server for other uses? Yes.
Can it take the credit card numbers that you entered to use for some 'secure' shopping app and do the same? Yes.
Strangely, the downloads/reviews/rating system on the app store are the main indicators to how 'trustworthy' a developer or software is.
As a developer, I by no means wish to shed negative light on my profession or peers. As a slightly paranoid human, I will be the first to say that your information could definitely be at risk.
Bottom line, don't trust an app until you have read every line of its source code OR if the app is well ranked and well reviewed. Its just like encryption, it's only good encryption when it has withstood the abuse and scrutiny of security professionals.
Respectfully and hurriedly
Irishsquid
03-25-2011, 20:16
Sirs,
This part will make you giggle a little. Android apps are 'safe', as in they run inside their own little virtual sandbox on your phone. Therefore one application does not get to 'play' with the resources of another application, unless given 'permission'.
True, to an extent. What about those of us who run "rooted," phones? Who really pays that much attention to what you are granting su permissions to? Most people don't. I'm not most people, but as a security professional, just about every cert you take requires agreement to a "code of ethics," which, among other things, will include your agreeing to attempt to safeguard the general public.
I've essentially sworn to try to save people from themselves. Gotta love it.
True, to an extent. What about those of us who run "rooted," phones? Who really pays that much attention to what you are granting su permissions to? Most people don't.
Good point. Although I don't believe having escalated priviledges on the O.S. necessarily overrides the isolation principles followed by Android apps at runtime. I'm not completely sure about this though. Thank you, you've given me something to research further.
Irishsquid
03-26-2011, 23:29
Good point. Although I don't believe having escalated priviledges on the O.S. necessarily overrides the isolation principles followed by Android apps at runtime. I'm not completely sure about this though. Thank you, you've given me something to research further.
I'm still working on learning Android. Just recently got a copy of the dev platform, so I'm learning how everything interacts. I don't have any definitive answers yet. I do know that I wouldn't trust that sandbox concept until it is VERY well tested. If it worked that well, my Linux box would probably be using it already.
If Im not mistaken, it already exists on Linux in the form of the java vm. Im not familiar with how the application manifest from Android maps to what java does for shared services though. You've given me something else to research.
Looks like I have something interestg to do tomorrow!
Irishsquid
03-27-2011, 19:54
If Im not mistaken, it already exists on Linux in the form of the java vm. Im not familiar with how the application manifest from Android maps to what java does for shared services though. You've given me something else to research.
Looks like I have something interestg to do tomorrow!
JVM/JRE has a number of vulnerabilities which allow the execution of arbitrary code on the host.
JVM/JRE has a number of vulnerabilities which allow the execution of arbitrary code on the host.
Hopefully the Dalvik VM's methodology will have eliminated some of them:
We should point out that the final executable code in Android, as a result of the Dalvik VM, is based not on Java byte code but on .dex files instead. This means you cannot directly execute Java byte code; you have to start with Java class files and then convert them to linkable .dex files.
http://www.ctoedge.com/content/how-dalvik-virtual-machine-works-google-android
... I don't believe having escalated priviledges on the O.S. necessarily overrides the isolation principles followed by Android apps at runtime...
Sirs,
Just found some time to go find some documentation regarding this issue. I remembered reading about this when I started playing with Android apps last year, but wanted to back up my assertions before I made them.
Once installed on a device, each Android application lives in its own security sandbox:
The Android operating system is a multi-user Linux system in which each application is a different user.
By default, the system assigns each application a unique Linux user ID (the ID is used only by the system and is unknown to the application). The system sets permissions for all the files in an application so that only the user ID assigned to that application can access them.
Each process has its own virtual machine (VM), so an application's code runs in isolation from other applications.
By default, every application runs in its own Linux process. Android starts the process when any of the application's components need to be executed, then shuts down the process when it's no longer needed or when the system must recover memory for other applications.
In this way, the Android system implements the principle of least privilege. That is, each application, by default, has access only to the components that it requires to do its work and no more. This creates a very secure environment in which an application cannot access parts of the system for which it is not given permission.
However, there are ways for an application to share data with other applications and for an application to access system services:
It's possible to arrange for two applications to share the same Linux user ID, in which case they are able to access each other's files. To conserve system resources, applications with the same user ID can also arrange to run in the same Linux process and share the same VM (the applications must also be signed with the same certificate).
An application can request permission to access device data such as the user's contacts, SMS messages, the mountable storage (SD card), camera, Bluetooth, and more. All application permissions must be granted by the user at install time.
http://developer.android.com/guide/topics/fundamentals.html
Every application you install, MUST explicitly declare in its manifest what device services/resources/data it needs access to :
Every application must have an AndroidManifest.xml file (with precisely that name) in its root directory. The manifest presents essential information about the application to the Android system, information the system must have before it can run any of the application's code. Among other things, the manifest does the following:
It names the Java package for the application. The package name serves as a unique identifier for the application.
It describes the components of the application — the activities, services, broadcast receivers, and content providers that the application is composed of. It names the classes that implement each of the components and publishes their capabilities (for example, which Intent messages they can handle). These declarations let the Android system know what the components are and under what conditions they can be launched.
It determines which processes will host application components.
It declares which permissions the application must have in order to access protected parts of the API and interact with other applications.
It also declares the permissions that others are required to have in order to interact with the application's components.
It lists the Instrumentation classes that provide profiling and other information as the application is running. These declarations are present in the manifest only while the application is being developed and tested; they're removed before the application is published.
It declares the minimum level of the Android API that the application requires.
It lists the libraries that the application must be linked against..
http://developer.android.com/guide/topics/manifest/manifest-intro.html
Therefore it behooves the installer of apps, to carefully read what the app is requesting before just accepting it. Google stepped cleanly away from being responsible for YOUR data. YOU accepted the manifest definition when you installed it and it told you that it required access to services that cost you money, and YOU accepted it. etc...
Now back to the data issue vs escalated user privileges. By rooting your device, you are escalating YOUR privileges beyond the clean little level that Motorolla or Verizon or AT&T want you to have. This lets you do cool things like use your phone for a hotspot or change the ROM that your phone uses, stuff that your normal account level would not let you do. Rooting your phone does NOT escalate the privileges of the applications unless YOU again, give those applications permission to use the higher level root account.
Hopefully if this information has not settled anything, some can at least be more informed about how this stuff works in general (on Android at least).
In spite of my knowledge of this sort of thing, I still refuse to enter credit card numbers or other sensitive information either in any app or via the browser on my Droid, and please don't mistake this as a statement that you should.
I am a firm believer in "You're not paranoid if they really are out to get you".
In the words of the esteemed Flava Flave "Cant truss it".
Respectfully
perdurabo
04-01-2011, 09:09
The problem is that Android's security manifest templates are bunk, from a security standpoint. Practically everything requests access to sensitive compartments, such as your contacts & "phone", which then could let the phone intercept SMS messages and call logs [1].
I could choose no to approve such apps, but then I wouldn't have any apps and that would be a rather useless smartphone.
I much prefer Apple's application sandboxing [2] approach, which is still in its youth, but offers more granular mandatory access controls (it's based off of TrustedBSD & work from the NSA folks). Apple has made a recent push in this area for both iOS and Mac OS X.
Android could theoretically do this with SELInux, too, but I'm not sure how well that would work, or if it would work, in reality, since they aren't using GNU libc [3]. As far as Android being Linux, about the only thing that's really Linux is the kernel.
Combined with the low quality of software engineering that OEMs tack on, Android is unsuited for high security use, and in many ways, personal, as well.
[1] http://developer.android.com/guide/topics/security/security.html
[2] A very brief, high-level overview: http://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/RuntimeEnvironment/RuntimeEnvironment.html#//apple_ref/doc/uid/TP40007072-CH2-SW44
[3] http://android.git.kernel.org/?p=platform/bionic.git;a=summary