DAIDS: An Architecture for Modular Mobile IDS

Abstract

The popularity of mobile devices and the enormous number of third party mobile applications in the market have naturally lead to several vulnerabilities being identified and abused. This is coupled with the immaturity of intrusion detection system (IDS) technology targeting mobile devices. In this paper we propose a modular host-based IDS framework for mobile devices that uses behavior analysis to profile applications on the Android platform. Anomaly detection can then be used to categorize malicious behavior and alert users. The proposed system accommodates different detection algorithms, and is being tested at a major telecom operator in North America. This paper highlights the architecture, findings, and lessons learned.

Full text

DAIDS: An Architecture for Modular Mobile IDS
Alaa Salman Imad H. Elhajj Ali Chehab Ayman Kayssi
Electrical and Computer Engineering
American University of Beirut
Beirut, Lebanon
alaa@codedemigod.com, {ie05, chehab, ayman}@aub.edu.lb
Abstract— The popularity of mobile devices and the
enormous number of third party mobile applications in the
market have naturally lead to several vulnerabilities being
identified and abused. This is coupled with the immaturity of
intrusion detection system (IDS) technology targeting mobile
devices. In this paper we propose a modular host-based IDS
framework for mobile devices that uses behavior analysis to
profile applications on the Android platform. Anomaly detection
can then be used to categorize malicious behavior and alert users.
The proposed system accommodates different detection
algorithms, and is being tested at a major telecom operator in
North America. This paper highlights the architecture, findings,
and lessons learned.
Keywords—intrusion detection; dynamic analysis; behavior
profiling
I. INTRODUCTION
Android's popularity as a mobile operating system has
increased in recent years to occupy the number one spot in
terms of worldwide market share [1]. This increase in
popularity, along with the open nature of the official Google
Play store and the existence of third-party marketplaces has
made Android an attractive target for malware writers [2].
According to Halilovic et. al [3], malware on Android can
be categorized into three different groups: 1) malicious
applications that cause a threat to user experience, 2)
applications that generate extra costs, 3) applications that steal
private information. Some applications in these categories have
used kernel exploits to gain elevated privileges on the device
and in turn use these privileges to overcome the system’s
sandboxing and other security mechanisms. As devices get
more powerful, botnets targeting these platforms have also
started showing up [4].
Current approaches for detecting malware include static
analysis, dynamic analysis, or a mix of both with no clear
winner emerging as the ultimate detection method. Static
analysis mainly uses signature databases or pattern matching of
decompiled sources or disassembled byte code to match
against known malicious patterns. This type of analysis is very
similar to the analysis done by traditional anti-virus software
used on personal computers, and hence shares its weaknesses.
Namely, the databases of signatures and patterns need to be
constantly updated and the increase of sophistication of
malware, such as polymorphic payloads [5], is helping in
circumventing this approach. The byte code or decompiled
source code can hide malicious activities through slight
modification of the malicious code. Anti-virus scanners are
getting smarter, mostly through the addition of heuristic pattern
matching, but the race continues between anti-virus vendors
and malware writers.
Dynamic analysis is mostly based on application behavior.
The approaches use either heuristics or profiling data to
classify irregular or malicious behavior. This type of analysis is
inaccurate by nature and heavily depends on the classification
algorithms used. Weaknesses in the design of earlier versions
of the framework and the lack of automation tools often add to
this inaccuracy.
Thus far, neither approach is sufficient to stop malicious
applications which seem to be getting more sophisticated. The
current approach used by Google for its Play store is a mix of
both static analysis of the byte code and dynamic analysis of
the behavior of each submitted application [6]. However, even
the official Google-curated market place cannot escape
sophisticated malware [7]. The existence of centralized
marketplaces have contributed to the popularity of Android and
helped to streamline the installation and update of applications.
But it also provided malware writers with the same advantages.
Finding better approaches to detect and prevent malware on
Android mobile devices is currently a popular research topic.
In this paper, we propose an architecture for a modular host-
based intrusion detection system (IDS). The system monitors in
real-time the behavior of applications on the device and allows
for the use of dynamic analysis to detect bad or malicious
behavior.
This paper is organized as follows. Section II explores
related work in the field of host-based intrusion detection
systems with a focus on the ones targeting mobile devices.
Section III describes the current architecture of the proposed
system. Section IV presents the testing setup and results.
Section V describes the lessons learned, and Section VI
concludes with highlights for future work.
II. RELATED WORK
The use of host-based intrusion detection techniques has
been attempted by many researchers to detect and prevent
malware on Android devices.
2014 28th International Conference on Advanced Information Networking and Applications Workshops
978-1-4799-2652-7/14 $31.00 © 2014 IEEE
DOI 10.1109/WAINA.2014.54
328
2014 28th International Conference on Advanced Information Networking and Applications Workshops
978-1-4799-2652-7/14 $31.00 © 2014 IEEE
DOI 10.1109/WAINA.2014.54
328

