Mobile botnets for smartphones: an unfolding catastrophe?

2011-12-01

Hasan Ijaz

nexGIN RC, Pakistan

Muddassar Farooq

nexGIN RC, Pakistan

Syed Ali Khayam

NUST, Pakistan
Editor: Helen Martin

Abstract

The number of users subscribing to the voice, Internet and messaging services of cellular networks is increasing exponentially worldwide and the potential development of cellular botnets poses a serious threat. Hasan Ijaz and colleagues present a functional cellular botnet for Symbian smartphones with an efficient and effective command and control centre.


(This work is supported by the Pakistan National ICT R&D Fund.)

The number of users subscribing to the voice, Internet and messaging services of cellular networks is increasing exponentially worldwide. The development of cellular botnets, therefore, poses a serious threat because of their potential to incapacitate and bring down cellular networks. These bots may launch SMS floods leading to DoS attacks, carry out identity theft, send SMS spam, download malicious executables and carry out illegitimate financial transactions. Since the core of a cellular network processes an enormous volume of traffic, the application of traditional security measures such as firewalls is not practical – thus posing unique challenges for detecting such mobile bots. In this paper we present a fully functional cellular botnet for Symbian smartphones with an efficient and effective command and control centre. Using a formal model, we show that with a zombie army of just 66 compromised cell phones, a botnet can incapacitate a cell site (BTS tower), resulting in complete denial of service to voice and SMS traffic. In a preliminary study, by using numbers in the phonebook of a mobile phone our bot sent an install service message to 150 users – 90 of whom downloaded the (fake, non-malicious) binary and installed it on their phones.

1. Cellular botnets demystified

In the last decade, cellular mobile networks have caused a paradigm shift in the world of computing. Contemporary 2.5/3/4G cellular networks have been deployed worldwide and now form the core for offering integrated services of voice, text and data at reasonably high data rates. To use these services effectively, mobile phones have evolved into full-blown computing platforms which offer data services and applications comparable to those on desktop computers. (In 2008, the number of mobile phones in the world was estimated at 4.1 billion [1], while the estimated number of computers was just one billion [2].) As a result, they are becoming an attractive target for imposters and intruders. McAfee recently reported a more than 100% increase in malware, phishing and DoS attacks against mobile devices since 2006 [3]. On a similar note, a recent paper by Traynor et al. [4] used analytical and simulation results to highlight the significant damage that can be caused by a cellular botnet; i.e. a botnet comprising mobile phones as zombies.

In this paper, we report our experiences of developing SymBot, a fully functional botnet of mobile smartphones for the popular Symbian OS. (Symbian is reported to have had a 36.4% share of the mobile phone market in 2009, which is almost twice the market share of the second biggest phone vendor (Samsung) [5]. The architecture of SymBot is generic and can be realized on other platforms (such as Android) and networks (3G).) Our research effort is inspired by the Morris worm, one of the first publicly known computer worms [6]. While this worm opened the door for other malware which continues to plague the Internet to this day, many experts feel that the Morris worm did some good in that it exposed the inherently vulnerable designs of computer operating systems and the Internet and catalysed a serious security-centric rethinking of OS and networking design philosophies. Using our experiences of developing SymBot as a baseline, we argue that a similar reality check is required to enhance the security of mobile devices and networks.

2. Background & related work

In the last decade, botnets have emerged as one of the greatest threats to IP network availability and information confidentiality. As a result, detection of botnet activity has received significant attention in network security research [7], [8].

While botnets on the Internet are well studied, there is surprisingly little research literature on botnets for mobile devices and networks. There has been some research on how wireless links can be saturated to cause denial of service or how the open functionality of certain cellular services can help in a DoS attack [9]. However, to the best of our knowledge, there is only one paper on cellular botnets in which the zombies comprise mobile phones inside the cellular network. Traynor et al. [4] showed that botnets of as few as 11,750 phones can cause a reduction of throughput of more than 90% to area-code sized regions supported by most currently deployed systems.

In this paper, we provide a proof-of-concept implementation of a cellular bot – SymBot – for Symbian smartphones which is capable of launching prominent IP-based attacks.

The following section provides background on the Symbian OS and its development SDK, with details of the structures, facilities and API calls that were used to develop a cellular bot.

3. Exploiting Symbian OS for SymBot development

In this section, we first provide an overview of the Symbian OS security framework. This is followed by details of how we implemented different attacks and communication modules in SymBot.

3.1 Symbian security framework

A number of security measures are adopted in the Symbian OS that deny installation of malicious applications. A developer has to explicitly state the desired capabilities of its application and hard-code them in the header of the executable image. The developer must also specify the system API calls that the application will use to achieve the desired functionality; this information is provided in a .mmp file. With this information, the developer submits the source code of his application and .mmp file to the Symbian Signed website (http://www.symbiansigned.com/). This site issues a code signing certificate to the developer which he subsequently uses to create an install SIS package. The available signing options and capabilities are shown in Figure 1.

Symbian Signed grid .

Figure 1. Symbian Signed grid [10].

Using the SIS package, a developer can install his application on a Symbian smartphone with the help of an install server. The install server allows or disallows the installation by checking the capabilities required by the binaries, comparing them with the configuration of the device, and verifying the signature of the SIS package which contains all the binaries, resource files and the metadata required for installation. Once the application is started, the header of the executable image is loaded into memory and the loader associates the new process with the capabilities specified in the header. The capabilities are set only once and cannot be changed at runtime [10].

If an application makes a system call which is incompatible with its capabilities, Symbian OS does not allow the call to execute. This is the main security premise adopted by the Symbian OS to disallow installation of malware on-the-fly. However, the top left corner of Figure 1 shows capabilities (in shaded blocks) that can be given to an application through self-signing; i.e. there is no need to get a code signing certificate from the Symbian website. We now discuss the architecture of our SymBot, emphasizing how these capabilities can be misused to perform different exploits.

3.2 Architecture of SymBot

We have developed a GUI application – Currency Converter – which converts a given amount from one currency to another. Since the application needs to connect to the Internet to receive daily foreign exchange rates, a user can easily be tricked into granting the application access to NetworkServices. The application is designed as a self-signed, multi-threaded process. Once the user launches the application, the bot starts working in the background. The main modules of SymBot are:

  1. Central processing module

  2. Watchdog module

  3. Threat-invoking module

  4. Encryption module

  5. Communication module.

The remainder of this section describes each of these components.

Central processing module (CPM)

This module handles the flow of data and decision making for the bot. After infection, the CPM opens a TCP port and an SMS socket connection. Currently, the phone number of the C&C is hard-coded in the bot. The central processing module queries its location from the location update module. On receiving the location information, it is forwarded to the encryption module and an encrypted message is sent to the C&C. Depending on the commands, the CPM invokes the following sub-modules:

  1. Location update. SymBot retrieves the GPS location of a phone using the CLocation API call defined in lbs.lib, which is enabled by the Location capability. Using this API call, SymBot periodically sends the location of the infected mobile phone to its C&C centre. The C&C aggregates the information to compute the number of zombies in a given site and if the number exceeds a threshold value, it has the capability to launch an effective DDos attack.

  2. Financial data stealing. Most of the cellular operators in Pakistan allow users to share their credit via an SMS [11]: users send a template SMS containing a recipient phone number and amount of credit, and the credit is automatically transferred to the recipient. When the command for stealing financial data is received, this module checks the network operator to which the user is subscribed. This is done by checking the default SMS message centre. Depending on the service provider, the template SMS is constructed and sent to the communication module. In order to evade detection, transfer could happen through a chain of zombies between the victim and the bot master.

  3. Personal information stealing. SymBot accesses the phonebook using the CContactDataBase API call in the cntmodel.lib library. This API call is enabled by the ReadUserData and WriteUserData capabilities. Using this API call, an attacker can also access the additional information for contacts in the phonebook: name, email address, home phone numbers, etc. SymBot sends the complete set of information to the C&C, as this can be sold to telemarketing and advertisement companies. Moreover, the contact information could be exploited by scammers to launch phishing attacks on phonebook contacts by acting as bank employees, promotion managers for cellular operators, or other persons of trust. Interested readers can find information related to closure of a major online cellular phone directory at [12].

Watchdog module

The watchdog module stores the date and time of the attack, which is given to it by the CPM. It runs a thread which continuously matches the current system date and time with the attack date and time and accordingly commands the threat-invoking module to launch attacks.

Threat-invoking module

This module launches SMS spam or a DoS attack depending on the commands received from the watchdog module. The spam generator basically creates SMS messages containing a link to the website on which the bot SIS file is placed. (According to a survey of 2,150 UK mobile phone users [13], two thirds of the users received SMS spam, and 38% of the users received a text containing a link to another site.) Thus SMS spam can also use social engineering to trick a user into installing malicious applications. The DoS attack module launches an SMS flood on the network which is explained in detail in Section 4.

Encryption module

The C&C defines the mode of communication with the bot. If the C&C demands encrypted communication, the encryption module sends a binary SMS in Packet Data Unit (PDU) mode. The payload of the PDU contains binary information, e.g. an image, encrypted text, etc. A binary SMS can hold 140 bytes of data, allowing any block cipher – like AES or DES – to be applied to it. By using encrypted SMSs SymBot can hide its communication from a sniffing IDS which may be deployed to monitor the activities of potentially malicious applications. Using a 256-bit AES key, this module encrypts its data and sends it back to the main module in the following format: Encrypt(Length of Message | Message | Padding Bytes). The length of the message is used so that the receiver can extract only the original message without the padding that was used to enable encryption.

Communication module

The communication module handles the exchange of information to/from the networks outside the GSM. Most of the time, the communication activities are related to the exchange of information with the C&C.

Using the RSocketServ and RSocket API calls – defined in esock.lib and enabled by the NetworkSevices capability – the communication module opens a TCP or UDP port. This port can be utilized by the bot master to send malicious binaries containing platform security hacks – the latest platform security hacks are reported on www.symbianfreak.com. Once a mobile phone is compromised, the attacker can install malicious applications without the need for signature certificates. These applications can launch attacks on the critical core network entities (e.g. Home Location Register (HLR), Visited Location Register (VLR), SMS gateway, etc.) through meta commands [4].

An effective botnet must have the ability to exchange information among an army of zombies in a stealthy fashion. The communication module does this by sending SMSs through sockets, which are enabled by the RSocketServ, TSmsAddr, CSmsBuffer and RSmsSocketWriteStream API calls defined in esock.lib, smsu.lib, smu.lib and estor.lib, respectively. This approach has two inherent advantages: (1) communication takes place under the hood without alerting the user or raising any alarm, and (2) cheaper communication ensures that the user’s credit depletes gradually, once again avoiding raising any alarm.

MMS is another option available to realize intra botnet communication. To send MMSs, we use the CMmsClientMtm API calls defined in mmscli.lib. Using this feature, a bot can download command files embedded in JPEG images and share them with other bots, making detection of malicious activity a significant challenge. However, MMS services are relatively expensive, so SymBot does not use them.

Table 1 shows a summary of SymBot’s exploits, associated API calls and libraries.

ExploitLibrary usedCapabilities requiredSigning
Stealing personal infocntmodel.libReadUserDataSelfSigned
Opening proxiesesock.libNetworkServicesSelfSigned
Botnet communicationsmu.libNetworkServicesSelfSigned
Financial data stealingsmcm.libNetworkServicesSelfSigned
Spammingsmcm.libNetworkServicesSelfSigned
Location trackinglbs.libLocationSelfSigned

Table 1. SymBot exploits.

3.3 Command and control mechanism

An efficient command and control structure is fundamentally important for botnet operation. This requirement for efficiency is amplified in cellular environments where the data rates are typically much lower than on the Internet. Thus a cellular bot master has to devise intelligent methods to exchange information with the bots without being detected. Most of the methods used to disrupt IP botnets focus on detecting the command and control structure and disrupting the communication. The two well-known C&C mechanisms for IP botnets are P2P and centralized. For SymBot, we have developed a centralized C&C structure for three reasons:

  1. In a P2P C&C mechanism, bots have to continuously search their neighbours for the search keys and command files. Moreover, the bots have to send keep-alive messages throughout the botnet. For cellular bots, such communication will lead to prohibitively high overheads. In particular, as the number of zombies in the botnet increases, the number of concurrent flows for the keep-alive messages and the searching mechanism will cause significant unwanted competition for scarce cellular resources which are not designed for concurrent flows [14].

  2. Likewise, when the bots are submitting stolen information from the compromised mobile phones, the data flowing from all the neighbours would cause the smartphone memory to be depleted very quickly. This would not only alert the user but also lead to detection of the malware.

  3. DDoS attacks cannot be successfully carried out with a P2P structure because estimation of the number of active bots within a cell using P2P communication has a very high overhead.

We have developed a generic C&C architecture which communicates with the bot through a GSM/CDMA/UMTS modem connected to a computer. In this way the C&C is placed in the cellular network. It has two advantages: (1) the C&C can utilize all the communication methods described earlier, and (2) the limitations faced by smartphones are eliminated by the use of a computer.

The C&C builds and maintains a vector space in which it saves the location of all bots connected to it. The columns of the vector space represent the sites in the city and the rows represent the number of bots in each site. Once the C&C finds that it has the necessary population in each site to launch an effective attack, it sends the attack commands to all bots.

4. Distributed Denial of Service Attack

We have used existing models by Traynor [9] and enhanced them to calculate the number of zombies required to saturate the control channels of a GSM network, which results in denial of voice and messages services. Using our enhanced model, we found that an army of 66 zombies is required to launch DDoS at a site (BTS). Our analysis was based on the core network of Telenor in Islamabad that consists of 40 sites and 300,000 users. We discovered that we would need just 3,000 zombies (just 0.1% of the total subscribers) to launch a complete denial of service in the metropolitan area of Islamabad.

Using the model, we concluded (for the sake of brevity, we skip the calculations) that with approximately 22 bots in a single sector, and with 66 bots in a single cell, our GSM botnet could incapacitate the cellular core network for legitimate voice and text messaging services. Our botnet is location-aware and hence can trigger the DDoS attack once it finds 66 bots in a single sector. It is interesting to consider the fact that during the daytime, the universities and offices are crowded with people. In such a scenario, the botmaster could easily recruit the required number of zombies to launch a successful DDoS attack.

4.1 Preliminary user study of infection propagation

While designing our user study, we had to be mindful of the security and privacy of the subjects. To this end, we created a benign version of our currency conversion application and uploaded it on a website. The authors’ mobile phones were then used to send SMS service messages, containing the URL of the website, to the phone contacts, inviting them to download and install this useful application for free. This SMS message was sent to a total of 150 contacts. Interestingly, 90 of them downloaded and installed the benign application on their mobile phones. This preliminary study demonstrates that an alarming infection rate of 60% could be achieved even using this rudimentary infection/distribution strategy.

We then asked the users some questions about the choice they made. Based on their answers, we conclude that, although few of these users would download and install a piece of software referred to them through an Internet email, the same message on a mobile phone SMS can achieve a much higher infection rate. This is mainly because people still think that cellular networks and mobile phones are inherently ‘safe’ from malware; as a consequence, they are less wary about installing new applications on mobile phones. This prevalent mindset results in a very effective and easy distribution mechanism for malware which can use trivial SMS and MMS communication media to infect smartphones.

5. Conclusion and future work

In this paper, we have presented our experiences of developing a fully functional botnet for the Symbian OS. We have shown that most of the malicious activities of a botnet can easily be implemented on the Symbian platform. The underlying communication media also provides the capacity to remotely control the botnet and to launch crippling attacks on the cellular infrastructure. Our analytical and experimental models have shown that 66 zombie smartphones can incapacitate a cell site through voice and SMS DoS attacks. We have also revealed some alarming infection rates that can be achieved in cellular networks using trivial distribution mechanisms like SMS and MMS. We believe that our findings will challenge the existing belief (or fallacy): mobile phones are inherently safe because of a reliable core of cellular networks. As a result, we hope that security countermeasures will receive their due attention.

Bibliography

[1] ITU Corporate Annual Report 2008. http://www.itu.int/osg/csd/stratplan/AR2008 web.pdf.

[2] Gartner Forecast: PC Installed Base, Worldwide, 2004-2012. http://www.gartner.com/DisplayDocument?id=644708.

[4] Traynor, P.; Lin, M.; Ongtang, M.; Rao, V.; Jaeger, T.; McDaniel, P.; La Porta, T. On cellular botnets: Measuring the impact of malicious devices on a cellular network core. Proceedings of the 16th ACM Conference on Computer and Communications security, 2009, pp. 223–234.

[5] De La Vergne, H.; Milanesi, C.; Zimmermann, A.; Cozza, R.; Huy Nguyen, T.; Gupta, A.; Lu, C.K. Competitive Landscape: Mobile Devices, Worldwide, 4Q09 and 2009.

[6] Spafford, E. The Internet worm program: an analysis. ACM SIGCOMM Computer Communication Review, vol. 19, no. 1, p. 57, 1989.

[7] Gu, G.; Zhang, J.; Lee, W. BotSnier: Detecting botnet command and control channels in network traffic. Proceedings of the 15th Annual Network and Distributed System Security Symposium (NDSS), 2008.

[8] Gu, G.; Porras, P.; Yegneswaran, V.; Fong, M.; Lee, W. Bothunter: Detecting malware infection through ids-driven dialog correlations. Proceedings of the 16th USENIX Security Symposium, 2007, pp. 167–182.

[9] Enck, W.; Traynor, P.; McDaniel, P.; La Porta, T. Exploiting open functionality in SMS-capable cellular networks. Proceedings of the 12th ACM Conference on Computer and Communications Security, 2005.

[10] Mueller, B. From 0 To 0Day On Symbian: Finding Low Level Vulnerabilities On Symbian Smartphones. 2009. https://www.sec-consult.com/files/SEC_Consult_Vulnerability_Lab_Pwning_Symbian_V1.03_PUBLIC.pdf.

[12] Working Cell Phone Number Directory Worries Privacy Advocate. http://www.pr-inside.com/working-cell-phone-number-directory-worries-r1550881.htm.

[13] Savvas, A. Two thirds of Britons say they have been victims of mobile spam. http://www.computerweekly.com/news/2240085822/Two-thirds-of-Britons-say-they-have-been-victims-of-mobile-spam.

[14] Traynor, P.; McDaniel, P.; La Porta, T.; et al. On attack causality in internet-connected cellular networks. Proceedings of the 16th USENIX Security Symposium, 2007, pp. 307–322.

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.