ron munitz - the ultimate android security checklist - codemotion rome 2015
Post on 15-Jul-2015
245 Views
Preview:
TRANSCRIPT
PSCG
Ron Munitz
Founder & CEO - The PSCGron@thepscg.com
CodemotionRomeMarch 2015
@ronubo
The Ultimate Android Security Checklist
The slides are available online at: thepscg.com/talks/
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 2015
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
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 (Since Lollipop everything!)@ SE Linux ■ Multi-user sdcard @ FUSE■ Trusted boot support @ HW / kernel / up to apps
○ ...
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
Note: For older Android versions, there have been a known nasty exploit in installd that completely breaks this model… (and there have been several more since)
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
● 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
● But what if I don’t have Eclipse?○ Use jd-gui (my current choice)○ Use JEB ○ Use other commercials or non commercials tools
PSCG
Ahead Of Time Compiling (ART)
● Experimental support before Lollipop● Default Runtime since Lollipop● AOT is a next generation JIT
○ In “plain Italian”: 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, ...
Protecting Your Code
● There are no 100% bullet-proof protections● There are however effective hardening
methods such as○ Obfuscation○ String Encryption○ Asset Encryption○ Tamper Detection○ And more
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 [and more] with commercial tools
■ DexGuard - Proguard’s older brother○ Same as ProGuard but more and specifically for
Android.■ String Encryption■ Class Encryption■ Asset Encryption■ Tamper Detection■ ….
○ Not free or open sourced.
■ There are other tools that pretty much do the same things like DexProtector.
■ Any particular tool you use and would like to recommend?
PSCG
Protecting Your Code
● Some more (historical?) Java obfuscation/code shrinking tools:
■ yGuard■ JavaGuard■ JODE ■ jarg (really old)■ ...
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
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
There is by default some data protection● Q: What happens to existing data once a “Developer*
Phone” oem-unlocks ?● A: The unlock mechanism requires that the bootloader
erase any existing user data as part of the unlock step.● P(roblem): Root access gained via exploiting a kernel
bug or security hole can bypass this protection.
* Note that not all phones allow to unlock the bootloader. Yet it does not mean they are not exploitable
PSCG
Rooting Android
Relatively easy for most phones. 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
Rooting Android
Relatively hard for trusted-boot phones
New documentation update (Wow!):http://source.android.com/devices/tech/security/verifiedboot/index.html
This is pretty much like the Chrome-OS work, if you are familiar with it:http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot
* Note: ARM Trust-Zone is not something new. Yet it is not widely deployed in the Android ecosystem. (Care to speculatewhy?)
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…
PSCG
Thank You
PSCG
Consulting/Training requests: ron@thepscg.com
top related