Security of Mobile Devices

terrificbeepedΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 11 μήνες)

124 εμφανίσεις


Security of Mobile Devices



Lon Kastenson






Abstract


T
he line between

the

personal computer and mobile
smart
phone

has already begu
n to blur.

The
hardware race is in full swing as chip manufacturers put out the latest and greatest every quarter
and the operating systems on top of that hardware have

evolved into an entire ecosystem. An
ecosy
stem complete with exciting

new features, applications, developers, and let us not forget
the enthusiasts
. However, with each

new

smartphone activation there is
a new target born. An
unfortunate side
-
effect of the

explosive growth seen in smartphones is the issue of security.

As the demand

for mobile platforms to offer the same conveniences as modern personal
computers

increases

the risks

do as well. Vulnerabilities such as malware, direct attacks, data
interceptio
n, exploitation, and social engineering all have transitioned into mobile space as
fluidly as the operating systems themselves. This paper will inform the r
eader of these threats,
identify
the

pros and cons of some operating systems, and
draw a conclusion
towards the future
of security in mobile devices
.





Introduction


In
June 2004 the first malware application was identified for the popular Symbian operating
system. According to the Alexander Gos
tev, a member of the Kaspersky new v
irus identification
te
am, “The trickle of new malicious programs for Symbian that began in 2004 has become a
constant stream which threatens to become a torrent.” This marked the first time his team had
dealt with a virus designed for the ARM family of processors since the focu
s previously was
only on x86 based architectures. Gostev goes on to talk about the
origin of the virus, several
methods by which to spread and concludes by reference to his law of computer virus evolution.
It can be summarized in three points:

1.

The platfor
m must be popular.

2.

There must be well
-
documented development tools for the application.

3.

The presence of vulnerabilities or coding errors.
[
1]

2


While these points may seem obvious, there is no doubt that a relationships exists between these
points and the amo
unt of attacks on an operating system. But since the focus of this paper is on
mobile space, let’s take a look at the current
market share of smartphone operating systems.



Figure
1
:
Worldwide Smartphone Sales in Quarter 2 of 201
1

[2]

Researchers believe growth of the smartphone market will continue to rise at the expense of
feature phones. Roberta Cozza, a researcher at Gartner
believes “Consumers in mature markets
are choosing entry
-
level and midrange Android smartphones over fe
ature phones, partly due to
carriers’ and manufacturers’ promotions.”

[3]

It would be a fair assumption that some of these
new fi
rst time smartphone buyers are no
t the tech savv
y sort and their upgrade from a relatively
safe feature phone to a smartphone w
ill leave t
hem vulnerable to exploitation.

The

operating
system documentation and Software Development Kits (SDKs)

available to anybody is be
yond
what one might imagine. This

research
paper explores the official documentation
of Android
[4]
,
iOS
[5]
, Symbian
[6]
, and Windows Phone
[7]

barel
y scratched the surface of what i
s available. A
multitude of wikis, forums,

chat rooms,

and tutorials exists outside official documentation,

and

some
even about how to exploit the device itself.

The combination of popularity,

accessibility of resources, and a wide range of users each with
unique vulnerabilitie
s it i
s no wonder the smartphone security is becoming a hot issue. In fact, in

IBM’s annual X
-
Force Trend and Risk Report for mid
-
2011 it states: “The bad guys are moving

on to new attack surfaces, and one of those new battlefields is smartphones” IBM predicts that
exploits targeting mobile devices “will more than double from 2010.”
[8]


3




Types of Attacks

Briefly mentioned before, the basic types of attacks that can happ
en

include: Malware, Direct
Attacks, Data Interception, Exploitation, and Social E
ngineering. Many of these attacks have
origins in or are direct copies of previously developed exploits and hacks.


Malware

M
alware is also known as viruses, worms, trojans, a
nd spyware.
One of t
he most well
-
known
type
s

of exploit
s
, malware has steadily increased in the absence of any real dire need for a third
-
party security suite for mobile devices.

