BadNews reveals ongoing challenges in the Android marketplace

2013-08-01

John Foremost

Independent researcher, USA
Editor: Helen Martin

Abstract

The Android threat BadNews has been spreading through both Google Play and other app download sites, affecting 30 or more apps and with an estimated two to nine million devices having downloaded the affected apps. John Foremost looks at the ongoing challenge of securing the Android marketplace.


BadNews is an Android threat that has been spreading via the legitimate Google marketplace (Google Play), affecting 30 or more apps, with an estimated two to nine million devices having downloaded the affected apps.

In 2011, DroidDream [1] rocked the Android marketplace when over 100 apps were found to contain code created by rogue developers. This time, BadNews changed the rules of the game by lying in wait before deploying any noticeable payload.

Since the advent of DroidDream, Google and others have taken measures to improve the security of app distribution and management. In a cat-and-mouse world, fraud continues to drive new security measures in emergent markets, including the exploding Android market.

Most consumers realize that if they obtain apps from a ‘crack’ site or download some of the more nefarious types of apps – related to porn, gambling and the darker side of life – their risk increases. This is especially true in regions such as Russia and China where rogue sites and apps are emerging by the thousands. Recently, for example, there were multiple websites in Russia supposedly distributing anti virus software, the Bad Piggies game, and other popular apps – which were, in fact, trojans. This type of risk can be mitigated by consumers not visiting ‘crack’ sites or downloading nefarious apps, as well as by checking the apps they do download with various freeware security solutions prior to use.

In the case of BadNews, infected apps were distributed both through Google Play and via similar app download sites, such as AppBrain. Analysis of the hostile code reveals developer certificate creation in February and April 2013, with BadNews emerging in April/May. Popular apps for wallpaper, greetings and others were amongst the array distributed with BadNews code. As seen with so many other apps, consumers simply downloaded and installed them with little to no regard to the permissions requested. For example, the Live Wallpaper – Savannah app (MD5 98cfa989d78eb85b86c497ae5ce8ca19) has the following permissions:

  • ACCESS_NETWORK_STATE

  • ACCESS_WIFI_STATE

  • INSTALL_PACKAGES

  • INSTALL_SHORTCUT

  • INTERNET

  • READ_PHONE_STATE

  • RECEIVE_BOOT_COMPLETED

  • RESTART_PACKAGES

  • VIBRATE

  • WAKE_LOCK

  • WRITE_EXTERNAL_STORAGE

These permissions enable the code to run upon boot, write data to the SD card, read the phone state, and have networking access and details and C&C communications. The last part is critical, as BadNews didn’t enable C&C communications straightaway. Instead of quickly being detected and removed from Google Play, BadNews lay in wait, infecting millions of devices before fully revealing itself. Once enough time had passed for critical mass to be achieved, C&C operations and payloads were activated.

BadNews used an adware scheme similar to that seen in several other trojans – a common form of monetization in Android threats. This is obvious in a wide variety of C&Cs and source code statements found within hostile classes. For example, a few URLs found in the code are listed below:

  • hxxp://media.admob[.]com/mraid/v1/mraid_app_banner.js

  • hxxp://media.admob[.]com/mraid/v1/mraid_app_expanded_banner.js

  • hxxp://media.admob[.]com/mraid/v1/mraid_app_interstitial.js

  • hxxp://schemas.android[.]com/apk/lib/com.google.ads

  • hxxp://e.admob[.]com/imp?ad_loc=@gw_adlocid@&qdata=@gw_qdata@&ad_network_id=@gw_adnetid@&js=@gw_sdkver@&session_id=@gw_sessid

    @&seq_num=@gw_seqnum@&nr=@gw_adnetrefresh@&adt=@gw_adt@&aec=@gw_aec@

BadNews stores configuration and downloaded updates and payloads on the SD card. It can also send fake messages and prompt users to install other (malicious) apps or fake updates for legitimate applications. Details regarding the phone – such as model, IMEI and build version – are also sent to a remote C&C server.

Adware and exfiltration of sensitive data relating to mobile devices is big business for e crime operators. When performed to scale – in the millions – just a penny for each device infected yields great profits. Sensitive information is an asset that is worth plenty in the criminal underground, where IMEI and other phone data can be used for many types of fraud. For example, in 2010, actors in Chennai, India were found to have used the Spiderman Kit to plant fake IMEI numbers on mobile devices. IMEI numbers are heating up as a global privacy issue, where many entities are now attempting to track and/or manage identities based upon IMEI and user associations. This type of data can be used by attackers to track victims, and may also be resold on the black market.

Google responded very quickly to the BadNews incident once the threat was realized. Unfortunately, millions of downloads of affected apps had already taken place before the malware was discovered. In the wake of BadNews, one has to ask: how many other rogue developers and apps exist in the marketplace that have yet to be discovered? The problem is similar to that encountered by CNET and downloads.com, where downloads were largely trusted in the early days and later abused by the creators of Windows malware.

Another interesting twist in the BadNews case is ambiguity over what really happened regarding the distribution of the code. Some claim it was through rogue development while others believe it may have taken place through legitimate developers being tricked into using compromised code. Unlike large software houses like Microsoft, that have authority and control over the development of secure coding, the open source and official developers’ marketplace have no such oversight. This greatly complicates the task of managing apps when thousands of new ones emerge at an amazing rate.

Even attempting to download and manage all the legitimate apps in the marketplace is a staggering challenge, let alone carrying out secure code review and monitoring. Looking for hostile code in the Android marketplace can be compared with searching for a needle in a global haystack. New measures are likely to be required to respond to this challenge. New technologies are required in classifying and categorizing code and possible threats, correlating code bases (and modifications thereof), and gap analysis between advertised and actual permissions. Controls around developers and response to hijacked developer identities and accounts, rapid dynamic analysis and reputation capabilities are just a few more of the measures which must be matured to assist in this complex challenge.

Abuse is almost impossible to stop and security very often has to be reactive, forcing new creative measures for managing the risk affordably. Google has made great strides in protecting its marketplace. Consumers should also be aware of risks associated with apps and permissions and should be encouraged to check apps before installing them, using freeware scanners and similar solutions, as well as running security apps on their devices.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest articles:

Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

Aditya Sood & Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited to compromise the C&C panel in order to gather threat intelligence, and present a model of mobile AppInjects.

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…


Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.