Mobile Client-Honeypot

by

Pacharawit Topark-ngarm

Supervisors: Dr. Ian Welch, Dr. Peter Komisarczuk

Submitted in partial fulfilment

of the requirements for
Doctor of Philosophy in
Engineering and Computer Science
Victoria University of Wellington

8 December 2009
 Abstract

Today the smartphone has become more powerful than ever before and
has become a significant proportion of the mobile phone with 15% market
of all phones sold being classed as smartphones. We use smartphone more
like we use a laptop computer to browse the Internet, send/receive emails,
transfer files, watch, create and transmit multimedia and install new software.
The smartphone malware threat has continuously increased in the last few
years since the first mobile malware (cabir) was found on the Symbian mobile
phone in 2004. In this research our target is to develop a mobile honeypot
that will search for mobile malware and study the characteristics of these
malware threats. We will extend the Capture-HPC developed by Christian
Seifert et al. to work within the constraints of a smartphone platform. This
technique provides a cost effective solution and goes beyond the smartphone
constraint of processing power and power consumption. We will evaluate
the accuracy and performance our technique compared with the system that
runs on the actual smartphone. As a result of this study, we aim to better
understand the characteristic of the current mobile malware as well as create
instruments and analysis tools. This work leads to the development of a
more effective intrusion detection and prevention system for smartphone.
Contents

1 Introduction 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Research Question . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background and Related Work 3

2.1 What Is Malware? . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Malware Defenses . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.2 Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.3 Intrusion Detection System . . . . . . . . . . . . . . . 5
2.2.4 Honeypot . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Smartphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Smartphone Malware . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Malware Families and Variants: Statistics . . . . . . . 11
2.5 Smartphone Exploit . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.1 Browser Exploit . . . . . . . . . . . . . . . . . . . . . . 16
2.5.2 Bluetooth Exploit . . . . . . . . . . . . . . . . . . . . . 17
2.6 Smartphone Defenses . . . . . . . . . . . . . . . . . . . . . . . 18
2.6.1 Operating System . . . . . . . . . . . . . . . . . . . . . 18
2.6.2 Intrusion Detection System . . . . . . . . . . . . . . . 21
2.6.3 Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7 Software Development for Smartphones . . . . . . . . . . . . . 25
2.7.1 IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.7.2 SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.7.3 Emulator . . . . . . . . . . . . . . . . . . . . . . . . . 26

i
3 Proposed Solution 27
3.1 General Requirements . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Why can’t we use Capture-HPC? . . . . . . . . . . . . . . . . 28
3.3 Mobile Client-Honeypot . . . . . . . . . . . . . . . . . . . . . 28
3.3.1 Capture Server . . . . . . . . . . . . . . . . . . . . . . 28
3.3.2 Analysis Engine . . . . . . . . . . . . . . . . . . . . . . 30
3.3.3 Database . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.4 Capture Client . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.1 Mobile Honeypot on Emulator . . . . . . . . . . . . . . 33
3.4.2 Mobile Honeypot on Actual Smartphone . . . . . . . . 33
3.4.3 Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Conclusion 35
4.1 Work Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Expected Contributions . . . . . . . . . . . . . . . . . . . . . 35
4.3 Progress To Date . . . . . . . . . . . . . . . . . . . . . . . . . 35

ii
List of Figures

2.1 Client Honeypot Architecture . . . . . . . . . . . . . . . . . . 8

2.2 Simplified view on the most common smartphone interfaces
based upon a Figure from [1] . . . . . . . . . . . . . . . . . . . 8
2.3 Diagram of malware percentage for each platform from Jun 04
- Aug 06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Diagram of malware percentage for each platform from Sep 06
- Aug 09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Graph of new variant found each month from Sep 08 Aug 09 15

3.1 Mobile Client-Honeypot . . . . . . . . . . . . . . . . . . . . . 29

3.2 Mobile Client-Honeypot Architecture on Emulator . . . . . . . 32
3.3 Mobile Client-Honeypot Architecture on Bare Metal . . . . . . 32

iii
List of Tables

2.1 Common Virus, Worm, and Trojan Horse characteristics . . . 4

2.2 Smartphone interfaces and threat through them . . . . . . . . 9
2.3 The description of threats . . . . . . . . . . . . . . . . . . . . 10
2.4 Summary of mobile malware from June 2004 to August 2006 . 11
2.5 Summary of mobile malware as of August 2009 . . . . . . . . 13
2.6 Summary of mobile malware from September 2009 - August
2009 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1 Time line of future research . . . . . . . . . . . . . . . . . . . 37

iv
Chapter 1

Introduction

1.1 Introduction
Mobile malware has continuously increased since the first mobile malware
appeared in June 2004[2]. In order to protect users from them, we need to
know how they infect the device, what is the payload of those malwares. The
goal of this project is to build a client-honeypot system for mobile device such
as smartphone. Mobile client-honeypot will go out and search for malware
which will specifically infect mobile device. Smartphone emulator allows us to
run smartphone application and emulate smartphone status without having
a physical device. Moreover, running smartphone emulator on a desktop
computer helps us to go beyond some of the smartphone constraints, e.g.
battery consumption, processor power.

1.2 Research Question

The main research question of this thesis are:

• Can we apply the concept of client honeypots to mobile devices such

as smartphones?

• What useful information can we extract to analyze malicious behavior

and malware trend?

From the above questions, we should be able to answer the following

questions:

• Can attackers tell the difference between an emulator and a “real”

smartphone?

1
 • How effective are mobile honeypots running on emulators compared to
the “real” smartphone?

• How effective are mobile honeypots compared to antivirus solutions?

Moreover these questions also interest us:

• How much are different mobile operating systems prone to the same
type of attack?

• Do drive-by-downloads present differently to smartphone compared to

PC?

1.3 Scope
We limit our study to the creation of mobile client-honeypot system that
will be running on emulator. Besides focusing on using emulator, we further
concentrate on the smartphone trojan which is the most popular form of
mobile malware. The method of evaluation will be less concerned about the
speed of the system but will give priority on the accuracy.

2
Chapter 2

Background and Related Work

In this chapter, we review the basic concept of malware and existing defense
mechanisms on PC and smartphone.

2.1 What Is Malware?

Malware is a short word for malicious and software[3], so its software writ-
ten with malicious intention. There are many techniques that the attackers
used to spread the malware. Some of the well known techniques are code
injection, file transport, exploit, or boot sector corruption. File injection is
the exploitation of a computer bug that is caused by processing invalid data.
Code injection can be used by attacker to inject code into a computer pro-
gram to change the course of execution. For example, code injection is used
by some Computer worms to propagate. An exploit is a piece of software,
a chunk of data, or sequence of commands that take advantage of a bug,
glitch or vulnerability in order to cause unintended or unanticipated behav-
ior to occur on computer software or hardware. This frequently includes such
things as violently gaining control of a computer system or allowing privilege
escalation or a denial of service attack. Malware can harm the compromised
device in many ways. There are three main categories of malicious software:
virus, worm, and Trojan horses.
A virus is a computer program that can copy itself and infect a computer
without the permission or knowledge of the owner. A virus mostly comes in
executable file. If the user executes this file the virus processes its malicious
commands, which can be almost everything the OS allows.
A worm can often spread without user interaction. Depending on the
OS, this can operate with the same permission as the user. Once started, it
searches for infectable victims in range. If a victim is found, it uses an exploit

3
to attach itself to the victim and then repeats this behavior. Sometimes
worms drop other malware that can be backdoors that allow remote access.
Malicious programs installed that way can make the victim vulnerable to a
remote triggered Denial of Service (DoS) attacker.
A Trojan horse is a program that is disguised as a popular application in
order to persuade a user to execute or install it. This is done by choosing
a well-known name like from a popular game and placing the malware for
download on a web page or file sharing tool.

Table 2.1: Common Virus, Worm, and Trojan Horse characteristics

Malicious Prop- Vector Payload

erty
Virus need host / re- file transport, replication,
quire user inter- file injection, variant
action exploit
Worm independent exploit replication,
program / no remote ac-
user interaction cess
required
Trojan program with file transport, remote
Horse hidden agenda/ exploit access,
require user destructive
interaction functional-
ity

2.2 Malware Defenses

In this section, we review the existing defenses to malware.

2.2.1 Firewalls
Firewalls primarily consist of packet filters and/or proxy servers. A packet
filter is a component that can restrict network flow based on the information
found in the TCP/IP header. Once network flow is permitted, a packet filter
does not provide any protection against the data contained in this network
flow. However, a packet filter can block access on a particular server port,
which would effectively block a particular type of client from connecting
to particular types of servers, at the expense of availability of the service.