The trend of smartphone targeted attacks is rapidly increasing due to the co
mbined portability of
along with the computin
g and networking power of PCs.
Malware can be installed on a device in
several different ways

and

the three
most common

routes are attacks from the Internet, infection
from compromised PC during the data synchro
nization, and peer smartphone attack or infection.
Alexander Gostev and his team

found that

the virus was transmitted through a Bluetooth flaw[1].

W
ithout going into too much
detail;

malware typically is after two things. First it needs a way to
propagate
itself to more devi
ces. I
t will look for ways to spread such as sending SMS messages
to the victim’s entire contact list. Secondly, it will want to gather data, this can be accomplished
many ways, logging keystrokes, installing illegitimate software, spoof
ing certificates or entire
websites, all the way to hijacking an entire system until the process itself is killed.


Direct Attacks

Direct Attacks are t
argeted attacks on a device based on a known security
issue, m
any times
these stem from a weakness in a c
ommon application or a fault within the OS itself.
Last year
Android users were urged to update their Adobe Flash Player application as it had a serious flaw
that would allow a malicious script crash the entire system[
9]. Direct attacks differ from m
alware

because a harmful program

is not installed on the
device;

rather

a weakness is exploited and can
cause the system to behave erratically possibly setting it up for a chained exploit.

In the report released by IBM X
-
Force, the top areas of concern are SQL
injection and searching
for open services in a device that is broadcasting any type of connection. Document readers and
multi
-
media players have certain vulnerabilities if they are connected to the Internet. To enforce
that clients and not just servers sho
uld be vigilant IBM found that, “Forty percent of 678 Fortune
500 companies and popular websites contain client
-
side JavaScript vulnerabilities.”
[8]



4


Data Interception

An increasingly common method of obtaining information is via data interception. Data
i
nterception usually happens when a device is connected to a compromised network. There are
many programs and tools available to accomplish this task.

One in particular for the Android OS is called WireShark. From the
ir application description:

Wireshark i
s the world's foremost network protocol analyzer. It lets you capture and interactively
browse the traffic running on a computer network. It is the de facto (and often de jure) standard
across many industries and educational institutions
[10]
.


WireShark me
rely analyzes the packets,
however, combined with some type of password cracker would allow an intruder to obtain your
unique logon information.

Another exploit involving data interception is setting up a wireless network with the same name
as a genuine ne
twork that is in close proximity. That way the attacker only needs to store all the
packets of data from a terminal with administrative access to the network. Cain and Abel, Abel
speci
fically
allows the installation and execution of a cache dump of all log
ons. Cain and Abel is
another versatile tool that is perfectly legitimate to have on a system, but has the potential to
crack through network encryption given enough time to run
[11]
.


Exploitation and Social Engineering

While it may be a very low tech appr
oach to obtaining sensitive information, social engineering
and exploitation should not be u
nderestimated. Receiving a text message from an unknown
source or solicitation (phishing) are likely attempts at soc
ial engineering. Recently, the Android
M
arketpla
ce fell victim to some social engineering where malware was named to be similar
popular applications. The fake applications pulled all the device information and also had the
potential to download more code after “rooting” the device. Rooti
ng means the ope
rating system

allows certain applications f
ull root access to the device

and may cause more pro
blems
.


Comparison of Operating Systems

The popular

mobile

operating systems today are Android, iOS, Symbian, Blackberry OS, and
Windows Phone
. This paper

will c
over

Android and iOS in detail

with a few comments on

other

mobile operating systems in general
.


Android

OS

The
newest contender in the smartphon
e arena and as Figure 1

described the biggest as well.
Android is a modern mobile platform that
was designed t
o be truly open,

the source code for
Android is all open source as well as any Android developed application on the phone. It is not
uncommon to see people with different “ROMs” of
Android. T
hese ROMs are typically based
off of the open source code along w
ith third
-
party modificatio
ns.
In the context of an Android
5


device, ROM

(Read
-
only Memory)

is the internal flash memory where the core operating system
resides. It can also refer to a specific version firmware that can be applied to a device through a
proc
ess usually referred to as flashing.
An improperly flashed ROM can often

