As presented in DroidCon Tel Aviv 2015 http://il.droidcon.com

1. Hacking Android Apps
Erez Metula, Application Security Expert
AppSec Labs (Founder & CEO)
ErezMetula@AppSec-Labs.com

2. Agenda
Introduction to android application security model
Mobile app security – why should we care?
Top 10 of the most common android app
vulnerabilities
DEMOS !

3. About me
Application security expert
Founder & CEO of AppSec Labs
Book author - Managed Code Rootkits
Speaker - BlackHat, Defcon, RSA, OWASP, etc.
Trainer - Secure Coding / Hacking

4. Android Security Model
Well established OS, based on Linux
Sandboxed VM runtime (“Dalvik”) similar to Java’s JVM
The OS creates unique user for each app
Each app runs in a sandbox using its UID
Security is enforced at the OS and the App level
Each app is signed
Applications are totally isolated by default
So where’s the problem ???

5. Top 10 – most common
vulnerabilities (OWASP)
1. Weak Server Side Controls
2. Insecure Data Storage
3. Insufficient Transport Layer Protection
4. Unintended Data Leakage
5. Poor Authorization and Authentication
6. Broken Cryptography
7. Client Side Injection
8. Security Decisions Via Untrusted Inputs
9. Improper Session Handling
10. Lack of Binary Protections

6. Things an attacker will probably do
Reverse engineering the APK – peek into code, manifest file,
etc
Grab all app files stored in /data/data/
Debug the running app & Setting breakpoints
Hook important runtime calls
Monitor & manipulate network traffic (sniffing, proxying)
Monitor process activity
Observing file access
Analyze memory dumps (MAT, hprof dumps)

7. Weak Server Side Controls

8. Weak Server Side Controls
Using the android mobile app to attack the server
business logic
Not a risk specific to the mobile platform
Common server side vulnerabilities such as SQL
injection, XSS, insecure authentication, etc.
Often by redirecting the phone’s request to a proxy
and manipulate with it

9. DEMO
Intercepting and manipulating client/server
requests

10. Insecure Data Storage

11. Insecure Data Storage
Many of the most publicized mobile application security incidents have
been caused by insecure or unnecessary client-side data storage.
Sometimes app developers assume the app data cannot be accessed by
an attacker
Sensitive information – usernames, passwords, Encryption keys,
Credit cards, session identifiers, tokens, etc.
Private information - Phone numbers, Addresses, Emails, locations
Interesting places that might contain sensitive data
SQLite databases
Log Files
XML Data Stores or Manifest Files
Binary data stores
SD Card
Cloud

12. Insecure File Permissions
In general, app files are sandboxed
Writing files with poor permissions
Files on /data/data/APP/ with “everyone read”
Files stored on SDcard (no permissions !!)
Allows AppA to steal files from AppB
Example – Skype bad permissions - steal contacts !

13. Insufficient Transport Layer
Security (no HTTPS)

14. Insufficient Transport Layer
Security (no HTTPS)
“10% of apps fail doing SSL cert validation” - CERT
HTTPS (TLS or SSL), are cryptographic protocols that
provide communication security over the Internet:
Encrypting the transport layer
Authentication the server side
Any request sent without HTTPS is vulnerable to..
Information disclosure
Data tampering
Server spoofing and phishing

15. Another common Mistakes – no
cert validation
• usage of out of date/self signed SSL certificates
TrustManager[] trustAllCerts = new TrustManager[] { new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return new java.security.cert.X509Certificate[] {};
}
public void checkClientTrusted(X509Certificate[] chain, String authType)
throws CertificateException { }
public void checkServerTrusted(X509Certificate[] chain, String authType)
throws CertificateException { }
}};

16. Unintended Data Leakage

17. Unintended Data Leakage
Unintended data leakage occurs when
a developer accidentally places sensitive data in a location on the
mobile device that can be accessed by other apps / physical access
Another case is during sensitive data processing, a side-effect (that is
unknown to the developer) results in that information being placed
into an insecure location
Examples - places to look for
URL Caching (Both request and response)
Keyboard Press Caching
Copy/Paste buffer Caching
Application backgrounding
Logging
HTML5 data storage
Browser cookie objects
Analytics data sent to 3rd parties

18. Example - Insecure Log Exposure
Some apps store their own logs inside the local folder
Logs can contain info such as
Important events (app start, user login details, page load)
Exceptions
Sensitive variables (encryption keys, serial numbers)
Sensitive information (credit cards, passwords)
Often such files are stored without any protection at
the file system
Sometimes such files don’t even have any file
permission protection – any app can steal such info

19. Common Pitfall - Leaking
Information to Runtime Logs
Private information is often written to logs
Location, Phone identifiers ,Passwords, CC, URL, etc

20. Poor Authorization and
Authentication

21. Poor or missing authentication
Attacker van to anonymously execute
functionality
Can also allow to impersonate other
users
Sometimes weak passwords can lead to
broken authentication
Strong passwords are hard to enter on a
mobile device
Short passwords (4-digit PINs) are often
used

22. Poor Authorization and
Authentication
Example - Device authentication based on IMEI,
IMSI, UUID is not sufficient
Hardware identifiers persist across data wipes and factory resets
Don’t use device identifier as session token
Another example - When security is enforced at the
client side
The UI shows the user only what he can do. What he cannot is
disabled or just not visible
Attacker can bypass this quite easily

