Going Nave: Using a Large-Scale Analysis of Android Apps ... · Android Security Mechanisms: ... • Malicious apps can use nave code to hide malicious ac)ons from stac analysis of

GoingNa)ve:UsingaLarge-ScaleAnalysisofAndroidAppstoCreateaPrac)calNa)ve-Code

SandboxingPolicyVitorAfonso,AntonioBianchi,YanickFratantonio,AdamDoupe,Mario

Polino,PaulodeGeus,ChristopherKruegel,andGiovanniVigna

SudeepNanjappaJayakumar

Agenda1.  WhatisSandboxing?2.  Introduc)on3.  SandboxSecurityRelevance4.  Contribu)ons5.  Background6.  SandboxingMechanisms7.  AnalysisInfrastructure8.  Transi)ons9.  Evalua)on&Insights10.  UsageofExternalLibraries11.  SecurityPolicyGenera)on12.  Limita)ons13.  RelatedWork14.  Conclusion

Introduc)on

•  Google’s Android opera)ng system currently enjoys the largest market share,currentlyat84.7%,ofallcurrentsmartphoneopera)ngsystems.

•  Theofficialappmarket forAndroid, theGooglePlayStore,hasaround1.4millionavailableapps.

•  Thena)vecodehasdirectaccesstothememoryoftherunningprocess,fromthisitcancompletelymodifyandchangethebehavioroftheJavacode.

•  Anextensiveanalysisofthena)vecodeusagein1.2millionAndroidapps.Firstthesta)canalysiswasdoneon446kappsusingna)vecodeandthenwiththedynamicanalysis.

WhatisSandboxing?

•  Sandbox isasecuritymechanismforsepara)ngrunningprograms. It isocenusedto execute untested or untrusted programs or code, possibly from unverified oruntrusted third par)es, suppliers, users or websites, without risking harm to thehostmachineoropera)ngsystem.

•  A sandbox is implemented by execu)ng the socware in a restricted opera)ngsystemenvironment, thus controlling the resources (for example, file descriptors,memory,filesystemspace,etc.)thataprocessmayuse.

SandboxSecurityRelevance•  Least-Privilege: The na)ve code of the app should have access only to what is

strictlyrequired,thusreducingthechancesthena)vecomponentcouldextensivelydamagethesystem.

•  Compartmentaliza5on:Thena)ve codeof the app should communicatewith theJavapartonlyusingspecific,limitedchannels,sothatthena)vecomponentcannotmodify, interactwith,orotherwisealtertheJavarun)meandcodeinunexpectedways.

•  Usability:The restric)onsenforcedby thesandboxmustnotpreventa significantpor)onofbenignappsfromfunc)oning.

•  Performance: The sandbox implementa)on must not impose a substan)alperformanceoverheadonapps

Contribu)ons

1.  Atoolisdevelopedtomonitortheexecu)onofthena)vecomponentsinandroidapplica)onsandthisisusedtostudythena)vecodeusageintheandroid.

2.  Thecollecteddataisanalyzedandac)onableinsightsareprovidedintohowthebenign apps use the na)ve code . Here the raw data ismade available for thecommunity.

3.  Finally the results are shown that elimina)ng permissions of na)ve code is notidealasthepolicywouldbreaktheappsinthedataset.

BackgroundTounderstandtheanalysis,itisnecessarytoreviewtheandroidsecuritymechanismson how na)ve code is used in android systems, what damage it can cause andpreviouslyproposedsandboxingmechanisms.•  AndroidSecurityMechanisms•  Na)veCode•  MaliciousCode•  Na)veCodeSandboxingmechanisms

SandboxingMechanismsAndroidSecurityMechanisms:•  WhenappsareinstalledonanAndroidphone,theyareassignedanewuser(UID)andgroups(GIDs)

basedonthepermissionsrequestedbytheappinitsmanifest.•  Appsmustdeclarethepermissionsneededinthemanifest,andatinstalla)on)metherequested