brick


the device,
rendering it unusable
[12]
.

Android claims to reduce the chance for

most of the common attacks to happen especially

socia
l
engineering attacks

using a unique permis
sions system
. Android runs on many devices, now
ranging from smartphones, tablets, and set
-
top boxes all with their own hardware configuration.
However, Android does take advantage of some hardware
-
specific security capabilities such as
ARM v6 eXecute
-
Neve
r which marks certain areas of memory as non
-
executable. Android’s
operating system itself is built over the top of the Linux kernel. As
such system level
applications D
isplay
, Bluetooth, Camera, N
etwork controller
s, etc.

are accessed directly by the
opera
ting system. Refer to
Figure 2

to get a better picture of how the Androi
d OS is organized
and to
understand how the Android sandbox works.

Android has two main security measures, the
Android Security Program and the Android Platform Security Architecture.


Android Security Program

The Android Security Program outlines the model and describes the standards for the hardware,
firmware, and applications developed for the operating system. The key components include
:




Design R
eview
: Each major feature is reviewe
d by engineering and security teams, with
appropriate security controls integrated into the architecture of the system.



Penetration Testing and Code R
eview
: Vigorous security reviews performed by the
Android Security Team, Google’s Information Security Eng
ineering team, and
independent consultants.



Open Source and Community R
eview
: Security reviews are also available to any
interested party. The open nature of the Linux kernel and the Android OS guarantee
significant external security reviews.



I
ncident
R
esp
onse: The response and follow up of released devices, firmware, and
hardware. The Android team monitors
the security concerns from the community and
release updates, patches, and minimizes and vulnerabilities discovered.

Updates are
received OTA (over the
air) or can be downloaded and patched manually.

[
4
]

In short
, the Android Security Program mission statement is to
“Enable a vigorous ecosystem of
applications and devices built on and around the Android platform and supported by cloud
services.”


6


Android
Platform Security Architecture

On the other side of the coin, the actual code that drives Android has key security features
implemented. This code is constantly maintained and updated to compensate for any new risk
introduced to the system. Its key compone
nts include:



Linux Kernel Security: The Linux kernel is a stable and secure kernel
that has been in
widespread use

and

t
he specific version running under Android, Linux
2.6

has been
around since late 2003. Some
features include, a user
-
based permissions mo
del, process
isolation, an extensible mechanism for secure Inter
-
Process Communication (IPC) and
the ability to remove potentially unsecure parts of the kernel.



Application Sandbox:
O
ne of the most important security
measures

is the application
sandbox t
he

chart below

(Figure 2)

shows the layout of the sof
tware stack. The purpose
of the layout

is to demonstrate ho
w integral the sandbox protects the operating system
from being compromised by just one application. Each library, framework, runtimes and
appl
ica
tion runs in its own sandbox, i
t has full control of everything in its sandbox but
nothing more unless granted permissions by the user. This means that any erratic
behavior by one application will not cause any instability outside of its own sandbox. The
o
nly exception is if an application has been granted
super user

(root) permissions, which
is not the default setting for the stock operating system and is not recommended for the
typical Android user.



Figure
2
:
The Android Softw
are S
tack [
13
]



System Partition and Safe Mode: The kernel and OS level resources are on a separate
partition that is read only while the operating s
ystem is in use. Safe mode allows only
operating system level applications to run.

7




Filesystem Permissions:

A

u
ser
-
based permissions means that each user cannot read

from

or write

to

another user’s files. In the case of Android, a user is an application. This goes
along with the idea that each application can only run in its own sandbox and has only the
permissio
ns granted to it by the user.



Filesystem Encryption: All user data can be encrypted with the
d
m
-
crypt

implementation
of AES128 with CBC and ESSIV:SHA256. User passwords are encrypted with SHA1
that protects against brute force attacks. Stricter password gu
essing methods can be
chosen by the user and enforced directly by the operating system.[
4
]

Android security
measures reaches farther than this but th
is is a solid overview for the basics of
its security.


iOS


Apple has developed a similar set of security
precautions