Berthomé et al. [8] proposed the static injection of bytecode
into applications to monitor private data access and SMS
sending functionality. The monitoring aspect was used in the
development of an IDS/IPS called AndroSpywareMonitor
which attempts to report or block these activities.
Alazab et al. [9] used DroidBox, the Android application
sandbox, to generate behavioral graphs to help analyze run-
time activities and establish functional patterns. The patterns
were then used in cross-examining naming classification of
malware families by known antivirus vendors.
Halilovic et al. [3] suggested the design of a host-based IDS
that uses a support vector machine with features such as
number of calls to people in or out of a contact list in order to
classify malicious applications.
A. Shabtai et al. [10] described a framework, dubbed
KBTA for knowledge-based temporal abstraction, for
continuously monitoring a device to identify malicious
behavior. The framework relies on a lightweight agent that
continuously samples various features on the device such as
CPU, memory, and battery consumption, and analyzes the
collected data. The device state is inferred based on behavioral
temporal patterns and context-sensitive interpretation of
accumulated data.
Our work is most inspired by the KBTA approach and uses
similar continuous monitoring of time stamped data and uses
triggers that affect the context-sensitive interpretation of it.
However, our work is more general and differs in our focus to
offer a pluggable modular platform that can use different
algorithms for the interpretation of the data.
III. DESIGN OF IDS ARCHITECTURE
This section describes the architecture of our proposed
intrusion detection system. Subsection A describes the overall
architecture of the IDS while subsection B describes the
collected data. Subsection C describes how the data is analyzed
and profiled. Subsection D describes one sample algorithm for
detecting anomalies in application behavior. Finally,
subsection E concludes with some implementation notes.
A. IDS Architecture
The Dynamic Android Intrusion Detection System
(DAIDS) is a modular host-based intrusion detection system
that tries to identify malicious or misbehaving applications by
profiling their behavior. It is composed of several semi-
independent components and it uses most traditional host-
based intrusion detection methods but combines those with
mobile-specific attributes for increased accuracy and
efficiency.
The intrusion detection system consists of data collectors,
profilers, and threat detectors. As a user-facing application, it
also includes an alert manager and associated user interface
components. Out-of-the-box, the system monitors and logs
resource usage of applications and it has built-in profilers and
detectors that make use of the collected data. This will be
detailed in its own section.
Since energy consumption is a major factor to account for
while designing any host-based system running on a
smartphone, several optimizations had to be developed to
ensure the efficiency of the whole system. Figure 1 shows an
overview of the architecture while details are described in their
respective sections.
Fig. 1. Diagram showing the IDS architecture
B. Data Collected
Data collectors acquire and store information such as timed
snapshots of application resources and system events. The
collectors use different timers depending on the variability of
the collected resource. Special care was taken to write
optimized code to minimize the amount of processing and
memory use in these frequently-run tasks. An example of this
was aiming to use efficient memory structures and performing
the database inserts in bulk and within a single transaction
whenever possible.
The types of data that are collected include:
• Installed packages on the device along with their
metadata that includes time of installation, time of
update, requested permissions, requested features, and
the first time the application was launched.
• Timed snapshots for running processes.
• CPU consumption per process in snapshot.
• Memory levels per process in snapshot.
• Bandwidth consumption per package. It collects bytes
sent and received as well as number of packets sent and
received.
• Currently open connections per package. It collects IP
addresses and TCP ports that are open.
329329

