Design_v5_adam_reviewx

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

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

69 εμφανίσεις

Design

In this section we present an architecture for a two
-
pronged rootkit detection
system
for Android
smartphones
that consists of a VMM and
a
kernel module. First, we present the threat model

that our
approach aims to solve
.

Next we discuss the design

of the VMM and
the
interface between the VMM
and
the
k
ernel module within the guest OS.
We then describe the design of a kernel module used to
detect common methods employed by rootkits.

Threat Model

Since
rootkits specificall
y targeting smartphones have not been

well

documented, we have generalized
the first component of
our a
ttack model towards the Linux kernel
. This aspect of the attack model would
apply to any device or PC using the Linux kernel as its OS. Android clearly f
its this description as it
is built
directly upon the Linux kernel
.
We
a
ssume
that
the

rootkit deployed by
an
attacker
would attempt to
modify

kernel data structures within memory such as the system call table
, as this is typical kernel
-
mode
rootkit behavi
or
.

While
first generation

rootkits

conceal
ed

malicious activity by modifying persistent
system files, user level integrity checkers and signature scanners have already b
een developed to detect
rootkits that modify system files
.

We
feel
these
user level a
ttacks are well known and the tools that
detect these attacks are widely available

[chkrootkit, tripwire]
. Therefore, we decided to focus on
more

complex attacks [Adore, Knark] that tamper

with the OS kernel in memory
as a means
to subvert tools
used to report and audit system state.

We also
acknowledge
that our approach would fail to detect
rootkits

such as Shadow W
alker that operate
without modifying the OS kernel
by modifying the
hardware st
ate
.

The second component of our at
tack mod
e
l is necessary because
Android has
two distinct user
-
mode
execution environments
, and the
details of the lower environment are

totally hidden from the typical
Android user
. This is a major architectural difference from that of traditional PC
-
based

Linux
distributions.

The best
-
known of the two execution environments by Android users is the

one provided by the

Android
Runtime and Application Framework

as they

provid
e

the actual user interface. Android apps, such as
those that a user would obtain fr
om the Android Market, run in this environment and are executed by
the Dalvik Virtual Machine.
Android apps have
permissions to various system resources, such as GPS
access, advertised to the user the first time the app is executed. The user can exam
ine and approve or
disapprove the app based on whether or not the resources requested are appropriate for the
expected
app behavior. We assume that this system
generally
works as advertised

for providing necessary
security.

Attacks do occur at this level,
as
Google recently had to remove 5
8

malicious apps from the
Android Market

and invoke the remote application removal feature to wipe the apps directly from user
handsets for the first time ever

[Android Malware Outbreak]
. Still, it is not clear whether th
e users were
fooled
,

or

just

not diligent

while

performing the
resources permissions
check on installation. Even so,
clearly Android has built
-
in contingency plans for providing security fallbacks, and malware operating at
this level will garner a lot
of scrutiny and be quickly discovered. As a result, we do not concern ourselves
with attacks at this level.

The other user
-
mode environment on Android is the Linux user
-
mode environment where Linux
applications


including the Dalvik Virtual Machine


exec
ute. A malicious Linux application could be
installed one time

and given user
-
mode root access on ever
y boot by simply having a line added to the
init.rc

file to do so. From this point, it is possible to query

the GPS coordinates
, to open a network
connect
ion,

and

to
access the
Linux
file system
. File system access allows the ability

to
read

the call logs,
phone book, and text messages
as this data is stored as

unencrypted

sqlite database files

as
demonstrated from kernel
-
mode by
the
Mindtrick rootkit
[This

is not the droid you’re looking for]
. In
addi
tion, the typical method for a user to determine what applications are running on the system
through the Settings app only shows Android apps, it does not display the executing Linux applications
or services on

the device. This means that Linux applications effectively are hidden from the user
without the need for any special measures to be taken to do so.

With no special
hiding
measures taken
by the attack, existing tools for detecting user level attacks [chkro
otkit, tripwire] would not detect foul
play.

As a result of this information
,

this unique threat to the Android platform
, and the extremely
sensitive nature of the data at risk
, we decided to focus on security in this area as well.




VMM

Design

A
virtual machine monitor is a thin layer of software that runs on

top of

the bare hardware or on an
existing OS. VMMs have typically been used to emulate the underlying hardware in such a way that
allow
s

multiple operating systems

to run in isolation on to
p it by virtualizing the hardware and then
multiplexing the hardware bet
ween each guest OS
.
Figure 1 illustrates the organization of our VMM
with respect to the Android software stack.











Since the VMM operates at a layer below the guest OS, it is at a prime location to monitor the integrity
of the
guest kernel because it is securely isolated from the hostile guest environment yet still maintains
sufficient visibility into the guest.

This model of monitoring a guest OS is known as virtual machine
introspection and has been widely accepted as a secure

