PSCG

Ron Munitz

Founder & CEO - The PSCGron@thepscg.com

CodemotionTel-AvivNovember 2014

@ronubo

The Ultimate Android Security Checklist

This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/

© Copyright Ron Munitz 2014

PSCG

about://Ron Munitz● Founder and CEO of the PSCG

○ The Premium Embedded/Android consulting and Training firm● Founder and CTO of Nubo Software

○ The first Remote Android Workspace● Instructor at NewCircle● Senior Lecturer at Afeka College of Engineering● Always up for something new● Building up on diverse engineering experience:

○ Distributed Fault Tolerant Avionic Systems○ Highly distributed video routers○ Real Time, Embedded, Server bringups○ Operating Systems, very esoteric libraries, 0’s, 1’s and lots of them.

■ Linux, Android ,VxWorks, Windows, iOS, devices, BSPs, DSPs,...

● Always willing to learn. Always willing to Teach

PSCG

about://Information_Security

You just can’t win

But you can make attacking unworthy.

PSCG

The Android Security Program

● Design Review○ Each major feature of the platform is reviewed by engineering and

security resources.○ Only within Google and immediate partners

● Penetration Testing and Code Review○ Performed by the Android Security Team, Google’s Information

Security Engineering team, and independent security consultants.○ Identify weaknesses and possible vulnerabilities well before the

platform is open-sourced.

PSCG

The Android Security Program

● Open Source and Community Review○ The Android Open Source Project enables broad security review by

any interested party.○ Android uses open source technologies that have undergone

significant external security review

● Incident Response○ A full-time Android security team constantly monitors Android-specific

and the general security community for discussion of potential vulnerabilities.

○ They do a fantastic job but they are still only engineers. Not security gods

PSCG

Android Security Architecture

● Security Objectives○ Protect user data

○ Protect system resources (e.g. network, timeslice)

○ Provide application isolation

● More Security Objectives○ Protect another type of user - the developer

○ Intellectual Property cannot be underestimated

○ And that will be our focus in this talk

PSCG

Android Security Architecture

● Key Features○ Robust security at the OS level through the Linux

kernel○ Mandatory application sandbox for all applications○ Secure interprocess communication○ Application signing○ Application-defined and user-granted permissions○ Last but not least: the latest and greatest:

■ Enforcing @ SE Linux ■ Multi-user sdcard @ LXC■ Trusted boot support @ HW

○ ...

PSCG

Linux Security basics

● A user-based permissions model● Process isolation● Hardware isolation (OS 101)● Extensible mechanism for secure IPC● Configurable, hence allows to remove

unnecessary and potentially insecure parts of the kernel

● Does not DPI userspace○ Beware the untrusted device

PSCG

The Android Application Sandbox

The Android system assigns a unique user ID (UID) to each Android application and runs it as that user in a separate process.

PSCG

The Android Application Sandbox

● The Android operating system is a multi-user Linux system in which each app is a different user.

● By default, the system assigns each app a unique Linux user ID (the ID is used only by the system and is unknown to the app). The system sets permissions for all the files in an app so that only the user ID assigned to that app can access them.

● Multi user support allows the same applications to run on several users○ App’s “User name” := uX_aY // user X, app Y ○ UID := CONST * X + Y

PSCG

The Android Application Sandbox

● Each process has its own virtual machine (VM), so an app's code runs in isolation from other apps.

● By default, every app runs in its own Linux process.○ This can be changed with shared signatures

● A process starts when any of the app's components needs to be executed

● A process shuts down when it's no longer needed● Or when the system must recover memory for other

apps.○ This is almost ALWAYS overlooked○ Indirect attacks are still attacks, and they are harmful

(@see Meetup.com’s DDOS incident)

PSCG

The Android Application Sandbox

Sandbox Isolation Example● Suppose A tries to do something malicious like

○ read application B's data ○ dial the phone (application P ) without permission

● Then the operating system protects against this because application A does not have the appropriate user privileges.

● Some sort of principle of least privileged○ Some sort: @see SE Linux

PSCG

The Android Application Sandbox

Android applications can allow access to their resources to other applications by:● Declaring the appropriate manifest-

permissions● Running in the same process with

other trusted applications, thus sharing access to their data and code

● A classic point for vulnerabilities ○ Abuse of permission mechanism kindness