for their iOS operating system
. Like
Android
, iOS has developed its own security architecture. Unlike Android, iOS is closed source,
Apple decides which parties are responsible for the testing and review of code and security risks.
The actual p
rocedure that Apple uses in code review and testing is not something publically
shared
.

Before looking at the response of an incident, it is important to note that iOS has strictly defined
terms
to which the user must adhere
. The iStore, similar to the And
roid ma
rket, has stricter
regulation on

w
hic
h applications can be created and sold
. There are specific interface design
characteristics, functionality, content allowed, and technologies allowed

and

i
f any
one
of these

rules

is not followed to the discretio
n of the review board an application is likely to be rejected
until it is fixed accordingly. The upside of this

strict regulation

is that the chance of Malware
being released on an o
fficial channel is very slim, t
he downside is that applications
which may
not pose a se
curity risk may still be denied
[
14
]
.

When an incident is discovered the response team releases a public notification and will release
the appropriate patch to the end
-
user. This patch will install the next time the device
connects to
a PC to s
ynchronize
.


Security Architecture

The implemented security architecture of iOS has some similarities to Android, those will be
explained later in this section, but it is worth mentioning that iOS is built upon a “Core OS”
kernel. This kernel, while it may

share some similarities with UNIX based systems is developed
specifically for iOS.

8



Figure
3
: Overview of iOS security architecture.
[1
5
]




Security Server Daemon: The securi
ty server that implements protocols to keychain items
an
d other security APIs. iOS security services do not provide an authentication interface,
there is no need for a user interface since everything is automated or handled by the APIs
themselves.



iOS Security APIs: Based in the Core Services layer, the four ma
in security APIs are.

o

Keychain: The keychain will

store passwords, keys, certi
ficates, and other secrets.
It is also

in charge of encrypting and decrypting this data (not to be confused with
encryption of data, the keychain encrypts the actual passwords a
nd encryption
keys). Calls upon Core OS libraries in that case.

o

CFNetwork: High
-
level API that is technically outside the security APIs that is
used by applications to create and maintain a secure data stream and add
authentication to a message.

o

Certificat
e, Key, and Trust Services: Handle certificates, add certificates to the
keychain, create encryption keys, encrypt and decrypt data, sign and verify
signatures, and manage trust policies. Also requires Core OS libraries.

o

Randomization Services: Creates pse
udorandom numbers

for encryption

that are
virtually discernible from any recognizable sequence. Uses a randomization
service located
in the Core OS layer. Two layers of abstraction from the actual
randomization seed.



Authentication,
Identification
, and Aut
horization
: Contains the sandboxing, similar to
what Android does but iOS only has one sandbox for all applications, libraries, and
9


runtimes outside of the kernel layer. Permissions are granted from here once an
application has been authorized. The means b
y which might be automatic or could ask
the user to input a specific PIN.

[
5
]

There

are many more concepts to be discussed about the specific security precautions in the
code
, but a
s a

general overview
one can see that iOS and Android have their difference
s but also
share
many

of the same

security precautions
.


Android OS
vs.

iOS

Dr. Charlie Miller, a security researcher who has exposed vulnerabilities in just about every
mobile OS
,

expressed his feeling on Android and iOS security.
He believes that Android

has the
stronger Application sandboxing but with the weak control on the market, more and more
applications are able to install Malware which bypasses this
security feature

by rooting the
target’s phone and granting the malware administrative
privileges
.
He also mentions that Apple,
while weak in its application sandboxing, has superior memory encryption, due to the fact that
the number randomizer offers better protection against a spoofed certificate. Dr. Miller gives the
nod to iOS as the best in securit
y, but he believes the worst is yet to come. The “bad guys” as he
puts it, have not yet shown a lot of inte
rest in the mobile device world
[
1
6
]
.



Conclusion

The growth of smartphones and mobile devices in general has impacted society in a big way.
The
smar
tphone is now its own

industry and with that comes a greater importance to have tight
security precautions without hindering the end
-
user.

The hackers, malware, and spyware writers
are
making the transition to mobile.