4
Alternatively, a packet filter can allow for more fine grained control of access.
It can prevent access to malicious servers by blocking network flow to these
servers.

2.2.2 Antivirus
Antivirus software is another defense mechanism. The early versions were
highly focused to detect just particular types of viruses. Shortly after, first-
generation scanners appeared that were able to identify viruses based on sim-
ple string matching. Antivirus software initially was tasked with identifying
viruses and disinfecting the infected files. The scanning techniques, as a re-
sult, were highly specialized to concentrate on binary data within executable
files. In addition, antivirus software uses emulators to identify stealth viruses
and heuristics to identify unknown viruses. In recent years, antivirus soft-
ware has started to focus on identification of exploits found on web pages
as well. Nevertheless, a recent evaluation of available antivirus software has
revealed that they are quite ineffective in detecting web exploits probably
due to the historical focus on identifying malicious binary data.

2.2.3 Intrusion Detection System

An Intrusion detection system (IDS) is a network security device that mon-
itors network and/or system activities for malicious or unwanted behavior.
There several types of Intrusion Detection Systems.

Network-Based Intrusion Detection

A network-based IDS (NIDS) looks for attack signatures in network traffic.
Typically, a network adaptor running in promiscuous mode monitors and
analyzes all traffic in real-time as it travels across the network. The attack
recognition module uses network packets as the data source. There are three
common techniques for recognizing attack signatures: pattern, expression or
bytecode matching, frequency or threshold crossing, and correlation of lesser
events. Snort is a popular NIDS developed in the open-source community.

Host-Based Intrusion Detection

A host-based IDS (HIDS) looks for attack signatures in log files of hosts.
It can also verify the checksums of key system files and executables at reg-
ular intervals. Some products can use regular-expressions to refine attact
signatures (e.g. passwd program executed AND .rhosts file changed). Some

5
product listen to port activity and generate alerts when specific ports are
accessed, providing limited NIDS capability. There is a trend towards host-
based intrusion detection. The most effective IDSs combine NIDS and HIDS.
Due to the near real-time nature of IDS alerts, and IDS can be used as a
response tool, but automated responses are not without dangers. An attacker
might trick the IDS to respond, with the response aimed at an innocent target
(e.g. by spoofing the source IP address). Users can be locked out their
accounts because of false positives. Repeated email notifications become a
denial-of service attack on the administrators email account.

Anomaly Detection
Statistical anomaly detection (or behavior-based detection) uses statistical
techniques to detect potential intrusions. First, the ‘normal’ behavior is
defined as a baseline. During operation, a statistical analysis of the data
monitored is performed and the deviation from the baseline is measured. If
a threshold is exceeded, an alarm is issued. This type of IDS does not need
to know about security vulnerabilities in a particular system. The baseline
defines normality. So, there is a chance to detect new attacks without having
to update a knowledge base.
On the other hand, anomaly detection detects just anomalies. Suspicious
behavior does not always define as an intrusion. For example, a number
of failed login attempts could be due to an attack or to the administrator
forgot the password. There are some problems that we need to point out.
Attacks are not always anomalies especially when the baseline is adjusted
dynamically and automatically. A careful attacker might just gradually shift
‘normality’ over time until his planned attack no longer generates an alarm.
We have to be concerned about false positives (false alarms) when an attack
is identified but none is taking place, and false negatives when an attack is
missed because it acts within the range of normal behavior.

2.2.4 Honeypot
Honeypot is a trap set to detect, deflect, or in some manner counteract
attempts at unauthorized use of information systems. Generally it consists
of a computer, data, or a network site that appears to be part of a network,
but is actually isolated, (un)protected, and monitored, and which seems to
contain information or a resource of value to attackers.

6
Client Honeypots
Client honeypots are a technology that is able to detect client side attacks.
Client honeypots can be used to identify malicious servers on a network.
They do so by generating a queue of server requests, issuing these requests
to the servers one-by-one and consuming the response of the servers. After
a response is consumed, the client honeypot can perform an analysis that
determines whether the server is malicious or benign. Figure 2.1 shows the
architecture of a generic client honeypot.
A low-interaction client honeypot will analyze the servers response and
match the signature to a list of known attacks. If there is a match, the server
will be classified as malicious. Honeyd Virtual Honeypot[4] is an example of
a low-interaction client honeypot.
A high-interaction client honeypot uses a more thorough approach. Full
client operating systems and applications are used and the entire system is
monitored for state changes. Classification is based on monitoring unau-
thorized state changes or actions occurring on the system after the client
honeypot has interacted with a server. Client honeypots have solely purpose
and since no other activity is occurring on them, unauthorised state changes
such as new processes, newly installed files, etc. can be detected by the client
honeypot. Once state changes are detected and the classification has been
made, the machine needs to be reset into a clean state before it can inter-
act with another server[5]. The advantage of this approach is it can detect
both known and unknown attacks, however the increased resources needed
means this method is slower than a low-interaction client honeypot. Strider
HoneyMonkey[6] is an example of a high-interaction client honeypot.

2.3 Smartphone
Similar to PC, smartphone usually has operating system (OS) and often
provided with SDK makes smartphone easier than in the past to program.
Figure 2.2 show a simplified view on the most common smartphone interfaces
which can be accessed through libraries included in SDKs[1].
A smartphone has many vulnerabilities. It can be stolen, hacked, or
exploited with malware through each interface. Table 2.2 shows smartphone
interfaces and threats through them[1].

• The Device Interfaces, for example; mini USB interface, power supply,
or headphone interface. These can be attacked by physically destroying
the interface or by giving inappropriate inputs, such as plug-in the
phone with too high voltage.

7
CHAPTER 2. BACKGROUND AND RELATED WORK 7

Request

Benign
Server
Response

Request

Client Honeypot

Attack
Malicious
Server

!
Figure 2.1:2.1:
Figure Client honeypot
Client architecture
Honeypot [36].
Architecture

made, the machine needs to be reset into a clean state before it can interact
with another server [36]. The advantage of this approach is it can detect
both known and unknown attacks, however the increased resources needed
means this method is slower than a low-interaction client honeypot. Strider
HoneyMonkey [41] is an example of a high-interaction client honeypot.

2.1.1 Capture Honeypot Client

Capture-HPC [33] is a high-interaction client honeypot being developed by
Seifert et al. We have chosen Capture-HPC as a case study for this research.
Figure 2.2 shows the architecture of Capture which runs on a group of net-
worked computers. A set of URLs to be tested is passed to the Capture-server
component, which (one-by-one) delegates these to Capture-client components
to test. The CaptureClient instance is executed inside a Virtual Machine
(VM) hosting! Windows XP (a default installation and standard network se-
Figuresettings).
curity 2.2: Simplified viewVMs,
Multiple on the most
each common
running smartphone interfaces
a CaptureClient instance,based
can
upon a Figure from [1]

8
 • The Connectivity Interfaces, these including both wired and wireless
communication interfaces. The example of wired interface is USB data
link. The examples of wireless interface are 2G/3G mobile commu-
nication, Wireless-LAN, Bluetooth, and IrDA. Wireless communica-
tion cannot guarantee confidentiality, since attacks can come from any
where in radio range. This allows various kinds of attacks.
• The User Interfaces consist of the interfaces related to user input and
output. Most attacks of PCs are applicable here, for instance people
can misuse unattended foreign devices for dialing premium numbers,
altering data, deny incoming calls, or read and fake information.
• The External Memory Interfaces can be used to insert infected mem-
ory card in order to distribute malware. Many kinds of attack can be
done after the phone is compromised. Common card formats are Com-
pact Flash, Secure Digital (SD) Memory Card, and Multimedia Card
(MMC), Memory Stick, and etc.
But not only the external interfaces have such vulnerability, the internal
interfaces such as the OSs application programming interfaces (APIs) can
also be compromised. Attackers can program malicious code and install to
the phone. As stated earlier, API can usually control most of the devices
features and most of the available API can normally be accessed by provided
SDK. There are usually APIs provided for file system, SMS, MMS, email,
OS, audio, camera, phone call, and several other tasks. This has shown that
the danger of smartphone malware is very high. Next section, we will discuss
about smartphone malware.

Table 2.2: Smartphone interfaces and threat through them

Auth. Violation
Eavesdropping
Masquerading

Loss or Mod.
Repudiation
Forgery
DoS

Device •
Connectivity • • • • • • •
User • • • • • •
External Memory • •
API • • • • • • •

9
 Table 2.3: The description of threats

Masquerading An entity claims to be another

