Android Mobile Application Hacking

OWASP IL 2012

Erez Metula , Application Security Expert AppSec Labs (Founder) ErezMetula@AppSec-Labs.com

About me
Founder of AppSec Labs Application security expert Book author
Managed Code Rootkits (Syngress)

Speaker & Trainer

Presented at BlackHat, Defcon, RSA, OWASP, etc.. Secure Coding / Hacking trainer

About AppSec Labs

Expert application security company focusing mainly on Web & Mobile apps Cutting edge application security services
Penetration testing Training Developers, IT Consulting Secure coding

Provider of cloud based application security training

Agenda
Introduction to mobile security Android PT workspace Common Mistakes & Attack Vectors AppUse VM for mobile PenTesting

We are more connected than ever

Mobile device growth some facts

80% of the world have a mobile device Some countries have more devices than people Some countries have more devices than toilets
Example - India

What makes mobile application security so different?

Different threat model
Some vulns stayed the same - sqli, xss, authz New vulns related to client side attacks such as other app attacking our app !

Different tools required for pentesting

No more mostly all I need is a proxy

Different skills for pentesters

Reversing is a key factor

Lack of (mature) security tools

Challenges for performing Android PT

Tools many micro tools Knowledge lots of things to know Complexity multiple steps are involved even for simple operations
Static Analysis - Extract application from device, Reverse Engineering , Explore file system deployment, Locating secrets in code/config files, Disassembly, Patching Dynamic Analysis - Debug the running app, Analyze memory dumps, Analyze network traffic, Analyze remote services, Manipulate network traffic

Until we created AppUse..

AppUse
Formal definition: Android Pen-test Platform Unified Standalone Environment Informal definition: App + Abuse = AppUse In short - Open source Linux VM loaded with everything needed for Android application PT (custom emulator, tools, IDE, practice apps, etc.) Download: https://appsec-labs.com/AppUse

DEMO information gathering with AppUse

manifest apk dex permissions apktool apkinspector

Intro to Android Linux OS security

Android was designed from the ground up with a strong security model (the sandbox) Each app runs in its own Linux process with its own UID by default.
Each app runs as a separate user Each app runs in a separate process Each app runs with different permissions Each app has its own DB

Applications are signed with the developers key

So what are the vulnerabilities were after?

Server side (old school) vulnerabilities

Nothing new here look for server side vulns such as sqli, xss, auth, authz, etc
Not related at all to Android Redirect the phones request to a proxy and manipulate with it Can be tricky apps dont like proxy certs
You need to push the proxys into the phone

Unprotected communication
Another old school.. Not using any transport encryption such as SSL..
No encryption No server side authentication

Insecure file system permissions

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

Insecure file system storage

Storing sensitive data by the app
Passwords Encryption keys Credit cards

Even if the app does restrict access (as opposed to previous slide), its still a problem
Device can get lost Device can be stoled

Phone identiers used in authentication

Binding some phone identifier (usually the IMEI) as a unique identier to network requests.
Served as kind of a cookie

IMEI is often tied to PII

Intents - Androids IPC mechanism

Unprotected Broadcast Receivers

Similar to web forceful browsing Applications use broadcast receiver components to receive intent messages. If the receiver is not protected by a permission, a malicious application can forge messages. Victims side:

DEMO unprotected content provider

Similar to broadcast receiver, but this time the focus is data rather than functionality

DEMO - Dropbox

Leaking Information via unsafe broadcasts

any application can receive intent broadcasts that
do not specify the target component protect the broadcast with a permission

Can lead to exposure of sensitive information by malicious apps

Leaking Information to Logs

Android provides centralized logging API Private information is often written to logs
Location, Phone identified, Passwords, CC, etc. Any app with the READ_LOGS perm can read from it Example taken from recent PT:

DEMO Logcat (webgoat login)

Intent DoS
Android applications frequently process intents received from other applications. Many times theres no input validation, which can DoS the service
Example - null checks on IPC input

Null dereferences cause an application to crash, and can thus be used to as a DoS

Local SQL Injections

Different attack vector than regular sqli !!
In regular sqli the client is the attackr In mobile sqli the client is the victim

Unauthorized access to paid-for resources

wallet, SMS, phone calls, NFC Apps with privileged access to such APIs can abuse and/or be abused

Advanced usage of Android Rootkits

Android rootkits - Modify the Android device!
Rootkit like technique (as described in my book Managed Code Rootkits) to alter the behavior of the dalvik VM Affects ALL applications without touching the APK

Replace internal Android VM internal parts of code to Create a pentester friendly environment
Disable security mechanisms (ex: SSL checks) Hook into important functions Change return values, parameters, etc. Get notification when specific function is called Break on function execution

DEMO NFC breakpoint

Summary
Mobile app security is more important than ever Mobile App PT requires different skills & tools than traditional Web App PT Dont reinvent the wheel. Use AppUse for your mobile PenTesting (new version soon!!!) https://appsec-labs.com/AppUse We provide mobile app security hands-on training
Hacking Secure coding