Popular Android Anti-Virus Software Fooled By Trivial Techniques
wiredmikey writes "A group of researchers from Northwestern University and North Carolina State University tested ten of the most popular AV products on Android, and discovered that they were easily fooled by common obfuscation techniques. In a paper (PDF), the researchers said they tested AV software from several well-know security vendors. In order to evaluate the mobile security software, the researchers developed a tool called DroidChameleon, which applies transformation techniques to Android applications. Known malware samples were transformed to generate new variants that contain the exact malicious functions as before. These new variants were then passed to the AV products, and much to the surprise of the paper's authors, they were rarely flagged — if at all. According to the research, 43% of the signatures used by the AV products are based on file names, checksums or information obtained by the PackageManager API. This means that, as mentioned, common transformations will render their protection useless for the most part. For example, the researchers transformed the Android rootkit Droid Dream for their test. DroidDream is a widely-known and highly dangerous application. Yet, when it was transformed, every AV program failed to catch at least two variants."
AV products suck!
The whole premise of trying to match a virus 'signature' is simply stupid and useless.
"Ma'am, is this your son?"
"Well, my son was wearing a hat, so no."
Chances are it does. Just because you're too stupid to believe there's no possible way a virus can get onto your phone, doesn't mean that there's someone out there with the know-how and the skill to do just that. There is (and has never been) anything that is 100% secure.
Really? I've got an HTC 8X on a wireless charger right in front of me (hence the Verizon version)... care to point to a virus or three (or just malware) that targets Window Phones?
Don't worry... I'll wait.
While I will admit that nothing is 100% secure... the protection model on Windows Phone does sure seem to keep malicious code away better than Android.
Help Brendan pay off his student loans
Heh heh heh. Successful troll.
It was possible on WP7, at least in the earlier patch versions. I'm not aware of any malware anybody actually created, but there were a few known vulns in most devices that could be exploited for elevation of privilege. They were routinely used for beneficial homebrew software, though.
On WP8... well, there's no malware known to exist for it yet, but there's nothing much in the way of homebrew either. Microsoft locked the OS up so tightly that it's somewhat limited in terms of actual usability and very limited for extensibility.
There's no place I could be, since I've found Serenity...
...that AV apps not tested (such as avast!) are immune from this problem, and the authors only chose to report on those AV programs that failed their tests?
Citation please.
As I recall... the initial 'exploit' used by the ChevronWP7 folks involved running a local web server on your PC... then tricking your phone into developer unlocking against it... rather than the official Microsoft servers.
I wouldn't exactly call this a vector for virus infiltration.
Ditto when it comes to homebrew apps (which could only run on developer unlocked device (legit or not unlocked))... and required manual side-loading of the app.
Claiming malware was possible on WP7 is like claiming it's possible to infect the Pentagon with your super-l33t virus... provided you can trick someone into going into one of the secure server rooms, logging in as a local administrator, accessing your hax0red website... then clicking "Yes, I want to run configure; make; make install".
Help Brendan pay off his student loans
The same can be said for most any AV software , especially ones on mobile platforms.
http://interserver.net/
Nobody targets Windows phone because nobody cares about windows phone. Nobody uses it. Microsoft is constantly striving to be even relevant, let alone get a remarkably sized userbase.
I seem to recall that as an excuse around these parts for a decade or so regarding Linux... as well as the claim that "many eyes make bugs shallow"... and yet quite often we hear about a bug in the Linux kernel, or Bind, or some other major component that has been undiscovered for years and years.
How'd that work out? Oh right... Android (Linux based) is the most easily hackable mobile phone OS out there!
Help Brendan pay off his student loans
I remember that being said about Linux devices round the parts for so long... which are obviously still (like Oracle DBs) unhackable/unbreakable.
How much longer should I wait? My old HTC Trophy (running Windows Phone 7.x) also (as far as I am aware) never had any major exploits against it.
While it's easy to say "no one cares about targeting an OS with a .0000000002% market share"... call be silly... but I'm still kind of surprised no one wanted to make a name for themselves as the first person to hack Windows Phone.
Help Brendan pay off his student loans
Anti-virus software is a scam anyway, the OS should be secure enough not to let a program damage your device or corrupt stuff anyway. As anti-trojan detectton it's completely useless too. Any trojan than can make off with your data and sell it anyone and everyone is a bad thing, and yet not a single Facebook app is ever flagged as malware!
How'd that work out? Oh right... Android (Linux based) is the most easily hackable mobile phone OS out there!
You say that like it's a bad thing.
-- Alastair
Tell the guys writing the smartphone virus cleaning software that our world is in danger of obliteration by a large asteroid, and we're building a series of Ark ships to get everybody off the planet to safety. The smartphone virus cleaning software writers will depart on the "B" Ark, along with hairdressers and middle-managers.
Then the rest of us will laugh our asses off.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
Fuck me, Steve. Get over it already. RIP.
Not talking about ChevronWP7 or anything like it. The actual homebrew stuff for WP7 wasn't well publicized, partially because a lot of it was flying under the MS radar so far as possible, but it existed. The best-know "root" program is called WP7 Root Tools (http://www.wp7roottools.com) and exploits various firmware bugs in HTC, LG, and Samsung firmware (and possibly others) for WP7 to gain near-complete control over the OS, disable many of the "security" restrictions (such as the prohibitions on third-party non-"app" executables), give full access to the filesystem, registry, and certificate store, and allow running any other app as TCB (WP7's equivalent of "root" or "Admin"). Other apps before it, including things like TouchXplorer and Advanced Config, took less complete control but nonetheless had permission to do any number of nasty things had that been the intention of the developers. Additionally, once the later versions of Root Tools (with the "elevate other apps" feature) came out, a considerable number of homebrew apps that needed such permissions immediately sprung up, providing a perfectly good avenue for somebody to slip in a Trojan app. Indeed, it was a considerable concern.
The point about requiring manual sideloading is valid (in fact, installing WP7 Root Tools would have been a lot easier if Microsoft would have signed it and put it in the store, since otherwise it could be difficult to install on some devices after Mango introduced the interop-lock). However, I fail to see the important difference between installing an app you think is safe because it's on the store, and an app you think is safe because it comes out of the developer community that has been adding such cool features to your phone. Either way, it's a manual action on your part to install the app, and most people aren't going to decompile it and examine it for malicious code even if they had the know-how to do so. As for whether Trojans in general constitute "real" malware, that's all that the Android apps in question are, or the malicious iOS apps for jailbroken phones, or similar.
To address your little analogy, social engineering is one of the best ways to bypass security there is; the weakest link in computer security usually sits between the user's ears. Also, your analogy seriously falls flat on its face when you consider that it wasn't supposed to be *possible* to "[log] in as a local administrator" on WP7. A seriously locked-down system wouldn't allow your scenario either.
Then there's the minor, but really easy, attacks which were possible against WP7 without requiring firmware access or bypassing interop-lock or any such thing. For example, the XAP files that would let you access other device or operator marketplaces could just have easily crippled your phone's marketplace functionality, overwritten your personal documents, broken your installed apps, and other things. Those were just carefully crafted ZIP archives with a .XAP extension and some XML files to make the installer recognize them; the same attack was actually possible using .ZIP files as well and wouldn't have been that hard to socially engineer somebody to try, or could have been bundled into an otherwise-legit XAP on the store.
There's no place I could be, since I've found Serenity...
This doesn't surprise me at all. The so-called virus scanners can't actually scan for viruses (i.e. examine the code of third-party apps) because that would break the copy protection. The paper mentions this at the beginning.
Do you have WP7 Root Tools installed on your Trophy? If so, at least three different exploits were used: the ZIP path traversal that made the interop-unlock "app" work (all the work was actually done by the installer), the Connection Setup hack that achieved interop-unlock by hijacking the network database using some debug code to inject a script that modified the registry, and the exploit that Root Tools itself used in the HTC drivers to gain arbitrary code execution in the kernel.
Just because Heathclif74 was not, so far as anybody knows, embedding any malware in his software doesn't mean he couldn't have been, or one of the many other authors posting their work on XDA-Devs and WPCentral.
There's no place I could be, since I've found Serenity...
Modifications of the binaries creates a new variant of a virus, which may go undetected. I'm shocked! If you'd like an AV solution that performs a deep inspection on every binary, each time they are executed on your device, it's going to be a sloooooow ride.
How much longer should I wait? My old HTC Trophy (running Windows Phone 7.x) also (as far as I am aware) never had any major exploits against it.
Maybe another 5 million users or so? Oh wait...
yet quite often we hear about a bug in the Linux kernel, or Bind, or some other major component that has been undiscovered for years and years
i seem to recall that as an excuse around these parts for a decade (continuing today) regarding linux... and yet those bugs aren't exploited, even when the potential target is driving much of the consumer embedded world, servers (including probably majority of web servers and many large corporate intranets), and now smartphones.
Android (Linux based) is the most easily hackable mobile phone OS out there!
calm down a bit there sunshine... android is really a userland running on a virtual machine (dalvik). if you find an android vulnerability that affects the underlying linux kernel, then you'll have a major story. yes android is probably pathetically insecure (it would be nice if it were as secure as linux), but the linux kernel underneath dalvik is as tight and tested as the numerous datacenters around the world require it to be.
some slashdotters like to pick on how linux fans claim android = linux when it suits and not when it doesn't. android is an application layer running inside a virtual machine (so it is separated from the linux kernel), but there is still linux underneath (so every android deployment is also a linux deployment). linux and android are usually lumped together when arguing about market share, and separated when arguing about security, but there's nothing contradictory if you take the context of the argument into account.
what about the worst virus of all: ANDROID?!?!? that entire OS is a virus masquerading as a useful product. it needs to obliterated
regards,
steve ballmer
Malware that targets your phone? You realize that the software comes from Microsoft, right?
Landshark. Candygram.
Besides. Android does a pretty good job of controlling what each and every app can access. There's a sandbox around each app. As long as you are careful which apps you install, and look closely at the permissions they require, you should be relatively safe from most malware. If you're at all unsure about an app, it's probably better just to not install it. Sure there are problems, but I think Android is one of the better platforms out there. Not too many others I'm aware of have such fine grained control of what exactly each application may do on your system.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
"Deep inspection" would only be needed the first time an executable is run. It's easy and quick to check a file hasn't changed since last time.
yes android is probably pathetically insecure ...but the linux kernel underneath dalvik is as tight and tested as the numerous datacenters around the world require it to be.
Even if true, how exactly does this distinction matter to the millions of Android users out there?
"My phone was so infected that it was unusable, all my accounts were hacked, and my porn stash was stolen, but at least it was just the vm and my linux kernel held up! (at least I think.. i can't really tell...)"
I don't practice particularly careful practices with my phone AT ALL, installing and uninstalling things all the time, etc etc and at most, at the absolute most, I've seen one chunk of malware. The real problem is not malware it's the permissions you grant the legitimate stuff you put on. WHY, does such and such game or widget need my phone book, email address book, call log browser history and location db? That's the problem right there.
Why can't the major software vendors publish sha265sum signatures (hashes) of all their files?
Why can't the major software vendors cooperate on a dns-like service where you look up the signature of a file you have on your disk in order to know if it is unaltered?
Why can't we crowd-source a new service where people and everybody can submit the signatures of files they have and believe to be OK...
- because the bad guy or his first victim would register the signature of the infected file?
- Well, let's take some measures... The submitters need to have had a pgp/gpg key registered with a keyserver for at least two years,
and the service response includes a field telling how many distinct submitters have submitted this same signature.
All right, I come to think about more problems with this idea faster than I can write about them... But many of them have fairly obvious solutions, and some may not completely invalidate the benefits... Who would like to contribute to a discussion about such a concept?
There is no substitute for common sense. Especially, no body of rules will do.
Point me to a few viruses for BeOS, OS/2 / eComStation, SolarOS, or Menuet.
Android is the most hackable mobile phone OS out there? Sure, but if you're going to argue that that discredits the security of the kernel like you seem to be saying, go ahead and point out how much of that is due to kernel bugs. (As far as I can tell, the main kernel bug was Samsung's ugo+rwx access to system memory--which would only be an issue for those who haven't updated).
The real issue is twofold:
First, many eyes won't do a thing to help if half the phones never get a single update after source code goes public. If you can find and fix every single bug within a month of the source drop, it will not change security for a device that's stuck with a rom from just after the code drop.
Second, notice that term "code drop". To quote Rob Landley, "Android isn't open source, it's regularly updated abandonware." "Many eyes" cannot work when there's no source before release; when you look at Honeycomb, applying it to Android becomes even more absurd.
Android does not run on a virtual machine, it uses the Dalvik VM to execute apps written in Java
err... you do realize what the "VM" bit stands for right?
i know "android" is the collective term for the kernel, vm and wm, libs, etc, but the insecure bit that TFA is probably talking about (who actually reads TFA anyway) is the app layer, not the kernel... if a virus were able to breach the kernel it would make front page news around the world because there are huge interests at stake (including corporate and government).
from http://en.wikipedia.org/wiki/Dalvik_(software) ... "Dalvik is the process virtual machine (VM) in Google's Android operating system".
It's also perfectly capable of exerting native apps that bypass the VM
i would be interested to know what native apps can bypass the vm without first gaining root access at least (with root of course you can do anything and so could a virus).
how exactly does this distinction matter to the millions of Android users out there
1) i wasn't addressing the millions of Android users out there
2) it was part of my argument with the parent comment (which was trying to conflate the insecure bit of android with linux)
"My phone was so infected that it was unusable, all my accounts were hacked, and my porn stash was stolen, but at least it was just the vm and my linux kernel held up! (at least I think.. i can't really tell...)"
that same kernel (well, mostly same) is shared by more than just android...if dalvik is corrupted to the point of destruction but the kernel holds up, that will probably matter more to the world that all the embedded and datacenter applications are still secure
in all fairness to apple (i'm a linux fanboi, not an isheep)... users don't go looking for viruses to infect their system (windows and mac), but because mac has heritage in the multi-user unix platform it has some inherent security advantages over windows, which seems to get infected even without user intervention.
windows has a virus problem not only because it is so easily infected by its design, but because it is so easily infected makes it even more of a target
ballmer really hates the gpl because it prevents him from building the secure bits of linux into windows and solving all his virus woes... well maybe
Does Bouncer detect the origional? I'd be (possibly more) curious to know if Bouncer could detect the variants too.
Can a person program a new solution to a problem? Why should anyone be able to stop such a thing? -Richard Stallman
err..yeah, I do. It's what "Android doesn't run on".
i realize we're just talking across each other, but part of android does run inside dalvik (which is a virtual machine). in the context of this thread and TFA, the part of android in question is the part running inside the VM, which the post that i was originally replying to was conflating with the linux part (outside the VM).
A recent Samsung kernel exploit was found in any phones that used the Exynos 4412 and 4210 CPU's. It did make the news, but not exactly around the world
i guess if its not an inherent vulnerability that would make sense, and the vulnerability would have to be exploited for it to make front page news. vulnerabilities that can't really be exploited aren't as sensational. i'm not familiar with the samsung thing, but i'm guessing it wasn't a serious threat.
apps written using the NDK are coded in C/C++ with light Java wrappers that do nothing but call the code
native windows programs still run the same way when run on windows inside a virtualbox vm too, but they are still constrained by the limits of the virtual machine. dalvik is a process virtual machine, but i'm assuming even the c/c++ programs you mention are constrained by the limitations of the dalvik process. is it even possible to run a process outside dalvik from within dalvik? i wouldn't have thought so but i could be wrong. maybe if you had root access you could run malicious code on the next boot, or maybe create a cron job, but it would still require root filesystem permission. i'm still (even after reading a little bit about it) not really familiar with how you can gain root filesystem permissions from within dalvik given that i would assume dalvik would itself be running as a separate user with restricted filesystem permissions (kind of like apache). a wikipedia page on the topic talks about "exploiting security bug(s) in the firmware" but that would then be device-specific (like a bug in any device driver). if anyone has any experience in rooting an android device i would be interested to hear how it is done (practically speaking). there is a "su" app, but i imagine there is more to it than just installing the app. i'm not interested in rooting my android phone, but it might help my understanding of how android in general works (because abstract android framework diagrams don't really tell me a whole lot).