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

Android Security

jinqian
July 03, 2017

Android Security

Android Security in a Nutshell

jinqian

July 03, 2017
Tweet

More Decks by jinqian

Other Decks in Technology

Transcript

  1. Agenda • Mobile Security in a Nutshell • Android Security

    Overview • Secure Network communication • Reverse engineering • Obfuscation • Tampering Detection • More Security Tips • Conclusion
  2. A Smartphone contains an MNO (Mobile Network Operator) smartcard with

    a connection to a mobile network. Moreover, it has an operating system that can be extended with third-party software.
  3. Specifics of Mobile Devices • Creation of cost: billing event,

    Payment system • Network environment: strong connection, OTA firmware update process, remote device • Limited device resources: RAM, battery • Expensive computation cost: security algorithm
  4. SMS Vulnerabilities An implementation bug in the SMS parser of

    the Siemens S55: receiving a short message with Chinese characters lead to a Denial of Service (DoS)
  5. MMS Vulnerabilities Commwarrior is a Symbian Bluetooth worm that was

    the first to spread via Multimedia Messaging Service (MMS) and Bluetooth. The worm affects only the Nokia Series 60 software platform.
  6. Mobile Malware: Infection Methods • Browser-based vulnerabilities • WiFi Man

    In The Middle • Distribution via application markets • Mail attachement • Physical compromise
  7. Android Malware “Ghost Push” • encrypt its APK and shell

    code, • run a malicious DEX file without notification, • add a “guard code” to monitor its own processes, • rename .APK (Android application package) files used to install the malicious apps, • and launch the new activity as the payload.
  8. HummingBad: A Persistent Mobile Chain Attack (Feb 2016) The first

    attack vector, called Right_core, is a silent operation triggered by one of three common events on the device. • BOOT_COMPLETED – occurs after booting the device. • TIME_TICK – occurs every time a minute passes. • SCREEN_ON – occurs when the screen is turned on. The second attack vector, called qs, is initiated only if the first vector failed to gain root. This attack vector uses social engineering in order to achieve its purspose. The component “qs” is also XOR encrypted and needs to be decrypted by the parent malware. The malware’s authors Yingmob racked up around US $300,000 per month at its peak.
  9. Malware: detection • Signature based detection • Static function call

    analysis • Anomaly detection • Rootkit detection • Software-based attestation: verify the memory contents of embedded devices and establish the absence of malicious changes to the memory contents.
  10. Software-based Attestation Figure 1: Generic external memory verification. The verifier

    has a copy of the device’s presumed memory, and sends a request to the embedded device. The device can prove its memory contents by returning the correct response.
  11. Software-based Attestation Figure 2: Memory verification attack. The attacker replaces

    the verification code with malicious verification code and copies the old verification code into empty memory.
  12. Operation System Protection • Limited privileges and process isolation •

    File permissions • Hardened Kernels ◦ Address Space Layout Randomization ◦ Stack protection ◦ Non-executable writable memory • Sane Default Settings (e.g. bluetooth connectivity) • OTA Updates
  13. CopperheadOS ➔ Hardened C standard library and compiler toolchain ➔

    Hardened kernel ➔ Stronger sandboxing and isolation for apps & services ➔ Backported security features and quicker patching ➔ Firewall & network hardening ➔ Open-source and free of proprietary services ➔ Security-centric user experience changes
  14. System and kernel security • Linux security ◦ A user-based

    permissions model ◦ Process isolation ◦ Extensible mechanism for secure IPC (Inter-Process Communication) ◦ The ability to remove unnecessary and potentially insecure parts of the kernel • Application sandbox: UID, separate process, native code
  15. System and kernel security • System Partition and Safe Mode

    • Filesystem Permissions • SELinux: Security-Enhanced Linux • Verified boot (Android 6.0+) • Cryptographic APIs ◦ KeyChain Class, from API 14 • Rooting of Devices
  16. System and kernel security • Filesystem Encryption ◦ Android 3.0+:

    full filesystem encryption ◦ Android 5.0+: supports full-disk encryption ◦ Android 7.0+: file-based encryption • Password Protection
  17. App Security: Elements of Applications • AndroidManifest.xml: the control file

    that tells the system what to do with all the top-level components • Activities: the code for a single, user-focused task • Services: a body of code that runs in the background, in its own process or in the context of another application. Bind to use • Broadcast Receiver: an object that is instantiated when an IPC mechanism known as an Intent is issued by the operating system or another application
  18. App Security: Permission Model Android 6.0+: Requesting Permissions at Run

    Time Accessing Protected APIs: • Camera functions • Location data (GPS) • Bluetooth functions • Telephony functions • SMS/MMS functions • Network/data connections
  19. App Security: IPC Inter-Process Communication • Binder • Services •

    Intents • ContentProviders: a data storehouse that provides access to data on the device, e.g. for contact list access.
  20. Mediaserver ... Medie Player Linux Kernel /dev/binder Servicemanager System_server ...

    App3 App2 App1 Context Manager Camera Audio Flinger Package Manager Location Manager
  21. App Security: CA & Application Signing • Certificate authorities ◦

    Prior to Android 7.0: device manufacturers could modify the set of CAs shipped on their devices ◦ Android 7.0+: uniform set of system CAs, modification by device manufacturers is no longer permitted • Application Signing ◦ Shared UID feature: declare security permissions at the Signature protection level, restricting access only to applications signed with the same key
  22. Security with HTTPS and SSL Possible SSH handshake exception while

    verifying server certificates: • Unknown certificate authority • Self-signed server certificate • Missing intermediate certificate authority
  23. Security with HTTPS and SSL OkHttp attempts to balance two

    competing concerns: • Connectivity to as many hosts as possible. That includes advanced hosts that run the latest versions of boringssl and less out of date hosts running older versions of OpenSSL. • Security of the connection. This includes verification of the remote webserver with certificates and the privacy of data exchanged with strong ciphers.
  24. SSL Pinning Pinning is the process of associating a host

    with their expected X509 certificate or public key. • Which certificate to pin against in the chain? • Certificate or public key pinning? • Handling compromise: Fail hard or fail soft? • Where should we store the certificate/public key? ◦ Preloading ◦ Trust on first use ◦ Over the air
  25. Network Security Configuration <?xml version="1.0" encoding="utf-8"?> <manifest ... > <application

    android:networkSecurityConfig="@xml/network_security_config"...> ... </application> </manifest>
  26. Free tools • Apktool: https://ibotpeaches.github.io/Apktool/ • dex2jar: https://github.com/pxb1988/dex2jar • smali/baksmali:

    an assembler/disassembler for the dex format used by dalvik, Android's Java VM implementation: https://github.com/JesusFreke/smali • jd-gui: https://github.com/java-decompiler/jd-gui
  27. Pull APK from device $ adb shell pm list packages

    $ adb shell pm path your-package-name $ adb pull /full/directory/of/apk
  28. ProGuard: Shrinking Java source code (.java files) is typically compiled

    to bytecode (.class files). Bytecode is more compact than Java source code, but it may still contain a lot of unused code, especially if it includes program libraries. Shrinking programs such as ProGuard can analyze bytecode and remove unused classes, fields, and methods. The program remains functionally equivalent, including the information given in exception stack traces.
  29. ProGuard: Obfuscation Compiled bytecode still contains a lot of debugging

    information: source file names, line numbers, field names, method names, argument names, variable names, etc. This information makes it straightforward to decompile the bytecode and reverse-engineer entire programs. Sometimes, this is not desirable. Obfuscators such as ProGuard can remove the debugging information and replace all names by meaningless character sequences, making it much harder to reverse-engineer the code. It further compacts the code as a bonus.
  30. ProGuard: Preverification When loading class files, the class loader performs

    some sophisticated verification of the byte code. This analysis makes sure the code can't accidentally or intentionally break out of the sandbox of the virtual machine.
  31. ProGuard: Options • Input/Output Options • Keep Options • Shrinking

    Options • Optimization Options • Obfuscation Options • Preverification Options
  32. android { buildTypes { release { minifyEnabled true // Library

    specific proguard files proguardFile 'proguard-google-play-services.pro' proguardFile 'proguard-gson.pro' ... // Default proguard files & project app specific rules, proguardFile 'proguard-project-app.pro' proguardFile getDefaultProguardFile('proguard-android.txt') // As of Gradle Android plugin 1.1.0, the test APK has a separate config testProguardFile 'proguard-project-test.pro' } } }
  33. DexGuard • By GuardSqaure, CTO Eric Lafortune • DexGuard is

    the commercial sibling of ProGuard for Android. • ProGuard provides name obfuscation: it can replace the original names of classes, methods, and fields by short, meaningless names. DexGuard additionally provides string encryption and class encryption.
  34. Tampering Detection • Check in run time if application has

    been modified in anyway or if the signature is changed • Verify the installer • It can be done with PackageManager • Multiple check point & use obfuscation in case it’s bypassed • Fail policy: what happens if modification is detected?
  35. Tampering Detection Example public boolean isHacked(Context context, String myPackageName, String

    google, String amazon){ // Renamed? if (context.getPackageName().compareTo(myPackageName) != 0) { return true; // BOOM! } // Relocated? String installer = context.getPackageManager().getInstallerPackageName(myPackageName); if (installer == null){ return true; // BOOM! } if (installer.compareTo(google) != 0 && installer.compareTo(amazon) != 0){ return true; // BOOM! } return false; }
  36. Tampering Detection • Obfuscation is fundamental! • Avoid client-side checks

    • You may want to check out SafetyNet API: https://developer.android.com/training/safetynet/index.html
  37. Security Tips • Remove logcat logging from your production builds

    • Avoid storing your data in the shared storage • Encrypt your preferences / files => the private folder can be found on the device at path /data/data/yourpackage • Encrypt your SQLite database: https://github.com/sqlcipher/sqlcipher