android app hacking - erez metula, appsec
TRANSCRIPT
Hacking Android Apps
Erez Metula, Application Security Expert
AppSec Labs (Founder & CEO)
Agenda
Introduction to android application security model
Mobile app security – why should we care?
Top 10 of the most common android app vulnerabilities
DEMOS !
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
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 ???
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
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)
Weak Server Side Controls
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
DEMO
Intercepting and manipulating client/server requests
Insecure Data Storage
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
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 !
Insufficient Transport Layer Security (no HTTPS)
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
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 { }
}};
Unintended Data Leakage
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 accessAnother 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 forURL Caching (Both request and response) Keyboard Press Caching Copy/Paste buffer Caching Application backgroundingLogging HTML5 data storage Browser cookie objects Analytics data sent to 3rd parties
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
Common Pitfall - Leaking Information to Runtime Logs
Private information is often written to logs
Location, Phone identifiers ,Passwords, CC, URL, etc
Poor Authorization and Authentication
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
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
Demo
IMEI restriction bypass with ReFrameworker
Broken cryptography (“Encraption”)
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
Spot the bug
what’s wrong with this code?
Spot 3 different bugs related to encryption!!!!Hard
coded
key
Bad
algorithm
Bad
crypto
mode
Client side injections
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 fromAnother app via intent/content provider
Shared file (ex: sdcard) manipulated by another app
Server side response
3rd party web site
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);
Security Decisions Via Untrusted Inputs
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
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
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
DEMO
Intent Denial of Service (DoS)
Improper Session Handling
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).
Lack of Binary Protections
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.
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
Reverse engineering
Extract application from device (adb pull app.apk)
Reverse Engineering the apkExtracting the APK content
apktool d someapp.apk –o outputDir
DisassemblySmali/baksmali
Decompile the APK
dex2jar - Converting the classes.dex file to a jar
Decompiling the jar file and getting java source code
Analyzing the appLocating sensitive files on device storage, Insecure file permissions, Locating secrets in code/config files, Tracking insecure IPC, etc.
Patching the apkRebuilding the APK content
apktool b outputDir –o new.apk
Re-Signing modified apk’sSignapk new.apk new_signed.apk
Put it back (adb push new_signed.apk)
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…
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
QUESTIONS ?