23. Demo
IMEI restriction bypass with ReFrameworker

24. Broken cryptography
(“Encraption”)

25. Broken cryptography
(“Encraption”)
Usage of a broken or risky cryptographic algorithm may result
in the exposure of sensitive information.
Configuration files or databases belonging to the app may
contain some encrypted data
Many times the app does bad encryption
Hard-coded key is stored in the source code
Same key for all users
Key can be stolen by other apps due to bad permissions
Key is stored right next the encrypted data
Custom, easily defeated crypto implementations (“encraption”)
Encrypting some data while storing the encryption key at the
client side does not help that much

26. Spot the bug
what’s wrong with this code?
Spot 3 different bugs related to encryption!!!!
Hard
coded
key
Bad
algorithm
Bad
crypto
mode

27. Client side injections

28. Client side injections
Results in the execution of malicious code
Malicious code is provided in the form of input that
is processed by the app
During processing, the input is interpreted as
executable code which is executed by the app,
running with its access permissions
Input can come from
Another app via intent/content provider
Shared file (ex: sdcard) manipulated by another app
Server side response
3rd party web site

29. Some examples
SQL Injection – embedding untrusted input into raw SQL statements
String query = "select * from table where columnName=‘“+external_input+”’”;
db.rawQuery( query, null );
Command Injection – embedding untrusted input into OS command execution
Process process = Runtime.getRuntime().exec("top -n “ + external_input );
Directory traversal – using a manipulated file name
basePath = “/sdcard/DCIM/”;
Filename = getInput();// “../../data/data/target.app.packagename/shared_prefs/preferences.xml”
openFileOutput(basePath+filename, Context.MODE_WORLD_READABLE);
XSS/Javascript injection into WebView – embedding input into HTML
String htmlCode = "<html><body><button type="button" onclick="myFunction()">+ external_input
+"</button></body></html>";
webView.loadDataWithBaseURL("null", htmlCode, "text/html", "UTF-8", null);

30. Security Decisions Via Untrusted
Inputs

31. Insecure IPC
(Inter Process Communication)
Interoperability - A unique aspect of the Android system design is that any
application can start another application’s component
Apps are sandboxed, and cannot directly activate a component from another
application.
Therefore, to activate a component in another application, apps deliver an
asynchronous message to the system (“intent”)
The system then activates the target component

32. Exposed components
Components are not visible to other apps by default. Unless….
It has At least one <intent-filter> tag
It is declared as exported “exported=true”
<receiver android:name="com.appsec.hackmepal.BrReciever" android:exported="true"> </receiver>
It is a dynamically registered broadcast receiver
public

33. Insecure IPC
(Inter Process Communication)
If it is exposed, and you didn’t use android:permission than
you’re screwed.. ☺☺☺☺
Some examples
Unauthorized caller/intent spoofing
Permission re-delegation/Confused deputy
Phishing/CSRF
Intent sniffing
DoS
Component hijack/identity theft

34. DEMO
Intent Denial of Service (DoS)

35. Improper Session Handling

36. Improper Session Handling
Mobile apps often use session tokens to maintain
state over stateless protocols like HTTP or SOAP
Client authenticates with the backend server
gets a session cookie in response
Cookie is added to all requests sent to the server
Server can enforce authentication and authorization
Common mistakes
Insecure Token Creation
Failure to Invalidate Sessions on the server side
Lack of Adequate Timeout Protection
Failure to Properly Rotate Cookies (timeout, changing user role, etc).

37. Lack of Binary Protections

38. Lack of Binary Protections
Exposure of the application to a variety of risks
Results in a mobile app that can be analyzed,
reverse-engineered, and modified
It is extremely common for apps to be deployed
without binary protection.

39. The Problem of Reversing &
Decompilation
Major risks
Code exposure
Business logic (secret algorhithms, etc)
Security vulnerabilities in the code
Secrets in code (passwords, Encryption keys, etc)
Software piracy
Code modification
Add backdoors to original code
Patching - Change the application logic, add or remove
functionaliy, etc

40. Reverse engineering
Extract application from device (adb pull app.apk)
Reverse Engineering the apk
Extracting the APK content
apktool d someapp.apk –o outputDir
Disassembly
Smali/baksmali
Decompile the APK
dex2jar - Converting the classes.dex file to a jar
Decompiling the jar file and getting java source code
Analyzing the app
Locating sensitive files on device storage, Insecure file permissions, Locating
secrets in code/config files, Tracking insecure IPC, etc.
Patching the apk
Rebuilding the APK content
apktool b outputDir –o new.apk
Re-Signing modified apk’s
Signapk new.apk new_signed.apk
Put it back (adb push new_signed.apk)

41. Obfuscated Code and
anti-debugging
Although it’s a bit harder to read, class and member types
must stay the same..
Encrypted values must have the key somewhere near
Anti debugging code can be removed…

42. Summary
Android application level vulnerabilities put the service and
the end user at risk
Never take any security decisions at the Android side!
Remember this: “APK = open source code”. This way you’ll
avoid doing stupid things (security wise ☺)
Integrate security into your development lifecycle
Performing penetration testing on your Android apps

43. QUESTIONS ?

44. THANK YOU !
ErezMetula@AppSec-Labs.com
Download AppUse for free:
https://appsec-labs.com/appuse/