(Or: [I agree])○ Automatic exposure on intent filter

Use: android:exported=”false”

PSCG

The Android Application Sandbox

Memory Corruption Exploits● A memory corruption error does not lead to

compromising the security of the device, due to all applications and their resources being sandboxed at the OS level.

● A memory corruption error will only allow arbitrary code execution in the context of that particular application, with the permissions established by the operating system.

● Suspect to data inspection, code injections/tampering...

PSCG

The Application Sandbox Rational

● Application Sandbox is enforced by the kernel● Hence its security reduces to the kernel’s security● Which means that in a “properly configured” (read:

trusted) device one must compromise the security of the the Linux kernel.

● Trust NO ONE● Or restrict everyone.

PSCG

System Permissions

Summary of application isolationNo application, by default, has permission to perform any operations that would adversely impact other applications, the operating system, or the user.● reading or writing the user's private data (such as contacts or

emails), ● reading or writing another application's files,● performing network access,● keeping the device awake, so on.

PSCG

System Permissions

Reaching out of the basic sandboxApplications must explicitly share resources and data● They do this by declaring the permissions they need for

additional capabilities not provided by the basic sandbox, including access to device features such as the camera.

● Exception: the intent-filter case

PSCG

System Permissions

The Manifest File - Using Permissions● To make use of protected features of the device,

developers must include in application’s AndroidManifest.xml one or more <uses-permission> tags declaring the permissions that your application needs.

PSCG

System Permissions

Example of some permissionsACCESS_NETWORK_STATE● Allows applications to access information about networksCHANGE_NETWORK_STATE● Allows applications to change network connectivity stateDUMP● Allows an application to retrieve state dump information from

system services.DEVICE_ADMIN_POLICY● Allows an application to apply administrative activities such as

wiping a device

PSCG

System Permissions

Applications statically declare the permissions they require, and the Android system prompts the user for consent at the time the application is installed. ● Android has no mechanism for granting permissions

dynamically (at run-time)* ● Any attempts to use non explicitly permitted functions will fail● Applications can also share files by using sharedUserId

attribute in the AndroidManifest.xml

*The PackageManager can remove and later re-grant permissions, but only those who had been previously acknowledged

PSCG

Application SigningAll Android applications must be signed. Application or code signing is the process of digitally signing a given application using a private key to:● Identify the code's author

● Detect if the application has changed

● Establish trust between applications

PSCG

Android Application Build Process● The Android Asset Packaging Tool (aapt) takes your

application resource files, such as the AndroidManifest.xml file and the XML files for your Activities, and compiles them. An R.java is also produced so you can reference your resources from your Java code.

● The aidl tool converts any .aidl interfaces that you have into Java interfaces.

● All of your Java code, including the R.java and .aidl files, are compiled by the Java compiler and .class files are output.

● The dex tool converts the .class files to Dalvik byte code. Any 3rd party libraries and .class files that you have included in your project are also converted into .dex files so that they can be packaged into the final .apk file.

PSCG

Android Application Build Process

● All non-compiled resources (such as images), compiled resources, and the .dex files are sent to the apkbuilder tool to be packaged into an .apk file.

● Once the .apk is built, it must be signed with either a debug or release key before it can be installed to a device.

● Finally, if the application is being signed in release mode, you must align the .apk with the zipalign tool. Aligning the final .apk decreases memory usage when the application is running on a device.

PSCG

Reverse Engineering an App

● In life, it is hard to build and easy to destroy● In Software it can be the same● But it doesn’t have to.● Reverse Engineering is the process of

unbuilding. Decompiling. Extracting information out of compiled programs

● It is a fascinating domain● That can have disastrous outcomes

Android rev-eng Tools● apktool

○ Decodes resources to nearly original form and rebuild them after making some modifications; it makes possible to debug smali code step by step.

● dex2jar ○ dex2jar is a tool for converting Android's .dex format to Java's .class

format. just one binary format to another binary format, not to source.

● JD-Project - jd-gui/jd-plugin○ The “Java Decompiler project” aims to develop tools in order to decompile

and analyze Java 5 “byte code” and the later versions.

PSCG

Android rev-eng tools

● smali○ Assembler/disassembler for the dex format used by dalvik, Android's Java VM

implementation. Supports the full functionality of the dex format (annotations, debug info, line info, etc.)

