My Android Security session in Code Motion , December 2014, Tel-Aviv, Israel.
In this session I will present the essential security measures for Application Developers, show how to reverse engineer purely protected apps, and discuss what common security guidelines will and will not work against untrusted, rooted devices. The session will include the confessions of an evil, yet good attacker, and will unleash some serious security flaws you have probably never considered in your app development.
For Training/Consulting requests: info@thepscg.com
3. 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
5. 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
6. 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
7. 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
8. 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
9. 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
10. 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
11. 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
12. 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
13. 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
14. 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
15. 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
16. 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
17. System Permissions
Summary of application isolation
No 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
18. System Permissions
Reaching out of the basic sandbox
Applications 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
19. 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
20. System Permissions
Example of some permissions
ACCESS_NETWORK_STATE
● Allows applications to access information about networks
CHANGE_NETWORK_STATE
● Allows applications to change network connectivity state
DUMP
● 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
21. 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
22. Application Signing
All 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
23. 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
24. 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
25. 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
26. 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
27. 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
28. 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
29. 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
34. 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
35. 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
37. 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
38. 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
39. 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.properties
ex: # proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt
■ Find examples for proguard-project.txt in Proguard’s webpage.
PSCG
40. 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
41. Protecting Your Code
● Obfuscate your code
○ Obfuscation Tools
■ There are more obfuscation companies for java
protection
● yGuard
● JODE
● JavaGuard
● jarg
● ...
PSCG
42. 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
43. 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
44. 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
45. 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
46. 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
47. 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..>
48. Ahead Of Time Compiling (ART)
$ oatdump --oat-file=system@priv-app@Settings.apk@classes.dex ### Excerpts
MAGIC:
oat
042
CHECKSUM:
0x48675513
INSTRUCTION SET:
X86_64
INSTRUCTION SET FEATURES:
none
DEX FILE COUNT:
1
…...
51. 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, ...
52. 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
53. 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
54. 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
55. 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
○ ...
56. 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
57. 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
58. 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
59. 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
60. 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
61. Rooting Android
Relatively easy. Almost too easy (@see XDA)
There is a protection
To 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
62. 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
63. 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
64. 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
65. 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
66. 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
67. 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
