Mobile Worms and Viruses

IT653 - Network Security

Course Project Report
by

Amit Kumar Jain (06329023)

Amogh Asgekar (06329006)
Jeevan Chalke (06329011)
Manoj Kumar (06329002)
Ramdas Rao (06329034)

under the guidance of

Prof. Bernard Menezes

a
Kanwal Rekhi School of Information Technology
Indian Institute of Technology, Bombay
Mumbai 400 076
Contents

1 Introduction 1
1.1 Comparison between mobile malware and PC malware . . . . . . . . . . . . . . . 1

2 A survey of current mobile malware 2

2.1 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Attack vectors for mobile malware . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 Mobile Virus Families . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4 Harm caused by mobile malware . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Case Studies 5
3.1 Cabir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Comwar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Cardtrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Futuristic Threats (original ideas by the authors) 6

4.1 Location Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Bugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Leakage of confidential data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 DDOS attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5 Protection and Prevention Mechanisms 8

5.1 Common protection against mobile malware . . . . . . . . . . . . . . . . . . . . . 8
5.2 MOSES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3 Proactive Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4 Our thoughts on protective measures . . . . . . . . . . . . . . . . . . . . . . . . . 12

6 Conclusion 13

7 APPENDIX 15

i
 Abstract

This document is the project report for “Mobile Worms and Viruses” completed as
part of the course IT653 (Network Security) at KReSIT, IIT Bombay. We begin
with examining what Mobile Worms and Viruses are, and the differences between
these and their PC 1 counterparts. This report refers to such malicious software
for mobile devices as Mobile Malware. The mode of spreading of mobile malware
and their effects have been enumerated. The risks and threats from these are then
examined, and various methods that have been used to prevent and protect against
their attacks are listed. Case studies of three widespread and important mobile
malware, Cabir, ComWar and CardTrap are presented. We also examine the extent
of harm that could be caused by mobile malware in combination with other newer
technology. Though such viruses do not yet exist, it can be seen that it is only a
matter of time before they can wreak havoc.

Declaration

This report based on the input from sources we found on the Internet. We acknowledge the
use of these sources. The figures, charts, graphs and tables used in the report have been
taken from these sources. Mention of the source for each figure, chart, graph or table has
been mentioned along with the figure or chart. A list of the sources that were referred for
the creation of the report appears in the Bibliography.

Keywords: Mobile Viruses, Mobile Worms, Cabir, ComWar, CardTrap, MOSES, Proactive
Security, Location Tracking, DDOS, Mobile bugging

1
Personal Computer

ii
1 Introduction
A large number of mobile devices are now part of everyday use. These include cell phones,
smartphones and PDAs (Personal Digital Assistants). The functionality and applications offered
by current day mobile devices are beginning to rival those offered by a traditional PC. These
mobile devices are usually have some form of connectivity (e.g., GSM, GPRS, Bluetooth, WiFi).
These devices have vulnerabilities like PCs, but also have some peculiarities of their own. Worms
and viruses, and other malicious software have been released that exploit vulnerabilities in some
of these devices. These malware can cause harm or annoyance to the users of the mobile devices.
Over the past few years, there has been a substantial increase in the number of malware that have
been written for mobile devices. As per [2], there exist at least 31 families and 170 variants of
known mobile malware. Statistics [2] have shown that at least 10 Trojans are released every week.
Even though it took computer viruses twenty years to evolve, their mobile device counterparts
have evolved in just a span of two years.
To understand the threat that is involved, we first present the comparison of the environment
for PC-based and mobile device malware.

1.1 Comparison between mobile malware and PC malware

The following points illustrate the differences and similarities between mobile malware and PC
malware.

• Vulnerabilities in PCs that have been exploited are related to vulnerabilities in the operat-
ing system or application software. Patches for such vulnerabilities are released periodically
by the software vendors. The users (or administrators) of the PCs are then responsible for
ensuring that these patches are applied to their systems as and when released.
Though vulnerabilities for mobile devices have been found and documented [2], it is very
difficult to “roll-out” patches to the software or firmware on the mobile devices that have
already been sold. Considering that the users of mobile devices include a vast majority of
people that are not security conscious, it is difficult to expect users to “apply patches” to
their devices as and when the patches are released. This problem is compounded because
there is no easy way to upgrade the firmware or software of a mobile device just by using
the mobile device. Connectivity with a PC is usually the only way to upgrade the firmware
or software.

• Mobile devices such as phones are almost always switched on and stay connected to the
network.

• Unlike a PC whose neighboring network nodes remain relatively fixed, the “neighbors”
of a mobile device keep changing with every change of location of the user carrying the
mobile device. As a result, for example, a single user with an infected phone entering a
stadium, can potentially infect the phones of all the people within the stadium if these
phones have the same vulnerability.

• Mobile phone users are less security conscious than the average Internet user.

1
 On the positive side:

• Unlike PCs, several variants of mobile devices exist. This makes it difficult for the mobile
malware to infect or spread to dissimilar devices. For example, a mobile worm spreading
through MMS can do little if the phone it has infected does not have MMS functionality.

• Mobile malware have not yet caused critical harm or damage. At most

– they increase the user’s billing, or

– cause the mobile phone to stop working (can be restored by a factory reset)

However, as a result, there is not enough motivation, either for device manufacturers or
for the users, for taking preventive action against mobile malware.

2 A survey of current mobile malware

2.1 Classification
As with any entity with multiple types, a taxonomy based classification is necessary to properly
identify the various individuals to respective classes. According to [2] the following was seen to
be the best mode of classifying mobile malware.
The classification system is structured on the following three characteristics:

• Behavior :
Mobile malware can be classified depending upon the way the malware behaves. For
example, whether it propagates like a virus or a worm, or whether it opens backdoors for
attackers, like a trojan.

• Environment:
Another characteristic in the classification is the type of operating system that the mo-
bile malware has been designed to infect and spread to. This also includes vulnerable
applications that the malware might exploit.

• The family name and variant:

Some malware are variants of existing ones. This classification characteristic identifies if
the mobile malware is a completely new entity or has been built based on some other
previously existing one.

2.2 Attack vectors for mobile malware

Current known mobile malware use the following attack vectors:

• Bluetooth: Many mobile devices have the capability to communicate with other devices
in a short range using the Bluetooth technology. However, several flaws exist in both
the protocol as well as its implementation [8]. Some mobile malware exploit these to
spread. Others disguise themselves as legitimate applications (Trojans) and try to spread
to other devices that are within its Bluetooth communication range. These latter types of
malware prompt the user to install the application and when the user does install them,
these malware cause harm to the mobile. The first known mobile malware, Cabir spread
through Bluetooth.

2
 Malware that spread through Bluetooth can only communicate within the range of com-
munication of Bluetooth devices (typically a few meters). However, such malware can
still rapidly spread across many devices if there is dense collection of Bluetooth-enabled
devices. Such an attack has been reported previously [3] at the World Athletics champi-
onship in Helsinki in 2005. A large number of people that were in the stadium had their
devices infected with Cabir very rapidly.

• SMS2 , MMS3 , WiFi: Some mobile malware spread themselves through SMS, MMS or
WiFi technology. Most of these send SMS or MMS to other phones and attach themselves
to the message that they send. ComWar, for example, spreads through MMS.
There also exists a buffer overflow vulnerability in the SMIL (Synchronized Multimedia
Integration Language) parser on mobile devices based on the Microsoft Windows Mobile
2003 operating system. This parser is used for parsing incoming MMS messages. As
demonstrated by [5], this can be exploited to launch a buffer overflow attack on the recipient
of such an MMS message. The user only needs to view the message to trigger the exploit;
there is no need to explicitly launch an application.
Malware that spread through SMS or MMS can spread across larger areas simply because
the only restriction to spreading across the continents is the amount of balance left in the
user’s mobile phone account.
Some worms that spread exploiting vulnerabilities in WiFi could also infect mobile devices
that are WiFi capable.

• Vulnerabilities in the operating system: Vulnerabilities exist in the operating systems

used by mobile devices. SymbianOS, included as the operating system in most Nokia
mobile phones, has several vulnerabilities [2], [3]. For example, one vulnerability found in
the Symbian Series 6.x devices (Nokia 3650 and Siemens SX-1) is to create a file called
“INFO.wmlc” in the root folder with 67 spaces between the “INFO” and the “.”. This
causes the mobile to work slowly or even crash.
Microsoft Windows Mobile 2003 is the other popular operating system used on mobile
devices. This latter operating system also suffers from vulnerabilities. For example, the
Duts virus exploits a zero-day vulnerability in the file handling API of the operating
system.
At this point, it is worth mentioning that there are also several phones [13] (some by
Motorola and Samsung) that use Linux or its variant as the operating system.