● androguard○ Androguard is mainly a tool written in python to play with :

■ Dex/Odex (Dalvik virtual machine) (.dex) (disassemble, decompilation),■ APK (Android application) (.apk)

● There are more. Commercial and non commercial● When there is a will there is a way● There is a will. Code, data, behavioral attacks, IP.

PSCG

Reverse Engineering an App

● apktool takes your signed or unsigned application apk and retrieves ○ readable AndroidMenifest.xml ○ All its resources. ○ .dex/.odex files as .smali files

which are dex disassembly.● dex2jar tool creates jars that contain .

class files of the application by converting .dex files.

● A Java Decompiler (*jd*) can then be applied. ○ The source code can be retrieved

automatically by installing jd-plugin on Eclipse and opening .class files.

Signed Apk

Resources

apktool

.dex files Manifest

.class files Java files

dex2jar

jd-plugin

PSCG

Reversing Showcase

● For resources we will use apktool○ Which are usually

available in the .apk without charge

○ But in a binary forms (i.e. XML’s)

PSCG

Reversing Showcase

PSCG

Reversing Showcase

● After using apktool, we get the resources in the expected folder

PSCG

Reversing Showcase

● This tool will serve us to get the .class files

PSCG

Reversing Showcase

● After running dex2jar, we get jar file containing the .class files.

PSCG

Reversing Showcase

● This tool will help us open .class files without source code

● In this case we install JD-Project as plugin to eclipse

● There is also a standalone version

PSCG

Reversing Showcase

● In order for JD-Project to work, we need to have the jar in .classpath

● For that we will add jar file as external

PSCG

Reversing Showcase

● There we have it.Snake app reverse engineered.

PSCG

Reversing Showcase

● But what if I don’t have Eclipse?○ Use jd-gui (my current choice)○ Use JEB ○ Use other commercials or non commercials tools

PSCG

Protecting Your Code with Proguard

● Proguard○ Shrinks, optimizes, and obfuscates your code

■ by removing unused code and renaming classes, fields, and methods with semantically obscure names.

○ The result■ smaller sized .apk file that is more difficult to

reverse engineer.○ Available through the Android SDK.

PSCG

Protecting Your Code with Proguard

● To enable Proguard:○ set the proguard.config property in the<project_root>/project.

properties file. ○ The path can be an absolute path or a path relative to the project's

root.○ usually there is a commented line that should be uncomment in the

project.propertiesex: # proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt

■ Find examples for proguard-project.txt in Proguard’s webpage.

PSCG

Protecting Your Code

● Obfuscate your code○ Obfuscation Tools

■ DexGuard○ Same as ProGuard but more and specifically for

Android.■ String Encryption■ Class Encryption■ Asset Encryption■ Tamper Detection■ ….

○ Not free or open sourced.

PSCG

Protecting Your Code

● Obfuscate your code○ Obfuscation Tools

■ There are more obfuscation companies for java protection● yGuard● JODE● JavaGuard● jarg● ...

PSCG

Protecting Your Code

● Perform signature verification tasks on a trusted server

● Protect your unlocked content○ Use a real-time service to deliver your content, such as a content feed. ○ Use a remote server to deliver your content.

PSCG

Protecting Your Code

● Know the basics of crypto○ Nonces must not be predictable or reused. ○ Always use a cryptographically secure random number generator ○ If performing nonce verification on a server, generate the nonces on

the server.

● And the non basics● Know who to trust● And do not assume your device is a “saint”.

PSCG

Protecting Native Code

● While most Android applications developers use pure Android/Java language, it is wrong to assume a pure Java world:○ Exhibit #1: Anything that uses HTML/JS.

■ Yes. That means all of your hybrid apps. ○ Exhibit #2: Anything that uses native code

■ Most likely games, TIFF/PDF readers, highly optimized code, portable code, high performance code and a lot more.

● Let’s talk about exhibit #2.

PSCG

Protecting Native Code

● Briefly: JNI is to Java what __asm is to C● You can load dynamic libraries “.so” to

“extend” your Java code○ That is not the case for (standard) iOS

● The bad news: Another level to protect. And you HAVE to do it yourself. (Woohoo, DIY!)

● The good news: If you do it right you can make attacker’s life even harder.

PSCG

Native Code Protection Techniques

● Similar principles from Java● Toolchain aid:

