Open source
  • Bandwidth benchmark
  • TouchWidgets UI lib
  • Diviner big number math
  • Documentation
  • x86 instructions ref
  • GIT quick ref
  • GPG quick ref
  • Avoid Ubuntu
  • Android malware risks
  • iOS malware risks
  • OS/X security tips
  • Who blocks Tor
  • Software engineering
  • BASH aliases
  • I.B. pro/con
  • Nutrition
  • Other apps
  • Blog
  • Contact
    1 at zsmith dot co

    Android Malware Overview

    Revision 14
    © by
    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.

    In other cases it is simply unclear how the malware got onto brand-new phones.

    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.

    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:

    1. The failure of Google to vet application developers.
    2. The failure of Google to analyze applications for suspicious features.
    3. 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 consumer 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.

    Scam apps

    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. Link

    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. Article about Path app.

    Scam emails

    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. Link

    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 exploits

    Wikipedia article

    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. Link

    The MITRE organization proved in 2010 that a drive-by WebKit exploit based on Javascript affected both iOS and Android.

    Reasons for vulnerability

    Dependence on China (a police state)

    While outsourcing of manufacturing has boosted profit margins of many companies, 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.

    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 Google enough that Google may cause a seachange: Google to snatch control of Android updates from phone makers.

    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 capability

    It 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.

    Discovery by Replicant project.

    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.

    An example: CVE.

    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.

    Related: JIT spraying attacks

    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.

    To be sure, Google is not the only clueless company. During a speech in 2013 in San Francisco, one designer of Mozilla's Firefox OS boasted that Javascript could be used to initiate phone calls on phones running that OS, as if that were a good thing.

    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 used to perform 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. Daily Mail article

    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.

    Mitigations

    As with pre-Android dodgy phones from China, you can mitigate the risks of using them as follows:
    1. Do not ever connect to the Internet via Wifi, lest your data be exfiltrated.
    2. Do not ever connect to the Internet via cellular data, lest your data be exfiltrated.
    3. 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.

    Other links




    © Zack Smith