An Android Application Sandbox System for Suspicious Software Detection


of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
An Android Application Sandbox System for Suspicious Software Detection Thomas Bl¨ sing, Leonid Batyuk, Aubrey-Derrick Schmidt, a Seyit Ahmet Camtepe, and Sahin Albayrak Technische Universit¨ t Berlin - DAI-Labor a {thomas.blaesing, leonid.batyuk,} {ahmet.camtepe, sahin.albayrak} Abstract Smartphones are steadily gaining popularity, creating new application areas as their capabilities increase in terms of computational power, sensors and communication. Em
  An Android Application Sandbox System for Suspicious Software Detection Thomas Bl¨asing, Leonid Batyuk, Aubrey-Derrick Schmidt,Seyit Ahmet Camtepe, and Sahin Albayrak Technische Universit¨at Berlin - DAI-Labor { thomas.blaesing, leonid.batyuk, } { ahmet.camtepe, sahin.albayrak  } Abstract Smartphones are steadily gaining popularity, creatingnew application areas as their capabilities increase interms of computationalpower, sensors and communication. Emerging new features of mobile devices give opportunityto new threats. Android is one of the newer operating sys-tems targeting smartphones. While being based on a Linuxkernel, Android has unique properties and specific limita-tions due to its mobile nature. This makes it harder to de-tect and react upon malware attacks if using conventionaltechniques. In this paper, we propose an Android Application Sand-box (AASandbox) which is able to perform both static and dynamicanalysisonAndroidprogramsto automaticallyde-tect suspicious applications. Static analysis scans the soft-ware for malicious patterns without installing it. Dynamicanalysis executes the application in a fully isolated envi-ronment, i.e. sandbox  , which intervenes and logs low-levelinteractions with the system for further analysis. Both thesandbox and the detection algorithms can be deployed  inthe cloud  , providing a fast and distributed detection of sus- picioussoftware in a mobilesoftware store akin to Google’s Android Market. Additionally, AASandboxmight be used toimprove the efficiency of classical anti-virus applicationsavailable for the Android operating system. 1 Introduction Anti-virus research is an ongoing process of identify-ing and analysing new and unknown malware for extract-ing possible detection schemes that can be used within anti-virus software. A virus scanner [33] can block viruses,worms, and Trojan horses from infecting the often realtime monitored system. Although behavioural detection ismostly included in anti-virus software, most malware is de-tected by scanning for and finding a certain patterns, alsocalled signatures. Therefore, the malware has to be knownby the scanner through a signature database, otherwise itis not able to detect and remove it. For generating thesesignatures, malware needs to be analysed for identifyingsignificant and meaningful patterns that should be uniqueto the malware and its relatives 1 . But not only signature-generation requires analysis; in order to disinfect a system,the behaviourof the malware needs to be understoodfor be-ing able to undo critical changes. For doing so, sandboxescan be used, which guarantees an almost realistic execu-tion of suspicious binaries in an isolated environment. Suchsandboxes are known in the domain of stationary comput-ers, e.g. CWSandbox [34] or Java sandboxes [12], but es-pecially smartphone platforms lack such kind of analysingsoftware 2 . This raises concerns since smartphones have al-ready faced a wave of malware [31, 28] and it can be ex-pected that new malware will emergefor popularplatforms,like iPhone 3 or Android 4 . In this case, analyzing capabili-ties are left to a few people within anti-virus companies.This would not be that concerning but Oberheide et al. [23]showed that the average time for receiving a signature for anew malwareis about48days. This in turnmeans that userswith infected system need to wait 48 days until they have achance to disinfect it, leaving the window of opportunityvery wide open for new malware.Therefore,we presentan approachhowto realizea sand-box for Android-based applications. We preferred Androidover iPhone since its source code is set open source allow-ing us to implement modifications even on system level of the operating system. Our sandbox is capable of perform-ing static and dynamic analysis. In the static part, the sand-box decompresses installation files and disassembles corre-sponding executables. This can be used for cheap and fastpre-checks that might already indicate malicious code frag-mentsandcharacteristics. In thedynamicpart, we makeuse 1 malware families contain malware that share similar malicious codefragments 2 anti-virus vendor internal tools are not published 3 4 55978-1-4244-9356-2/10/$26.00c  2010 IEEE  of the Android emulator which is normally used for testingand debugging ordinary Android applications. InvestigatedApplications are installed to the emulated and isolated en-vironment. After that, applications are executed and can beused within the sandbox for performing behavioural analy-sis. For improving the dynamic analysis process, the possi-bility of automatedgenerationof user inputs is investigated.Since these analyses requires extensive resource capabili-ties, our system is intended to be run as a cloud service.Software distributors, like the Android Market or the App-Store, can run this analyses on each submitted applicationor users, in turn, can upload suspicious applications to theirconvenience.This work is structured as follows. Section 2 givesmore insights into the field of Smartphone Security. InSection 2.2, we describe common analysis methodologiesused to investigate malicious software. In Section 3, ourapproach in creating such a sandbox is presented. Sec-tion 4 presents possible analysing procedures that can beperformed in our sandbox. In Section 6, we conclude. 2 Related Work In the following section, we give a short introduction tothe field of mobile malware research, and an overview onstatic and dynamicmalware detectiontechniques, includingsandboxing. 2.1 Smartphone Security In developed countries, mobile phones often outnumberpotential subscribers. For example, in Germany over 80million handsets are spread over a total of approximately82 million residents [27]. According to [11], the figures inother countries are similar, and the share of smartphones isincreasing. While manyphonesarebeingprimarilyusedformakingcalls and sendingtext messages, browsingthe inter-net and using third-party applications gained a significantshare in mobile device usage. This trend clearly requiresa deeper look at the security aspects of mobile platforms,especially those which allow internet usage along with in-stalling third-party applications. These are commonly re-ferred to as smartphones .In order to provide most versatility and flexibility to theuser,smartphonesrunsophisticatedoperatingsystems com-parable to those of desktop PCs. Manufacturers providede-velopers with tools to create and distribute custom applica-tions. Due to high complexity of mobile device software,security threats emerge [14], comparable to the those whicha conventional PC is exposed to. Nevertheless, smartphonesecurity has its own specifics [31]. A smartphone is tiedto a mobile network infrastructure, including its billing sys-tem, providingan attacker with a means of immediate com-mercial exploitation, making identity theft possible, and al-lowingforDenial-of-Serviceattacks againstthe(potentiallyfragile) wireless network [4]. Additionally, privacy issuesarise since a smartphone can deliver a lot of delicate in-formation about its user straight out of its sensors, such aslocation, microphone, camera, etc.Since smartphones are a viable target to attackers, suf-ficient defence mechanisms must be introduced. However,this is a hard task, partly due to limitations of mobile hard-ware which is not capable of running a full blown mal-ware detection suite in the background. Another reasonis, according to [31], that this research field gained insuf-ficient attention, especially when compared to conventionaldesktop- and server-based malware detection.Only a few good works cover security issues of mobileplatforms. Most authors focus on the attack mechanisms.Collin Mulliner et. al. [19, 18, 20, 21] developed severalsmartphone exploits, both on Windows Mobile and Sym-bianOS. Racic et al. [24] discovered an MMS vulnerabilitywhich allows an attacker to drain the battery of the victim’sphone. Becher et. al. [1] created a worm running on aversion of Windows Mobile.However,despite the fact that Androidis a youngmobileOS if compared to Apple’s iOS or Nokia’s Symbian, sev-eral publications discuss Android-specific security mech-anisms, involving overall security assessment of the plat-form [5, 31], malware detection [29], application permis-sion analysis [8], and kernel hardening [32]. This amountof attention to one particular mobile platform clearly indi-cates the emerging need in solid mechanisms for securityanalysis on Android. 2.2 Static Software Analysis vs. Sandbox-ing Techniques For malware detection, a detailed knowledge of applica-tion’s characteristics is essential, which may be obtained byvariousmeans. Accordingto [2], two commonpractices ex-ist - static and dynamic analysis of software. Both have ad-vantages and disadvantages [17], and numerous approachesto both static and dynamic analysis paradigms exist.Static analysis involves various binary forensic tech-niques,includingdecompilation,decryption,patternmatch-ing [33] and static system call analysis [30]. All of thesetechniques have in common that the (potentially malicious)software is not being executed. Here, a common approachis filtering binaries by malicious patterns, called signatures .Even nowadays, many anti-virus software suites base onthis approach. Due to its nature, static analysis has an ad-vantage of being fast and relatively simple [17]. Its pri-mary disadvantage is that malicious code patterns have tobeknown inadvance ,makingitimpossibletoautomaticallydetect new malwareor malicious polymorphiccodewithout 56 2010 5th International Conference on Malicious and Unwanted Software  an intervention of a human expert.A set of techniques, which involve running an appli-cation in a controlled environment and monitoring its be-haviour, are known as dynamic analysis . Various heuris-tics have been used to best capture and analyse dynamicbehaviour of applications, such as monitoring file changes,networkactivity, processes and threads [33] and system calltracing [9], on which we focus in our work. Since soft-ware is being executed and kept alive for a longer time toobtain its runtime characteristics, it is obvious that dynamicanalysis techniquesare computationallymore complexthanstatic analysis.A common approach to dynamic software analysis is sandboxing . A sandbox can be defined as “an environmentin which the actions of a process are restricted according toa security policy”[3]. In practice, this means that a sandboxis an instance of the target OS, which is isolated in a waythat prevents malware from performing harmful actions.A sandbox’ security policy may vary, depending on theactual use case. The policy may be defined in a defensiveway, causing the process to be stopped at a particular pointin order to be examined - or even aborted to prevent po-tential damage to the system. Another option is monitor-ing and recording all system activity while the applicationis running, and processing the gathered information after-wards. This approach is especially useful for monitoringof unknown software and classifying it, e.g. by identifyingabnormal system states and analysing their cause [22, 13].Several designs and implementations of applicationsandboxes exist, such as the widely used CWSandbox [34].Existing sandboxes differ in the targeted platform, and theway policy enforcement is performed. User space sandboxsystems rather inject code into system libraries in order togain control over the APIs which are used by most appli-cations, or run software samples through a debugger, e.g.ADSandbox [6]. User space sandboxes can be detected bymalware, which, in turn, would simulate normal behaviourin order to remain undetected [25]. Kernel space sand-boxes try to overcome this problem by taking a low-levelapproach of monitoring raw system calls inside the kernel .This minimizes the chance of the sandboxbeing recognizedby malware, but is harder to implement and produces largeamounts of highly complex data. However, even kernel-level root-kit-based sandboxes can possibly be detected, asshown in [15, 7, 10].Unfortunately, the majority of existing sandbox imple-mentationstargetdesktopandserveroperatingsystems, dueto theirheterogeneityandwide deployment. Therehas beenvery little to no research on sandboxes targeting mobile en-vironments such as iOS or Android. Our main contributiontries to fill this gap and providea robust set of tools for mal-ware analysis on Android, including polymorphic virusesand new threats. 3 Android Application Sandbox Sandboxes are often located within kernel space sinceaccess to critical parts of the OS can be realized. The kernelis a very essential part of a system because it acts as bridgebetween hardware and software.One approach of sandbox systems is to monitor systemand library calls including their arguments. This is oftendone trough system call redirecting, also known as systemcall hijacking [35]. System calls, short system calls, arefunction invocations made from user space into the kernelin order to request some services or resources from the op-erating system [16]. For understanding how system callscan be hijacked, we will first explain how they are invokedin general. Figure 2 shows an examplefor the read() sys-tem call on a Linux based system. In turn, Figure 1 showsthe same example from Figure 2 but here the system call isfinally redirected.For being capable to analyze potential harmful applica-tions for the Android platform our system realizes systemand library call monitoring. Android uses a modified Linuxbasis to host a Java-based middleware running the user ap-plications. This implies that calls should not be monitoredon Java level since other calls being made by native Linuxapplication might get lost. One might argue that only Javauser application space is relevant for malware detection butSchmidt et al. [31] showed that it is possible to place piggy-bag Linux malware into Android systems. Due to this na-ture, calls are monitored on the lowest level possible. Foraccomplishing this task, we have implemented a loadablekernelmodule(LKM)beingplacedin theAndroidemulatorenvironment. This action needs special attention since theemulator tends to get very unstable from low-level changes,like we realized. Especially resource limitations and modi-fications of the Linux System by Google need to be treatedcarefully, which e.g. also had results on the amount of databeing traced. Currently, the system is not able to store argu-mentsofcalls sincethis takes toolongcausingthe systemtocrash. Additionally,Android bases on an ARM architectureleading to the problem that the ID of the calls are differentto the ones, e.g. from an Intel system.The LKM is intended to hijack all available system callstargeting for the ARM architecture since this is used forthe Android operating system. The following pseudo codeshows how the system calls are redirected: asmlinkage longnew_syscall(type1 param1, type2 param2, ...){retval = src_syscall(type1 param1, type2 param2, ...);PRINT_TO_LOG( syscall() , retval);return retval;} In the pseudo code you can see that each system callwhich is redirected firstly behaved like the srcinal system 2010 5th International Conference on Malicious and Unwanted Software 57  call to get the real return value. This is achieved since be-cause we have a policy that enforces only logging of thereactions of the system call. Then the ”PRINT TO LOG”prints out the gathered informations to the kernel log. Afterthis, the srcinal return value is returned to the kernel envi-ronment so that the context of the application can proceed.   u  s  e  r  s  p  a  c  e    k  e  r  n  e   l  s  p  a  c  e m ai  n (   )   _ _l  i   b  c  _r  e a d  (   )   s  y s t  em _ c  al  l   (   )   s  y s  _r  e a d  (   )  fi l   e s  y s t  em or n et w or k  or  d  evi   c  en o d  e EAX = __NR_readint 0x80check errorreturnSAVE_ALLcheck limit of EAXsyscall_table[EAX]()handle signalsRESTORE_ALLiretfile=fget(fd)checkfile opsand locks(file->f_op->read())fputs(file)returncheck destinationretrieve datacopy datareturn ......... pop_arguments ......... push_arguments _libc_read() Figure 2. Steps involved in performing a read() system call from user space (derivedfrom [26]). Each arrow in the figure repre-sents a jump in the instruction flow. 4 Static and Dynamic Analysis of AndroidApplications We propose a novel two-step analysis of Android appli-cations, consisting a full-fledged kernel-spacesandbox, anda fast static pre-check. AASandbox executes automatically,without any need for human interaction, and saves the logsof system calls and static analysis for further inspection.As an input, the AASandbox takes an Android applica-tionarchive,whichis packagedina *.apk file andis there-fore referred to as APK  . Applications are written in Javaand run in a custom Java virtual machine called Dalvik.Application source code is first compiled to standard Javabytecode, and then optimized and converted to Dalvik exe-cutable format for being interpreted Dalvik VM. Bytecodeis then packaged together with other application resources,including UI layouts, localization and a manifest file whichdefines the structure of the application. The structure of anAPK package is depicted in Figure 3.The AASandbox first performs a static pre-check, fol-lowed by a full-blown dynamic analysis. Android Emulator - install APK - execute APK - generateinput on APK  Logfile Dynamic Analysis APK  AndroidManifest.xml classes.dex Ressources pictureslayout.xml libraries (.so) ... Static Analysis Logfile - uncompress APK - disassemble APK - search forpatterns Figure 3. Design of the Android Applica-tionSandbox(AASandbox). AASandboxcon-sists of three main parts: the APK, staticanddynamicanalysis methods,andresultingdataset for further analysis. 4.1 Static Analysis of Android Applica-tions An Android application package (APK) is scanned forspecial patterns (e.g. Runtime.Exec()  ), which may be usedto classify the application. Our implementation of staticanalysis is lightweight enough to run on-device. However,since the dynamic analysis clearly requires emulation on amore powerful machine, we decided to run the static analy-sis off-line, too. Decompression: An Android application is a com-pressed (ZIP) bundle of files. When uncompressed, itscontent is split into three main parts in a directory named  APK-NAME  /unzipped/ : ã AndroidManifest.xml - an XML file holdingmeta information about the application, e.g. descrip-tions, security permissions, etc. ã classes.dex - a single file which holds the com-plete bytecode to be interpreted by Dalvik VM. ã res/ - a folder consisting of files defining the layout,language, etc. Getting the Starter Name: In this step, the main“launchable activity” is extracted from the manifest file. Itis used for identifying the application, but is also important 58 2010 5th International Conference on Malicious and Unwanted Software
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks