An Antivirus API for Android Malware Recognition
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
An Antivirus API for Android Malware Recognition
Rafael Fedler, Marcel Kulicke and Julian Schütte
Fraunhofer AISEC
Garching near Munich, Germany
{fedler,kulicke,schuette}@aisec.fraunhofer.de
Abstract an app itself, but only into components downloaded and ex-
ecuted at runtime [9]. Furthermore, it has been shown that
On the Android platform, antivirus software suffers from current antivirus software deploys hardly any code level de-
significant deficiencies. Due to platform limitations, it can- tection techniques [20]. Due to these reasons, tests of an-
not access or monitor an Android device’s file system, or dy- tivirus software may report high detection rates for most
namic behavior of installed apps. This includes the down- products in theory, but in practice this does not result in a
loading of malicious files after installation, and other file high level of protection.
system alterations. That has grave consequences for device The deficiencies of antivirus solutions on Android and
security, as any app – even without openly malicious code in their lack of any effective detection methods for dynamic
its package file – can still download and execute malicious behavior, i.e., heuristics or signature based approaches on
files without any danger of being detected by antivirus soft- arbitrary file system objects, result from platform limita-
ware. In this paper, we present a proposal for an antivirus tions. As any other software installed on Android-based
interface to be added to the Android API. It allows for devices – commonly referred to as apps – antivirus soft-
three primary operations: (1) on-demand file system scan- ware is also confined in its own file system sandbox [1]. It
ning and traversal, (2) on-change file system monitoring, cannot access directories of any other app, and thus can-
(3) a set of basic operations that allow for scanning of ar- not scan other apps’ files for malicious patterns or behav-
bitrary file system objects without disclosing their contents. ior. Any app which is not included in the antivirus apps’
This interface can enable Android antivirus software to de- databases will not be detected when downloading malicious
ploy techniques for malware recognition similar to those of files to its own directory, e.g., privilege escalation exploits
desktop antivirus systems. The proposed measures comply or other malicious components. Thus, we consider the level
with Android’s security architecture and user data privacy of protection offered by antivirus software on the Android
is maintained. Through our approach, antivirus software platform insufficiently low.
on the Android platform would reach a level of effective- To improve the capabilities of antivirus software on the
ness significantly higher than currently, and comparable to Android platform, we propose an addition to the Android
that of desktop antivirus software. API. We present an interface for antivirus software to per-
form various operations on file system objects of an An-
1 Introduction droid device. It allows for both signature-based and heuris-
tic detection methods on arbitrary file system objects, as
The currently most extensive test of Android antivirus well as almost full file system scanning and monitoring.
software reports detection rates above 90% for approxi- User data privacy is preserved: Neither file system objects’
mately 25% of all Android antivirus software, and more names and full paths, nor file contents may be read by an-
than 50% of all products showed detection rates of 65% tivirus software. Our approach would increase the level of
and above [2]. These detection rates, due to platform limita- protection that can be offered by Android antivirus software
tions, are only achieved by tests of app installation package to a level comparable to that of desktop malware recognition
files. Most portions of an Android file system, including solutions, which is a major improvement over the capabili-
the working directories of apps, are not accessible by an- ties demonstrated by current Android antivirus solutions.
tivirus software . Antivirus software cannot scan working The rest of the paper is organized as follows. We in-
directories’ contents. Thus, current antivirus software can troduce the background theory in Section 2. This includes
be easily circumvented by not including any openly mali- Android system basics and a discussion of Android mal-
cious functionality in the initially installed package file of ware techniques. The deficiencies of antivirus software onthe Android platform are explained in Section 3, also cov- database contains the code path where an app’s package file
ering why retrospective detection rate tests fail to reliably with its bytecode is stored, the app’s package name, its UID,
determine the effectiveness of antivirus software. In Sec- and other entries. In contrast to many other Android op-
tion 4 we introduce our concept for an antivirus interface erating system resources, the package database is publicly
as part of the Android API. We will detail possible opera- readable.
tions, resulting implementable recognition techniques, user
data privacy, and how the interface is secured against unau- Package File Access Package files themselves are also
thorized access. We will discuss our approach in Section 5 readable by any app. This, in combination with the pack-
before concluding the paper in Section 6. age database being readable, provides access to package
files: Antivirus software can acquire the path to package
2 Background files from the package database and then open package files
After providing the necessary background information directly. This way, common antivirus detection techniques
related to the Android operating system, we will give a short can at least be applied to the static app installation package
insight into Android malware behavior. Also, to demon- file.
strate current antivirus shortcomings, we will briefly cover
one typical technique deployed by malware for executing Android Malware Techniques While different malware
its malicious functionality while avoiding detection by an- deploys various techniques to achieve propagation, infec-
tivirus software. tion and operation, one technique is of particular relevance
when discussing antivirus software on Android: the dy-
2.1 Android Platform namic fetching and execution of code [22]. We assume it
In the following, we will introduce the basics of the An- will be increasingly used by malware for various reasons.
droid platform’s measures for file system access control and (1) Native code enables malware to escalate privileges to
for managing the list of installed packages. The whole An- root access, as all currently available standalone root ex-
droid security architecture will not be discussed in detail, ploits are given as native code. (2) Carrying additional ma-
as a multitude of publications on this topic can be found licious code along with a malware app’s package file instead
[7, 21, 8]. of dynamically downloading it after installation can lead to
detection by Google’s Bouncer service during publishing in
the Android Market (“Google Play”) [18]. (3) In general,
Android File System Security On traditional desktop it is advantageous to download any malicious payload after
operating systems, processes started by one user all inherit installation, so it cannot be found in an app’s package file,
that user’s user ID (UID). Usually, this means every process in order to avoid detection.
can access all files by every other process with the same This behavior can already be witnessed by malware in
UID. To introduce additional security and data privacy, and the wild, as shown by RootSmart/BSmart [13]. It demon-
to prohibit access to any file system objects by other apps, strates the deficiencies of antivirus software for Android.
the Android operating system breaks with the aforemen- A seemingly completely harmless app which is not (yet)
tioned traditional UID assignment scheme. Every app is included in an antivirus app’s database can carry out addi-
assigned its own unique UID at installation time by default tional functionality not present in a package file by fetching
[1]. Access parameters to every app’s working directory executable code from the Internet. Such newly added code
are set accordingly, such that each app can only access its cannot be noticed by antivirus software and might include
own working directory. This UID assignment scheme es- privilege escalation exploits.
tablishes a file system sandbox for apps [21]. They are con-
fined in their own directory, separating each app from every
3 Android Antivirus Software
other, and from operating system’s files and folders.
Android antivirus software is limited drastically by this In this section, we will provide a summary of the afore-
file system-based sandboxing. It cannot scan the file system mentioned deficiencies of antivirus software on Android.
on demand or monitor file system changes. Most impor- We will also discuss why product tests based solely on the
tantly, this includes the working directories of other apps. detection rate are misleading regarding the real level of pro-
Antivirus software is thus oblivious to any files other apps tection offered.
might download or create at runtime, including malicious
code. 3.1 Limitations
The root cause of Android antivirus software ineffective-
Package Database The Android operating system keeps ness is the inability to directly access the file system and its
track of installed apps in a package database [5]. This contents. While this is a big benefit in all other cases as itensures data security and privacy of installed apps, it is a file handles. They again can be used to navigate through
major hindrance for antivirus software. Android antivirus directories, or to perform operations on files for malware
cannot deploy recognition techniques based on heuristics recognition. To allow for the traversal of the whole file sys-
or signatures to arbitrary file system objects, and especially tem, e.g., through breadth-first or depth-first search, this list
not to apps’ working directories’ contents. Thus, dynam- of aliases has to be ordered and aliases need to be calculated
ically downloaded code will not be found. This dynami- deterministically. Order is achieved by prepending an entry
cally fetched code may also be the only component which number. The alias can be a hash function of the absolute
openly demonstrates malicious behavior, keeping the app path of a file system object. The list also needs to contain
which downloaded the malicious payload free of any suspi- flags denoting whether an alias represents a file or a direc-
cion and detection. tory. This enables antivirus app to distinguish between di-
rectories which should be traversed, and files which should
3.2 Product Tests be scanned for malicious contents. We propose the follow-
ing tuple format as entries for a directory listing:
Typical antivirus product tests purely based on detec-
hentry no.i hdirectory/f ile f lagi haliasi
tion rate are only of limited significance for Android an-
To illustrate the concept, Listing 1 shows the output of a
tivirus software. Due to the nature of these tests, in which
regular directory listing via the “ls” command, while List-
a sample set is collected and then used as a testbed, only
ing 2 shows the output of a directory listing as performed by
the antivirus vendors’ retrospective knowledge of malicious
our proposed method. Each line of Listing 2 corresponds to
package files is tested. For many samples it is only tested
the same line of Listing 1 and contains the tuple described
weeks or months after their initial discovery. We do not
above.
consider such retrospective tests a valid representation of
the real protection level offered in real time, when new Listing 1. Usual directory listing
threats emerge. In reality, it is also of major importance user@computer : / t o p l e v e l d i r $ l s
how quickly a database was updated, determining how dir1
long users can unknowingly install malware without being dir2
warned by their antivirus app. Also, tests do not take into file1
account that no single antivirus app will be capable of de- file2
tecting malicious activity inside the working directory of file3
unknown malware, no matter how high the theoretical de-
tection rate. Thus, we consider the detection rate figures
reported by tests, e.g., by [2], misleading. They suggest Listing 2. Directory listing using aliases; out-
nearly complete protection for some products, even though put of the proposed API method for directory
these products can be easily evaded by malware developers. listings
0 p a55822426a5330c04625a41d264c190b
4 An Antivirus Interface
1 d b72b7253c45f9d22044c86bf4d7e4902
To address the weaknesses of current Android antivirus 2 d 515 d c 2 6 7 b b d 0 a f 0 1 9 d 2 2 e 7 6 6 a f 0 c b 7 e 4
software and to increase its effectiveness significantly, we 3 f f8bb5cc06b4ed23683b276ca05153e82
propose a new interface for antivirus apps on the Android 4 f 7 b2de0a0f16d100dfbf2d84603840ee2
platform. It allows for the execution of a number of oper- 5 f 9 fa5ba9abe67916142cb6bc0eee7658b
ations on arbitrary files. User data privacy is kept in tact
If the antivirus app wants to continue traversing the file
through aliasing of paths and by permitting only indirect
system, it can pass one of the directory aliases to the
access to files, instead of reading file contents directly.
method for directory listings. To allow scanning from
predefined or user-defined paths on downwards, the method
4.1 File System Navigation
for directory listing will also accept paths instead of aliases.
File system access, to be provided via directory listings, If the antivirus app wants to perform operations on a file,
is not granted directly but through API methods, which are it can pass a file alias to the corresponding methods for
to be offered by a corresponding class and methods in the file operations. Lastly, the directory listing provided by
Android framework. If a directory listing is requested by an the antivirus interface can also contain an entry for the
antivirus app, where the directory can be specified as a path parent directory, i.e., for “..”, which is denoted by a “p” flag.
provided as a string or as an alias, the antivirus app will
receive a list of the directory contents. However, to ensure File system access can be either granted from the root of
user data privacy, this list should not contain absolute or rel- the file system, i.e., for the whole file system, or only from
ative paths, but aliases. These are string representations of the app code paths and working directories (/data/app,/data/data and /system/app) downwards. Mostly, package files will be largely identical and hardly varying.
but not always, access to these directories will be sufficient Furthermore, many malware types on the Android platform
for malware recognition. make use of dynamic fetching of malicious payload files.
The implementation of the navigation by aliases and es- Such components will often be the same across many de-
pecially the whole traversal of the file system using aliases vices.
will require the API interface either storing or calculating The aforementioned aspects contribute to a high level
the aliases of (direct) parents in the file system. Alterna- of file homogeneity, making hashes of full files a valuable
tively, a trapdoor function for computing aliases may be characteristic for malware detection. The antivirus inter-
used to allow the interface to recover paths from aliases. face should thus provide methods to calculate typical hash
These serve the purpose to map aliases passed by the an- functions such as MD5 or functions from the SHA family.
tivirus software back to file system paths. Such a hash would be calculated given an alias or a file path.
Again, the antivirus interface has to store a list mapping the
4.2 File Operations aliases to file paths of the directory listed last by the an-
tivirus app, unless a trapdoor function is used.
File operations offered by the proposed interface should
aid in the detection of potentially malicious files. Mal-
ware recognition is usually achieved by signature matching, 4.2.3 Heuristics
heuristic analysis, or also hash-based. We will detail in the
following how our proposed interface can provide for these Apart from pattern or hash matching, antivirus software also
malware recognition techniques. uses heuristic techniques to detect malware. The major ad-
vantage is that potentially malicious behavior can also ex-
pose currently unknown malware, and is often unaffected by
4.2.1 Signatures minor alterations which would circumvent pattern or hash
matching. Such heuristics are mostly based on sequential
Common signatures contain one or multiple byte sequences,
execution of specific library, API, or system calls, and may
which can be linked in various relations, such as logical
contain also certain passed arguments.
(AND, OR) or regarding location in a target file. Such re-
Heuristic techniques can be divided into static and dy-
lations can be expressed via regular expressions. Thus, our
namic heuristics [15]. While the former is easier to conduct,
proposed interface shall provide a method to conduct pat-
the latter yields better results. However, it is not trivial to
tern matching using regular expressions. That method will
implement on the Android platform and introduces poten-
only return true or false for any given pattern described by
tial security risks.
a regular expression passed to the method. This ensures
user and system data privacy, while still allowing signature-
based detection. Different pattern matching algorithms can Static Static heuristic techniques do not execute the file to
also be used, which can improve pattern matching per- be examined and do not observe dynamic behavior. Instead,
formance or compatibility with existing vendor signature they observe the existence and order of certain call patterns
databases. [6]. For example, to find a specific system call sequence
in a binary file, the resulting opcodes can be searched for
[3]. To include certain parameters, the opcodes preceding
4.2.2 Hashes
the system call itself and parameters can also be examined.
Malware can also be detected using hash functions. On The latter works especially well if constant values (such as
desktop platforms this is not as effective, as many variants system call numbers or other parameters) are involved and
with minor alterations of one malware may exist, which are included inline with the opcode itself (as “immediate
circumvents full-file hash matching. On mobile platforms, value”). Pointers to any dynamic data, however, cannot be
though, hashes are of bigger benefit. Desktop malware is easily evaluated due to their sole validity during runtime.
usually spread highly decentralized via exploitation of soft- Java apps can also be examined this way, although the ex-
ware vulnerabilities, and often the same malware may be amination method has to be adjusted to the specific proper-
spread by many people for whom it has been “personal- ties of Dalvik bytecode [23].
ized”. This leads to hashes being a less useful approach. To support these heuristic techniques, the mechanism for
On mobile platforms, however, with difficult app vulner- signature scanning can be used. To this end, it needs to sup-
ability exploitation and with centralized software distribu- port patterns passed as byte sequences and described via
tion, hash-based malware detection gains value. Malware regular expressions, although granularity at byte level can
is usually spread as part of repackaged or seemingly harm- also be helpful for common signature-based approaches.
less apps, which have to be distributed via app markets to This allows for identifying specific opcode sequences.
reach the highest possible number of users. Thus, malware The two aforementioned heuristic techniques result in asignature-representable pattern form. Further static heuris- 4.2.5 Limiting Operations to Executable File Types
tic techniques are presented by Zhou et al. [23], including
analysis of an app’s manifest file and the structural layout of To limit operations to suitable filetypes, i.e., heuristics oper-
an app’s package file. These techniques can also be carried ations to executable files, the antivirus interface should also
out by antivirus apps through the interface presented in this offer a method returning the filetype of a file, given its alias
paper. or path, e.g., as a MIME type. Such functionality is already
included in the file utility. This saves resources and en-
sures that only suitable files are loaded for scanning. Only
Dynamic Dynamic heuristics test executable files by run- returning a boolean value matching a list of MIME types
ning or emulating them [6]. This is done, for example, by instead of returning a MIME type increases data privacy.
sandboxes or emulation environments, but other techniques
may also be used. They can follow the execution flow of a 4.3 File System Monitoring
program without harming the host system.
File system monitoring, often referred to as “on-access
On the Android system, when devising a possible an- scanning” or “guard”, checks for any changes made to the
tivirus interface to support these type of operations, multiple file system and tests new or changed files automatically.
problems arise. Foremost, letting one app execute any code We identified multiple approaches to facilitate this feature
by another app is a breach with the Android security archi- which, however, cannot monitor the whole file system.
tecture. Depending on the implementation of the dynamic
heuristics component, this may put the host system at risk.
Furthermore, very sophisticated malware may also attack Monitoring of the Package Database
and compromise its environment. Such attacks have already The Android package database, located in
been carried out successfully against Google’s Bouncer ser- /data/system/packages.xml, may be moni-
vice [19], which is also a dynamic heuristic malware recog- tored for changes by the Android antivirus software
nition software. or by the antivirus interface. Such monitoring can be
If such dynamic heuristics were to be implemented, implemented by means of the inotify Linux kernel
much of its functionality would have to be placed in the mechanism [17], which allows monitoring software to be
antivirus interface itself. We regard a direct interface for notified automatically if changes to a file system object,
antivirus software to load executables (both binaries and i.e., a file or a directory, occur. This way, the antivirus
apps) a very high risk which should be avoided. Also, interface can inform the antivirus software via Intents about
typical Linux kernel techniques such as chroot and in- changes to the package database. In such Intents, paths to
terception of file system writes or redirection to a RAM- the new working directory and to the application package
disk for sandbox execution should only be carried out file of newly installed apps can be passed to the antivirus
by trusted, well-controlled software. Hence, possible ap- software for scanning. If the monitoring is performed
proaches, e.g., chroot-based or with interception of any by the antivirus software itself, it needs to extract this
potentially harmful writing activity to the file system, to the information from the package database on its own. While
network interface, or to other interfaces, ought to be imple- the working directory itself is not included in the package
mented by the antivirus interface itself and not by antivirus database, it may be derived from the package name.
software. A feasible implementation for binaries would be
a safe and controlled execution of the strings, strace,
and ltrace utilities in a chroot environment or without Intents upon App Installation When a new pack-
any write access to network interfaces or the file system for age is installed, the Android system broadcasts a
the file to be examined. Java app execution can also be con- PACKAGE ADDED Intent which contains the newly in-
ducted in a Dalvik VM instance with blocked write access stalled app’s package name. This way antivirus software
and an attached debugger. can be informed of changes to the package database with-
out having to manually monitor it. Upon receiciving of this
intent the package database can be read to identify the new
4.2.4 Offset/Seek Access app’s package file’s path and the working directory. The
path of those can then be passed to the file operation meth-
Some desktop AV products perform certain operations at ods offered by the antivirus interface to perform malware
offsets inside the files for quick signature matching. This detection techniques on the newly added files and directo-
operation should also be offered to provide for the afore- ries. Furthermore, the event of a new package being added
mentioned operations, such as regular expression matching can also be used by the antivirus interface itself to place new
and hash calculation between start and end offsets. inotify handles to monitor the file system.Monitoring of the File System Monitoring of the whole options and additions arise which can optimize the perfor-
file system cannot be accomplished without major efforts mance of the interface and thus of antivirus apps using this
and complexity. However, single directories can be mon- interface. Other matters of interest include data and espe-
itored by means of the inotify interface. As described cially file system path privacy, the limited possibilities for
above, it automatically notifies programs if changes to file action after malware detection, and related work. All of
system objects occur. inotify can be applied at different these will be discussed in the following.
levels. For example, a inotify handle can be placed on
the /data/app and /data/data directories to monitor 5.1 File Content Disclosure
for new app installations. To monitor single app activity
more closely, inotify handles can also be placed to all Regular expressions might be misused to infer knowl-
working directories of apps (in /data/data/[package edge about the contents of files by incremental probe
name]) and their subdirectories. If such an inotify han- construction. Our approach at protecting the interface
dle notifies the antivirus interface of any changes, the an- from rogue apps by only granting previously checked and
tivirus interface sends an Intent containing one or multiple whitelisted legit antivirus apps will significantly reduce the
paths or aliases to the antivirus app. The antivirus app can risk of apps misusing the interface in such a away. Alterna-
then perform its operations. This approach, if used on sub- tively, approaches based on secure multi-party computation
directories of working directories too, allows for close ob- that prohibit the disclosure of file contents may be used [14].
servation of file system activity by any user-installed app.
To ensure full monitoring of the working directories of 5.2 Aliases for Addressing
all apps, if an inotify handle notifies the antivirus in-
terface (and subsequently, the antivirus app) of a newly We proposed aliases for input and output of the direc-
added directory, the antivirus interface can again place an tory listing and file system traversal mechanism. For this
inotify handle on the newly added directory. mechanism to work, the antivirus system needs to be able
to translate aliases back into file system paths. Different op-
4.4 Securing Access to the Interface tions exist:
(1) The antivirus interface maintains a database of all file
Given the potentially widespread access to a device’s file
system objects and their related hashes. We discourage this
system, the interface needs to be adequately secured. Plac-
option, as it requires file system monitoring and a lot of re-
ing the decision solely into the user’s hands by granting an
sources.
Android permission at installation time is discouraged by
(2) Dynamic calculation of hashes and file system neigh-
the authors. Instead, additionally to using a typical permis-
bours (including parents): For the latest directory listing re-
sion, runtime signature checks can be performed by the API
quested by an antivirus app, the antivirus interface calcu-
using a whitelist approach. To this end, the framework’s
lates and stores the hashes of all file system objects which
PackageManager.getPackageInfo() method us-
have been returned by the listing function. Also, it stores
ing the PackageManager.GET SIGNATURES flag can
the hash of the direct parent to allow traversal up in the
be used. As the number of AV products on the market is
file system hierarchy. This eliminates the need for file sys-
very limited – 41 were tested by AV-Test [2] – , it is a feasi-
tem monitoring, as all hashes are calculated dynamically,
ble effort for Google (or a device vendor adding this inter-
and requires only few resources. Arbitrary aliases, however
face to their Android distributions) to maintain a signature
cannot be passed to the antivirus interface, for example for
whitelist matching the signing certificates of the major AV
specific single files and directories. Still, commonly this
vendors. This whitelist can be updated over the Internet.
feature would be requested by the user, who would enter a
Assuming that no malware has already gained root access
file path instead of an alias.
and transport of the whitelist is correctly protected, tamper-
(3) Trapdoor functions: Trapdoor functions (f (path, t) −→
ing will not be possible. The advantage of this dynamically
alias, f 0 (alias, t) −→ path) are two-way functions which
updated whitelist is that Google or a device vendor is in
map an input value to an output value and vice versa, given
control of these privileged apps. Checks can be performed
a trapdoor parameter. Only a party in possession of the
to prevent malicious apps from using the AV interface.
trapdoor parameter may compute the functions correctly.
The antivirus interface may use such a function to translate
5 Discussion between paths and aliases. Keeping the trapdoor parame-
We have described above the basic mechanisms which ter a secret from antivirus software, data privacy is ensured
have to be offered by an antivirus interface to carry out mal- completely. Antivirus software is only presented with the
ware recognition techniques using signatures and heuristics, aliases. Also, this allows for the passing of arbitrary aliases
to traverse the file system, and to monitor important parts of to the antivirus interface, which is not possible with option
the file system. Regarding implementation, several issues, (2). A possible trapdoor function, for example, can be RSA.5.3 File System Access Backend of them, however, are not suitable for deployment on de-
vices due to very high requirements in memory and com-
The antivirus interface itself needs to be granted ac-
puting resources.
cess to the whole file system, or to specified parts of it
which should be scanned, e.g., package file directories 5.6 Post-Detection
(/data/app) and working directories (/data/data).
Such access is required to translate real file system paths This paper has described different components of an in-
to aliases and to allow for operations on file system objects terface for malware recognition for the Android platform.
to be provided to the antivirus software. Removal of malicious files has not been part of the de-
To allow for such access, the interface can be assigned scribed interface. Removal practice should be discussed
a permanent, hard-coded user ID with corresponding capa- separately, as several different options and problems arise.
bilities, i.e., read-only access to the whole or parts of the Introducing the possibility to remove arbitrary files would
file system. In this case, the interface would need its own violate Android’s security architecture. Also, antivirus soft-
process. Alternatively, legitimate antivirus apps can receive ware equipped with such capabilities would become a very
the predefined user ID and then call the interface’s meth- valuable target for manipulation and attack. Furthermore,
ods. Read-only access to the whole file system or to specific system instability may occur when single files can be re-
portions like working directories and all subdirectories can moved by third-party software oblivious to file dependen-
be granted using access control lists, as defined in POSIX- cies. If malicious files are found in an app’s working di-
1003.1e, which are supported by the Linux kernel [11, 16]. rectory, the user may be informed of the apps potentially
malicious behavior and be prompted to uninstall it. This is
5.4 Efficiency also the predominant current practice.
To increase efficiency, the functionality of the antivirus 5.7 Related Work
interface can be partly parallelized and automated. In-
stead of playing an intermediary role for antivirus software, In Android 4.2, Google introduced a reputation-based
which traverses the file system through information pro- system for notifying users of possibly malicious apps in-
vided by the interface and which issues pattern matching stalled on Android devices. However, analysis suggests that
commands for one file at a time, more functionality can its warnings are primarily based on SHA1 hashes and pack-
be shifted to the interface itself. For example, as in our age names. In general, there is much room for improve-
approach the signatures are patterns for regular expression ment [12]. In the beginning of 2012, Google also put their
matching, the interface could be provided with the whole Bouncer into operation, which conducts dynamic heuristic
signature database at the start of a scan in a predefined for- malware recognition for new app submissions to Google
mat. The interface, which would become more of a sys- Play (formerly the Android Market). However, Bouncer has
tem service, can then traverse the file system on its own, been successfully compromised itself [19]. These two sys-
also eliminating the need for aliases. Also, the signature tems stress the importance assigned to malware recognition
database can be cached, instead of passing signatures every by Google. Other practical analysis and detection systems
time when processing a file. This way antivirus software include Mobile-Sandbox, to be presented at SAC’13 and al-
would be reduced to supplying the signature database at the ready in operation at mobilesandbox.org, AASandbox [4],
start for signature-based and static heuristic detection. and App-Ray developed by Fraunhofer AISEC [10]. Parts
of the techniques described in these publications and used
5.5 Dynamic Heuristics in the aforementioned systems can also be implemented as
additions to our antivirus interface presented in this paper.
While for signature and static heuristics recognition However, these systems are deployed as remote services.
antivirus software can be reduced to supplying pattern Our approach addresses effective on-device malware recog-
databases, dynamic heuristics usually require more com- nition and dramatically increases effectiveness of on-device
plex data structures and analysis techniques. As argued malware recognition.
in Section 4.2.3, a multitude of problems emerges, in-
cluding implementation difficulties and system security, 6 Conclusion
as demonstrated by attacks against Google’s Bouncer ser-
vice [19]. Different approaches for implementation exist, Due to current platform limitations, antivirus software
such as a chroot environment, emulation, or intercepting on Android is not very effective. It is oblivious to activi-
write access to the file system or network interfaces when ties in apps’ working directories and to dynamically down-
running tools such as strings, strace and ltrace. loaded malicious files. However, as malware sample and
Other researches have already developed several dynamic family numbers increase and device manufacturers are re-
heuristics-based analysis systems for Android apps. Most luctant about supplying security updates, effective malwaredetection techniques gain importance. This is also shown by 12th USENIX Security Symposium, SSYM’03, Berkeley,
efforts of Google by introducing a reputation-based warning CA, USA, 2003. USENIX Association.
system for potentially malicious apps in Android 4.2. This [7] W. Enck, M. Ongtang, and P. McDaniel. Understanding an-
adds another layer of security after Google’s Bouncer ser- droid security. IEEE Security & Privacy, 7(1):50–57, Jan.–
Feb. 2009.
vice, which may be circumvented by dynamic code fetching
[8] R. Fedler, C. Banse, C. Krauß, and V. Fusenig. Android OS
techniques, or may even be attacked directly [19]. security: Risks and limitations. Technical report, Fraunhofer
The main contribution by this paper is the possibility for AISEC, May 2012.
antivirus software to scan arbitrary files on a device, with- [9] R. Fedler, J. Schütte, and M. Kulicke. On the effectiveness
out violating Android’s security architecture. To this end, of malware protection on Android. Technical report, Fraun-
our interface acts as a proxy service. Arbitrary file system hofer AISEC, April 2013.
objects can be traversed and scanned using signature and [10] Fraunhofer AISEC. App-Ray. http://app-ray.de/.
heuristic approaches. File system portions can also be mon- [11] A. Grünbacher. POSIX access control lists on Linux. In
itored. This applies especially to apps’ working directo- Proceedings of the FREENIX Track: 2003 USENIX Annual
ries. Consequently, apps can no longer download malicious Technical Conference. USENIX Association, June 2003.
[12] X. Jiang. An Evaluation of the Application (”App”)
files at runtime and execute them without antivirus software
Verification Service in Android 4.2, December 2012.
noticing. Access to our interface is restricted to apps which http://www.cs.ncsu.edu/faculty/jiang/appverify/.
are trusted by Google using a whitelist approach. [13] X. Jiang. New RootSmart Android Malware Uti-
The antivirus interface designed in this paper enables lizes the GingerBreak Root Exploit, February 3, 2012.
Android antivirus apps to deploy techniques similar to those http://www.csc.ncsu.edu/faculty/jiang/RootSmart/.
of desktop products not only on package files and small file [14] F. Kerschbaum. Practical private regular expression match-
system parts, but on a whole device. The increase in effec- ing. In Security and Privacy in Dynamic Environments,
tiveness is significant, as up until now package names and pages 461–470. Springer, 2006.
[15] E. Konstantinou and S. Wolthusen. Metamor-
app installation package files were the primary criteria for
phic virus: Analysis and detection. Technical
recognition of malware installed on devices.
report, Information Security Group at Royal Hol-
We consider signature and static heuristics-based recog- loway, University of London, 2009. Available at:
nition for potentially arbitrary file system objects a valu- http://media.techtarget.com/searchSecurityUK/downloads/
able addition to Android device security. Antivirus soft- RH5 Evgenios.pdf.
ware with said capabilities would be an additional layer of [16] Linux manual page. acl(5). Available at:
security for Android devices, improving the level of pro- http://linux.die.net/man/5/acl.
tection offered by antivirus software on Android by far. Re- [17] Linux manual page. inotify(7). Avail-
search into on-device dynamic heuristics and post-detection able at: https://www.kernel.org/doc/man-
courses of action will be part of our future work. pages/online/pages/man7/inotify.7.html.
[18] H. Lockheimer. Android and security, February
2012. http://googlemobile.blogspot.com/2012/02/android-
References and-security.html.
[1] Android Open Source Project. Android Security Overview, [19] J. Oberheide and C. Miller. Dissecting the An-
October 2012. http://source.android.com/tech/security/. droid Bouncer. In SummerCon ’12, June 2012.
[2] AV-Test. Test Report: Anti-Malware solutions for An- http://jon.oberheide.org/files/summercon12-bouncer.pdf.
droid. Technical report, March 2012. http://www.av- [20] V. Rastogi, Y. Chen, and X. Jiang. Droidchameleon: eval-
test.org/fileadmin/pdf/avtest 2012-02 android anti- uating android anti-malware against transformation attacks.
malware report english.pdf. In Proceedings of the 8th ACM SIGSAC symposium on Infor-
[3] D. Bilar. Opcodes as predictor for malware. In- mation, computer and communications security, pages 329–
ternational Journal of Electronic Security and Dig- 334. ACM, 2013.
ital Forensics, 1:156–168, 2007. Available at: [21] A. Shabtai, Y. Fledel, U. Kanonov, Y. Elovici, S. Dolev, and
http://inderscience.metapress.com/content/N760240L16832162. C. Glezer. Google android: A comprehensive security as-
[4] T. Bläsing, L. Batyuk, A.-D. Schmidt, S. Camtepe, and sessment. Security Privacy, IEEE, 8(2):35–44, March–April
S. Albayrak. An android application sandbox system for 2010.
suspicious software detection. In 5th International Con- [22] Y. Zhou and X. Jiang. Dissecting android malware: Charac-
ference on Malicious and Unwanted Software (MALWARE), terization and evolution. In 2012 IEEE Symposium on Secu-
pages 55–62, Oct. 2010. rity and Privacy (SP), pages 95–109, May 2012.
[5] J. Burns. Exploratory Android surgery (talk slides). In [23] Y. Zhou, Z. Wang, W. Zhou, and X. Jiang. Hey, you, get
Black Hat Technical Security Conference USA, May 2009. off of my market: Detecting malicious apps in official and
Available at: https://www.blackhat.com/html/bh-usa-09/bh- alternative android markets. In Proceedings of the 19th Net-
usa-09-archives.html. work and Distributed System Security Symposium, February
[6] M. Christodorescu and S. Jha. Static analysis of executa- 2012.
bles to detect malicious patterns. In Proceedings of theYou can also read
