Android Security Workshop

Android Security Workshop

OWASP Poland


Alexander Antukh

February 24, 2016


  1. Android security workshop OWASP Poland 24.02.2016

  2. Agenda  Android fundamentals  Application components security  Coffee

    break (free cookies )  OWASP top 10 mobile risks  Reverse engineering & malware analysis
  3. Android fundamentals Andrii Sygida OWASP Poland 24.02.2016

  4. Agenda • Android Architecture • Android security fundamentals • Android

    6.0 security release • Google security features
  5. Intro • Android is the world's most popular mobile platform.

    Features: • Multi-tasking • Widgets • Notifications • Voice Typing and Actions • Photos and video • Most widely used smartphone OS • Phones, tablets, Google TV and more
  6. Stats • There are 1.2 billion mobile users. By 2018

    that number with be 5 billion. • Mobile adoption is growing 8x faster than traditional web applications. • Mobile payments will exceed $90 Billion by 2017 Bugcrowd Cybersecurity Research 2015
  7. Android Architecture

  8. Linux Kernel • The architecture is based on the Linux

    ( started from 2.6) kernel. • This layer is core of android architecture. It provides service like power management, memory management, security etc. • It helps in software or hardware binding for better communication.
  9. Libraries • The next layer is the Android’s native libraries.

    • It is this layer that enables the device to handle different types of data. • The WebKit library is responsible for browser support, SQLite is for database, FreeType for font support, Media for playing and recording audio and video formats
  10. Android Runtime • Core libraries • Dalvik Virtual Machine •

    DVM vs JVM Differences • ART
  11. Dalvik VM • The software that runs the apps on

    Android devices • It's fast, even on weak CPUs • it will run on systems with little memory • it will run in an energy-efficient way • Provides application portability and runtime consistency • Runs optimized file format (.dex) and Dalvik bytecode • Java .class / .jar files converted to .dex at build time
  12. ART VS DVM • Android 4.4 – Experimental. From android

    5.0 - Default • Ahead-of-time (AOT) compilation • Improved garbage collection • Improved diagnostic detail in exceptions and crash reports
  13. Application Framework Activity Manager: Manages the activity life cycle of

    applications Content Providers: Manage the data sharing between applications Telephony Manager: Manages all voice calls. Location Manager: Location management, using GPS or cell tower Resource Manager: Manage the various types of resources we use in our Application
  14. Application Layer • SMS client app • Dialer • Web

    browser • Contact manager
  15. APK how it’s works

  16. Android Application Security • Android sandbox • Permission labels defined

    in AndroidManifest.xml • Signature • Install time security decisions • Android 6.0 Security release
  17. Android 6.0 • Runtime Permissions • Verified Boot • Hardware-Isolated

    Security • Fingerprints • SD Card Adoption • Clear Text Traffic • System Hardening • USB Access Control
  18. Defense layers

  19. Google Play 1 2 3 4 5 Require and validate

    Developer information Review Applications before distribution Permanently stop distribution Reduce attacker flexibility Remove applications after installation
  20. Apps from Unknown Sources By default, only Google Play and

    other pre-installed app stores are allowed to install apps The vast majority of installs come from Google Play
  21. Verify Apps Apps are verified prior to install Warn for

    or block Potentially Harmful Applications Over 10 million installs verified every day
  22. Verifying is on and visible when need

  23. Core security features to build secure applicaton • The Android

    Application Sandbox. • An application framework with robust implementations of common security functionality such as cryptography, permissions. • An encrypted file system that can be enabled to protect data on lost or stolen devices. • User-granted permissions to restrict access to system features and user data. • Application-defined permissions to control application data on a per-app basis.
  24. Thank you  Any questions?

  25. Links • • OReMr0BrDfHyfyPw/pub?start=false&loop=false&delayms=3000&slide=id.g1202bd8e5_0193 • •

    • • • • • • • • • • • • • • • • • dcd364cc95b4&v=qf1&b=&from_search=8 • •
  26. Application Components Security Alexander Antukh OWASP Poland 24.02.2016

  27. Android Application Security Often the app contains some sensitive data:

    • Passwords • Authentication tokens • Contacts • Communication records • IP addresses or domain names to sensitive services
  28. Android Application Security Global problems in securing the applications: •

    How sensitive data is stored – Isolation – Privilege separation • How sensitive data is transmitted – Extra-device communication – Inter-application communication – Inter-component communication
  29. Android Application Components Activities Services Content providers Broadcast receivers

  30. Android Application Components AndroidManifest.xml: defines in which way the app

    works and what kind of interaction between components and outer world is possible. Permissions are set there, too. • Activities – <activity> • Services – <service> • Content providers – <provider> • Broadcast receivers – <receiver>
  31. Android Manifest Sample manifest file: Note the following: • Permissions

    <uses-permission android:name="string"/> <permission android:protectionLevel="…" /> • Components and their attributes
  32. Android Manifest Protection levels: • dangerous – increased risk (directly

    affect users) • normal – minimal risk (default value) • signature – same certificate • signatureOrSystem – same certificate || app in Android system image
  33. Android Manifest • debuggable • enabled • exported • permission

    Activities Services Content providers Broadcast receivers Example components attributes:
  34. Intents An intent is a defined object used for messaging

    that is created and communicated to an intended application component. It includes all relevant information about calling application, desired application component and request actions/data Intent intent = new Intent(Intent.ACTION_VIEW); intent.setData(Uri.parse("")); String pack = ""; ComponentName comp = new ComponentName(pack, pack + ".BrowserActivity"); intent.setComponent(comp); startActivity(intent);
  35. Drozer Open source tool to interact with other applications through

    IPC - leading security assessment framework for Android. Manual on installation and usage
  36. Drozer The best thing about Drozer: you don’t need to

    write your apps to interact with other apps :) dz> run app.activity.start --action android.intent.action.VIEW --data-uri --component
  37. Drozer Is installed in a default package of AppUse with

    adb, so enough just „click-and-play”
  38. Activity components An Activity provides a screen with which users

    can interact in order to do something. Users can perform operations such as making a call, sending an SMS, etc. Example: login screen of your Facebook app. Activities
  39. Activity components attacks • If an activity can be triggered

    by other apps (by an attacker), it can be abused! • Launching by intents, it’s possible to achieve the following: – Modify data in background – Tricking the user – Leaking sensitive information Activities
  40. Activity components attacks • General hijacking scheme: • Results of

    an attack: – Malicious Activity could read the data in the Intent and then immediately relay it to a legitimate one – Spoofing the expected Activity’s user interface to steal user-supplied data (phishing) Activities
  41. Activity components attacks Activities • List and launch exported activities

    dz> run -a com.mwr.example.sieve Package: com.mwr.example.sieve com.mwr.example.sieve.FileSelectActivity com.mwr.example.sieve.MainLoginActivity com.mwr.example.sieve.PWList dz> run app.activity.start --component com.mwr.example.sieve com.mwr.example.sieve.PWList
  42. Activity components demo Activities

  43. Services A Service can perform long-running operations in the background

    and does not provide a user interface. Other components can bind to a Service, which lets the binder invoke methods that are declared in the target Service’s interface. Intents are used to start and bind to Services Example: playing music or downloading a file. Services
  44. Services attacks Although generally don’t seem dangerous, they could potentially

    perform sensitive operations. To attack a service one need interaction (it must be exported or respond/accept input from message formats like intents, files, or the network stack) Services
  45. Services attacks Typical attacks: Denial of Service and Information Leakage

    • Find exported services • Launch them one-by-one with logcat to check for sensitive info • Fire off intents and wait for it! Services
  46. Content providers A content provider presents data to external applications

    as one or more tables. In other words, content providers can be treated as interfaces that connect data in one process with code running in another process. Example: using content providers, any app can read SMS from inbuilt SMS app’s repository in our device. Content providers
  47. Content providers • What info can they hold? – User’s

    phone numbers – Passwords – SMS • And one of the main problems are again permissions! run --permission null Content providers
  48. Content providers attacks • Unrestricted access to app database –

    Just query it! * – run app.provider.query content://settings/secure • SQL injection • Path traversal * Other attack vectors on auth might include altering data e.g. by using app.provider.insert command Content providers dz> run scanner.provider.injection -a com.mwr.example.sieve
  49. Content providers attacks • Unrestricted access to app database Content

    providers dz> run scanner.provider.finduris -a com.mwr.example.sieve ... Accessible content URIs: content://com.mwr.example.sieve.DBContentProvider/Keys/ content://com.mwr.example.sieve.DBContentProvider/Passwords content://com.mwr.example.sieve.DBContentProvider/Passwords/ dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --vertical
  50. Content providers attacks • SQL injection Content providers dz> run

    app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --selection "'" unrecognized token: "')" (code 1): , while compiling: SELECT * FROM Passwords WHERE (') dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --projection "* FROM Key;--" | Password | pin | | thisismypassword | 9876 |
  51. Content providers attacks • Path traversal Content providers One interesting

    real-life example: dz> run content://com.mwr.example.sieve.FileBackupProvider/etc/hosts localhost dz> run content://com.mwr.example.sieve.FileBackupProvider/data/data/com.mwr.e xample.sie ve/databases/database.db /home/user/database.db Written 24576 bytes
  52. Content providers demo Content providers

  53. Broadcast receivers A broadcast receiver is a component that responds

    to system-wide broadcast announcements such as Battery Low, boot completed, headset plug etc. Though most of the broadcast receivers are originated by the system, applications can also announce broadcasts. Broadcast receivers
  54. Broadcast receivers • If receiver accepts broadcasts from untrusted sources,

    app is at risk Broadcast receivers
  55. Broadcast receivers attacks Typical fail: authorization! • Enumerate receivers •

    Determine how the receiver handles the action • Send intent and enjoy Broadcast receivers
  56. Broadcast receivers attacks <receiver android:name=".broadcastreceivers.SendSMSNowReceiver” android:label="Send SMS" > <intent-filter> <action

    android:name="org.owasp.goatdroid.fourgoats.SOCIAL_SMS" /> </intent-filter> </receiver> … <uses-permission android:name="android.permission.SEND_SMS" /> Sample manifest from GoatDroid: Broadcast receivers
  57. Broadcast receivers attacks public void onReceive(Context arg0, Intent arg1) {

    context = arg0; SmsManager sms = SmsManager.getDefault(); Bundle bundle = arg1.getExtras(); sms.sendTextMessage(bundle.getString("phoneNumber"), null, bundle.getString("message"), null, null); Utils.makeToast(context, Constants.TEXT_MESSAGE_SENT, Toast.LENGTH_LONG); } The following is the code that determines how the receiver handles the org.owasp.goatdroid.fourgoats.SOCIAL_SMS actions: Broadcast receivers
  58. Broadcast receivers attacks run app.broadcast.send --action org.owasp.goatdroid.fourgoats.SOCIAL_SMS --component org.owasp.goatdroid.fourgoats org.owasp.goatdroid.fourgoats.broadcastreceive

    rs.SendSMSNowReceiver --extra string phoneNumber 1234567890 --extra string message PWNED Broadcast receivers
  59. General defenses for App Components Applies for all abovementioned items:

    • Setting "android:exported" attribute to "false" (only this user ID as the current app will be able to access the activity) • Limiting access with custom permissions for an activity (RECEIVE_SMS and others)
  60. References • • • components/ •

    • • • • • • • • •
  61. Thank you! • For additional questions or just to stay

    in touch: @c0rdis.
  62. OWASP top 10 mobile risks Pawel Rzepa OWASP Poland 24.02.2016

  63. Important notes • The goal of this presentation is to

    provide you a basic knowledge about mobile risks and easy methodology to find those risks in your applications. • If you want to add anything important/interesting and related to the topic – feel free to interrupt me ;).
  64. What are we going to talk about…

  65. Before we start… the threat model

  66. M2 - Insecure data storage

  67. Insecure data storage – what it is? • Simple words

    definition: valuable pieces of data (e.g. passwords, cookies, personal information) are stored in the data-stores on the device in insecure (plain text or reversable encoding) format.
  68. Insecure data storage – what to look for? • Look

    for any sensitive information in: – SQLite databases (local) – XML Data Stores – Plain text configuration files – Cookie stores – SD Card
  69. Insecure data storage – how to find? • Install and

    run application for some time • Monitor changes in /sdcard before and after installing an application • Analyze package files on different stages: adb pull /data/data/<apk_package_name>
  70. Insecure data storage - demo

  71. Insecure data storage – real example • Outlook stored all

    attachements as unencrypted and world readable files on external storage.
  72. Insecure data storage - mitigations • Don’t store data unless

    it’s absolutely necessarry. • Use encryption for local storage (use method setStorageEncryption). • For databases consider using SQLcipher for Sqlite data encryption. • Ensure any shared preferences properties are NOT MODE_WORLD_READABLE.
  73. M3 - Insufficient transport layer protection

  74. Insufficient transport layer protection – what it is? • Simple

    words definition: application does NOT implement TLS or it does incorrectly.
  75. What do you mean „incorrectly”? • Insecure implementations are: –

    Using known weak ciphers / version (e.g. SSLv2/SSLv3, RC4) – Securing only part of the communication (e.g. only authentication) – Lack of certificate inspection
  76. Certificate inspection in web applications – chain of trust. •

    In web applications the validation of certificate is on the side of a browser. • It is done by a „chain of trust”. • But how a mobile app can know if it is communicating with a proper server?
  77. Cert Pinning - theory • Embedded in source code expected

    X509 certificate or public key. if (presented_cert == pinned_cert) Start_connection(); else Drop_connection();
  78. Cert Pinning - reality • Guys from Leibniz Universität Hannover

    tested 100 apps and… • 21 apps trust all certificates • 20 apps accept all hostnames • And in the end they asked developers why it happened… More:
  79. Insufficient transport layer protection- how to find? • Passive analysis

    with Wireshark/Burp (to check if all traffic is encrypted) • Use Mallodroid: ./ –f AppToCheck.apk –d ./javaout • Look for end point implementation flaws using SSLyze (or for public domain): sslyze --regular
  80. Insufficient transport layer protection- example

  81. Insufficient transport layer protection- few facts from reality • According

    to the FireEye research from July 17 2014, among 1000 most-downloaded free applications in the Google Play store: Source:
  82. Insufficient transport layer protection- mitigations • Any sensitive data MUST

    be transfered over TLS • How to do it properly? Follow the rules: n_Cheat_Sheet
  83. M4 - Unintended data leakage

  84. Unintended data leakage – what it is? • Simple word

    definition: OS/frameworks puts sensitive information in an insecure location in the device. • Important note: insecure data storage talks about developer conscious efforts to store data in insecure manner, while unintended data leakage refers to OS/framework specific quirks which can cause data leakages.
  85. Unintended data leakage – common leakage points • URL Caching

    • Copy/Paste buffer Caching • Logging • Analytics data sent to 3rd parties (e.g. ads sending GPS location)
  86. Unintended data leakage – how to find? • Extract data

    from leaking content providers using Drozer: dz> run app.provider.finduri <package_name> • Use logcat to verify what is being logged using ADB: adb logcat [output filter] • Use listener (Burp/Wireshark) to monitor what is being sent to 3rd parties. • Use Intent Sniffer to see if any confidential data is sent via Intents.
  87. Unintended data leakage - demo

  88. Unintended data leakage - mitigations • NEVER log any sensitive

    information (observe what you’re storing in crashlogs). • Disable copy/paste function for sensitive part of the application. • Disable debugging (android:debuggable="false").
  89. M5 - Poor Authorization and Authentication

  90. Poor Authorization and Authentication – what is it? • Simple

    words definition: if you’re able to bypass authentication and/or laverage your privileges then… your app has poor authorization and/or authentication.
  91. Poor Authorization and Authentication – how to find? • Try

    to bypass authentication by accessing exported activities using Drozer: dz> run app.activity.start –component <component_name> • Intercept traffic with Burp and modify parameter to login as other user/see unauthorized content (e.g. by manipulating device ID). • Test account lockout policy • Test strong password policy
  92. Poor Authorization and Authentication - demo

  93. Poor Authorization and Authentication – real example • A flaw

    in application can become an entry point to compromise an operating system. • For example a Viber app:
  94. And always remember to… • …stay reasonable when you’re going

    to follow advices from the Internet…
  95. Poor Authorization and Authentication - mitigations • Assume that client-side

    authorization and authentication controls can be bypassed - they must be re-enforced on the server-side whenever possible! • Persistent authentication (Remember Me) functionality implemented within mobile applications should never store a user’s password on the device. It should be optional and not be enabled by default.
  96. M6 - Broken Cryptography

  97. Broken Cryptography – what it is? • Simple words definition:

    using insecure implementation or implementing it in a insecure way. • Few reminders (yeah I know you know it…): – encoding != encryption – obfuscation != encryption
  98. Broken Cryptography – how to find? • Decompile the apk

    using dex2jar (or luyten for more verbose result) and review jar file in JD-GUI. • Look for decryption keys (in attacker-readable folder or hardcoded within binary). • Try to break encryption algorithm if an application uses custom encryption. • Look for usage of insecure and/or deprecated algorithms (e.g. RC4, MD4/5, SHA1 etc.).
  99. Broken Cryptography - example • Encrypted db is definitely a

    good idea…
  100. Broken Cryptography - example • …but not when you’re hardcoding

    passwords to decrypt it in code…
  101. Broken Cryptography – real example • NQ Vault

  102. Broken Cryptography - mitigations • Use known, strong cryptography implementations.

    • Do not hardcode keys/credentials/OAUTH tokens. • Do not store keys on a device. Use password based encryption instead.
  103. M7 - Client side injection

  104. Client side injection – what it is? • Simple words

    definition: malicious code can be provided as an input and executed by the application (on the client side). • The malicious code can come from: – Other application via intent/content provider – Shared file – Server response – Third party website
  105. Client side injection – what to inject? • SQL injection

    to local db • XSS/WebView injection • Directory traversal • Intent injection
  106. A new Android’s toy – the Intents • Android application

    can talk (Inter-Process- Communication) to any other component (e.g. other application, system service, running new activity etc.) via special objects called Intents. Intent i = new Intent(Intent.ACTION_VIEW,Uri.parse(„”)); Intent i = new Intent(android.provider.MediaStore.Action_IMAGE_CAPTURE);
  107. Client side injection – how to find? • SQL injections:

    dz> run scanner.provider.injection –a <package_name> • Data path traversal dz> run scanner.provider.traversal –a <package_name> • Intent injections dz> run app.package.manifest –a <package_name> dz> run –a <package_name> dz> run --permission null –a <package_name> dz> run intents.fuzzinozer --package_name <package_name> -- fuzzing_intent
  108. Client side injection – real example • The UniversalMDMClient (built-in

    application Samsung KNOX – a security feature to seperate personal and professional activities). • Crafted URI with „smdm://” prefix allows for remote installation of ANY application, while a user thinks he’s installing an update for UniversalMDMClient. • How it works in practice?
  109. Client side injection - mitigations • Always validate on a

    server side any user input! • For internal communication use only explicit Intents. • Avoid using Intent-filter. Even if the Activity has atribute „exported=false” another application can define the same filter and a system displays a dialog, so the user can pick which app to use.
  110. M9 - Improper session handling

  111. Improper session handling – what it is? • Simple words

    definition: if your session token can be guessed, retrieved by third party or never expires then you have a problem.
  112. Improper session handling – how to find? • Intercept requests

    with proxy (e.g. Burp) and verify if: – Verify if a session expires (copy a cookie and try to use it after 30 minutes) – Verify if a session is destroyed after authentication state changes (e.g. switching from any logged in user to another logged in user) – Verify if you are able to guess any other session (e.g. it’s easy to impersonate other user when application uses device ID as a session token).
  113. Improper session handling – few facts from reality • What

    we know is that „sessions have to expire”… • …but how long should it REALLY last? • According to experiment* the average application session (counted from opening an app to closing it) lasts… 71.56 seconds. * -
  114. Improper session handling - mitigations • Invalidate session on a

    server side. • Set session expiration time adjusted to your application. • Destroy all unused session tokens. • Use only high entropy, tested token generation resources.
  115. Thank you!

  116. References • • • • • • • • • aelc19qq6ernql5m2 • • • • • • • • • • • screen • •
  117. Reverse Engineering & Malware Analysis Daniel Ramirez OWASP Poland 24.02.2016

  118. Anatomy of an apk

  119. Getting our apk file • From the phone – APKOptic

    – Astro File Manager • Using ADB • Use APKpure
  120. Decompiling || Disassembling • Decompiling: – High Level – Java

    Code • Disassembling: – Low Level – Assembly Code • Why Disassembling and not Decompiling?
  121. Decompiling DEX JAR JAVA JAR DEX JAVA

  122. Decompiling-Dex2Jar • dex2jar – Converts Dalvik bytecode (DEX) to java

    bytecode (JAR) – Allows to use any existing Java decompiler with the resulting JAR file
  123. Decompiling – Java Decompilers • JD-GUI || Luyten – Closed

    source Java decompiler – Combined with dex2jar, you can use JD-GUI or Luyten to decompile Android applications • Both are Java decompilers but have different OUTPUT!
  124. JD-GUI

  125. Luyten

  126. None
  127. Disassembling DEX SMALI

  128. Disassembling • Apktool – Open source Java tool for reverse-engineering

    Android app – Transform binary Dalvik byte code(dex) into Smali source
  129. Signing apk • Using signapk.jar java -jar signapk.jar certificate.pem key.pk8

    your- app.apk your-app-signed.apk • Using AppUse
  130. Demo Time

  131. Demo Decompiling Luyten

  132. Demo Modify Smali Files

  133. Demo

  134. Lack of binary protection • At this point if you

    can read the source code of the application, modify the behavior of the application  doesn’t have enough protection.
  135. Techniques to mitigate the Lack of Binary Protection

  136. Verify Sign

  137. Obfuscated • Some obfuscation tool, allow to encrypt String in

    source code. – ProGuard(*) – DexProtector – DexGuard
  138. Anti-Emulator

  139. Debuggable

  140. Demo Time #2

  141. Demo

  142. Demo Decompiling Luyten

  143. Demo Modify Smali Files

  144. Demo

  145. Recap • We’ve seen how it’s possible change the behavior

    of an app by disassembling, modify the smali code and recompiling the app • Some techniques to “try” to prevent the lack of binary protection
  146. MALWARE

  147. Malware Statistics #1

  148. Malware Statistics #2

  149. Malware #1-Flappy-bird • Some application ask for permission that don’t

    need. • E.g: Game asking for send sms ??
  150. Malware #1-Flappy-bird • Some application ask for permission that don’t

    need. • E.g: Game asking for send sms ??
  151. Malware #2-iMatch

  152. Permissions Dangerous #1

  153. Permissions Dangerous #2

  154. Dendroid botnet Botnet especially developed for attacking android user’s which

    has the functionalities like • Record call • Block SMS • Take video/photo • Send text • Send contacts • Get user account • Call Number • Update App • Delete files • Get browser history • Get call history • Get inbox SMS
  155. Dendroid botnet -malware

  156. Dendroid botnet - Manifest

  157. Demo Time

  158. DroidDream Malware • Steal sensitive data – IMEI –> block

    phone – IMSI – Device model – SDK
  159. DroidDream example #1 - Paint • Access_coarse_location==GPS • Read_phone_state

  160. DroidDream example #1.1

  161. DroidDream example #2 – Hotgirls

  162. How to Protect Yourself • Go to Settings → Security

    → Turn OFF "Allow installation from unknown sources" . • Always keep an up-to-date Anti-virus app • Avoid unknown and unsecured Wi-Fi hotspots
  163. Summary • Obfuscate the code and mitigate the lack of

    binary protection using anti-emulator,etc. • Be aware of what permissions you’re giving to the application.
  164. •

  165. None
  166. References • • • Book:The mobile hackers handbook

    • Book:Android Hackers Handbook • android-applications/ • • test-in.html • and-secure-android-apk/ • step-by-step.html