android app hacking - erez metula, appsec
TRANSCRIPT
![Page 1: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/1.jpg)
Hacking Android Apps
Erez Metula, Application Security Expert
AppSec Labs (Founder & CEO)
![Page 2: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/2.jpg)
Agenda
Introduction to android application security model
Mobile app security – why should we care?
Top 10 of the most common android app vulnerabilities
DEMOS !
![Page 3: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/3.jpg)
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
![Page 4: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/4.jpg)
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 ???
![Page 5: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/5.jpg)
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
![Page 6: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/6.jpg)
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)
![Page 7: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/7.jpg)
Weak Server Side Controls
![Page 8: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/8.jpg)
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
![Page 9: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/9.jpg)
DEMO
Intercepting and manipulating client/server requests
![Page 10: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/10.jpg)
Insecure Data Storage
![Page 11: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/11.jpg)
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
![Page 12: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/12.jpg)
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 !
![Page 13: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/13.jpg)
Insufficient Transport Layer Security (no HTTPS)
![Page 14: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/14.jpg)
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
![Page 15: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/15.jpg)
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 { }
}};
![Page 16: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/16.jpg)
Unintended Data Leakage
![Page 17: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/17.jpg)
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
![Page 18: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/18.jpg)
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
![Page 19: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/19.jpg)
Common Pitfall - Leaking Information to Runtime Logs
Private information is often written to logs
Location, Phone identifiers ,Passwords, CC, URL, etc
![Page 20: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/20.jpg)
Poor Authorization and Authentication
![Page 21: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/21.jpg)
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
![Page 22: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/22.jpg)
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
![Page 23: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/23.jpg)
Demo
IMEI restriction bypass with ReFrameworker
![Page 24: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/24.jpg)
Broken cryptography (“Encraption”)
![Page 25: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/25.jpg)
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
![Page 26: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/26.jpg)
Spot the bug
what’s wrong with this code?
Spot 3 different bugs related to encryption!!!!Hard
coded
key
Bad
algorithm
Bad
crypto
mode
![Page 27: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/27.jpg)
Client side injections
![Page 28: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/28.jpg)
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
![Page 29: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/29.jpg)
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);
![Page 30: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/30.jpg)
Security Decisions Via Untrusted Inputs
![Page 31: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/31.jpg)
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
![Page 32: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/32.jpg)
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
![Page 33: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/33.jpg)
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
![Page 34: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/34.jpg)
DEMO
Intent Denial of Service (DoS)
![Page 35: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/35.jpg)
Improper Session Handling
![Page 36: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/36.jpg)
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).
![Page 37: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/37.jpg)
Lack of Binary Protections
![Page 38: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/38.jpg)
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.
![Page 39: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/39.jpg)
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
![Page 40: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/40.jpg)
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)
![Page 41: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/41.jpg)
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…
![Page 42: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/42.jpg)
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
![Page 43: Android App Hacking - Erez Metula, AppSec](https://reader034.vdocuments.mx/reader034/viewer/2022042602/55cbcf99bb61eb431e8b46e2/html5/thumbnails/43.jpg)
QUESTIONS ?