Eavesdropping An entity reads information that it is not in-
tended to read
Authorization An entity uses a service or resource it is not
Violation intended to use
Loss or Variant Data is being altered or destroyed
of Data
Repudiation An entity falsely denies its participation in a
communication act
Forgery An entity creates new information in the
name of another entity
Denial of Service Any action that aims to reduce the availabil-
ity and / or correct functioning of services or
systems

2.4 Smartphone Malware

In this section, we will discuss the general information of smartphone mal-
ware.
“Mobile Phones: The Next Frontier For Hackers?” by Leavitt et al.[7]
had provided a general overview on smartphone malware. They present some
of the malwares in 2005: Cabir, Skull, Mquito. Cabir runs on smart phones
that support the Nokia-licensed Symbian Series 60 platform. Cabir can be
acquired via a shared infected application or it can replicate via Bluetooth.
The worm arrives on victims phones as .SIS (Symbian installation system)
application-installation file. When user install, the worm will interfere with
a host devices Bluetooth system by forcing it to constantly scan for other en-
abled devices. This reduces a devices battery life and either makes Bluetooth
unavailable to legitimate applications or degrades Bluetooth performance.
Skulls is a Trojan horse that target Nokia 7610 phone, and thus masquer-
ades as a useful application to convince users to install it. Skulls makes
the original Symbian binaries such as file management, Bluetooth control,
messaging, Web browsing, and application installation and removal useless
by replacing them with non-functional binaries. The phones can then only
make and receive calls. Mquito is a version of the popular Mosquito game on
Symbian Series 60 device whose copy protection crackers have broken. Once
the game is installed, it secretly sends unauthorized SMS text messages to

10
high-cost toll phone numbers in Germany, Holland, Switzerland, and the UK.

2.4.1 Malware Families and Variants: Statistics

Mobile malware had grown rapidly during the first two years (2004 - 2006)
of its first presented. During this period, a wide range of malicious programs
targeting mobile phones appeared, and these programs were very similar to
malware which targeted desktop computers: viruses, worms, and Trojans
which including spyware, backdoors, and adware. Table 2.4 shows the sum-
mary of the malware during the period of June 2004 to August 2006. At
that time, Symbian was the dominant market leader. If the situation had
remained unchanged, there should be a huge amount of malware for Symbian
smartphones now. However, the situation has changed: Symbian have lost
their leading market share to other mobile operating systems and devices.
At present, Nokia’s share of the smartphone market is around 45%.

Table 2.4: Summary of mobile malware from June 2004 to August 2006

Platform Number of Number of Percentage

Families Variants of Variant
Symbian 26 161 94.71%
J2ME 1 2 1.18%
WinCE 2 3 1.76%
MSIL 2 4 2.35%
Total 31 170 100.00%

Microsoft was the first to hit Symbian with Windows Mobile platform.
Windows Mobile 5 was the core success and was supported by many major
phone manufacturers. Version 6 was released after, with the source code of
the operating system being published. Today, Windows Mobile holds about
a 15% share of the global smartphone market, and is the market leader in
some countries. Four of the biggest mobile phone manufacturers (excluding
Nokia) have licensed Windows Mobile from Microsoft.
Research In Motion or RIM has also grown its market share consistently.
Blackberry device, which runs a proprietary operating system, has become
very popular in the USA, especially for businessperson. No malware for
this platform has been identified apart from BBproxy, a proof-of-concept
backdoor created by vulnerability researchers.
Apple’s iPhone uses the mobile version of Mac OS X, and very quickly
became one of the best selling mobile devices across the world. By now, more

11
 !
Figure 2.3: Diagram of malware percentage for each platform from Jun 04 -
Aug 06

than 21 million iPhones of all types have been sold. If including the sales
of the iPod Touch (an iPhone without the phone), then the total number
reaches 37 million.
The recently launch of Google’s Android platform, which offers a lot of
possibilities for creating applications and using Google services, then sud-
denly, it’s very unclear which platform will be the leader in the future.
When virus writers realized that there was no clear leading operating
system for mobile devices, they also realized its not possible to target the
majority of mobile device users with a single attack. Because of this, they
started focusing less on writing malware which targeted specific platforms,
and more on creating programs that is capable of infecting multiple platforms.
The virus writers have turned their attention to Java 2 Micro Edition.
Just about all modern mobile phones support Java and can run Java applica-
tions which can be downloaded from the Internet. In creating malicious Java
applications, virus writers have gone beyond the limits and have managed
to significantly extend the number of infectable devices with cross-platform,
which now includes regular mobile phones as well as smartphones.
In August 2006, there were 31 mobile malware families and 170 vari-
ants. As of August 2009, Kaspersky Lab had identified 106 families and
514 variants, which represent 202% growth within the period of three years.
The number of malware families has increased by 235%[8]. Table 2.4 shows

12
summary of mobile malware as of August 2009.

Table 2.5: Summary of mobile malware as of August 2009

Platform Number of Number of Percentage of Increase from

Families Variants Variant Aug 06
Symbian 62 253 49.22% 92
J2ME 31 182 35.41% 180
WinCE 5 26 5.06% 23
Python 3 45 8.75% 45
SGold 3 4 0.78% 4
MSIL 2 4 0.78% 0
Total 106 514 100.00% 344

!
Figure 2.4: Diagram of malware percentage for each platform from Sep 06 -
Aug 09

More precisely, with in the past 1 year, the virus writers has been more
focused on cross-platform infection. Table 2.6 shows the new variants found
in each month during the past 1 year.
Three years ago, mobile malware was capable of
• Spreading via Bluetooth, MMS
• Sending SMS messages

13
 Platform Sep-08 Oct-08 Nov-08 Dec-08 Jan-09 Feb-09 Mar-09 Apr-09 May-09 Jun-09 Jul-09 Aug-09 Total
Symbian 0 1 0 1 13 3 1 5 0 2 1 0 27
J2ME 22 4 2 7 2 5 14 0 4 1 0 1 62
WinCE 19 1 0 0 0 0 0 0 0 0 0 0 20

14
Python 0 0 0 1 0 0 0 0 0 1 0 0 2
SGold 0 0 0 0 0 0 0 0 0 0 0 0 0
MSIL 0 0 0 0 0 0 0 0 0 0 0 0 0
Total 41 6 2 9 15 8 15 5 4 4 1 1 111
Table 2.6: Summary of mobile malware from September 2009 - August 2009
!
Figure 2.5: Graph of new variant found each month from Sep 08 Aug 09

• Infecting files
• Enabling remote control of the smartphone
• Modifying or replacing icons or system applications
• Installing “fake” or non-working fonts and applications
• Combating antivirus programs
• Locking memory cards
• Stealing data
Within the past three years mobile malware has adopted a number of
new technologies and techniques which include:
• Spreading via removable media (memory cards)
• Damaging user data
• Disabling operating system security mechanisms
• Downloading other files from the Internet
• Calling paid services
• Polymorphism (self-modified to hide from antivirus programs)

15
2.5 Smartphone Exploit
An exploit is a piece of software, a chunk of data, or sequence of commands
that take advantage of a bug or vulnerability in order to cause unintended
behavior to occur on computer software or hardware. The result of a success-
ful exploit may vary from gaining control of a computer system or allowing
privilege escalation or a denial of service attack.

2.5.1 Browser Exploit

A browser exploit is a piece of code that exploits a bug in a web browser.
The code makes the browser do something unexpected, which normally in-
cluding crash, read or write local files, propagate a virus or install malware.
Malicious code may exploit HTML, JavaScript, Images, ActiveX, Java and
other Web technologies. HTML alone can only crash browser in some cases
on vulnerable web browsers. However, if HTML combines with malicious
ActiveX or Java code, it can freeze or crash a browser, or even crash the
computer running that browser.
An example of browser exploit technique is shown in [9] by Daniel et
al. This technique can be used to develop client side exploits against web
browsers that use JavaScript. The attacker creates a web page containing
JavaScript commands and convinces the victim to browse the page. This
technique is applicable when one has a heap overflow in hand. A heap over-
flow is a type of buffer overflow that occurs in the heap data area. The
buffer that is overflown will be referred as the vulnerable buffer. The goal is
to control a buffer in the heap immediately following the vulnerable buffer.
Its accomplished by arranging the heap so that all holes in it that are big
enough to hold the vulnerable buffer are surrounded by buffers that is con-
trolled.
Another example of browser exploit has been describe in [10] where a
group of researchers found vulnerabilities in iPhones safari browser. The
iPhone comes with a version of the Safari web browser called MobileSafari.
This version of the browser is very similar to Safari application on the desktop
and they share much of the same code base. However, many of the features
of Safari have been removed in MobileSafari. The authors of [10] have create
an exploit page for MobileSafari. When this page is viewed, it will trigger
heap buffer overflows which exist in the Perl Compatible Regular Expressions
(PCRE) library used by the JavaScript engine in Safari. The result of the
exploit leads to arbitrary code execution. In the case of [10], it forced the
iPhone to make an outbound connection to a server that is controlled by the
author. The compromised iPhone then send personal data including SMS