permissionsarepresentedtotheuser,whodecidestocon)nueorcanceltheinstalla)on.

Na5veCode:TherearefourwaysinwhichtheJavacodeofanAndroidappcanexecutena)vecode.1.  Execmethods2.  Loadmethods3.  Na)vemethods4.  Na)veac)vity

SandboxingMechanismscontd…MaliciousNa5vecode:•  Maliciousappscanusena)vecodetohidemaliciousac)onsfromsta)canalysisoftheJavapor)on

oftheapp.•  Akackers can directly call system calls to execute root exploits is by exploi)ng vulnerabili)es in

na)vecodeusedbybenignapps.

Na5veCodeSandboxingMechanisms:•  Severalapproacheshavebeenproposedtosandboxna)vecodeexecu)on.ForinstanceNa)veGuard

andRobusta.•  Theseapproachesmovetheexecu)onofna)vecodetoaseparateprocess.•  Twocomplementarygoalsareobtained:(1)thena)vecodecannottamperwiththeexecu)onofthe

Javacodeand(2)differentsecurityconstraintscanbeappliedtotheexecu)onofthena)vecode.

AnalysisInfrastructure

•  Design and implementa)on of a system that dynamically analyzes androidapplica)onsisusedtostudythena)vecode.

•  Alsothena)vecodesandboxingpolicyisgeneratedautoma)cally.•  Analysis consists an instrumented emulator which records all the events and

opera)onsexecutedwithin thena)vecodesuchas invokedsyscallsandna)vetojavacommunica)on.

•  Androidsystem4.3isusedfortheanalysis.

AnalysisInfrastructurecontd…Sta5cPrefiltering:•  Performingdynamicanalysisonalltheappswouldtakemore)me,sothesta)canalysiswasusedto

filtertheappswhichhadna)vemethod,na)veac)vity,havingacalltoexecmethod,havingacalltoloadmethodorhavinganELFfileinsidetheAPK.

•  Androguardtool isusedforthesta)canalysis,and iden)fythena)vemethods, itwassearchedinthedalvikbytecodewiththemodifiernamed“na)ve”.

•  Na)veac)vi)eswereiden)fiedbytwomethods:1.  LookingforaNa)veAc)vityinthemanifest.2.  LookingforclassesdeclaredintheDalvik

bytecodethatextendNa)veAc)vity.

AnalysisInfrastructurecontd…DynamicAnalysisSystem:•  Aceriden)fyingthewhichappsusethena)vecode,nowweneedtounderstandhowappsusethe

na)vecodeandforthisweusedynamicanalysistomonitorseveraltypesofac)onsperformedbytheapps.

•  Thisincludessystemcalls,JNIcalls,Bindertransac)ons,callstoExecmethods,loadingofthird-partylibraries,callstona)veac)vi)es’na)vecallbacks,andcallstona)vemethods.Thesystemcallswerecapturedusingthestracetool.

•  TomonitorJNIcalls,callstona)vemethods,andlibraryloading,themodifica)onto“libdvm”isdone.

•  Alsomonitortheamountofdataexchangedbetweenna)veandJavacodeisdonewheremeasuringtheamountofdatapassedinparametersofcallsfromna)vecodetoJavamethodsandviceversa,aswellasthesizeofthereturnedvalue.

•  Alsothesizeofthedataiscapturedtosetfieldsinjavaobjects.

Transi)ons

Transi)ons

Evalua)on&Insights•  Analysis is limited to 2minutes to keep it feasible andGoogleMonkey to s)mulate the appwith

random events, andwe then automa)cally generated a series of targeted events to s)mulate allac)vi)es,services,andbroadcastreceiversdefinedintheapplica)on.

•  During dynamic analysis, 33.6% (149,949) of the apps iden)fied by sta)c analysis as poten)allyhavingna)vecodeactuallyexecutedthena)vecode.

•  Alsotheyhavemanuallyanalyzedsta)cally&dynamically,20randomappsthatwerehavingna)vecode.8appswereunreachablefromthejavacodeandtheremainingappstoocomplextomanuallyinspect.