2.3 Mobile Virus Families

Figures 1 and 2 shows the increase in known mobile malware. Figure 1 shows variants of mobile
viruses in each month from June 2004 (first mobile virus found in June 2004) till June 2006
along with cumulative index.
Figure 2 shows the increase in the known mobile malware families. As per [2], there are 31
families of virus and 170 variants exist today. This also shows the curve is rapidly increasing
and hence in future we may expect much more harmful viruses.
2
Short Messaging Service
3
Multimedia Messaging Service

3
 Figure 1: Increase in known mobile malware variants
(Source: [2])

Figure 2: Increases in known mobile malware families

(Source: [2])

The figure 4 in the Appendix shows classification of the known mobile malware. We can see
that 15 variants exist for Cabir and 31 for Skuller. Most of the current known mobile malware
affect the Symbian operating system.

2.4 Harm caused by mobile malware

Current mobile malware are capable of causing the following harm to the infected devices or its
user:

• Causing financial loss to the user

– Initiate unnecessary calls, send SMS or MMS

– Send private information (such as contacts or address book information) to a prede-
fined phone

4
 • Spread via Bluetooth, causing drainage of battery

• Cause the devices to work slowly or to crash

• Infect files (attach its code to the application sis files)

• Modify or replace icons or system applications

• Wipe out information (such as address books) on the infected devices

• Install bogus applications on the device

• Allow remote control of the device

3 Case Studies
In this section, we look at case studies of some important and widespread mobile malware.

3.1 Cabir
Cabir is the first network worm capable of spreading through Bluetooth and was first detected
in June 2004. It was a Proof-of-Concept code developed by the group 29A. The intention was
to demonstrate how to exploit Bluetooth to spread worms. This worm infects mobile phones
which run the Symbian OS. Any handset running the Symbian OS is potentially vulnerable to
infection. Examples of such phones include the Nokia 3650, 7650 and N-Gage phones.
The worm itself is an SIS format file, called caribe.sis. Each time the infected phone is
switched on, the worm scans the list of active Bluetooth connections. The worm selects the
first active connection detected and attempts to send its main file, caribe.sis, to this device. If
receipt of the infected file is confirmed, the users will be asked if they wish to launch the file.
This worm does not cause any real harm since the intention was to only demonstrate how
Bluetooth could be used for spreading. However, since the worm keeps scanning for active
Bluetooth devices, it drains the battery of the phone rapidly.
Since Cabir is well documented and code is available freely, other malicious users used it for
developing malicious code to cause real damage. Cabir has 15 different variants.

3.2 Comwar
Comwar is the second landmark in mobile malware. This is the first worm for mobiles phones
which is able to propagate via MMS and could potentially go global in just minutes. It also
spreads over Bluetooth. It infects telephones running under OS Symbian Series 60.
The executable worm file is packed into a Symbian archive (*.SIS). The archive is approx-
imately 27 - 30KB in size. The name of the file varies: when propagating via Bluetooth, the
worm creates a random file name, which is 8 characters long, e.g. bg82o s1.sis
Once launched, the worm searches for accessible Bluetooth devices and sends the infected
.SIS archive under a random name to these devices. When the recipient user confirms that the
file is to be accepted, it will infect the phone.
The worm also sends itself via MMS to all contacts in the address book. The subject and
text of the messages varies. Since it sends MMS to all the contacts in address book it is not

5
as a proof of concept and the intention is to cause financial harm by charging the mobile user.
Scanning active Bluetooth devices also drains the battery.

3.3 Cardtrap
Cardtrap is the first mobile virus found which is capable of infecting Windows PCs. The most sig-
nificant characteristics of Cardtrap are that it also installs three Windows worms (Win32.Rays,
Win32.Padobot.Z and Win32.Cydog.B) onto the device’s memory card. Once the card is in-
serted into the PC, Padobot.Z will attempt to start automatically on machines running Windows
OS via the “autorun.ini” file.
A recent virus called Crossover (2006) spreads from Windows desktop PCs to mobile devices
running on Windows Mobile Pocket PC. Once it is installed on a Windows PC, the virus makes
a copy of itself and adds a registry entry pointing to the new file so that the payload is activated
each time the machine is rebooted. It then waits for an application for synchronizing Pocket
PC devices with the infected Windows desktop PC.
When a connection is detected, it copies itself over to the Pocket PC device, deletes all files
in the My Documents directory, copies itself to the system directory and places a link to itself
in the startup directory.

