A quick online search would reveal a number of articles declaring any one of the last few years as being the “year of mobile malware.” Conversely, these searches also reveal that claim that the same years are not going to be the year of mobile malware. These search results go back as far as the early part of the decade. The contradictory nature of these bold predictive headlines could be explained by the fact that the articles are typically written at the beginning of each year—and who knows what the year may hold at the outset?
But if the criteria to qualify 2011 as the real "year of mobile malware" was to be challenged, then surely the events of the past few weeks alone should be enough to justify the fact that this year truly has seen considerable seismic activity that has shifted the tectonic plates of the mobile threat landscape.
Figure 1 – Mobile malware, 2011: types and targets
The message that is coming through loud and clear is that the creators of these threats are getting more strategic and bolder in their efforts. We are seeing increasing attempts to complicate the infection vectors of mobile malware to the point where a simple uninstall is insufficient.
Multiple payloads
One such strategy is to separate the malicious package into staged payloads. The idea is simple: instead of having one payload that carries all of the malicious code for any given attack, break the threat into separate modules that can be delivered independently. There are several advantages to deploying the threat in this way. First, it obviates the tell-tale sign of a huge, overzealous permissions list accompanying the installation of the threat, which may alarm the user as to the intention of the malicious app. Secondly, smaller pieces are easier to hide and inject into other apps. Furthermore, dispersing the attack across separate apps complicates the integrated revocation processes from the service provider, marketplace etc.
Figure 2 – Dispersed payload process of mobile threat
A textbook example of this is the newly discovered variant of Android.Lightdd. Apart from a few minor variations, such as the service name running in the background now being called “Game Services” and the three new domain names that it attempts to connect to, everything else remains the same as the previous samples discovered last month. This includes the encryption routine and the keys used to hide data within the threat.
Figure 3 – Data-gathering process of Android.Lightdd
This threat is the first stage in a multi-payload delivery system, responsible for reconnaissance and intelligence gathering (model, language, country, IMEI, IMSI, OS version) on the compromised device, which precedes the downloading of additional payloads.
Figure 4 – "Game Services" running in Android.Lightdd
An interesting fact is that the threat was capable of downloading additional components and updates through official channels of distribution as well as Internet/direct downloads. At the time of writing, all of the hosts associated with the threat are offline.
Figure 5 – Example of additional components and updates through official channels of distribution
Overcoming the user acceptance hurdle
As with its previous variant, Android.Lightdd still requires the user to accept the installation of any download—a major obstacle in this model of delivering a payload. However, another threat also discovered in the wild, Android.Jsmshider, has found a way to overcome this obstacle.
By signing the payload with an AOSP (Android Open Source Project) certificate, the threat was capable of performing further downloads without any interactions or prompts, as the underlying device considered the payload to be a system update through virtue of the accompanying certificate. At this point, however, this deception only works for custom modifications.
Figure 6 – Example of Android.Jsmshider exploiting Android Open Source Project certificate
Given the relatively elaborate installation of this threat, you would think that the final payload being deployed would rival something akin to the Stuxnet worm, but in fact, the final payload in the majority of cases was nothing more than a garden-variety premium SMS sender. Premium SMS senders and/or dialers don’t get a lot of respect from antivirus researchers, mainly because they lack sophistication and, just like those emails that we all get from a distant contact promising us a cut in the deal of a lifetime, depend largely on social engineering for a payoff. But they have been around for ages and, as far as mobile threats go, have the quickest ROI for their authors.
There is plenty of research demonstrating that the average price of a stolen credit card (due to competition and market forces etc.) has dropped to as low as $0.40 – $0.80 (USD) per unit. In contrast, the latest dialer to be discovered that was targeting North America would pay the author $9.99 per successful install and execution. Furthermore, if the threat is not detected by the user, each subsequent execution would result in a continuous revenue stream—until the owner of the device saw his or her next phone bill, that is.
Another interesting trend that Symantec has observed is the use of in-app features that facilitate the promotion and/or download of other apps. In some cases, we have seen this implemented as full-fledged browsing access to another third-party app store that has been embedded as undocumented functionality of the original app that the user has downloaded from the official marketplace—without any indication that the victim is downloading browsing apps from another website or store.
Figure 7 – In-app features that facilitate the promotion and/or download of other apps
Even though user interaction is required to install additional apps, there is a concern that this vector has an element of social engineering, whereby the user assumes that, since the first app was downloaded through an official channel, any additional apps must also be originating from there, too. As there is no indication to the user that he or she is downloading from a third-party site, an element of trust might be established with this particular vector.
All things considered, the real question that comes to mind is: if this truly is the “year of mobile malware,” where do we go from here?
Leave a reply