16
text messages, contact information, call history, and voice mail information
over this connection. All of this data is collected automatically and secretly.
Other personal data such as passwords, emails, and browsing history can also
be obtained from the device.

2.5.2 Bluetooth Exploit

Bluetooth wireless technology is a short-range communications technology
intended to replace the cables connecting portable and/or fixed devices[11].
Bluetooth has a very limited range, usually around 10 metres (32.8 ft) on
mobile phones, but laptops can reach up to 100 metres (328 ft) with powerful
(Class 1) transmitters. Normally, Bluetooth exploit is quite limited due to
the range of the radio.

Bluejacking
Bluejacking is the method of sending unsolicited messages over Bluetooth to
Bluetooth-enabled devices such as mobile phones, PDAs or laptop comput-
ers. For example; sending a vCard which typically contains a message in
the name field to another bluetooth enabled device via the OBEX protocol.
Bluejacking is usually harmless but the receiver may be confused and think
that the device is malfunctioning.

Bluesnarfing
Bluesnarfing is the unauthorized access of information from a wireless device
through a Bluetooth connection. This allows access to a calendar, contact
list, emails and text messages. In order to perfom a Bluesnarfing attack, the
attacker needs to connect to the OBEX Push Profile (OPP). OPP has been
specified for the easy exchange of business cards and other objects. In most
cases, this service does not require authentication. The Bluesnarfing attack
connects to an OBEX Push target and performs an OBEX GET request
for known filenames such as ‘telecom/pb.vcf’ for the devices phone book or
‘telecom/cal.vcs’ for the devices calendar file.

Bluebugging
Bluebugging is the name of a bluetooth security loophole on some bluetooth-
enabled cell phones. Exploiting this loophole allows the unauthorized down-
loading phone books and call lists, the sending and reading of SMS messages
from the attacked phone and etc. Bluebug security loophole allows issuing

17
AT commands via a covert channel to the vulnerable phones without prompt-
ing the owner of this phone. This security flaw allows a many things that
may be done when the phone is attacked via Bluetooth. For example: make
a phone call, sending SMS, read phone book/SMS, connecting to Internet,
and etc.

2.6 Smartphone Defenses

This section, we review existing smartphone defense mechanisms.

2.6.1 Operating System

Symbian
Symbian Limited is a software producing company located in London, UK. It
is owned by Ericsson (15.6%), Nokia (47.9%), Panasonic (10.5%), Samsung
(4.5%), Siemens (8.4%) and Sony Ericsson (13.1%). Symbian core business is
developing and licensing Symbian OS, an operating system for mobile devices
which has evolved from former Psions Epoc. Smartphone manufacturers that
license Symbian OS are Arima, Ben Q, Fujitsu, Lenovo, LG Electronics, Mo-
torola, Mitsubishi, Nokia, Panasonic, Sam- sung, Sharp and Sony Ericsson.
Symbian OS introduces three security concepts, which are capabilities,
installation file signing, and data-caging. Capabilities limit access to sensi-
tive APIs. There are basically three levels of limitation where on the highest
level full device and network access is granted to the corresponding appli-
cation. These limitation levels are defined by certificates that are used to
sign Symbian OS Installation System (.SIS) files. Without a valid signing,
it is not possible to install application on Symbian OS devices unless the
users turn off the certificate checking function on their devices. Data-caging
extends this approach as it limits access to the file system. Depending on the
limitation coming from the certificate, application can only write to certain
areas, like the application folder, user data folder, or system folder.

Windows Mobile
The Windows Mobile operating system is based on Windows CE and was
developed for mobile devices like PocketPCs, PDAs, smartphones, and em-
bedded systems. In 2003 there were three different version of Windows Mo-
bile: Windows Mobile 2003 for Pocket PC, Windows Mobile 2003 for Pocket
PC Phone Edition and Windows Mobile 2003 for Smartphones. The cur-
rent version Windows Mobile uses the .NET Compact Framework to enable

18
.Net applications. Windows Mobile supports WIFI, GPS, PC (Windows)
synchronization.
Windows Mobile security concept has three major approaches: security
roles, security policies, and application signing. Security roles define users
or groups having predefined rights on a device. The most privileged role
allows changing security policies, which are rules permitting certain actions
on the device, for example, installing and running unsigned applications.
Application signing principles of Windows Mobile are very similar to the
ones with the Symbian OS. Basically, Windows Mobile software is signed in
order to permit access to sensitive APIs.

iPhone
The Apple iPhone is a very interesting device that can be classified as smart-
phone since Steve Jobs from Apple announced a SDK for it. The device runs
a modified version of Mac OS X and includes several applications, e.g. the
Safari browser, a music player, and digital camera.
The security architecture of the iPhone can best be described as one of
reducing the attack surface. This is accomplished by limiting the number
of applications on the device and limiting the functionality of the existing
applications. MobileSafari is an example of the reduced functionality of the
application. On a normal Mac OS X computer, Safari comes with the ability
to display Flash, while MobileSafari does not have this capability. Moreover,
when downloading archives like dmg or zip files, Safari will launch the appro-
priate helper applications, save them to disk, and then mount or uncompress
them. MobileSafari refuses to download these file types. Similar limitations
are on MobileMail as many attachment types supported on standard Mac OS
X installs are not supported by MobileMail. Also, the iPhone does not listen
on any TCP or UDP ports for incoming data. This reduction of the type
of data processed by the device is an effective way to reduce the potential
surface for vulnerabilities.
Apple iPhone does not allow third party applications to run on the device
unless the application is signed by Apple. The application has to go through
many verification processes. Developers have to submit their applications to
Apple and Apple will test the applications to make sure that the application
don’t contain any bug or malicious activities. The verification process could
take up to two weeks.

19
Android
Google Android is a package of software that includes an operating system,
middleware and basic applications. The Android system is built on the Linux
2.6 Kernel and supports most of original provided functionalities. Android
treats every application equal, which means on the one hand that a developer
is able to replace every single android program. On the other hand it means
that if you develop an android application it can be run on any Android
device and only limited by the provided functionalities of the device.
The security mechanisms that found in Google Android basically are
based on the same mechanisms that in the linux system. Especially access
control, user and group IDs, are managed where every installed application
gets its own user ID with its specific permissions. These permissions allow
fine-tuned access adjustment for processes using certain functionalities such
as sending SMS messages or dialing a phone call.

J2ME
The Java 2 Platform Micro Edition is no stand-alone operating system, but
since most of today’s smartphones support it and allowed Java ME applica-
tion to be installed on devices, so we should mention it in this section. J2ME
enables cross-device compatibility. J2ME has introduced three OS levels[12],
they are runtime, configuration, and profile.
On runtime level, Java ME uses a virtual machine known as Kilobyte
Virtual Machine (KVM), which executes precompiled byte code. This feature
enables Java to run built code on almost every system that compatible to
the libraries used for the build. The KVM is optimized for less memory
consumption than native code.
An example of configuration is the Connected Limited Device Configu-
ration (CLDC). It contains the KVM and several core device libraries. It
was designed for small, resource constrained devices with 160-512 Kbytes
Memory[12].
J2ME profiles have a small size so they fit in almost every compatible
current low-end phone. The Mobile Information Device Profile (MIDP) en-
ables sandbox security and it also introduces digital signatures and rights
categories.
J2ME applies security mechanisms to all of these levels. At runtime level
code is run in a“sandbox” environment and verification system checks ap-
plications and classes for failures. At configuration level, several approaches
were chosen. Depending on the profile, various limitations are given, signed
classes are introduced, or even the complete Java SE security package is

20
provided. At profile layer application signing is demanded, which means
that developers are assigned into categories, they are: manufacturer, opera-
tor, identified third party, and unidentified third party. Each domain allows
access to more or less critical API calls, where the calls are allowed, user
permitted, or denied. If a call is allowed, it can be used without restrictions,
whereas a user permitted call asks the user, whether he wants the specific ap-
plication to do a certain action or not. Unsigned application have restricted
capabilities and need a user permission for most calls, where it is possible
to deactivate the the permission request in the corresponding application
manager.

2.6.2 Intrusion Detection System

