© 2013-2017 by Zack Smith. All rights reserved.
How Android malware reaches your device
Why did the Android cross the road? Because he was standing in a shitload of malware.
Malware pre-installed on brand new phones
This is perhaps the most alarming means by which malware gets onto phones and yet it has been proven to be increasingly commonplace. Oftentimes such preinstalled malware cannot be uninstalled.
For whatever reason, several Chinese manufacturers may have allowed middleman companies to get access to brand-new phones before shipping them out to customers, or the phones actually come in unsealed boxes so any middlemen can install malware such as spyware. Manufacturers suspected of this practice include Huawei (maker of the new Google flagship 6P phone), Lenovo (also known for shipping laptops with malware on them), Alps, Xiaomi according to G Data.
- Check Point: Malware Pre-Installed On Some Android Phones
- G Data announcement of discovery of pre-installed spyware
- Discussion of G Data discovery of pre-installed spyware
- Another discussion of G Data discovery of pre-installed spyware
In other cases it is simply unclear how the malware got onto brand-new phones.
- Cheetah Mobile discovers Cloudsota malware preinstalled on Android tablets sold on Amazon.
- Palo Alto Networks finds pre-installed spyware on Coolpad phones
- Marble Security finds pre-installed malware on Samsung, LG, Motorola phones e.g. infected Netflix app
You should not expect that this phenomenon is limited to the above-identified companies. There is no reason to believe that most small phone makers rigorously inspect the firmware of their phones when they arrive in the US from Chinese suppliers. If they do, what is not detected as malware at the phone maker when they do their testing may later be.
Take the example of the BLU Vivo Air, which is just a rebranded version of the Elife S5.1 from the Chinese manufacturer Gionee. BLU claims it has a software team in their service center that inspects incoming phones.
- But do they check each phone?
- Does inspection definitely involve running antivirus software? If so, which one?
- Is the antivirus software they use up to date?
- Are there exploits on the phones that are too new to have become known to antivirus companies?
So many questions... but virtually every manufacturer lacks transparency.
The one mitigation that could save small manufacturers from a large public relations crisis when customers realize the company is not working hard to protect their privacy would be for companies to install stock Android themselves on the phones when the phones arrive from China. Alas there is no evidence to suggest that smaller phone companies do this at the moment. Small companies most likely leave software installation entirely up to their Chinese partners, leaving customers vulnerable. Do they even employ a single engineer? Most likely not.
Spyware from the manufacturer
Some companies are just curious about you.
- Replicant developers find and close Samsung Galaxy backdoor
- Hidden backdoor in top Samsung Galaxy models allows remote spying on usersā
- Ben Lincoln discovered the Motorola Droid X2 upload his passwords in the clear.
- Discussion of discovery by Ben Lincoln
Question for Samsung users: If you were to fly to Korea and go to the home of the CEO of Samsung, would he graciously let you spy on his personal life as much as he allows spying on yours?
Resubmitted infected apps
It turns out to be easy for people to decompile Android apk application packages from Dalvik bytecode back to Java source code, which allows miscreants to making a copy of an app from the Google Play store, modify it, possibly adding malware to it, and then resubmit it to Google Play or more commonly a third-party store as if this modified app were a legitimate app, when in fact it is pirated and infected.
The methods for obtaining and opening up an app's apk (installation) file, extracting the dex (program) file, converting that to a jar (Java Archive) file and then extracting and decompiling the Java class files from the jar are documented elsewhere on the web.
Decompilation is not always necessary. Android apps rely on human-readable and modifiable XML resource files, and simple but significant changes to text strings in the XML may sometimes accomplish all that a miscreant wants.
There have been reported to be many bogus apps in the Google Play store. There are three causes of this:
- The failure of Google to vet application developers.
- The failure of Google to analyze applications for suspicious features.
- The putative desire of Google to boost the number of apps for Android, at the expense of security.
In short, in typical Silicon Valley fashion they throw the user under the bus.
Google is recently, ostensibly cleaning up its act, and there is now a Verify Apps setting that can check for malware, but the third party stores bypass this.
There are apps that are scams to start with, such as SmSilence, which purported to offer coupons to South Koreans but allegedly uploaded much of the phone's data to a server in Hong Kong.
An Android porn app Adult Player according to security firm ZScaler takes selfie photographs of (excited) users and demands a $500 ransom.
Better vetting of developers and apps by Google, like Apple has already been doing for years, could have prevented such apps from reaching the Google Play store.
That said, there are iOS apps that have allegedly engages in misdeeds. One called Path is said to have raided users' address books to permit spamming of contacts.
People are increasingly using their phones and tablets for email, so hackers are now sending scam emails to people, not to attack Microsoft Windows as has been the miscreants' tradition for years, but now to hack their Android devices as well.
One malware that is delivered in this way is Stels, which induces victims click on a fake Adobe Flash update that instead installs Stels.
Thus, even if a user decides to be safe and never installs any apps himself, Android permits the installation of malware packages nevertheless.
Drive-by's are increasingly common and involve an attack that occurs when the phone user browses a malicious webpage.
- Malware can be executed from the browser.
- Malware can be installed from the browser.
The drive-by exploit is the most common form of mobile attack according to ENISA.
Reasons for vulnerability
Dependence on China (a police state)
While outsourcing of manufacturing has boosted profit margins of many companies and thankfully shifted pollution to Asia, the result has been risk for consumers because of the anything-goes environment in China, combined with the desire of the government to engage in spying, and the desire of many criminals there to profit from violating your privacy.
Google's failure to imitate Apple's vertical integration
Apple devices are more secure because they maintain strong control of the production of phones from start to finish. Google took an approach more similar to that of Windows PC makers, and unsurprisingly Android is about as insecure as Windows i.e. rather insecure.
While the total number of all new malware (not just Android) per day is perhaps variously 82,000 to 1 million exploits, Android is a major target and there are at least (according to G Data) 6000 or more new exploits appearing daily for Android.
Most of those are just variants of existing exploits, modified slightly to escape detection.
- G Data Q2 2015 mobile malware report
- Kaspersky estimate 300k/day.
- Panda estimate 82k/day.
- Trend Micro estimate 1 million/day.
Fragmentation and forking
There are many versions of Android and many manufacturer modifications to Android. The end result is that most phones other than Google's phones don't have Google's latest code on them. Manufacturers are responsible for processing updates, which they do tardily. An Android user cannot simply go direct to Google for new OS software, unless he has a Google phone.
Some savvy owners of some phones can however install Cyanogenmod, which is derived from Google's code. This mostly runs on more expenses phones.
Others may use Replicant, which is derived from Cyanogenmod's and Google's code. This mostly runs on older Samsung phones.
Devices that cannot be updated
Some Android devices cannot be updated because they don't have sufficient resources to run newer versions of Android and/or manufacturers have not bothered to issue updates for particular phones.
Older devices that cannot be upgraded will be perpetually vulnerable to a number of profitable exploits such as those based on GM Bot.
Some manufacturers consider a device to be no longer their responsibility after it is sold and have no intention of issuing updates. It's a sell it and forget it approach.
This situation is awful, and it has bothered some people at Google enough that Google may cause a seachange.
Devices are used like feature phones and never updated
Whereas the majority of iOS users update their devices quickly when a new iOS is released, many Android users treat their smartphones like feature phones and never update them.
Android updates that are not from Google for Google phones will often be delayed by the manufacturers as well as by carriers. Delays can mean that vulnerabilities remain in place for no good reason, and customers remain at risk.
Devices have built-in hardware espionage capabilityIt was discovered that some Samsung phones have the ability to uploads users' files from their phones through the cellular connection upon the request of perhaps carriers, governments, or operators of fake cell phone towers.
This would not be possible if Samsung had properly walled off the baseband processor, which is what talks to the cell phone tower, so that it could not access flash memory.
Design and code quality issue: Java Vulnerabilities in the Dalvik virtual machine that runs compiled Java apps still exist. Three seem to involve:
- Undocumented Dalvik API calls
- Corrupted dex files
... among other things. But I need to do more research to get a fuller picture.
Design quality issue: JIT
Java is only able to run fast because of just-in-time compilation, or JIT. This converts bytecode into actual ARM instructions.
JIT compilation in turn also relies on a major security weakness, namely the ability to convert a region of memory that is flagged as non-executable data into one that is executable code.
Modern computer hackers use this feature when they use ROP and JOP attacks to overcome the NX (no execute) bit protection, and this permits them to do code injection. What this jargon means is, in short, JIT relies on an OS feature that enables hackers.
Operating systems should not allow applications to convert data areas into code areas, but they do because of software like Java, and other interpreters that do JIT compilation.
Code quality issue: Insecure system calls
Some exploits target the system calls that Dalvik bytecode makes when it wants to perform system operations such as opening files, performing network operations, and the like.
Design quality issue: Apps permitted by Google to do alarming things
Apps will usually ask the user for permissions to engage in various behaviors or access various data. Some of these permissions, it turns out, are extraordinary. A typical person might be surprised to learn Android allows them. Unfortunately once that permission is granted, it's the law of the jungle.
- An app can record SMS messages.
- An app can install or uninstall other apps.
- An app can send SMS messages to premium services.
- An app can make phone calls to premium numbers without the owner ever having dialed a single digit.
- An app can alter files on your SD card including deleting them.
Google's permitting of these behaviors was not too smart. People trust Google, but upon learning that Android allows behaviors that may lead to real harm, a reasonable person would question Google's reasoning and even their intentions.
Code quality issue: Random number bug in Android Wallet
It was recently discovered that the random number generator that was used as part of the wallet feature in Android was in fact producing the same number always and was therefore the opposite of random. This bug was ostensibly fixed. But one must ask, how are cheap Android phones that are never updated going to get the fix?
Code quality issue: Reliance on libraries that have vulnerabilities
Android relies on commonplace libraries that may exhibit vulnerabilities from time to time. But how many of the phones that have these susceptible libraries will never be updated, or updated too late to prevent a malware infection?
The above-mentioned WebKit vulnerability is an example.
JPEG files were utilized to create the GingerBreak exploit to turn Android devices into remotely controlled bots.
Fireye discovered a serious flaw due to the use of a vulnerable ad library.
Links to articles about Android malware
Is the situation bad? Yes it is. Android's numerous vulnerabilities proves the superiority of Apple's vertical integration approach and Apple's approach to security.
- 99% of all mobile threats target Android devices (Kaspersky)
- 2013 Q2 assessment (Kaspersky)
- FBI and DHS warning about Android malware
- 79 percent of exploits target Android
- F-Secure warns about Android malware
- Cleaner app uploads all your stuff to server and eavedrops on you
- Bruce Schneier
- Kaspersky 2010 vs 2011
As with pre-Android dodgy phones from China, you can mitigate the risks of using them as follows:
- Do not ever connect to the Internet via Wifi, lest your data be exfiltrated.
- Do not ever connect to the Internet via cellular data, lest your data be exfiltrated.
- Consider not ever connecting the phone to your computer via USB. This is an (albeit rare) infection vector.
This means a dodgy phone can still be used quite effectively for:
- Making phone calls.
- Playing media files from microSD.