Download Section for introduction % \section{Introduction} Over the last several

%
% Section for introduction
%
\section{Introduction}
Over the last several years, innovations in the advancement of computing
and communication hardware have allowed mobile phones to evolve into
affordable general purpose computing platforms. In the fourth quarter of
2010 alone, 101.2 million smart phones were sold worldwide, a growth of
88.6\% from the previous year \cite{Canalys11}. These phones are equipped
with a rich set of hardware interfaces and software applications that
allow personal and corporate users to interact with both the cyber and
physical world through Internet access, email, SMS, and location-based
services. To support the increasing complexity of software and hardware,
specialized versions of Linux, Windows, and Symbian operating systems
have been tailored to manage smartphone resources.
With the increased adoption of smartphones into our daily lives and their
large attack surface, it is no surprise that malware writers have begun
targeting mobile phones. In a study conducted by F-Secure in 2007, 373
unique instances of malware were found to target mobile platforms
\cite{hypponenstate}. This trend has only accelerated along with the
explosive growth in smartphone sales. According to Kaspersky Lab, the
amount of mobile malware has more than doubled over the last two years
when last measured in January 2011. The study found a total of 1046
unique mobile malware strains based on 154 mobile malware families
\cite{Kaspersky2011}.
This paper aims to increase security of Android mobile platforms by
providing a detection and prevention security system focused on a subset
of malware known as kernel-level rootkits. A rootkit is a tool that
enables administrator-level access to a computing platform, allowing it
to stealthily carry out malicious goals. For example, a rootkit may
employ anti-detection techniques such as hiding associated processes and
the open files it is using to carry out its malicious activities. While
most well-known instances of rootkits targeting mobile operating systems
have been limited to research publications \cite{bickford2010rootkits,
trustwave2010rootkits}, it is only a matter of time until malware
developers begin leveraging rootkits against smartphone operating systems
to a larger extent.
We decided to implement our rootkit detection and prevention system on
Android because this platform along with its underlying Linux operating
system is freely available, thereby allowing us to study and modify
interfaces with ease. As another factor in this selection, Android became
the leading smartphone platform in the fourth quarter of 2010 in terms of
units sold \cite{marketshare}, elevating it to the system of choice in
the smartphone market. Having achieved this status will undoubtedly lead
to elevating Android’s perceived value as a malware target. The final
factor in our selection was the fact that the existing Android
development environment provides debugging and emulation tools that ease
experimentation and research techniques on the platform.
Initial research also indicated that the Android platform is potentially
vulnerable to malicious user-mode Linux processes. After making these
findings, we decided to incorporate protection against this type of
threat into our approach as well. As with kernel-mode rootkits, a onetime physical access installation or remote exploit could be leveraged to
install this user-mode malware. The exploit would then be capable of
modifying the startup configuration file to persist execution across
reboots of the Android device. At this level of execution, it would be
possible for such a process with root access to attain and transmit
sensitive personal information including current GPS coordinates, call
logs, the phone book, SMS messages, and to access the network for
transmission of this data.
Systems capable of defending against advanced rootkits that target the
Linux kernel have been implemented as extensions of the operating system
itself \cite{baliga2008automatic,
levine2004methodology,yin2010hookscout}. These solutions alone, however,
are unable to provide guaranteed security in this scenario because they
are also susceptible to attacks. Having execution access below the
operating system is the most complete way to ensure that rootkit
operation can be prevented, since kernel-mode rootkits would exist above
this layer, and thus would not be able to employ “layer below” hiding
techniques or attacks on the security functionality itself. We have
decided to rule out the use of hardware modifications to accomplish
isolation due to their associated invasiveness and implementation
complexities. To operate at a layer below the operating system being
monitored we have derived our approach from the virtual machine
introspection methodology first proposed by Garfinkel et al.
\cite{garfinkel2003virtual}. While it is true that a virtual machine
monitor (VMM) could access and protect all resources of the smartphone at
the level of their physical representation, this is a cumbersome
execution environment in which to provide such protections. It is nearly
analogous to providing hardware-based protection and is not easily
scalable or extensible as the Android platform continues to evolve.
This leads us to our concept of a two-pronged approach, consisting of
coupling a Linux kernel module providing protection from within the
kernel with a VMM whose sole goal is to protect the kernel module while
otherwise allowing normal system operation. The kernel module is
responsible for verifying the integrity of the syscall table, as current
research indicates hooking system services is a top priority target of
kernel-mode rootkits \cite{bickford2010rootkits, trustwave2010rootkits},
and clearly making it a critical resource for which to provide
protection. In addition, research was performed to determine what Linux
user-mode processes are used by the Android framework to legitimately
access the aforementioned sensitive device resources. This information
was used to set up an access control list that prohibits processes which
do not appear in the table from accessing sensitive resources, while
leaving legitimate Android processes with their current access
permissions intact.