4 Futuristic Threats (original ideas by the authors)

This section has been thought of entirely by the authors.

Mobile malware as present today, does not present a significant risk to the average mobile user.
This is mainly because of the lack of potent mobile malware in the wild. We could determine
the following factors resulting in mobile malware being less harmful.

• Mobile devices did not store any critical information. Thus leaking it or erasing was not
lucrative to the mobile malware developers.

• Most of the mobile devices in use today do not support programmable capabilities or
for that matter processors capable of running applications. As a result, even with the
penetration of mobile devices being high, those that can support these mobile malware is
not very large.

Depending upon our study of the current technologies prevalent in the mobile domain, the
vulnerabilities present in them and the different possibilities of attack, we could briefly categorize
the futuristic threats in the following categories.

4.1 Location Tracking

Services already exist for tracking mobile users [6]. By using one of the many mobile phone
location tracking services aimed at businesses or concerned parents, and some trickery, it is
possibly to get almost anyone’s mobile phone position without their agreement. All that is
required is their mobile phone number, and carrier. Over the past year a number of sites have
popped up offering web based mobile phone tracking services. To use their services you purchase
a monthly subscription or set number of credits, and enter in the targets phone number. The
target then receives an SMS message asking them to confirm they consent to the tracking. After

6
the target replies, the tracker can then request their position online and receive a street address,
post code, and map of their location with an accuracy of around 250 meters.

4.2 Bugging
A bug is a tiny transmitter, that can covertly transmit the video and audio data to any receiver
nearby that is tuned to receive it. A mobile bug is an application that can take the microphone
audio data and the camera video data and stream it over a bluetooth connection. If an attacker
designs a mobile trojan and covertly installs it on a mobile device, then all the incoming and
outgoing voice calls can be tracked by that attacker. The trojan can also be programmed to
record this data and send it over a GPRS connection. This will result in a serious invasion of
privacy as well as a security risk. Leakage of video data can result in private information being
made public. Also as a result of the video data sent over the GPRS the user can be tracked
anywhere, including sensitive locations.

4.3 Leakage of confidential data

Mobile phones are increasingly being used for making online payments and managing e-accounts.
As a result of this a large amount of confidential data gets stored into the mobile. This includes
account information, account balance, passwords, credit card numbers, transactions etc. Also
mobile phones need authorization information which is stored in the form of public and private
keys. Since the data is easily accessible to any application, all of such sensitive and highly
confidential information can be easily leaked out by a trojan installed on the system.

4.4 DDOS attack

One of the most serious effects of having a multitude of mobile devices under a single MSP is
the threat of a DDOS attack. According to [12] a denial vulnerability existed in the GGSN4
made by Nokia. This could be remotely exploited by an attacker by sending a TCP packet as
0xFF. This was not handled by the GGSN which sent it into kernel panic and resulted in a
reboot of the GGSN. As a result of this, all the mobile devices connected to that GGSN would
lose connectivity.
This is a very serious vulnerability and one which can be attacked very easily. The DDOS
attack can be launched in two stages. In stage one the trojan will get installed into as many
mobile devices as possible and thus create a zombie army. Then on a aforementioned date and
time all of them will start to bombard the GGSN with these malformed packets resulting in
multiple reboots by the GGSN. Even if the GGSN blocked the devices one by one, it would take
a lot of time till they were all blocked.
The above exploit is the most serious effect possible of mobile malware that can result in
huge losses both for the mobile service providers as well as the users. Compared to DDOS
attacks on websites which hinder the access only to them, a DDOS attack on a mobile service
provider results in the total disconnection of all the clients under that service provider.
4
Gateway GPRS Service Node

7
5 Protection and Prevention Mechanisms
5.1 Common protection against mobile malware
• Keeping the device in non-discoverable Bluetooth mode: Since leaving a Bluetooth-enabled
mobile device in discoverable mode makes it vulnerable to attacks by mobile malware and
hackers that exploit the documented vulnerabilities [5] in Bluetooth, it is best to turn off
the Bluetooth discovery mode on the mobile device.