Several researchers addressed the problem of securing a mobile device where
several methods were suggested. One method could be the use of an in-
trusion detection system for smartphones. Samfat and Molva[13] presented
a distributed intrusion detection system for cellular networks that tries to
detect malicious behavior like masquerading or eavesdropping in mobile net-
works. They use two algorithms to monitor telephony activity and monitor
user roaming data in order to create user profiles and will be used as signa-
tures to detect abnormal behavior. This works with the features like calling
duration or cell site information.
In “Host-Based Intrusion Detection for Advanced Mobile Devices” by Mi-
ettinen et al.[14] They designed an intrusion detection framework, which com-
bines host-based and network-based intrusion detection. A host-based IDS
will monitor and collect data from mobile device which divided roughly into
three main classes: operating system events, measurements, and, application-
level events. A number of operating system events could be used to construct
models for intrusion detection. These include system calls, creation and ter-
mination of processes, file operations like open, close, read, and write, as
well as network operations like socket creation and deletion, or the sending
and receiving of data packets. By measurements, it means series of spe-
cific system performance indicators. Typical measurements could be CPU
activity, memory consumption, file I/O activity, and, network I/O activity.
Application-level events are high-level actions that are typically composed
of several elementary actions, which carry a specific meaning or purpose
as a whole. Examples of application-level events include, e.g., application
start/stop, user actions, location changes, and, communication events like
sending and receiving of messages, or, file downloads and uploads. So, if an
anomaly is detected on a mobile device, the device sends an intrusion alert
to a back-end server. This server is able to collect further information from

21
network-based sensors such as call records in order to create network related
intrusion alarms when it is necessary. They use a correlation engine which
is based at the server to correlate and filter the received alarms according
to correlation rules in its knowledge base. It then forwards the results to
a security monitoring GUI which will be analysed by security monitoring
administrators.
In Schmidt et al.[15], the authors demonstrate how to monitor a smart-
phone running Symbian OS in order to extract features that describe the
state of the device and can be used for anomaly detection. These features
are sent to a remote server, because running a complex IDS task on this kind
of mobile device still is not feasible, due to hardware limitations. They give
examples on how to compute some of the features and introduce the top ten
applications used by mobile phone users based on a study in 2005. The usage
of these applications is recorded and visualized and for a first comparison,
data results of the monitoring of a simple malware are given.
Nash et al.[16] introduce their first steps towards an intrusion detection
system against power-draining attack. Therefore they monitor the power
usage of processes and then identify potential battery-exhausting attacks.
Another battery-based IDS is presented by Jacoby et al.[17]. It measures
the devices power consumption, which is correlated with the application ac-
tivity on the device by running a rule-based host intrusion detection engine.
“SmartSiren” by Cheng et al.[18] had represented a technique of collecting
communication data and sending to a remote server in order to reduce the
processing load from resource-constrained smartphones. The data is analyzed
for anomalies and if found, the threatened devices are informed.
As an alternative to IDS, the suggestions by Hwang et al. could be used
to secure smartphones. In “Securing Embedded Devices”[19] they propose
the distinguishment of five layers on an embedded device, like a smartphone.
The design of security for embedded systems should differ from traditional
security design because these systems are resource-constrained in their ca-
pacities and easily accessible to adversaries at the physical layer. Therefore
embedded security cant be solved at a single security abstraction layer, but
rather is a system problem spanning multiple abstraction levels. These layers
are from top-down: protocol level, algorithm level, architecture level, micro
architecture level and circuit level.

2.6.3 Antivirus
There are many companies that provide antivirus software for smartphone
today. The major companies include:

22
 1. F-Secure

2. Symantec

3. Kaspersky

4. Trend Micro

2.6.4 Evaluation
Evaluation can be used to compare one technology against the other. We
will evaluate existing technology in order to identify the weak point of each
technique. Then, we will be able to determine the area that we need to
improve.
In “IDAMN: An Intrusion Detection Architecture” by Samfat et al. [13],
the authors monitor call activity and roaming data and use algorithms to
identify abnormal behavior. They use generated 300 intrusive session vectors
to test the system (one session representing one day of connection to the
network). They claimed that at least 80% of intrusive session was detected
with a false alarm rate varying from 2 to 5%. Also, much better performance
was obtained with the call vector analysis (6002000 vectors tested per user)
as the false alarm rates were under 2% with a minimum detection rate of
60%. In future work, they will try to develop speech and dialed number
verification algorithms to expand the detection.
Miettinen et al.[14] proposed an intrusion detection framework which
combined with 2 detection engines, IDS module at mobile device and network-
IDS at backend server. The IDS module can detect an attack by monitoring
system events, aggregates system measurements and collects application-level
events. The network-IDS engine evaluates the network-based monitoring
data against its intrusion detection models. The authors aimed to test how
accurate the detection results in future work.
In “Monitoring Smartphones For Anomaly Detection” by Schmidt et
al.[15], the authors have tested their detection model between variant feature
sets of the mobile device with different detection algorithm. The authors sug-
gested that reducing the amount of features from 70 to 14 would result in a
save of 80% in terms of disk space. Additionally, computation and commu-
nication costs are reduced significantly which has a positive impact on the
battery lifetime. By doing so, the system will lose only one percent in true
positive detection.

23
2.6.5 Summary
Operating System
There are two main approaches to security used by smartphone operating
systems. The first are access controls such as capabilities to limit the damage
that could be done by malware. The second are controls that prevent the
installation of arbitrary applications and only allowing trusted or verified
applications to be installed.
Both types of control are useful but are exploitable by attackers. For
example:

• An attacker may be able to trick an appstore into treating malware as

a “trusted” application. When installed it can exploit whatever per-
missions are associated with “trusted” applications on the smartphone.

• An attacker might plant a virus or a trojan on a user’s PC that car-

ries out a man-in-the-middle attack between the smartphone and the
appstore leading to installation of a trojan or virus as above.

• OS such as Symbian allows users to install any applications including

those from an untrusted third party. Users may install a trojan that
will exploit their use privileges.

• OSes such as the iphone prevent users from installing whatever appli-
cations they like. But for precisely this reason, users jailbreak their
phones to allow it to happen.

• Many drive-by-download exploits on the PC make use of vulnerabilities

in existing “trusted” software. As smartphone become more complex,
the likelihood of this happening increases.

Intrusion Detection Systems

Intrusion detection systems attempt to prevent or detect exploits such as
those identified above. Intrusion detection systems implemented so far only
capture a limited range of smartphone state such as battery usage or network
communication. A positive feature of smartphone IDSs is that they do allow
for limited local processing power by off loading some work to servers.
Miettinen et al.[14] do propose a framework that captures a much richer
set of state changes but it has not been implemented. In fact their proposed
system is similar to Capture-HPC in the range of state that it captures.

24
 A limitation of all the IDS schemes for smartphones reviewed so far is their
scalability. All require the user of physical smartphones. This introduces
limitations related to the cost of the smartphones and their limited power.

Antivirus
Antivirus software searches for infected files that match to virus signature on
the device. Antivirus software has limited detection ability against zero-day
attacks.

My research will address these issues. First, I intend to implement a

client honeypot framework combining features of Capture-HPC and [14] that
address the issue of capturing more state changes than existing IDS and
dealing with the limited processing power of smartphones.
Second, I intend to address the issue of scalability by allowing the use of
emulated smartphones in this framework rather than physical smartphones.
In addition, trojans were identified as a particular issue with relation to
bypassing operating system access controls. Therefore, a third issue I will
address is how to detect trojan software that may come from a variety of
sources including smart cards, web sites, application stores, etc.

2.7 Software Development for Smartphones

Developing, building, and testing smartphone software requires tools which
are often included in a SDK or integrated development environment (IDE).
These software packages will be briefly describe in this section.

2.7.1 IDE
An integrated development environment (IDE) combines most of the tools to
be able to write, compile, build and debug software. Todays IDEs integrate
all tools into one single tool that has Graphical User Interface (GUI) espe-
cially developed for certain platforms. Almost actions can be done through
the GUI, which often speeds up development. Examples for IDEs for mobile
devices are MS Visual Studio, Nokia Carbide, Eclipse, Apple’s Xcode.

2.7.2 SDK
A Software Developing Kit (SDK) is a collection of software that gives a
software developer the ability to create software for a certain platform, op-
erating system, or hardware. Most SDKs can be downloaded for free from

25
the internet. Current examples are the Symbian S60 3rd SDK, the Windows
Mobile SDK, Android SDK, iPhone SDK. Most SDKs are delivered with a
software emulator.