• System events as indicators for sc
r
package installation.
• Content events as indicators for SMS s
e
• File system events to indicate access t
o
media folder.
• Network activity events indicating net
w
• Optional logging of network packets i
and data.
The IDS uses the PackageManager class t
o
installed applications on the device. For ea
c
also records metadata for its correspondi
n
metadata collected are time of installation,
l
requested permissions and features. The met
a
to date when the application is updated.
Using the ActivityManager class, a
applications is periodically collected. Then,
application, different collectors are responsi
b
resource-usage such as CPU consumption b
y
[11] utility and memory usage using the
M
The process ID and user ID are used to pa
i
their corresponding application.
Two network-related components colle
c
consumption and open connections for run
n
The bandwidth consumed is collected usin
g
class and retrieves the amount of bytes se
n
with number of packets, while the open conn
e
for local and remote IP address/port combin
a
/proc/net/tcp.
The event collector implements a Broa
listen to screen on/off intents and package i
n
The package installation intent triggers the I
D
the new package to our monitored packages
l
updated metadata for an existing application.
The SMS sent/received event is gener
a
ContentObserver on the SMS data store. It
w
store for any activity and then issues an S
M
when noticed. Even though this is not an o
ff
monitoring SMS activity, we found that it w
o
to include in our system.
The IDS also includes utilities that requir
to function. Two such utilities are the file s
y
the network packet inspection utility. Both
Android NDK platform [12] to facilitate devel
The file system access utility uses
t
functionality in the Linux kernel to listen t
o
monitored files or directories. The utility mo
n
and media database for read events and report
s
b
y issuing a READ_CONTACTS and R
E
event. A NETWORK_ACCESS event is simil
a utility that uses libpcap [14] for deep p
a
These utilities function at a lower level than
t
API and so cannot specify which application
i
the events.
r
een on/off and
e
nt/received.
o
the contacts and
w
ork access.
i
ncluding headers
o
retrieve a list of
c
h application, it
n
g package. The
l
ast update time,
a
data are kept up
list of running
for each running
b
le for recording
y
parsing the top
M
emoryInfo class.
i
r resources with
c
t the bandwidth
n
ing applications.
g
the TrafficStats
n
t/received along
e
ctions are parsed
a
tions by reading
dcastReciever to
n
stallation intents.
D
S to either add
l
ist or to look for
a
ted by using a
w
atches the data
M
S-related event
ff
icial method for
o
rks well enough
r
e a rooted phone
y
stem access and
utilities use the
l
opment.
t
he inotify [13]
o
read events on
n
itors the contacts
s
them to the IDS
E
AD_GALLERY
arly generated by
a
cket inspection.
t
he Android Java
i
s responsible for
All this collected data is stored
i
depicted by Figure 2.
Fig. 2. Database schema used to store colle
c
C. Profilers and Detectors
A different set of workers, call
e
for using the collected data and
e
p
rofiles that will be used for a
n
involves intensive
p
rocessing but
i
frequently than collectors. A profil
e
characterizes normal system behavi
o
data mentioned earlier, one possibl
e
of IP addresses/ports opened duri
n
Another example could be the amo
u
specific application during a speci
f
can be any combination of parame
t
normal behavior of the monitored t
a
The last set of components, ca
l
use of the profile to detect an ano
m
used by multiple threat detectors
event that each detector is monito
r
threat detector can make use of
dependent on the profile model u
s
that combines a list of IP addresse
s
can be used by two threat detectors
.
bandwidth per IP address and the
listed IP addresses. Necessarily, t
h
have a different periodicity since
detector needs to monitor every ou
t
bandwidth abuse detector only need
i
n a database with a schema
c
ted data.
e
d profilers, are responsible
e
vents to build and update
n
omaly detection. This set
t usually needs to run less
e
is a list of parameters that
o
r [15]. Using the collected
e
profile could be the range
n
g a specified time period.
u
nt of bandwidth used by a
f
ied time period. A profile
t
ers collected to signify the
a
rget.
l
led threat detectors, makes
m
aly. A single profile can be
depending on the security
r
ing. But each profiler and
a different timer that is
s
ed. For example, a profile
s
with consumed bandwidth
.
One monitors for abuse of
other monitors for blac
k
-
h
e two threat detectors will
the IP address black-list
t
going connection while the
s to collect aggregates.
330330

