Android Security Overview and Safe Practices for Web-Based Android Applications

Android security overview and safe practices for web-based

Android applications Incalza Dario

@h4oxer

Contents

•  Introduction •  Overview Android platform •  Attack surfaces in Android •  Security in web-based applications

xda:devcon '14 -‐ Manchester -‐ Dario Incalza

Introduction

•  XDA – recognized Developer •  Student M. Sc. Computer science, majoring in

Development of Secure Software @ KU Leuven

•  Android enthusiast/developer •  Blogger (http://h4oxer.wordpress.com)


Introduction

•  Not technical •  Call for action •  Security is also your responsibility •  No need to be a security expert


The Android platform

•  Components in five main layers – Android applications – Android Framework – Dalvik Virtual Machine (since 4.4 ART) – User-space native code – The Linux kernel


The Android platform


Android Applications

•  Android Applications – Allows third party developers to add functionality –  Interaction through Android Framework API – Applications are signed with keys

•  Creates a trusted relationship between updates

– Application components •  AndroidManifest.xml, Intents, Activities, Broadcast

Receivers, Services and Content Providers


Android Framework

•  Interface for Android applications •  Allows developers to perform common tasks •  Standard and third-party libraries –  i.e. Apache HTTP and SAX XML Parser

•  Framework managers –  i.e. Activity Manager, View System, Package

Manager, etc.


The Dalvik Virtual Machine

•  Based on Java Virtual Machine •  Register-based <-> stack-based •  Pretty close to Java but not quite the same •  DEX- and O (ptimized) DEX-files •  Zygote – Shared core classes and libraries – Loader for Dalvik processes


User-Space Native Code •  Native code in operating system user-space •  Comprised of two primary groups –  Libraries:

•  Shared libs, access through JNI •  Vendor-specific <-> non-vendor-specific •  Bionic •  Interesting for security researchers

–  Core system services •  Init •  Radio Interface Layer (RIL) •  ADB


The Kernel

•  Linux Kernel but Android Fork •  Binder –  IPC mechanism – Client-server model – PID and UID identification for access control

•  Logger – Four buffers: main, system, radio, event – LogCat


The Android Platform: Conclusion

•  Very complex system •  Principle of least privilege •  Exploit on Android is a collection of

vulnerabilities –  i.e. ‘diaggetroot’ – HTC J Butterfly


Attack Surfaces in Android

•  Terminology –  Attack Vector: methods used to carry out an

attack –  Attack Surface: a target’s ‘open flanks’

•  Classification attack surfaces – Physical Adjacency – Local – Physical – Remote


Attack Surfaces in Android

•  Surface properties – Attack Vector – Privileges Gained – Memory Safety – Complexity

•  General Rule: as much privilege possible with as little investment as possible


Attack Surface – Physical Adjacency

•  Attacker in range of victim •  Wireless supported communication channels – GPS – Baseband – Bluetooth – Wi-Fi – NFC



•  Global Positioning System (GPS) – One-way communications mechanism – Accessible through android.location.* or Google

Play Services – End-user privacy not always respected – Location spoof attacks



•  Baseband – Communicate with mobile networks – Baseband firmware – Mostly Man-in-the-Middle (MITM) attacks

•  Set-up a base station with strong signal •  Rogue Base Station Attack

– Based on protocols •  Every protocol is an attack surface •  Resource intensive to exploit!!



•  Bluetooth – Rich attack surface – Based on profiles; +30 profiles! – Requires pairing

•  Numeric code •  Hard-coded codes => interesting!

– Possible Attacks: bluejacking, bluesnarfing, bluebugging



•  Wi-Fi – Rich attack surface – Similar attack surface as Bluetooth – Very extensive



•  NFC (Near Field Communication) –  Build on RFID –  Three main use cases

•  Tags •  ‘beam’ data •  Contactless payments

–  Successful attacks on NFC •  Charlie Miller – setup connections BT or Wi-Fi •  Georg Wicherski and Joshua J. Drake – browser attack •  MWR Labs – exploit file format parsing in Polaris Office


Attack Surface –Local

•  Ultimate goal: privileged code execution •  Android security architecture based on least

privilege •  Use code already running on device to gain

more privileges •  Interesting when rooting?



•  The File System – Unix based – Attack surfaces exposed via entries in fs – Exposed IPC functionality – Determining code behind an endpoint



•  System Calls – Kernel is responsible for handling system calls – Kernel handles malicious data in system call – Search for “SYSCALL_DEFINE” in kernel source

code



•  Binder – Unique for Android – Basis of Intents – Driver in kernel – Service in native code on top of Binder

=> Deeper attack surfaces => privilege escalation?



•  Other local attack surfaces – Shared memory – Baseband interface – Sockets


Attack Surface –Physical

•  Require physical touching •  Most people consider physical attacks

impossible to defend against



•  Dismantling devices – Disassembling device and attacking the very

hardware – Hardware not adequately protected – Attack surfaces:

•  Exposed serial ports •  Exposed JTAG debug ports

– Check Adam Outler on XDA TV!!



•  Android Debug Bridge (ADB) – USB debugging –  “Juice Jacking “ – Now authentication with RSA keypair


Attack Surface –Remote

•  Largest attack surface •  Can be devastating •  Holy grail for attacker



•  Browser Attacks – Browsers are complex systems – A lot of web technologies and protocols

•  All attack surfaces!!

– Drive-by attack = trick user to load url – MitM-attacks – Cross-site scripting (XSS) and Cross-site request

forgery (CSRF) – Same-Origin-Policy (SOP)



•  Other Attacks – Ad networks – Media and document processing – Google infrastructure – Malicious apps – third party app ecosystems


Security in web-based application

•  Webview component •  Webkit web browser engine •  Extensive use in hybrid applications •  Remote attack surface => security issues


Source: MWR Infosecurity


•  Disable Support for Plugins – Additional attack surfaces -> needed? –  webview.getSettings().setPluginsEnabled(false)

•  Disable File System Access – Access local resources – Enabled by default! –  webview.getSettings().setAllowFileAccess(false)

•  Disable Javascript –  webview.getSettings().setJavaScriptEnabled(false)



•  Webview issues –  is JS necessary ???? – Nothing against MitM => use crypto – Origin checking! – Only load 3rd party trusted content – Java-Javascript bridge is dangerous!!!!

•  SOP not enforced over bridge



•  Webview issues


Executing Java code in the context of your app!


•  Resource inspection –  Intercept pageloads – Check against whitelist of trusted parties – Override native methods in WebViewClient





•  Resource inspection – What about IFrames or content between script

tags or XmlHttpRequests? –  Not intercepted by shouldOverrideUrlLoading –  Override shouldInterceptRequest




A list of useful methods (http://xda-devcon.com/index.html) •  getHost – Gets the encoded host from the authority for the URI

•  xda-devcon.com •  getScheme – Gets the scheme of the URI

•  http •  getPath – Gets the decoded path

•  index.html



•  addJavaScriptInterface – Dangerous – SOP is not enforced for the bridge! –  IFrames => nightmare – Hybrid software stacks use this!

•  Apache Cordova •  Sencha Touch

– Fracking attacks => generic for all hybrid frameworks

Security in web-based application: Conclusion


– Difficult to get right – Pattern matching for whitelist of extreme

importance – Watch out for hybrid mobile apps – Consider the effort of developing native

Thanks!!


Q & A ?