○ Optimize ( e.g. gcc -o<X> …)○ Use different compilers/linkers○ “Confuse” disassembler with call conventions○ Strip everything not needed for object relocation (e.

g. strip --strip-unneeded)○ Compilation flags - see the AOSP platform build/core

and the NDK prebuilt toolchains.● User aid - Know your stuff - trust no one.

PSCG

Ahead Of Time Compiling (ART)

● Experimental support before Lollipop● Default Runtime since Lollipop● AOT is a next generation JIT

○ In “plain hebrew”: Your Java runs as native code.● It essentially compiles your DEX code, into

completely native code.○ Seems like problem solved right?○ Well not really.

■ Observe: oatdump --oat-file=<some file..>

Ahead Of Time Compiling (ART)$ oatdump --oat-file=system@priv-app@Settings.apk@classes.dex ### ExcerptsMAGIC:oat042CHECKSUM:0x48675513

INSTRUCTION SET:X86_64

INSTRUCTION SET FEATURES:none

DEX FILE COUNT:1

…...

Ahead Of Time Compiling (ART) KEY VALUE STORE:dex2oat-cmdline = --runtime-arg -Xms64m --runtime-arg -Xmx512m --boot-image=out/target/product/generic_x86_64/dex_bootjars/system/framework/boot.art --dex-file=out/target/product/generic_x86_64/obj/APPS/Settings_intermediates/x86_64/package.odex.input --dex-location=/system/priv-app/Settings.apk --oat-file=out/target/product/generic_x86_64/obj/APPS/Settings_intermediates/x86_64/package.odex --android-root=out/target/product/generic_x86_64/system --instruction-set=x86_64 --instruction-set-features=default --include-patch-information --runtime-arg -Xnorelocate --no-include-debug-symbolsdex2oat-host = X86_64image-location = out/target/product/generic_x86_64/dex_bootjars/system/framework/x86_64/boot.art

SIZE:3975604

….

Ahead Of Time Compiling (ART)1: Landroid/support/v13/app/FragmentCompat$BaseFragmentCompatImpl; (offset=0x001524d8) (type_idx=383) (StatusInitialized) (OatClassAllCompiled) 0: void android.support.v13.app.FragmentCompat$BaseFragmentCompatImpl.<init>() (dex_method_idx=1724) DEX CODE: 0x0000: invoke-direct {v0}, void java.lang.Object.<init>() // method@11019 0x0003: return-void….. OatQuickMethodHeader (offset=0x001c0000)... QuickMethodFrameInfo... vr_stack_locations: ins: v0[sp + #52] method*: v1[sp + #0] outs: v0[sp + #4] CODE: (code_offset=0x001c0018 size_offset=0x001c0014 size=88)... 0x001c0018: 85842400E0FFFF test eax, [rsp + -8192] suspend point dex PC: 0x0000 GC map objects: v0 (r3) 0x001c001f: 4883EC28 subq rsp, 40 0x001c0023: 48895C2418 movq [rsp + 24], rbx 0x001c0028: 48896C2420 movq [rsp + 32], rbp 0x001c002d: 488BEF movq rbp, rdi

Ahead Of Time Compiling (ART)

In other words the OAT files provide you with:● A full mapping from Native code to DEX byte

code● A full mapping from both to Java functions.● So you can apply the same techniques

for .dex file decompiling. ○ More tools: oat2dex, ...

Code Protection Techniques

● Encrypt data. ● If you can: implement your own crypto.

○ You should not, cannot, and absolutely must not trust anyone. Or anything.

○ On the other hand: Testing, manpower… Easier to use symmetric crypto for it.

● Common issues: Where do you store the keys? Computation costs.

● Remember Kerckhoffs’s Principles.(Partially)○ Do not disclose the keys.○ Do (not) disclose the algorithms (if you can)

PSCG

Monitoring countermeasures

● If you don’t need something - release it○ The longer an object lives - the more suspect to attacking it is

● Cleanup on initialization● Handle Errors - And cleanup.

○ Program crashes → Memory Dumps → Easier attacks

● Decide whether you protect (X)OR debug. You can’t win it all.○ Prevent tracing /debugging○ Remove Logs.

PSCG

More things to consider

● Protecting your own native code is relatively easy.● Protecting 3rd party libraries code is not.● These techniques are applicable to Windows Phones as