Android, iOS, Windows Phone, and many
other big software
developers must step up their security game. Users of those systems must also stay vigilant and
practice good habits when downloading software to their device.

Looking over the official
documentation one can see that the security practic
es are there, in fact they are adequate for the
time being. However, m
obile devices are quickly changing the way we handle our digital
activities and our processes and code design has to adapt
accordingly. Otherwise, the “bad guys”

will seize the chance an
d attack the unsuspecting end
-
users.






10


References

[1]Gostev, Alexander.

(2006 September)

Retrieved Oct
ober

2011, from Securelist


Mobile
Malware Evolution: An Overview Part 1
http://w
ww.securelist.com/en/analysis?pubid=200119916


[2]Wikipedia.
Retrieved October

2011, from Wikipedia
http://en.wikipedia.org/wiki/File:Smartphone_share_current.png

[3]
Gartner (n
.d.)
.

Retrieved October 2011, from Gartner


Gartner Says Sales of Mobile Devices
in Second Quarter of 2011 Grew 16.5 Percent Year
-
on
-
Year; Smartphones grew 74 Percent
http://www.gartner.com/it/p
age.jsp?id=1764714


[4]
Google. (n.d.).
Android Open Source Project
. Retrieved Sept 2011, from Android Open
Source


Android
Security Overview

http://source.android.com/tech/security/index.h
tml


[5]
Apple. (n.d.).
Mac OS X Developer Library.

Retrieved

Sept 2011, from Apple Developer


Security Overview
htt
p://developer.apple.com/library/mac/#documentation/Security/Conceptual/Security_Overview
/Introduction/Introduction.html


[6]
Nokia. (n.d.).
Symbian C++ Books.

Retrieved October 2011, from Nokia Developer


Fundamentals of Symbian C++/Platform Security
http://www.developer.nokia.com/Community/Wiki/Fundamentals_of_Symbian_C%2B%2B/Plat
form_Security


[7]
Microsoft. (n.d.).
MSDN.

Retrieved October 2011
, from MSDN


Security for Windows
Phone
http://msdn.microsoft.com/en
-
us/library/ff402533.aspx


[8]
IBM. (n.d.).
IBM Security Solutions.

Retrieved September 2011, from
IBM


IBM X
-
Force
2011 Mid
-
Year Trend and Risk Report
http://public.dhe.ibm.com/common/ssi/ecm/en/wge03015usen/WGE03015USEN.PDF


[9]
PCWorld.
Bradley, Tony. Retrieved

September 2011, from PCWorld


Adobe Flash Zero Day
Puts Android Smartphones at Risk.
http://www.pcworld.com/businesscenter/arti
cle/205411/adobe_flash_zero_day_puts_android_sm
artphones_at_risk.html


[10]
(n.d.).
WireS
hark User’s Manual.

Retrieved October 2011, from WireShark Wiki


WireS
hark User’s Manual
http://www.wi
reshark.org/docs/wsug_html_chunked/


[11]

Montoro, Massimiliano. Retrieved October 2011from oXit


About Cain
http://www.oxid.it/cain.html


[12]
(n.d.). Retrieved October 2011 from CyanogenMod Wiki


What is Cya
nogenMod?
http://wiki.cyanogenmod.com/index.php?title=What_is_CyanogenMod

[13]
Google. Retrieved October 2011 from Android Open Source

http://source.android.com/tech/security/images/image00.png


11


[14]
Apple (n.d.). Retrieved October 2011 from Apple Developer


Guidelines for Appstore
Submissions

http://developer.apple.com/appstore/resources/approval/guidelines.html

[15]
Apple. Retrieved October 2011 from Apple Developer
http://developer.apple.com/library/mac/documentation/Security/Conceptual/Security_Overview/
art/iphone_security_architecture.jpg

[16]
Accuvant. Farnum, Michael. Retrieved October 2011 from Accuvant


Dr. Charlie Miller
Compares the Security of iOS and Android
http://www.accuvant.com/blog/2011/10/20/dr
-
charlie
-
miller
-
compares
-
security
-
ios
-
and
-
android