Slide 1

Slide 1 text

Android Security XKE201707 Qian Jin

Slide 2

Slide 2 text

Agenda ● Mobile Security in a Nutshell ● Android Security Overview ● Secure Network communication ● Reverse engineering ● Obfuscation ● Tampering Detection ● More Security Tips ● Conclusion

Slide 3

Slide 3 text

Mobile Security in a Nutshell

Slide 4

Slide 4 text

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.

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Mobile Device Attack Vectors ● Hardware-centric attacks ● Device-independent attacks ● Software-centric attacks ● User-layer attacks

Slide 7

Slide 7 text

Mobile Device Attack Models ● Eavesdropping ● Availability attacks ● Privacy attacks ● Impersonation Attacks

Slide 8

Slide 8 text

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)

Slide 9

Slide 9 text

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.

Slide 10

Slide 10 text

Image Credit: https://www.cyber.nj.gov/threat-profiles/mobile-malware/

Slide 11

Slide 11 text

Number of detected malicious installation packages (Q2 2015 - Q1 2016)

Slide 12

Slide 12 text

Distribution of new mobile malware by type, Q1 2016 vs. Q4 2015

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

Mobile Malware: Infection Methods ● Browser-based vulnerabilities ● WiFi Man In The Middle ● Distribution via application markets ● Mail attachement ● Physical compromise

Slide 15

Slide 15 text

Safari JavaScript pop-up scareware (March 2017)

Slide 16

Slide 16 text

iOS malware XcodeGhost (September 2015)

Slide 17

Slide 17 text

Android Malware “Judy”

Slide 18

Slide 18 text

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.

Slide 19

Slide 19 text

iOS Malware WireLurker

Slide 20

Slide 20 text

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.

Slide 21

Slide 21 text

HummingBad returns as HummingWhale (Jan 2017)

Slide 22

Slide 22 text

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.

Slide 23

Slide 23 text

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.

Slide 24

Slide 24 text

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.

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Android Security Overview

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Root with Caution!

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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.

Slide 38

Slide 38 text

Mediaserver ... Medie Player Linux Kernel /dev/binder Servicemanager System_server ... App3 App2 App1 Context Manager Camera Audio Flinger Package Manager Location Manager

Slide 39

Slide 39 text

Application System Server Manager Service Binder IPC Binder.getCallingUid() Binder.getCallingPid() Proxy Stub AIDL

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Secure Network communication

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

Security with HTTPS and SSL Possible SSH handshake exception while verifying server certificates: ● Unknown certificate authority ● Self-signed server certificate ● Missing intermediate certificate authority

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

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.

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

Do not do SSL pinning without the blessing of your server’s TLS administrator!

Slide 49

Slide 49 text

Network Security Configuration ...

Slide 50

Slide 50 text

Reverse engineering

Slide 51

Slide 51 text

Figure 1. The build process of a typical Android app module.

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

Pro Tools ● JEB Decompiler: https://www.pnfsoftware.com/ ● Hex Rays decompiler: https://www.hex-rays.com/products/decompiler/

Slide 56

Slide 56 text

Pull APK from device $ adb shell pm list packages $ adb shell pm path your-package-name $ adb pull /full/directory/of/apk

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

Convert .dex to .class $ sh d2j-dex2jar.sh -f /your/apk/file

Slide 60

Slide 60 text

very readable if no obfuscation is in place

Slide 61

Slide 61 text

Demo Time Let’s dig some .apk dirt

Slide 62

Slide 62 text

Obfuscation

Slide 63

Slide 63 text

ProGuard

Slide 64

Slide 64 text

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.

Slide 65

Slide 65 text

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.

Slide 66

Slide 66 text

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.

Slide 67

Slide 67 text

ProGuard: Options ● Input/Output Options ● Keep Options ● Shrinking Options ● Optimization Options ● Obfuscation Options ● Preverification Options

Slide 68

Slide 68 text

ProGuard: example -injars bin/classes -outjars bin/classes-processed.jar -libraryjars /usr/local/java/android-sdk/platforms/android-9/android.jar -dontpreverify -repackageclasses '' -allowaccessmodification -optimizations !code/simplification/arithmetic -keep public class mypackage.MyActivity

Slide 69

Slide 69 text

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' } } }

Slide 70

Slide 70 text

No content

Slide 71

Slide 71 text

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.

Slide 72

Slide 72 text

Ref: https://www.pnfsoftware.com/blog/a-look-inside-dexguard/

Slide 73

Slide 73 text

Tampering Detection

Slide 74

Slide 74 text

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?

Slide 75

Slide 75 text

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; }

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

More Security Tips

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

Conclusion

Slide 80

Slide 80 text

I probably need another XKE to continue...

Slide 81

Slide 81 text

Thanks! :)