going nave: using a large-scale analysis of android apps ... · android security mechanisms: ......
TRANSCRIPT
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