2.7.3 Emulator
A software emulator gives developers the ability to run and test software
developed for other systems, such as iPhone, on their computers. This can
reduce costs, as a software can already be programed and run without buying
a real device. On the other hand, the emulator often does not support
all functionalities of a real device. Unlike a simulator, which reproduces
programs behavior, an emulation attempts to reproduce the same states the
original devices would enter at several points.

26
Chapter 3

Proposed Solution

In this chapter, we present our proposed solution in more detail. Our solu-
tion is targeted at using client honeypot with mobile system to search out
for mobile malware and monitor the activities of the malware. Our mobile
honeypot will include the general requirements as shown in section 3.1. Mo-
bile honeypot is a system that composed with many components and each
component has its own task. We will describe the components of mobile
honeypot and their tasks in section 3.3.

3.1 General Requirements

The following are general requirements for a solution derived from analysis
in Chapter 2:

1. The system will be able to detect mobile malware for several types of
interfaces including 2G/2.5G/3G, Bluetooth, Wireless-LAN.

2. The system will be able to detect several types of attacks including,

drive-by-download, browser exploit, SMS/MMS attacks, Bluetooth at-
tacks.

3. The system will be able to interact with the web server and will accept
all download.

4. The system will have forensic capability.

5. The system will be able to analyze network traffic.

6. The system will be able to run automated tasks.

7. The system will be able to run on multiple platform.

27
 8. The system will be able to reset to its initial state.

3.2 Why can’t we use Capture-HPC?

There are several differences between mobile system environment and the
desktop system. First, the mobile client honeypot will be required to monitor
many activities that specific to smartphone. These activities include making
call, sending SMS or MMS, establish Bluetooth connection, etc. Second,
anomalous behaviors on PC are easier to detect since the normal behavior
of a web browser is more well-defined. But in smartphone environment,
the behavior of a compromised system may look similar to that of a non-
compromised system, for example in terms of the pattern of SMS messages.
Third, the existing Capture-HPC will only visits websites and waits for the
web servers to attack, but most of mobile malwares need user installation in
order to infect the mobile device. So, the mobile client-honeypot needs an
automated function that can interact (download/install) with the websites.

3.3 Mobile Client-Honeypot

The mobile honeypot will be based on Capture-HPC[20] developed by Chris-
tian Seifert et al. In our research, we will develop mobile client-honeypot for
2 types of system. They will share most components of the system as show in
the Figure 3.1. It has three major components. Workstation has the control
software. Control software manages the capture clients that may either be
emulated or physical “bare-metal” devices.
The tasks of honeypots will be including browsing through a list of URLs,
interact with the web sites to install and run code, accepting connection
through communication ports, and monitoring the activities of the system
for anomaly behavior. Since the honeypot is a dedicated system, malicious
activities such as non-user initiated call or trying to send SMS may represent
that the system is under attack.

3.3.1 Capture Server

Capture server is the main component in the honeypot system which will
control the clients, in this case, the emulators. We will insert a list of URLs to
capture server, it then send instruction commands to the client and instruct
the client to visit websites according to the list and interact with the web
servers.

28
 ="842.*+24.&<>").3,"&*

+',&-#.*
+',&-#.*+24.)&*
/.#0.#*

5:-2'&"#*
/.'#@?*A"#* /?'#.*%':.* 1)'23%4%*
:'2B'#.* @":,").)&* 5)64).*
7'&'8'%.*

+',&-#.*+24.)&*
9"66.#*

;'#.<:.&'2* !"#$%&'(")*

Figure 3.1: Mobile Client-Honeypot

29
 Mobile honeypot is highly scalable. More clients can be added to the
system through capture server. If more than one client is running, capture
server will divide the URL list to an appropriate amount to share between
each clients in order to improve the speed of the scan.

3.3.2 Analysis Engine

In this section, we will review the mechanisms to detect malware, such as
viruses, macro viruses, worms, and trojans. The Analysis Engine uses the
APIs from each smartphone OS to detect state changes to the system. Our
system will use technique such as API hooking mechanism[21], which will
provide more accurate results as well as more information about state changes
that have occurred than the existing client-honeypot. While malware consists
of mostly binary data, which differs significantly from the nature of web pages
that mostly consist of markup, we believe the success of detection algorithms
against malware warrants an evaluation for our purposes.
The pattern matching mechanism is used for the entire set of malware:
viruses, macro viruses, worms and trojans. It is an effective method to detect
malware based on a uniquely identifiable string. We believe this approach
will be beneficial for detecting malicious web pages as exploits are also likely
to contain a uniquely identifiable string. Heuristics, the second detection
algorithm, consists of checking malware or SPAM messages against a set of
characteristics that point to malicious content. We suspect that similar char-
acteristics, for example the use of script code, can be found in the context of
malicious web pages, allowing us to identify those pages. Further, static code
analysis is used to detect code security violations. As already mentioned, we
believe web pages can be checked with this technique as some web pages
embed script code.

3.3.3 Database
A database is used to store the detail information of the scan in order for us
to do further analysis. The information that we would like to keep including:

• The URL of the website.

• Corresponding IP address.
• Date and time of visiting.
• Malicious status.
• Malicious activities.

30
 • Component in effect.

• System log.

We can then generate a report with the information we have in our

database. The report will provide us with the information of type of mal-
ware, infection vector, infection payload, the website where the malware is
found.

3.3.4 Capture Client

There will be a capture client software which will be installed on emulator
and bare metal system. The client will receive the tasks from capture server
and will direct the emulator to do the tasks specified by capture server such
as browsing through website, accepting connections, etc. Capture client will
use the APIs in the emulator to monitor and record the activities of the
emulator.
The honeypot is a dedicated system and ready be compromised from the
attacks which it will accept all connections and willing to install the software
from third party regardless the software is valid or not. Therefore, if there
is an anomalous behavior, it means that the system is compromised. After a
certain time of malicious activity, the client will reset itself to original state
and will be ready to continue running scan.
The first client-honeypot will be running on the software emulator of the
major smartphones operating system (OS) as shown in Figure 3.2.
The second client-honeypot will be running on the real smartphones or
“Bare-Metal” as shown in Figure 3.3. This system will require:

• Client software installed on the phone.

• External control from a workstation.

System Trade Off
There will be both positive side and negative side of the system running on
emulator. These are some of the trade off of the system running on emulator:

1. The system is running on the emulator which reside in a workstation

computer, therefore we can keep the system running without having to
worry about the battery.

31
 Mobile Client-Honeypot Architecture (Emulator)

Request 2G/3G Emulators

Gateway Capture
Response
portal Server
Symbian
Control
Request Windows Mobile
Capture Client
Instructions
Response Wi-fi Gateway
iPhone
Internet Capture Client Analysis
State Engine
Request Android
Capture Client
Change
Response SMS Gateway
Store
Capture Client

Cellular Network
Request Bluetooth
Database
Response Gateway

Workstation
Bluetooth Device

Figure 3.2: Mobile Client-Honeypot Architecture on Emulator

Mobile Client-Honeypot Architecture (Bare Metal)

portal Symbian/
Capture Client
Control
Instructions
Capture
via USB Server

Internet Request
Windows Mobile/ Analysis
Response
Capture Client Engine
Log
Log Store
Logger

Cellular Network iPhone/

Capture Client
Database

Android/
Workstation
Bluetooth Device
Capture Client

Figure 3.3: Mobile Client-Honeypot Architecture on Bare Metal

32
 2. The system is cost effective. There is no need to purchase the actual
device in order to run the system and the system is very scalable.

3. The system is easy to setup and store the state of the emulator.

4. The system is easy to deploy. We can setup our system on a workstation

without having many phones lying around

5. The emulator is lack of some functions of the actual phone that might
have effect on the attack.

3.4 Evaluation
This section, we describe how we would evaluate our system. Since we will
be running our system in two different types, we are interested to compare
the result between the two systems. In additional, we would like to evaluate
our system against other technique such as antivirus solution. We expect to
have advantages over antivirus solution since IDS is not based on signature
matching, hence, the system will be able to detect zero-day attack.

3.4.1 Mobile Honeypot on Emulator

The client honeypot running on emulator is expected to run faster than
the one running on bare metal system due to the fact that the system uses
desktop cpu which have much more processing power than the smartphone
cpu. The down side of this approach is that smartphone emulator normally
lacks of some functions from the actual smartphone, for example, the ability
to receive SMS. I intend to address some differences by including gateways
for SMS, 2G/3G, Wi-fi, and Bluetooth in my architecture. As Bluetooth is
very range dependent, I would expect to distribute Bluetooth sensors over a
wide area. Although this helps there will still be differences that attackers
may detect and modify their behaviors.