• Installing an anti-virus / IDS on the mobile device: Vendors such as Trend Micro [11] sell
anti-virus software and Intrusion Detection Systems (IDS) for mobile devices. Installing
these can protect the mobile devices from known malware.
Some vendors also sell firewalls for mobile devices.
However, it is not clear whether common users would go to the extent of installing such
additional software on their devices.

• Installing firmware updates when they are made available: Mobile device manufacturers
release updates to the firmware of the devices. These may contain patches to the vulnera-
bilities that are exploited by mobile malware. Upgrading to new firmware may reduce the
threat of being infected by mobile malware.

• Exercising caution when installing applications from untrusted sources: As in the case
of PC viruses, it is best not to install applications or to download other software from
untrusted sources.

• Filtering out malware at service provider : MMS messages that carry malicious payload
can be detected at the service provider based on their signatures and thus can be filtered
out at the service provider itself.

The futuristic threats provided above can be equated to the metaphorical tip of the iceberg.
The possibilities of attacking mobile devices can only be limited by what the technology permits
and hence very strong measure need to be taken for protection against such attacks. The
protection mechanisms can be broadly classified on the basis of the requirements of the protection
systems. They are

• System Level Security - MOSES Architecture System level security aims to make the
system more secure by restricting the execution of unauthorized applications.

• Network Level Security - Proactive Approach Network level security aims to provide a
basis of filtering out malware transitioning over the network between various devices.

5.2 MOSES
MOSES stands for MObile SEcurity processing System. and was developed by Anand Raghu-
nathan and his team working at NEC labs. The aim of designing MOSES was to overcome the
following challenges.

• Performance gap between the security processing requirements and the system processing
capabilities.

8
 • Limited battery life in mobile devices.

• Eliminating the possibilities of various types of attacks launched against the implementa-
tion.

According to [10]

The MOSES project employs a novel system-level design methodology to build the
hardware / software platform. The MOSES design methodology combines state-of-
the-art commercial design tools with several novel domain-specific methodologies that
are indispensable in deriving an optimized system architecture.

As per the MOSES methodology, a separate device from the main processor relates to a huge
jump in security. The idea is that if the security implementation is performed on a device
separate from the main processor,then if the main processor gets hacked into, the hacker won’t
have access to stored passwords and encryption keys that would be necessary for them to gain
access to further information.

Software Architecture

The software architecture for MOSES is layered and runs parallel to the one found in network
protocols. The top layer provides a generic interface which applications can use to be ported to
the platform. It consists of security primitives such as key generation, encryption/decryption of
a block of data which are implemented on top of a layer of complex mathematical operations.

Hardware Architecture

One of the most important features provided by the MOSES architecture is the extension of pro-
cessor instruction set for including cryptographic operations. This not only assists in increasing
the computational speed but also reduces the power consumed by the processor.

Performance

The MOSES platform has shown to speed up the execution of security protocols such as SSL,
IPSec, WTLS etc. For small data transactions, the MOSES platform contributes to an overall
transaction speedup of around 2.18X. In the case of large transactions, MOSES achieves and
overall transaction speed-up of 3.05X. [10]

5.3 Proactive Approach

The crucial protection measure performed in insecure environment is the search and destroy
methodology which is better known as the reactive approach. According to this principle, we
build a database of all the known virus signatures and then analyze the network traffic for their
existence.
This approach works when the network penetration is large but the network speed is slow.
As a result by the time the virus reaches critical mass and begins to cause chaos, the scanners
are already ready to pick it up.
But in today’s high speed networks, malware reach critical mass within a few hours. As
a result reactive approach fails miserably. In light of such context, we discuss a proactive
approach[1] that is better suited for solving this problem.

9
 The crux of implementing the proactive approach is to patch a client before it gets infected
or to stop a client from transferring data if it has been infected. However, the central problem of
the proactive approach lies in the assessment of the vulnerability of the client and the infection
status of the others. Hence to solve this problem, we need to develop a group-behavior based
proactive defense strategy.
The basic idea for doing so is as follows :

Behavior Vectors

