Post on 19-Oct-2015
description
Android Mobile Application Hacking
Erez Metula , Application Security Expert
AppSec Labs (Founder)
ErezMetula@AppSec-Labs.com
OWASP IL 2012
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
AppUseVM 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 identifiers used in authentication
Binding some phone identifier (usually the IMEI) as a unique identifier 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 dalvikVM
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 & toolsthan 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