3.4.2 Mobile Honeypot on Actual Smartphone

Our next evaluation is to install client-honeypot on the actual smartphone to
compare the result and accuracy with the system running on emulator. As we
mention earlier in section 2.7, the emulator can reproduce the same state of
the device but the lack of some functionalities of the actual smartphone might
create the different in the result. By comparing the two systems (emulator
& actual phone), we can determine the trade off of our solution.

33
3.4.3 Antivirus
Another possible solution to evaluate our system is to run the mobile mal-
ware through antivirus software. Since the antivirus will not search for the
malware out of the device, we need a collection of malware to feed onto the
device. Antivirus used signature-based detection to search for known mali-
cious patterns in executable code. However, it is possible for a user to be
infected with new malware in which no signature exists yet.
We also would like to evaluate our system against zero-day attack, we will
run the same set of malware through our system. If our system can detect
a malware that antivirus cannot, it’s indicated that our system can detect a
zero-day attack

34
Chapter 4

Conclusion

This chapter defines the work plan, specifies work done to date and outlines
expected contributions.

4.1 Work Plan

Table 4.1 shows the work plan for the completion of our research.

4.2 Expected Contributions

• Design of a mobile honeypot framework that addresses the need for
modeling user interaction with the honeypot

• Implementation of a mobile honeypot in a two representative mobile

phone operating systems.

• Development of an evaluation framework for mobile honeypots.

• Application of the evaluation framework to evaluate the mobile honey-

pot implementations.

4.3 Progress To Date

The following progresses have been completed to date:

• Downloaded and run smartphone emulator of popular platforms.

• Downloaded and installed SDK to create developing environment for

smartphone.

35
• Worked on creation of smartphone software to drive browser to visit
website.

• Finished taking supplement courses including WRIT101 and COMP307.

36
 Table 4.1: Time line of future research

Completion Date Description

Dec 2009 - Feb 2010 PhD suspend period

• Working on Summer Research Project

Feb 2010 Develop Mobile Client-Honeypot

• Develop capture-server

• Develop capture-client

• Integrate capture-client with emulator

Jun 2010 Gather malware information

• Create URL list

• Gather mobile malware

Aug 2010 First evaluation

• Run mobile honeypot within controlled

environment

Oct 2010 Second evaluation

• Run mobile honeypot in public

• Need human ethics approval

Feb 2011 Third evaluation

• Run mobile honeypot on actual phone

• Evaluate false positive & false negative

• Compare between two model

Apr 2011 Writing thesis

Oct 2011 Expect completion of PhD

37
Bibliography

[1] S. A. Aubrey-Derrick Schmidt, “Malicious software for smartphones,”

Technische Universität Berlin, Berlin, Tech. Rep., 2008, last
accessed in December 2009. [Online]. Available: http://www.dai-
labor.de/fileadmin/files/publications/smartphone malware.pdf
[2] M. Hypponen, “Malware goes mobile,” SCIENTIFIC
AMERICAN, no. November 2006, November 2006,
last accessed in December 2009. [Online]. Avail-
able: http://www.scientificamerican.com/article.cfm?id=malware-goes-
mobile
[3] R. Moir, Defining Malware: FAQ, October 2003, last accessed in
December 2009. [Online]. Available: http://technet.microsoft.com/en-
us/library/dd632948.aspx
[4] N. Provos, “Honeyd: A virtual honeypot daemon,” Center for
Information Technology Integration, University of Michigan, Tech. Rep.,
February 2003, last accessed in December 2009. [Online]. Available:
http://www.citi.umich.edu/u/provos/papers/honeyd-eabstract.pdf
[5] C. Seifert, I. Welch, and P. Komisarczuk, “Application of divide-
and-conquer algorithm paradigm to improve the detection speed of
high interaction client honeypots,” in SAC ’08: Proceedings of the
2008 ACM symposium on Applied computing. New York, NY, USA:
ACM, 2008, pp. 1426–1432, last accessed in December 2009. [Online].
Available: http://dx.doi.org/10.1145/1363686.1364018
[6] Y.-M. Wang, D. Beck, X. Jiang, and R. Roussev, “Automated web pa-
trol with strider honeymonkeys: Finding web sites that exploit browser
vulnerabilities,” in IN NDSS, 2006, last accessed in December 2009.
[7] N. Leavitt, “Mobile phones: the next frontier for hackers?” Computer,
vol. 38, no. 4, pp. 20–23, May 2005, last accessed in December 2009.
[Online]. Available: http://dx.doi.org/10.1109/MC.2005.134

38
 [8] A. Gostev and D. Maslennikov, “Mobile malware evo-
lution: An overview, part 3,” September 2009,
last accessed in December 2009. [Online]. Available:
http://www.viruslist.com/en/analysis?pubid=204792080

[9] M. Daniel, J. Honoroff, and C. Miller, “Engineering heap overflow ex-

ploits with javascript,” in WOOT’08: Proceedings of the 2nd conference
on USENIX Workshop on offensive technologies. Berkeley, CA, USA:
USENIX Association, 2008, pp. 1–6, last accessed in December 2009.
[Online]. Available: http://portal.acm.org/citation.cfm?id=1496703

[10] C. Miller, J. Honoroff, and J. Mason, “Security evaluation of apple’s

iphone,” July 2007, last accessed in December 2009. [Online]. Available:
http://securityevaluators.com/files/papers/exploitingiphone.pdf

[11] “Basics,” last accessed in December 2009. [Online]. Available:

http://www.bluetooth.com/Bluetooth/Technology/Basics.htm

[12] “Java me at a glance,” 2009, last accessed in December 2009. [Online].

Available: http://java.sun.com/javame/index.jsp

[13] D. Samfat and R. Molva, “Idamn: an intrusion detection architecture for

mobile networks,” Selected Areas in Communications, IEEE Journal on,
vol. 15, no. 7, pp. 1373–1380, August 2002, last accessed in December
2009. [Online]. Available: http://dx.doi.org/10.1109/49.622919

[14] M. Miettinen and P. Halonen, “Host-based intrusion detection for

advanced mobile devices,” in AINA ’06: Proceedings of the 20th
International Conference on Advanced Information Networking and
Applications, vol. 2. Washington, DC, USA: IEEE Computer Society,
2006, pp. 72–76, last accessed in December 2009. [Online]. Available:
http://dx.doi.org/10.1109/AINA.2006.192

[15] A. D. Schmidt, F. Peters, F. Lamour, and S. Albayrak, “Moni-

toring smartphones for anomaly detection,” in MOBILWARE ’08:
Proceedings of the 1st international conference on MOBILe Wire-
less MiddleWARE, Operating Systems, and Applications. ICST,
Brussels, Belgium, Belgium: ICST (Institute for Computer Sci-
ences, Social-Informatics and Telecommunications Engineering), 2007,
pp. 1–6, last accessed in December 2009. [Online]. Available:
http://portal.acm.org/citation.cfm?id=1361542

39
[16] D. C. Nash, T. L. Martin, D. S. Ha, and M. S. Hsiao, “Towards an intru-
sion detection system for battery exhaustion attacks on mobile comput-
ing devices,” in Pervasive Computing and Communications Workshops,
2005. PerCom 2005 Workshops. Third IEEE International Conference
on, March 2005, pp. 141–145, last accessed in December 2009. [Online].
Available: http://dx.doi.org/10.1109/PERCOMW.2005.86

[17] G. A. Jacoby, R. Marchany, and N. Davis, “Using battery constraints

within mobile hosts to improve network security,” Security & Privacy,
IEEE, vol. 4, no. 5, pp. 40–49, September 2006, last accessed in Decem-
ber 2009. [Online]. Available: http://dx.doi.org/10.1109/MSP.2006.139

[18] J. Cheng, S. H. Y. Wong, H. Yang, and S. Lu, “Smartsiren:

virus detection and alert for smartphones,” in MobiSys ’07:
Proceedings of the 5th international conference on Mobile systems,
applications and services. New York, NY, USA: ACM, 2007,
pp. 258–271, last accessed in December 2009. [Online]. Available:
http://dx.doi.org/10.1145/1247660.1247690

[19] D. D. Hwang, P. Schaumont, K. Tiri, and I. Verbauwhede, “Securing

embedded systems,” Security & Privacy, IEEE, vol. 4, no. 2, pp.
40–49, April 2006, last accessed in December 2009. [Online]. Available:
http://dx.doi.org/10.1109/MSP.2006.51

[20] C. Seifert and R. Steenson, Capture-HPC Client Honeypot /

Honeyclient, last accessed in December 2009. [Online]. Available:
http://projects.honeynet.org/capture-hpc/