A behavior vector can be defined as a collection of features which represent any client on the net-
work. For our representation, the behavior vector is two dimensional. One parameter represents
the physical information of the client device. The other represents the temporal information such
as network traffic and connectivity. Both of these can be extracted from the message headers
and the message logs.
The physical information of a client consists of data such as the operating system running on
the client, its version, the various applications running, the version of the firmware, etc. Since
most mobile malware propagate and infect by exploiting certain known vulnerabilities in the
system, having prior knowledge of the physical information of a client lets us classify the client
as vulnerable or not to the infection.
The second feature of the behavior vector can be calculated by the messages exchanged
by the different clients and hence is a temporal feature. This consists of information such as
the number of messages exchanged, the clients involved in the transaction, and the interarrival
rate of the messages. This component of the behavior vector puts a limit on the number of
clients that a mobile malware infection can propagate to. Thus every client in its immediate
neighborhood is at the maximum risk, those farther away, a little lesser.

Behavior Clustering

Once the behavior vectors are generated for all the clients based on the respective header infor-
mation and the message logs, the next step is to identify the various set of clients that belong to
the same cluster. The idea behind clustering is to have a limit on the number of filters to setup
within the network to monitor the traffic. Once a cluster is identified, then a single monitor can
be setup for the entire cluster. This is because any infection originating within the cluster will
stay confined to it and not pass outside.
There are a number of techniques that exist for clustering. A hierarchical graph partitioning
has been used to solve this problem, although any other approach can be used. Once the
clustering algorithm is executed on the behavior vector data, distinct clusters are identified.
Since the number of clusters is not fed to the clustering algorithm as it is not a requirement, the
algorithm is highly flexible in the number of clusters it can identify in the given graph data.
An important deployment issue is how often the service-behavior graph should be updated.
This is due to the highly volatile temporal data component. The solution depends on the
spreading speed of the malicious code and the amount of traffic flowing in the network. We
can also apply the triggered updates concept implemented in many intrusion detection systems.
Using triggered updates, the service behavior graph is updated whenever:

1. new vertices or edges are added (or subtracted) to (or from) the last computed graph.

10
 2. the parameters of the behavior vectors change by a certain threshold over the previous
values.

Proactive Containment Methods

Once the monitors setup within any cluster determine that the traffic from a particular client
is over a particular threshold, then we need to perform proactive containment to prevent an
infection from spreading, if one exists. This is performed in two stages.

Virus Throttling Algorithm

The virus throttling algorithm is designed keeping in mind the average flow of traffic in a network.
When a worm tries to propagate within a network, it repeatedly sends itself to every recipient
within that network. This type of behavior is identified by the virus throttling algorithm and
mitigated. The need for virus throttling algorithm exists because if a general user sends out a
legitimate and genuine message to multiple users, then a direct block approach will block this
legitimate message resulting in a false positive for the proactive approach. The intermediate
step of rate limiting due to the virus throttling algorithm decreases the false positive rate to a
near negligible value.

Figure 3: Virus Throttling Algorithm

(Source: [1])

The virus throttling algorithm works as follows : A working set of size n is maintained for
every client. This holds the clients that have been recently sent a message to. Whenever the
client wants to send a new message, the recipient is matched against this working set. If the
recipient exists, the message is sent immediately. If the recipient does not exist, then this message

11
is put on a delay queue. At periodic intervals, the top entry is removed from the delay queue.
This entry replaces the oldest entry from the working set using the least recently used algorithm.
Once that is done, all messages queued up for that recipient are delivered immediately. Also if
the queue length exceeds a particular threshold value, then all further messages can be blocked.

Quarantine

The aim of the virus throttling algorithm is to identify the false positives in the classifications
performed by the monitors installed in the clusters. Hence we set up a time and message
threshold on the output of the virus throttling algorithm. If after a certain period also the
message rate from the sender does not reduce, we can be certain that the client has been
infected by a worm, and hence we can quarantine that client from the network. All messages
from that client will thus be blocked.

5.4 Our thoughts on protective measures