The modular approach in the design of th
e
to implement multiple algorithms to detect m
a
These algorithms can collaborate or work
i
generate alerts. One such example algorithm i
s
testing section.
The resource-usage profiles and threat
d
schema depicted in Figure 3.
Fig. 3. Database schema used to store resource-usage pr
D. Implementation Notes
DAIDS stores all the generated data in
S
the default storage mechanism in Android. O
store the data generated by the collectors, pr
o
detectors. The second file is used for event
Java-
b
ased application and the rest of the data
b
the native utilities. A separate file is use
d
configuration data. The data was split into
d
files after experimentation showed increasin
g
caused by a high number of collectors which
to function at a high frequency and to gen
e
smartphone undergoing regular use.
Additional features were added in order
t
collection process easier:
• Application starts collecting data at de
v
• Ability to reset the collected data to
s
from getting too large.
• A
b
ility to stop scanning and reset
t
locked to avoid user error.
• Ability to export the collected data to
a device-specific UUID.
• Integration with the crash notification
s
[17].
• Timer periodicity for each componen
t
via an accessible database.
e
IDS can be used
a
licious behavior.
independently to
s
described in the
d
etectors use the
ofiles
S
QLite databases,
ne file is used to
o
filers, and threat
storage from the
b
ases a
r
e used by
d
for storage of
d
ifferent database
g
lock contention
necessarily need
e
rate events on a
t
o make the data
v
ice boo
t
-up.
s
top the database
t
he data is PIN-
SD storage using
s
ervice BugSense
t
can be tweaked
The application needs the
f
function:
• ACCESS_NETWORK_ST
A
existence of network co
m
collection.
• WRITE_EXTERNAL_STO
R
exported data to SD storage.
• INTERNET: Used to send
c
crash notification service.
• RECEIVE_BOOT_COMPL
E
application to start data coll
e
• READ_SMS: Needed to
activity.
IV. TES
T
Testing of the platform was
Galaxy S II and S III phones runn
i
later on stock Samsung ROM imag
e
to run on any Android platform ha
v
showed excellent performance and
r
phone models.
The crash notification service
r
crashes that were mostly the result
due to ungraceful native process sh
crashes were out of memory erro
r
from on excessively busy devices.
were transient in nature and mostly
when the phone is rebooting, so t
h
collection process.
One problem that did affect the
due to instability while exporting t
h
The export function copies the d
a
storage and empties the origin
a
operations resulted in corrupt datab
a
back to a problem in the size o
f
believe that these issues stem fro
m
badly with larger files and the An
d
the process mid-copy. An auto
m
implemented as a workaround for t
h
Resource usage of the IDS was
so as not to interfere with the reg
u
Figures 4 and 5 show CPU and m
one hour of operation.
f
ollowing permissions to
A
TE: Needed to check for
m
munication to optimize
R
AGE: Needed for writing
c
rash reports to third-party
E
TED: Needed to allow the
e
ction at device boot-up.
monitor SMS store for
T
ING
m
ostly done on Samsung
i
ng Android version 4.0 or
e
s. The platform is designed
v
ing the minimum specs but
r
eliability on the above two
r
eported a small number of
of database locking issues
u
tdown. The other types of
r
s that are hard to recover
However, these problems
due to edge cases; such as
h
ey did not affect the data
data collection process was
h
e databases to SD storage.
a
tabases to the internal SD
a
l database. Some copy
a
ses but could not be traced
f
the source database. We
m
the file system behaving
d
roid system or user killing
m
ated timed backup was
h
is issue.
designed to be ligh
t
weight
u
lar function of the device.
e
mory consumption during
331331

