Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Android Apps Security

Android Apps Security

Mobile Dev Day Genova - 3rd June 2014

A98925181b2256d38addf9c3f5bf4dea?s=128

Marco Grassi

June 03, 2014
Tweet

More Decks by Marco Grassi

Other Decks in Programming

Transcript

  1. ANDROID APPS SECURITY Mobile Dev Day - Genova Marco Grassi

    @marcograss MGrassi@viaforensics.com Mobile Security Researcher @ viaForensics 1
  2. $ whoami • R&D Team Member @ viaForensics • Part

    of my job is to attack and break mobile apps 2
  3. 3 Black Box Approach = We can use the app,

    Dynamic Analysis, Inspection + Reverse Engineering, Static Analysis (Mainly) APK
  4. AGENDA • Reverse Engineering and Obfuscation • Tampering Detection •

    Logging • File Storage • Secure Network Communications • IPC Attack Surface • RAM memory attacks • More Advanced Material : Runtime Manipulation • Extra: Creating Cheats for Android Games : ) 4 REAL WORLD EXAMPLES
  5. SANTOKU LINUX https://santoku-linux.com/ 5

  6. PULLING THE APK FROM THE DEVICE 6 • Often the

    APKs are downloaded from Google Play on the device, how can we extract them? Some solutions: 1. adb backup -apk com.mypackage (Works on Android 4.0 and newer) 2. Use a backup application (ASTRO File manager, Titanium Backup…) 3. adb shell , cd /data/app/, find your apk, then you can pull it with adb pull /data/app/ mypackage.apk (requires a adb root shell on the device)
  7. REVERSE ENGINEERING FREE TOOLS • apktool and smali/baksmali It will

    provide us a disassembled representation of the Dalvik bytecode, so sort “low level”, with registers, but very understandable because of bytecode metadata. Very useful to disable tampering protections, the code can be modified and the application can be recompiled and resigned. 7
  8. DISASSEMBLED SMALI CODE 8

  9. REVERSE ENGINEERING FREE TOOLS • dex2jar + Java decompiler (jd-gui,

    jad …) dex2jar will convert the .dex file to a .jar containing Java code We can then use the freely available Java decompilers and obtain back a Java representation of the code. Very readable if no obfuscation is in place. 9
  10. DECOMPILED JAVA CODE 10 JD-GUI Procyon CFR jadx(directly from dex)

  11. REVERSE ENGINEERING PRO TOOLS • JEB Decompiler Renaming feature, very

    handy with obfuscated applications Python and Java APIs Native Dalvik decompiler, it does not pass through Java byte code, decompilation is usually much better 11
  12. REVERSE ENGINEERING PRO TOOLS • IDA + Hex Rays Decompiler

    De facto the best interactive disassembler and decompiler on the market. Impressive set of APIs, you can write modules or scripts for everything. 12
  13. REVERSE ENGINEERING PRO TOOLS • Hopper Disassembler Very nice disassembler

    and decompiler with a killer price. 13
  14. OBFUSCATION PROGUARD • Free • Integrated into the build environment

    • NOT Android specific • http://developer.android.com/tools/ help/proguard.html 14
  15. DECOMPILED CODE WITH PROGUARD 15

  16. OBFUSCATION DEXGUARD • Commercial product from ProGuard author. • Android

    specific • Native support to string and code encryption and tamper detection • Very easy to use, with a config file like ProGuard 16
  17. DECOMPILED CODE WITH DEXGUARD 17

  18. TAMPERING DETECTION 18 • Check at runtime if the application

    has been modified in any way or if the signature is changed. • It can be done with the PackageManager class, retrieving the Signature[] array of your app and comparing with known values. If an attacker resigned the app, the signing key will be different. • Do the checks in multiple code points and use obfuscation, to avoid that it can be easily bypassed. • If your app ships only through Google Play, check with the APIs that it has been installed from Google Play and not from Unknown Sources. • If something is wrong, close the application without leaking informations where the protection code is, to make attacker’s life harder.
  19. DEFEATING TAMPERING DETECTION WHY OBFUSCATION IS FUNDAMENTAL 19 Why spend

    hours on implementing if our application has been modified, if there is a single point of failure? ! If the attacker can easily find the code, it can modify the application and disable it.
  20. LOGGING • Remove Logcat logging from your production builds. •

    It can be done with few lines in Proguard and Dexguard, they remove all the calls to Log.d, Log.e etc in the build process • It’s very easy for third party malware or an attacker to access the Logs on Android. 20
  21. FILE STORAGE EXTERNAL STORAGE • Try to avoid storing your

    data in the shared storage, almost any application can read it. (In 4.4 a small protection at permission level was added android.permission.READ_EXTERNAL _STORAGE, usually users does not check permissions too much anyway… Don’t rely on this.) 21 My Personal Data stored in a Evernote Note, publicly readable by anyone. CASE STUDY
  22. FILE STORAGE PRIVATE APP FOLDER • Encrypt your preferences/files •

    With root access they can be modified, avoid store sensitive data at all if possible • With a backup, they can be retrieved from the device usually • The private folder can be found on the device at path /data/data/yourpackage 22 That’s right.. It’s my User and my 36 character Password in PLAIN TEXT CASE STUDY
  23. FILE STORAGE SQLITE DATABASES 23 shell@hammerhead:/ $ pm list packages

    | grep easy package:com.handyapps.easymoney shell@hammerhead:/ $ exit $ adb backup -apk com.handyapps.easymoney unpack the backup with https://github.com/nelenkov/android-backup-extractor PASSCODE IN PLAIN TEXT RETRIEVED. FAIL! CASE STUDY
  24. SQLCIPHER 24 http://sqlcipher.net/sqlcipher-for-android/ Very easy to use encrypted SQLite database.

    Don’t store the key with the safe. The user must provide the password to access the content if possible.
  25. #1 RULE: YOU DO NOT IMPLEMENT YOUR OWN CRYPTOGRAPHY #2

    Rule: You do NOT implement your own Cryptography 25
  26. SECURE NETWORK COMMUNICATIONS • It’s your responsibility to protect data

    in transit! • Don’t transmit sensitive information without SSL/TLS • Implement if possibile Certificate Pinning, in this way your communications will be more resistant to MITM attacks, for example if a malicious certificate is pushed into the device, or if an attacker can impersonate your web service with a trusted certificate. 26
  27. IPC ATTACK SURFACE THE ANDROID MANIFEST 27 • Avoid the

    flag android:debuggable=true in production, an attacker can attach with a debugger and execute arbitrary code in your app. • Double check your exported components. Export a component to other processes only if it’s strictly necessary and at least protect the component with a permission. Android has some permissive defaults, some components are exported even if they are not declared exported=true, check the documentation. • If you export a content provider or another component that grants access to data and accepts untrusted output, be careful on the input to avoid sql injections and path traversal attacks.
  28. IPC ATTACK SURFACE EXAMPLE: SCREEN BYPASS 28 McAfee Antivirus &

    Security ! Now patched It was possible to bypass the activation and use for free some functionalities. ! $ am start -a android.intent.action.MAIN -n com.wsandroid.suite/ com.mcafee.main.MfeMain ! Credits: Sebastián Guerrero, @0xroot CASE STUDY
  29. RAM MEMORY ATTACKS • An attacker can retrieve and inspect

    the ram memory used by our application and search for sensitive informations. • Avoid storing such sensitive informations inside instance or static variables. 29
  30. RAM MEMORY ATTACKS • An easiest way to get an

    incomplete (VM only) chunk of live memory from our application is to use the “Dump HPROF” functionality in the monitor tool, with a debuggable application or a device with the flag ro.debuggable=1 30
  31. APPENDIX Extras with more advanced material 31

  32. RUNTIME MANIPULATION Why modify the code of the application recompiling

    it when we can modify the code at runtime, without alerting the basic tampering detection? 32
  33. RUNTIME MANIPULATION 33 We can change the behaviour of the

    applications and the system without touching any APK and we can enable/disable plugins with ease. ! We must have a rooted phone and install a framework that will modify some low level components of the Android OS, to make our life easier.
  34. MOST POPULAR FRAMEWORKS • Cydia Substrate • Xposed Framework •

    (New) Frida 34 http://www.cydiasubstrate.com/ http://repo.xposed.info/ http://frida.re/
  35. CANDY! Reverse Engineering is fun! 35

  36. LET’S USE RUNTIME MANIPULATION TO CHEAT IN ANDROID GAMES! 36

  37. AGIMAT • Simple cheat engine/app for Android using runtime manipulation

    • When more games are supported and if there is interest, it will be open sourced (no time) 37
  38. SUPER HEXAGON Addictive but difficult game for Android 38

  39. 39 It’s difficult? Let’s slow down the game with Reverse

    Engineering and runtime manipulation!
  40. VIDEO DEMO 40

  41. SECURITY IS A PROCESS. 41

  42. SECURE MOBILE DEVELOPMENT BEST PRACTICES AVOIDING COMMON PROBLEMS AND CREATING

    MORE SECURE APPS FOR IOS AND ANDROID 42 http://bit.ly/L1fBeT
  43. 43 bit.ly/1doIWa7 OWASP Mobile Security Project

  44. Great book to start with Secure Android Development, written by

    my friend @scottyab 44
  45. More advanced book on Android Hacking, by @pof and @jduck

    and others 45
  46. GET CERTIFIED bit.ly/1lwIGjl 46

  47. WE ARE HIRING! 47

  48. 48 @0xroot, @abelenko, @ahoog42, Brendan , @Fuzion24, @insitusec, @giantpune, @jduck

    @JMDlux, @kevinswartz_1, @kstrzemp, @mattdorn, @pof, @rozelaudric, @scottyab, Terence , @thomas_cannon, @tom_anderson2, @viaforensics, @vialated and many others…
  49. @marcograss MGrassi@viaforensics.com 49 EOF

  50. HOW CAN WE DEVELOP A PLUGIN AND WHAT WE CAN

    DO WITH IT? 50
  51. 1PASSWORD READER • Password wallet application for Android, a companion

    application of the Mac/Windows client, to be able to share our passwords between our PC and the mobile device, leveraging Dropbox or the Shared Storage. 51 CASE STUDY
  52. BE CAREFUL WITH BROADCASTED INTENTS 52 Vulnerable unprotected Broadcast Receiver

    to make the app timeout, with a Broadcasted Intent (Dangerous!) CASE STUDY
  53. LET’S INSTALL SOME MALWARE 53 CASE STUDY

  54. RESULTS 54 The Malware catch the Broadcast Intent before of

    the wallet. It suppress it, so the Wallet never get the Intent and never go to timeout its session. ! What we learned: The system often is not trusted when doing IPC with Intents, and in any case we must protect the exposed parts of our application, auditing and remediating. CASE STUDY
  55. 1PASSWORD: WHY SHARED STORAGE AND DROPBOX? • This choices are

    forced for technical limitation in the sharing process between the PC and the device. • Without root permissions, the user can only write in the shared folder, or the application can use third party services, such file sharing API by Dropbox, to share the wallet file. 55 CASE STUDY
  56. FIRST LOOK • The 1Password wallet is totally unobfuscated, so

    an attacker can easily understand the logic of the application and the weak points. • First weak spot: LOGS, the application disabled in productions the logging of the user credentials and other internal information to the Logcat, but the logs are only disabled, the code that logs at the critical points (even the user password) it’s in there. 56 CASE STUDY
  57. HELLO WORLD: WHAT CODE CHANGE? LET’S ENABLE LOGGING 57 CASE

    STUDY
  58. REPLACED METHODS 58 CASE STUDY Xposed Framework Plugin to re

    enable logging in this app
  59. RESULTS 59 12-03 22:49:24.614: I/Xposed(3402): logMsg - === BEGIN validate

    password: testing=== 12-03 22:49:24.614: I/Xposed(3402): logMsg - BEGIN decryptWithPBKDEF2 encrypted len=1056 password=testing iterations:71428 12-03 22:49:27.606: I/Xposed(3402): logMsg - derivedKeysLen=32baseKey.len=16 ivec=16 12-03 22:49:27.606: I/Xposed(3402): logMsg - END decryptWithPBKDEF2: result.len=1024 12-03 22:49:27.616: I/Xposed(3402): logMsg - SL5 key validation OK 12-03 22:49:27.616: I/Xposed(3402): logMsg - BEGIN decryptWithPBKDEF2 encrypted len=1056 password=testing iterations:71428 12-03 22:49:30.449: I/Xposed(3402): logMsg - derivedKeysLen=32baseKey.len=16 ivec=16 12-03 22:49:30.459: I/Xposed(3402): logMsg - END decryptWithPBKDEF2: result.len=1024 12-03 22:49:30.459: I/Xposed(3402): logMsg - SL3 key validation OK 12-03 22:49:30.459: I/Xposed(3402): logMsg - === END validate password CASE STUDY