model for monitoring the
guest
OS [virtual
machine introspection
]. As described in
Garfinkel et. al
,

a VMM could monitor the integrity of

any page
of physical memory or disk block in a guest OS,
however, a
k
ernel module within the guest that is aware
of
the guest’s context
and shares its execution environment
is better suited for the task.

Thus, o
ur
design furthers the virtual machine introspection model by extending into the guest kernel. The primary
objective of our VMM is to establish a root of trust within the guest by monitoring the integrity of a
guest
kernel module

from within the VMM itself
. The trusted kernel module is then responsible for

monitoring

the integrity of data structures within the guest.

When designing

the interface between our
VMM

and
the guest kernel module
, we

considered the following properties in order to establish trust
within the guest OS:



Availability:

The trusted kernel module gains execution as configured.

To ensure the guest’s
kernel module is executed, our VMM is designed to generate a specific interrupt that is raised
Hardware (Emulator)

Android_vmm

Linux Kernel

Libraries and
Runtime

Application
Framework

Application
Framework

Libraries and
Runtime

Trusted KM

Linux Kernel

Trusted KM

based on hardware timer interrupts monitored
by the VMM. An interrupt service routine within
the guest then
invokes the integrity checking operations provided by the

trusted kernel module.



Integrity:

The trusted kernel module is not modified by malicious code within the guest.

Before
the VMM invokes

the kernel module through an interrupt, a hash of the kernel module and its
data is performed to verify the integrity of the module. If the VMM detects that the kernel
module has been modified, the VMM replaces the kernel module with a copy of the origina
l
kernel module before invoking it.

In order to provide a simple interface that provides both integrity and availability between the guest
kernel module and the VMM, the VMM must have prior knowledge about the location and size of the
guest kernel module.

To accommodate this, the VMM is compiled with
the
static location, size, and
content of the guest kernel module. Future work may improve upon the interface design by allowing
the guest kernel module to pass this information

dynamically

and securely to th
e

VMM upon
initialization.

Kernel Module

Kernel modules are pieces of software used to extend the OS kernel functionality. These can be statically
built as part of the kernel or built as a standalone dynamically loadable kernel module. Kernel
-
mode
rootkits

operate as part of the kernel
and perform direct kernel object manipulation by using the latter
approach, typically.


Our protection kernel module,
which is monitored
by the VMM, will check the integrity of the syscall
table and ensure that it has not bee
n hooked. As discussed, this
condition
is clear indication of the
presence of a rootkit. If the kernel module detects that the syscall table has indeed been hooked, it will
simply replace the table with the original syscall table copy that is a part of the

kernel module itself.
This
functionality is illustrated in the
figure
s

below
.
To allow this copy to be obtained with no threat of
compromise requires the kernel module to have prior knowledge about the location and size of the
syscall table. To accommo
date this, the kernel module is compiled with the static location, size, and
content
s

of the syscall table
, which avoids the problem of potentially making a validation copy after an
attack has hooked the table.


To address the threat
s

presented

at the
L
inux library level
, the kernel module will be built with a
capabilities table and will restrict access to sensitive Android system resources

to only those processes
that appear in the capabilities white
-
list. Research will need to be performed to determine

what Linux
user
-
mode processes should have access to each of the sensitive Android resources. The Linux user
-
mode processes that act in support of Android should be a static set of services
, so this approach should
not impose a problematic restriction
. An
droid apps must
map to user
-
mode Linux processes in some
manner. This correlation will be used to allow any Android app to access these resources, as not doing
so severely impacts system usability. Additionally, Android apps gain their authorization to acc
ess
various sensitive system resources directly from the user, so it would be a poor design to automatically
disallow user
-
granted permissions.



References

Shadow walker
@article{sparks2005shadow,


title={{Shadow Walker”: Raising the bar for rootkit dete
ction}},


author={Sparks, S. and Butler, J.},


journal={Black Hat Japan},


pages={504
--
533},


year={2005}

}


Adore
-


http://lwn.net/Articles/75990/

Knark
-

http://www.ossec.net/rootkits/knark.php

Android Malware Outbreak
-

http:
//online.wsj.com/article/SB10001424052748703883504576186810666183384.html?mod=WSJ_hp
_LEFTWhatsNewsCollection

This is not the droid you’re looking for
-

http://www.defcon.org/images/defcon
-
18/dc
-
18
-
presentations/Trustwave
-
Spiderlabs/DEFCON
-
18
-
Trustwave
-
Spiderla
bs
-
Android
-
Rootkit
-
WP.pdf

[virtual machine introspection]



@conference{garfinkel2003virtual,


title={{A virtual machine introspection based architecture for intrusion
detection}},


author={Garfinkel, T. and Rosenblum, M.},


booktitle={Proc. Network an
d Distributed Systems Security Symposium},


volume={1},


pages={253
--
285},


year={2003},


organization={Citeseer}

}