Fig. 4. CPU consumption during one hour of operation
The CPU consumption heavily depends
o
of the timers set and device activity at time
maintains an overall low average of usa
g
defaults of 5 seconds for each collector. For t
h
in Figure 4, the average CPU usage was 9.9%.
Fig. 5. Memory usage during one hour of operation
The memory usage depends on the impl
e
different running components. To conserv
e
testing showed that it is preferable to re-use
m
components to avoid invoking the garbage col
l
The power consumed by the default s
e
average of 163 mW according to PowerT
u
testing device.
To test the capabilities of the system, an e
x
that monitors resource usage was implement
e
assigns installed packages an initial threat v
a
p
ermissions that are requested. Most applicati
p
ermissions than they need [16]. While the n
u
p
ermissions provides an indication of the cap
of the behavior of the application, there is a l
i
p
ermissions and features that should be give
n
in the Android security system. In differe
n
these permissions and features provide
a
o
n the periodicity
of sampling but
g
e using the set
h
e test run shown
e
mentation of the
e
battery power,
m
emory within the
l
ector.
e
t timers had an
u
tor [18] on one
x
ample algorith
m
e
d. The algorithm
a
lue based on the
ons request more
u
mber and type of
abilities and thus
i
mited number of
n
greater attention
n
t combinations,
a
pplications with
dangerous capabilities such as acce
s
to use services that cost money.
The threat level changes dyna
m
b
ehavior and resource usage but it i
s
level assigned to it at installation-ti
m
it. So primarily, the threat level has
application’s requested permissions
Two resource-usage profiles ar
e
anomalies. The first one measures
week of activity per application
resource usage for the lifetime of
p
rofiles are then used by their corre
s
report misbehaving applications
resource-usage to profiled ones.
Similar to the KBTA method
algorithm uses the captured syst
e
b
eing turned off, to modify the cal
c
the resultant threat level. Using th
e
Halilovic et al [3], this resource u
s
useful in detecting misbehaving
a
threat to the overall user experie
n
implementing a sample malicious
CPU cycles after the screen turns
o
consumption from the user.
Figure 6 shows a screenshot of
showcasing the platform’s functio
n
one of the PIN-locked actions.
Fig. 6. Screenshot showing the main menu
Fig. 7. Screenshot showing one of the pin-l
o
s
s to personal da
t
a or ability
m
ically based on application
s
seeded by the initial threat
m
e and it does not go below
a tight correlation with the
and features.
e
built and used in detecting
resource usage for the first
and the second measures
the application. These two
s
ponding threat detectors to
by comparing current
[10], the threat detection
e
m events, such as screen
c
ulation of usage trends and
e
classification proposed by
s
age algorithm was mostly
a
pplications that caused a
n
ce. This was verified by
application that consumes
o
ff and thus tries to hide its
the main men
u
of the IDS
n
ality while figure 7 shows
of the IDS
o
cked actions
332332