With the increasing number of attack vectors being developed and the vulnerabilities being
exposed, the need for advanced protective measures is very much on the rise. As a result, the
protective measures proposed above have a very strong futuristic value. The main aspect of both
of these proposed schemes is to be proactive in approach and not reactive. Since the spread time
of mobile malware has dropped down exponentially, the malware can reach critical mass before
any proper reactive techniques can be designed to successfully combat it. Hence the proactive
measures are the only ray of hope as they can curb the malware from propagation before it is
even detected.
The MOSES system [10] designed has a very strong architectural base. Separating the crypto
engines from the actual mobile processing provides a fence within which all the secure data is
held. As a result, even if the processor security was compromised, the attacker cannot decipher
the secure data held within it. MOSES also uses secure connections for all communications and
hence evesdropping these by bug applications installed on the phone is not possible.
We found that the work done on proactive security in mobile networks [1] is highly needed
in view of the current and forthcoming network threats. The ideas of behavior vectors and
behavioral clustering proposed by the group have a solid ground in data mining activities. As
a result, it is not possible for the worm to propagate at a high rate without being detected and
effectively quarantined.
One disadvantage we found with this approach is that the Mobile service provider needs
to carefully monitor and update all the parameters involved with this approach. This requires
significant effort and also changes to the current underlying technology. Hence most of the
mobile service providers are hesitant and unwilling in adopting this protection measure. But
in due course of time, with faster network speed and higher network load, the mobile service
provider will face threats from the infected mobile devices. We have shown one such example in
the section “Futuristic Threats”. In such a scenario, the service provider will have to implement
protective measures to protect the network from such attacks.

12
6 Conclusion
Mobile devices are becoming smarter and more powerful. Such devices, once in widespread use,
will herald the growth of using mobile devices for performing sensitive tasks such as storing
sensitive data and performing eBanking transactions. Recent reports show that there exist
sufficient vulnerabilities in these devices that could be exploited to cause harm to the device, to
reveal sensitive information or to use the mobile device in a malicious way. It is, therefore, easy
to visualize that in the near future, the threat posed by mobile worms and viruses can cause
considerable harm to the users of such devices.

Acknowledgements
The authors would like to thank the faculty, Prof. Bernard Menezes, IIT Bombay for encouraging
and supporting the team during the course of the project. The authors would also like to thank
Kaspersky Labs for bringing out a concise report [2], [3] on mobile worms and viruses.

References
[1] A. Bose,K. G. Shin.“ProactiveSecurityforMobileMessagingNetworks”, WiSe’06, Septem-
ber29,2006.

[2] A. Gostev, Kaspersky Labs. (October 2006). Mobile Malware Evolution: An Overview, Part
1. [Online]. Available: http://www.viruslist.com/en/analysis?pubid=200119916

[3] A. Gostev, Kaspersky Labs. (October 2006). Mobile Malware Evolution: An Overview, Part
2. [Online]. Available: http://www.viruslist.com/en/analysis?pubid=201225789

[4] A. Gostev, Kaspersky Labs. (October 2006). Kaspersky Security Bulletin, January - June
2006: Malicious programs for mobile devices. [Online]. Available: http://www.viruslist.
com/en/analysis?pubid=198981193

[5] C. Mulliner. “Advanced Attacks Against PocketPC Phones”, Defcon 14, August 2006.

[6] Darknet. (October 2006) Locate anyone in the UK via SMS. [Online]. Available: http:
//www.darknet.org.uk/2006/02/locate-anyone-in-the-uk-via-sms/

[7] K. Haataja, “Two practical attacks against Bluetooth security using new enhanced imple-
mentations of security analysis tools”, Proceedings of the IASTED International Conference
on Communication, Network and Information Security (CNIS 2005), Phoenix, Arizona, USA,
November 14-16, 2005.

[8] M. Herfurt. “Bluesnarfing @ CeBIT 2004”, CeBIT 2004.

[9] MobileActive.org (November 2006) Security Guide for Mobile Activists: Checklist and
Tips. [Online]. Available: http://mobileactive.org/wiki/index.php?title=Security_
Guide_for_Mobile_Activists:_Checklist_and_Tips

[10] S. Ravi. (October 2006) Embedded System Security. [Online]. Available: http://www.
princeton.edu/~sravi/security.htm

13
[11] Trend Micro. (October 2006) Trend Micro Mobile Security. [Online]. Available: http://
www.trendmicro.com/en/products/mobile/tmms/evaluate/overview.htm

[12] CVE-2003-0368. (October 2006) Common Vulnerabilities and Exposure. [Online] Available:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0368

[13] Linux Devices. (October 2006) The Linux Mobile Phones Showcase. [Online] Available:
http://www.linuxdevices.com/articles/AT9423084269.html

[14] 29A. (October 2006) Source Code - Cabir. [Online] Available: http://netsecurity.
51cto.com/art/200605/26545.htm

14
7 APPENDIX
Known mobile malware

Figure 4: Mobile Malware Families at a glance

(Source: [2])

15