well ● And only partially to iOS devices

○ Unless you have the time and knowledge to manipulate the O-Mach structure.

○ Or you use a jailbroken device...

● You can’t win. ● But you can break the attacker’s spirit.

PSCG

Using the sdcard

● If you store data on the SD card - you are storing it on a vfat/FAT32 file system

● Which means that everything there is exposed to everyone

● There are some ways to override it○ See KitKat new external Storage○ Override fuse implementations○ SELinux○ ...

Secure Containers

● Android allows to protect your APKs● By mounting them in a secure containers

○ @see /mnt/asec● It also allows you to add secure data to them● And protecting it is up to you

○ @see /mnt/obb○ This is a serious weakness for the wider public○ As obb’s tend to be shared between processes○ So encrypt them as well

Rooting Android

Rooting describes the acquisition of complete administrator rights on the device, allowing third-party programs to perform operations that were not originally available to them, such as controlling CPU clock speed or overwriting system files.

PSCG

Rooting Android

Application that has obtained administrative rights comes out of the application “sandbox,” so its declared features and granted permissions are no longer relevant. ● Can read and send files associated with other

applications, watch the device’s owner, using the microphone without the owner’s knowledge, etc.

PSCG

Rooting Android

● By default, on Android only the kernel and a small subset of the core applications run with root permissions.

● Android does not prevent a user or application with root permissions from modifying the operating system, kernel, and any other application.

PSCG

Rooting Android

● In general, root has full access to all applications and all application data.

● Users that change the permissions on an Android device to grant root access to applications increase the security exposure to malicious applications and potential application flaws.

PSCG

Rooting Android

Relatively easy. Almost too easy (@see XDA)

There is a protectionTo protect any existing user data from compromise the bootloader unlock mechanism requires that the bootloader erase any existing user data as part of the unlock step.*Root access gained via exploiting a kernel bug or security hole can bypass this protection.

PSCG

So where is the Checklist?!

● Let’s pay a visit to the Oracle○ Not the Complexity/Computability one.○ Not the San Francisco based one either.○ And not the Spartan one

Boy: Do not try and bend the spoon. That's impossible. Instead only try to realize the truth.Neo: What truth?Boy: There is no spoon.Neo: There is no spoon?Boy: Then you'll see that it is not the spoon that bends, it is only yourself.

*Quote taken from a movie which requires no introduction.

PSCG

So where is the Checklist?!

● The truth is there is no (single) checklist.● And the reason for that is that the checklist

changes according to your reality.● It is unreal to protect against everything. ● You need to work hard enough to make your

attacker make much harder● If you work too hard - you’ll lose focus.● So before thinking of a list - think what you

really want to protect

PSCG

Building your own checklist

● Ask questions. Doubt everything. But be pragmatic.○ What is my product “secrets”? In particular

■ Do I protect data? ● My data?● My customer’s data?

■ Do I protect my algorithms?■ Do I protect my servers against DOS?■ Do I protect my license? ■ Do I protect my data?

○ Who are my attackers?○ What can they benefit from attacking my product

PSCG

Building your own checklist

● Ask questions. Doubt everything. But be pragmatic.○ How hard am I willing to work? What is my team’s

skillset?○ How hard will my attacker be willing to work?○ What happens if an attacker succeeds?○ What is considered an attacker’s success?○ What hardware will they possess ○ Will it run a trusted OS?

■ This is actually not trivial - see my ROM cooking bootcamps

● So many questions...

PSCG

Building your own checklist

● Never stop asking.● But prioritize.● There is NEVER a general solution for all

problems.○ Saying otherwise is great for marketing ○ But that’s a brutal lie

● There are however 10 commandments which are always to be considered.

PSCG

The ultimate Security Checklist

● These 10 commandments would be○ Obfuscate and Shrink○ Optimize and Strip○ Encrypt your strings, assets, and data○ Encrypt database values○ And keep the keys away if you can○ Beware your client’s operating system○ Know what you want protect. Then know how○ Move your critical algorithms to native code - they will be harder to

rev-eng○ Remove any debugging/tracing/logging remainders○ Question, doubt and never stop thinking.

● And a bonus advice:○ Make your own commandments.○ You know yourself better than the others.

PSCG

Thank You

PSCG

Consulting/Training requests: ron@thepscg.com