V. LESSONS LEARNED
The scanner uses regular Java timers, which fire only when
the device is awake. So we experimented with changing the
timers to use a wake lock to keep the device partially awake
and perform continuous scanning. The increase in precision in
the captured readings did not warrant the increase in energy
consumption.
Heavy activity on busy test devices made some high
frequency collectors encounter database locking issues when
the scanner was using a single SQLite database to log all
activity. The use of several databases to split up the
information made this a rare occurrence.
Some other busy devices suffered from low memory
conditions which affected the functionality of the IDS along
with other applications. This made us suspect that any
continuous scanning behavior will perform poorly on Android
unless specific optimizations are made to address this issue.
VI. CONCLUSIONS AND FUTURE WORK
This paper provided an overview of detection methods used
for detecting malware on Android systems. We then proposed
and designed DAIDS, a modular host-based mobile intrusion
detection framework that monitors application behavior
looking for malicious patterns. An example algorithm that uses
resource usage to detect malicious behavior was described and
used to test the capabilities of the system. The proposed system
can be used as a framework for further testing and discovery of
detection techniques. The source code will be made available
at https://github.com/alaasalman/aids.
Our future work using this platform will consist of offline
analysis of data collected from a larger sample of devices in
real-use. The sampling test was run by TELUS Corporation
and used 15 Samsung Galaxy S III devices given to recruited
power users for the collection of data. The data was exported
and collected bi-weekly over a period of around 6 months. The
analysis will help in tweaking existing algorithms and
discovering new ones to be incorporated and distributed with
the system. A subset of the data will also be used for targeting
specific malware to observe system response and detection
rates of different algorithms. We also aim at refining the
integration points of our IDS with the operating system to
allow for deeper integration and better data collection to be
used in the detection of malicious applications.
ACKNOWLEDGEMENT
This research was funded by TELUS Corporation, Canada.
REFERENCES
[1] “Android and iOS Combine for 92.3% of All Smartphone Operating
System Shipments in the First Quarter While Windows Phone Leapfrogs
BlackBerry, According to IDC - prUS24108913.” [Online]. Available:
http://www.idc.com/getdoc.jsp?containerId=prUS24108913. [Accessed:
13-Nov-2013].
[2] “NQ mobile’s 2012 security report.” [Online]. Available:
http://www.nq.com/2012_NQ_Mobile_Security_Report.pdf. [Accessed:
13-Nov-2013].
[3] M. Halilovic and A. Subasi, “Intrusion Detection on Smartphones,”
arXiv e-print 1211.6610, Nov. 2012.
[4] Pieterse, H.; Olivier, M.S., "Android botnets on the rise: Trends and
characteristics," Information Security for South Africa (ISSA), 2012 ,
vol., no., pp.1,5, 15-17 Aug. 2012
[5] “Server-side Polymorphic Android Applications | Symantec Connect
Community.” [Online]. Available:
http://www.symantec.com/connect/blogs/server-side-polymorphic-
android-applications. [Accessed: 13-Nov-2013].
[6] “jon.oberheide.org - blog - dissecting the android bouncer.” [Online].
Available: http://jon.oberheide.org/blog/2012/06/21/dissecting-the-
android-bouncer/. [Accessed: 13-Nov-2013]
[7] “The Bearer of BadNews | The Official Lookout Blog.” [Online].
Available: https://blog.lookout.com/blog/2013/04/19/the-bearer-of-
badnews-malware-google-play/. [Accessed: 13-Nov-2013]
[8] P. Berthome, T. Fecherolle, N. Guilloteau, and J.-F. Lalande,
“Repackaging Android Applications for Auditing Access to Private
Data,” in Availability, Reliability and Security (ARES), 2012 Seventh
International Conference on, 2012, pp. 388–396.
[9] M. Alazab, V. Monsamy, L. Batten, P. Lantz, and R. Tian, “Analysis of
malicious and benign Android applications,” in Distributed Computing
Systems Workshops (ICDCSW), 2012 32nd International Conference
on, 2012, pp. 608–616.
[10] Asaf Shabtai, Uri Kanonov, Yuval Elovici, Intrusion detection for
mobile devices using the knowledge-based, temporal abstraction
method, Journal of Systems and Software, Volume 83, Issue 8, August
2010, Pages 1524-1537
[11] “top (software),” Wikipedia, the free encyclopedia. 11-Nov-2013
[Online]. Available:
http://en.wikipedia.org/w/index.php?title=Top_(software)&oldid=57696
3680. [Accessed: 13-Nov-2013]
[12] “Android NDK | Android Developers.” [Online]. Available:
http://developer.android.com/tools/sdk/ndk/index.html. [Accessed: 13-
Nov-2013]
[13] “inotify - Wikipedia, the free encyclopedia.” [Online]. Available:
http://en.wikipedia.org/wiki/Inotify. [Accessed: 13-Nov-2013]
[14] “TCPDUMP/LIBPCAP public repository.” [Online]. Available:
http://www.tcpdump.org/. [Accessed: 13-Nov-2013]
[15] “Deciphering detection techniques: Part ii anomaly-based intrusion
detection.” [Online]. Available:
https://secure.mcafee.com/japan/products/pdf/Deciphering_Detection_T
echniques-Anomaly-Based_Detection_WP_en.pdf
[16] A. Porter Felt, E. Chin, S. Hanna, D. Song, D. Wagner, “Android
permissions demystified”, in 18th ACM Conference on Computer and
Communications Security, Chicago, IL, 2011, pp. 627-638
[17] “BugSense | Crash Reports and Operational Intelligence for Android,
iOS, Windows Phone & Windows 8 apps.” [Online]. Available:
https://www.bugsense.com/. [Accessed: 13-Nov-2013]
[18] “PowerTutor.” [Online]. Available:
http://ziyang.eecs.umich.edu/projects/powertutor/. [Accessed: 13-Nov-
2013]
333333