Na)vecodeBehavior

•  The ac)ons were split into those performed by sharedlibraries(includingthoseperformedduringlibraryloading,na)vemethods, and na)ve ac)vi)es) and those that arethe result of invoking custom, executable, and binariesthroughExecmethods.

•  Theyhavealsopresentedtheac)onsperformedusingstandardbinaries(i.e.,notcreatedbytheapp),butinthiscasebasedontheirnamesandparameters,insteadoflookingatthesystemcalls.

Na)vecodeBehavior

Na)vecodeBehavior•  Around3,669appsthatperformanac)onrequiringAndroidpermissionsfromna)vecode.•  Thebelowtablepresentsthetopfivemostpopularpermissionsused,howmanyappsusethem,and

howwedetecteditsuse.

•  wecandrawtwoimportantconclusions:1.  Ifthena)vecodeisseparatedinadifferentprocess,itisnecessarytogivesomepermissionstothe

na)vecode.2.  Thepermissionsofthena)vecodecanbemorestrict(lesspermissive)thanthepermissionsofthe

Javacode.

Java-Na)veCodeInterac)ons•  Forbekerunderstandingna)vecodefromtheJavacodeoftheapps,theyhavemeasured

thenumberofinterac)onspermillisecondbetweenJavaandna)vecode,i.e.,thenumberofcallstoJNIfunc)ons,callstona)vemethods,andBindertransac)ons.

•  Themeanof interac)onspermillisecondis0.00142,whereasthevariance is0.00003andthemaximumvalueis0.22.Na)veGuard’sperformanceevalua)onwiththeZlibbenchmarkshowsa34.36%run)meoverheadfor9.81interac)onspermillisecondand26.64%for3.96interac)onspermillisecond.

•  Addi)onally, theyhavemeasuredthenumberofbytesexchangedbetweentheJavacodeandna)vecodepersecond.Themeanofbytesexchangedpersecondis1,956.55(1.91KB/s)andthemaximumvalueis6,561,053.27(6.26MB/s).

•  Only11appsexchangedmorethan1MB/s.•  Theamountofdataexchangedbetweenjavaandna)vecodewouldnotincurasignificant

overhead.

UsageofthesuBinary

•  To have great control over the system, theusers need to perform roo)ng in order toperform few ac)ons such as uninstalling thepre-installedapps.

•  Someof theseappsuse the“-c”argumentofsu to specify a command to be executed asroot.

•  These ac)ons did not work properly duringdynamic analysis, so we cannot obtain moreinforma)onontheirbehavior.

JNICallsSta)s)csThistablepresentsthetypesofJNIfunc)onsthatwereusedbytheappsandhowmanyappsusedthem.

Thistablepresentswhatgroupsofmethodsfromthe framework were called, along with theamount of apps that called methods in eachgroup.

BinderTransac)ons

•  1.64%(2,457)oftheappsthatreachedna)vecode during dynamic analysis performedBindertransac)ons.

•  Themost common class remotely invoked bythisprocess is IServiceManager,whichcanbeusedtolistservices,addaservice,andgetanobjecttoaBinderinterface.

•  AllappsthatusedthisclassobtainedanobjecttoaBinderinterfaceandtwoappsalsouseditto list services. This data shows that usingBinder transac)ons from na)ve code is notcommon.

UsageofExternalLibraries16.6%(24,942)oftheappsthatreachedna)vecode,nostandardlibrarywasusedbyagreatnumberofapps.

Severalcustomlibrarieswereusedbymorethan7.5%oftheappsthatexecutedna)vecode.

SecurityPolicyGenera)on

•  Oneofthemainsteptolimitthepossibledamagethatna)vecodecandoistoisolateitfromtheJavacodeusingthena)vecodesandboxingmechanisms.

•  Hereweproposetousethedynamicanalysissystemtogeneratesecuritypolicieswhichmeansthenormalbehavioroftheapplica)ons.

•  Thisdynamicanalysishastwomodes:1.  Permissivemode:

Inthismodethesystemwouldlogandreporttheusageofunusualbehavior.2.  Enforcingmode:Thesystemwouldblocktheexecu)onofunusualbehaviorandstoptheapplica)on.

ImpactofSecurityPolicies

•  Tounderstandtheimpactofimplementa)ontheyanalyzedthepopularity(lowernumberofinstalla)ons)oftheappswhosebehaviorseenduringthedynamicanalysiswouldbeblocked.

•  Amongtheapplica)onsforwhichthepolicywouldblockatleastonebehaviorthathasbeenexecutedatrun)me,1.87%(51)ofthemhavemorethan1millioninstalla)ons.

ImpactofSecurityPoliciescontd..•  Theyiden)fiedthreetypesofsuspiciousac)vi)esamongtheseapps.1.   Ptrace:

280 appsusedptrace. 276of theseonly call ptrace to trace itselfwithout checking theresult.Developersdothisonpurposebecauseappcannotbetracedbyanotherprocess.2. ModifyingJavacode:

Iden)fied7appsthatmodifytheJavasec)onoftheappfromna)vecode.Alltheseappsperformthisac)onfromthelibrarylibAPKProtect.so. Itharderforreverseengineeringtoolstodecompiletheapp.3. Forkandino5fy: 57 apps were iden)fied that create a child process in na)ve code and use ino)fy tomonitortheapps’directory,inordertoiden)fywhentheyareuninstalled

Limita)ons1.  Thepoliciesthatthetoolgeneratemightnotbecompletetheymightblockmoreapplica)onswhen

adopted at large-scale, and the performance overhead of isola)ng na)ve code could be higher,usingamore-sophis)catedinstrumenta)ontoolcouldpossiblyimprovetheamountofna)vecodebehavior.Deployingtheautoma)callygeneratedpoliciesinana)vesandboxwithrepor)ngmodewouldhelptoobservethebehaviorsthatthepolicieswouldblock.

2.  Another limita)on is that theauthors approach restricts access topermissions fromna)ve code,butits)llallowsthena)vecodetoinvoke(some)Javamethods.Thiswoulddras)callyreducethepossibilityofintroducingmaliciousbehaviors.

3.  Theauthorsarenotcompletelycertainthattherearenomaliciousappsinthedatasetdependingonhowthemalwareworks.

4.  The tracing system slows down the execu)on of the apps by around 10 )mes. Therewere onlysmallsubsetofappsrunandanalyzedi.e177apps.

RelatedWorkLargeMeasurementStudies:–  Viennotetal.didalargemeasurementstudyon1,100,000applica)onscrawledfromtheGooglePlay

app store. Theymeasured the frequencywithwhichAndroid applica)onsmakeuseof na)ve codecomponents.

–  Lindorferetal:Theyanalyzed1,000,000apps,ofwhich40%aremalware.AuthorsusedAndrubis,apublicly-availableanalysissystemforAndroidappsthatcombinessta)canddynamicanalysis.

Applica5onAnalysisSystems:–  Severalsystemshavealreadybeenusedinthispaperforanalysis.

Protec5onSystems:–  Fedler et al: proposed a systemwhere a root t exploits by preven)ng apps from giving execu)on

permission for custom executable files and by introducing a permission related to the use of theSystemclass.

Na5veCodeIsola5on:–  Therearelotofsystemsinordertoisola)ngthena)vecodeKlinkoffetal.[26]focusontheisola)on

of .NET applica)ons, whereas Robusta [33] focuses on the isola)on of na)ve code used by Javaapplica)ons

Conclusion

•  Developers are allowed tomix Java code and na)ve code enables developers tofully harness the compu)ng power ofmobile devices but this feature doesmoreharmthandoinggood.

•  Na)ve code sandboxing is the e correct approach to properly limit its poten)allymaliciousside-effects.

•  This paper demonstrates an approach to automa)cally generate an effec)ve andprac)calna)vecodesandboxingpolicy.

Thank you