[21] D. Leman, “Spy: A windows ce api interceptor,” October 2003, last

accessed in December 2009. [Online]. Available: http://www.ddj.com/

40
Mobile Malware List from June 2004 - August 2009
Number of
Name Date OS Functionality
variants
Worm.SymbOS.Cabir Jun-04 Symbian Spreads via Bluetooth 15
Virus.WinCE.Duts Jul-04 Windows CE Infects files 1
Backdoor.WinCE.Brador Aug-04 Windows CE Provides remote network access 2
Trojan.SymbOS.Mosquit Aug-04 Symbian Sends SMS messages 1
Replaces files, icons, system
Trojan.SymbOS.Skuller Nov-04 Symbian 31
applications
Worm.SymbOS.Lasco Jan-05 Symbian Spreads via Bluetooth, infects files 1
Trojan.SymbOS.Locknut Feb-05 Symbian Installs corrupted applications 2
Trojan.SymbOS.Dampig Mar-05 Symbian Replaces system applications 1
Spreads via Bluetooth and MMS,
Worm.SymbOS.ComWar Mar-05 Symbian 7
infects files
Replaces antivirus application
Trojan.SymbOS.Drever Mar-05 Symbian 4
loaders
Trojan.SymbOS.Fontal Apr-05 Symbian Replaces font files 8
Trojan.SymbOS.Hobble Apr-05 Symbian Replaces system applications 1
Trojan.SymbOS.Appdisabler May-05 Symbian Replaces system applications 6
Replaces system applications,
Trojan.SymbOS.Doombot May-05 Symbian 17
Comwar
Trojan.SymbOS.Blankfont Jul-05 Symbian Replaces font files 1
Installs damaged applications,
Trojan.SymbOS.Skudoo Aug-05 Symbian 3
installs Cabir, Skuller, Doombor
Disables system functions,
Trojan.SymbOS.Singlejump Aug-05 Symbian 5
replaces icons
Installs damaged applications,
Trojan.SymbOS.Bootton Aug-05 Symbian 2
installs Cabir
Deletes antivirus files, replaces
Trojan.SymbOS.Cardtrap Sep-05 Symbian system applications, installs Win32 26
malware on memory cards
Blocks memory cards, deletes
Trojan.SymbOS.Cardblock Oct-05 Symbian 1
folders
Trojan.SymbOS.Pbstealer Nov-05 Symbian Steals data 5
Trojan-Dropper.SymbOS.Agent Dec-05 Symbian Installs other malicious programs 3
Trojan-SMS.J2ME.RedBrowser Feb-06 J2ME Sends SMS 2
Windows Deletes files, copies its body to
Worm.MSIL.Cxover Mar-06 1
Mobile/ .NET other devices
Steals data, spreads via Bluetooth
Worm.SymbOS.StealWar Mar-06 Symbian 5
and MMS
Windows
Email-Worm.MSIL.Letum Mar-06 Spreads via email 3
Mobile/ .NET
Trojan-Spy.SymbOS.Flexispy Apr-06 Symbian Steals data 2
Trojan.SymbOS.Rommwar Apr-06 Symbian Replaces system applications 4
Trojan.SymbOS.Arifat Apr-06 Symbian — 1
Trojan.SymbOS.Romride Jun-06 Symbian Replaces system applications 8
Deletes antivirus files, replaces
Worm.SymbOS.Mobler.a Aug-06 Symbian system applications, spreads via 1
memory card
Wesber Sep 06 J2ME Sends SMS messages 1
Acallno Sep 06 Symbian Steals data 2
Flerprox Oct 06 Symbian Replaces system boot loaders 2
Hidmenu Oct 06 Symbian Hides the menu 1
Unlock.a Oct 06 Symbian Unlocks the phone 1
Smarm Jan 07 J2ME Sends SMS messages 10
Mead Feb 07 Sgold Infects files 2
Mrex Mar 07 Symbian Changes color schemes 1
Viver May 07 Symbian Sends SMS messages 2
Sends SMS messages containing a
Feak May 07 Symbian 1
link to itself in a zip-archive
SHT Aug 07 Symbian Hacker utility 1
Disrupts settings, changes themes
Konopla Aug 07 Sgold 1
and pictures
Reboot Aug 07 Symbian Restarts the device 2
Delcon Aug 07 Symbian Deletes contacts 1
SMSFree Oct 07 J2ME Sends SMS messages 10
Flocker Oct 07 Python Sends SMS messages 44
Deletes files from the phone
Deladdr Nov 07 Sgold (address book, applications, SMSs, 1
wap profiles)
Spreads via MMC memory cards,
HatiHati Dec 07 Symbian 1
sends SMS messages
Fonzi Jan 08 Symbian Deletes files 1
Killav Jan 08 Symbian Deletes antivirus solutions 3
Beselo Jan 08 Symbian Spreads via Bluetooth and MMS 2
Swapi Feb 08 J2ME Sends SMS messages 44
Answers all incoming SMSs and
SrvSender Mar 08 Symbian calls with a random SMS. Deletes 1
messages
Demands money, deletes all
Kiazh Mar 08 Symbian incoming and outgoing SMS 1
messages
Copies itself to removable disks,
steals data, loads software without
InfoJack Mar 08 WinCE 3
the user’s consent, disables
protection
Gpiares Apr 08 Symbian Sends SMS messages 2
Kuku May 08 Symbian Sends SMS messages 1
Sends the user’s messages to a
SmsSpy May 08 Symbian 1
number specified in a sfg-file
Displays fake messages about
Forvir May 08 Symbian system errors and reports a virus 1
has been installed on the phone
Hoaxer May 08 J2ME Sends SMS messages 6
Phone cannot be started after
KillPhone May 08 Symbian 3
reboot
Xanel May 08 J2ME Sends SMS messages 4
SMSi May 08 J2ME Sends SMS messages 15
Konov May 08 J2ME Sends SMS messages 14
Kros Jun 08 Symbian Replaces executable files 1
Blocks some operating system
Blocker Jun 08 Symbian 1
functions
Boxer Sep 08 J2ME Sends SMS messages 15
Redoc Sep 08 WinCE Sends SMS messages 19
Espaw Sep 08 J2ME Sends SMS messages 7
KaspAV Aug 08 J2ME Fake antivirus 3
Polymorphic companion virus,
PMCryptic Oct 08 WinCE 1
worm (memory card)
 MultiNum Oct 08 Symbian Sends SMS messages 1
Displays fake message saying
Razan Oct 08 J2ME 1
phone has been infected
Onro Oct 08 J2ME Sends SMS messages 3
DoctorW Nov 08 J2ME Fake antivirus 1
SMSSender Nov 08 J2ME Sends SMS messages 1
Sspy Dec 08 Python Spyware 1
Tagsa Dec 08 Symbian Sends SMS messages 1
Small Dec 08 J2ME Sends SMS messages 7
Noti Jan 09 J2ME Mobile content for SMSs 1
Okpon Jan 09 J2ME Sends SMS messages 1
Yxe Jan 09 Symbian Spreads via SMSs, collects data 4
Hacker utility to send specially
CoS Jan 09 Symbian 2
crafted SMSs
Kinap Jan 09 Symbian Changes fonts, icons, logos 7
Vers !"#.09 Symbian Sends SMS messages 1
Yakki Feb 09 Symbian Deletes fonts 1
Disabler Feb 09 Symbian Blocks SMSs, MMSs, calls 1
Getas Feb 09 J2ME Imitates a virus 1
Xef Feb 09 J2ME Sends SMS messages 2
GameSat Feb 09 J2ME Sends SMS messages 1
Rebrew Feb 09 J2ME SMS-Flooder 1
Mexasa Mar 09 J2ME Sends SMS messages 4
Xavava Mar 09 J2ME Sends SMS messages 3
Kblock Mar 09 Symbian Locks phone 1
Garlag Mar 09 J2ME Sends SMS messages 2
Redrob Mar 09 J2ME Sends SMS messages 4
Fnusob Mar 09 J2ME Sends SMS messages 1
Pornidal Apr 09 Symbian Makes calls to paid services 2
SMSRtap Apr 09 Symbian Monitors SMSs, calls etc. 3
Trojan-SMS.Agent May 09 J2ME Sends SMS messages 4
Caneo Jun 09 Symbian Monitors SMSs, calls etc. 2
Crymss Jun 09 J2ME Sends SMS messages 1
Smypa Jun 09 Python SMS-Flooder 1
Enoriv Jul 09 Symbian Sends SMS messages 1
Smofree Aug 09 J2ME Makes calls to paid services 1