Android Penetration Testing

42
Mobile Penetration Testing sainath volam

Transcript of Android Penetration Testing

Page 1: Android Penetration Testing

Mobile Penetration Testing

sain

ath

vo

lam

Page 2: Android Penetration Testing

INTRODUCTION TO MOBILE PLATFORM • BASICS

• WHY MOBILES?

• COMMON THREATS

• ANDROID ARCHITECTURE

• PROCESSORS

• STAKE HOLDERS

sain

ath

vo

lam

Page 3: Android Penetration Testing

BASICS OF MOBILE

sain

ath

vo

lam

Page 4: Android Penetration Testing

WHY MOBILES

http://gs.statcounter.com/

sain

ath

vo

lam

Page 5: Android Penetration Testing

Mobile Threat Model

sain

ath

vo

lam

Page 6: Android Penetration Testing

Mobile Threat Model

sain

ath

vo

lam

Page 7: Android Penetration Testing

COMMON THREATS

sain

ath

vo

lam

Page 8: Android Penetration Testing

WHAT IS ANDROID?

• OS or HARDWARE or PROGRAMMING LANGUAGE?

• VERSION HISTORY……..

• http://source.android.com/source/build-numbers.html

sain

ath

vo

lam

Page 9: Android Penetration Testing

ANDROID ARCHITECTURE

sain

ath

vo

lam

Page 10: Android Penetration Testing

ANDROID ARCHITECTURE (1)

• LINUX KERNEL: core of android which is responsible for memory management, process management, driver management.

• SQLite: lightweight version of database designed for mobiles.

sain

ath

vo

lam

Page 11: Android Penetration Testing

Dex(Dalvik Executable)

sain

ath

vo

lam

Page 12: Android Penetration Testing

PARTITIONS

• NAND flash memory is partitioned using

• BOOT LOADER: responsible for storing bootloader programs which initializes the hardware and implementing alternate boot modes like bootloader mode.

• SPLASH: stores the first splash screen which generally contains manufactures logo

• BOOT: stores the android boot image, which consists of a linux kernel(zimage) and the root file system ram disk(initrd).

• Recovery: stores a minimal android image that provides maintenance functions and serves as a failsafe.

• System: stores the android system image that is mounted as /system on a device. This image contains the android framework, libraries, system binaries and pre installed applications.

sain

ath

vo

lam

Page 13: Android Penetration Testing

PARTITIONS -1

• Userdata: device internal storage for application data and user files such as pictures, video, audio,and downloads. This is mounted as /data on the booted system.

• Cache: used to store recovery logs, update packages downloaded.

• Radio: a partition that stores the baseband image. This is responsible for telephony capabilities.

sain

ath

vo

lam

Page 14: Android Penetration Testing

LAB SETUP

• TOOLS OF TRADE:

• >=JDK1.6

• SDK

• GENYMOTION

• ORACLE VM

• NDK

• THE BEGINNING………….

sain

ath

vo

lam

Page 15: Android Penetration Testing

sain

ath

vo

lam

Page 16: Android Penetration Testing

ANDROID SECURITY MODEL

• Security at the OS level through the kernel

• Application sandboxing

• secure Inter process communication(IPC)

• Application signing

• Application defined user granted permissions

• Google Bouncer

sain

ath

vo

lam

Page 17: Android Penetration Testing

SECURITY AT OS LEVEL THROUGH THE LINUX KERNEL • PERMISSION ENFORCEMENT

• EVERY APP HAS IT’S OWN UID

• ……………………………..DEMO…………………………………

• adb shell

• ps

• Cat system/etc/permissions/paltform.xml

sain

ath

vo

lam

Page 18: Android Penetration Testing

APPLICATION SANDBOXING

• Each app runs inside it’s own sandbox(DVM)

• One app cannot access the data associated with another app.

• /data/data is the directory where all app data is located.

sain

ath

vo

lam

Page 19: Android Penetration Testing

APPLICATION SANDBOXING DEMO • Send an sms to your device or some other device.

• Get the adb shell

• Navigate to the sms app

• Cd /data/data/com.android.providers.telephony/databases/

• adb pull /data/data/com.android.providers.telephony/databases/mmssms.db

sain

ath

vo

lam

Page 20: Android Penetration Testing

APPLICATION COMPONENTS • Activity: An Activity provides a screen with which users can interact in order to do

something. Users can perform operations such as making a call, sending an SMS, etc.

• Example: Login screen of your Facebook app.

• Service: A Service can perform long-running operations in the background and does not provide a user interface.

• Example: Playing Music

• Content Providers: A content provider presents data to external applications as one or more tables. In other words, content providers can be treated as interfaces that connect data in one process with code running in another process.

• Example: Using content providers, any app can read SMS from inbuilt SMS app’s repository in our device.

• *READ_SMS permission must be declared in the app’s AndroidManifest.xml file in order to access SMS app’s data.

• Broadcast Receivers: A broadcast receiver is a component that responds to system-wide broadcast announcements such as Battery Low, boot completed, headset plug etc. Though most of the broadcast receivers are originated by the system, applications can also announce broadcasts.

sain

ath

vo

lam

Page 21: Android Penetration Testing

APPLICATION COMPENENTS…

• Intents: an intent is a simple message object which represents an intention of doing something.

Ex: am start –a android.intent.action.VIEW –d http://www.google.com

• Binders: a lightweight capability-based remote procedure call mechanism designed for high performance when performing in-process and cross-process calls. Binder is implemented a custom linux driver.

sain

ath

vo

lam

Page 22: Android Penetration Testing

APPLICATION SIGNING

• We can self sign the applications

• Any one can create his own certificate and sign the app.

• It is helpful if you want to inject the legitmate apps.

• Keytool, jarsigner,zipsigner

• Keytool and jarsigner are preinstalled with java

sain

ath

vo

lam

Page 23: Android Penetration Testing

VERIFYING APPS AND SIGNATURES USING KEYTOOL • Get the apk file from the device or internet

• Apk files are located at /data/app

• Adb pull /data/app/appname

• Extract the contents using winzip or winrar

• Locate META-INF/cert.rsa

• Open above file using keytool

• Keytool –printcert –file cert.rsa

sain

ath

vo

lam

Page 24: Android Penetration Testing

APPLICATION DEFINED USER GRANTED PERMISSIONS • Permissions should be declared by developer

• androidmanifest.xml takes care of it.

• User will get a popup to accept or deny during installation.

• We can accept all or deny all but we cannot choose.

• Androidmanifest.xml can’t be read directly.

• But there are ways in which we can do it.

sain

ath

vo

lam

Page 25: Android Penetration Testing

ANDROID APP STRUCTURE

sain

ath

vo

lam

Page 26: Android Penetration Testing

sain

ath

vo

lam

Page 27: Android Penetration Testing

M1- Weak Server Side Controls

• Applies to the backend services

• Not mobile specific, but essential to get it right.

• We still can’t trust the client

• Luckily, we understand these issues well

• Existing controls may need to be re-evaluated.

Impact

• Confidentially of data lost

• Integrity of data not trusted

sain

ath

vo

lam

Page 28: Android Penetration Testing

M1- Weak Server Side Controls Prevention Tips

• Understand the additional risks mobile apps introduce into existing architectures

• Leverage the wealth of knowledge that is already out there

• OWASP Web Top 10, Cloud Top 10, Web Services Top 10

• Cheat sheets, development guides, ESAPI

Control# Description

5.1-5.8 Keep the backend APIs (services) and the platform (server) secure

sain

ath

vo

lam

Page 29: Android Penetration Testing

M2- Insecure Data Storage

• Sensitive data left unprotected

• Applies to locally stored data + cloud synced

• Generally a result of: • Not encrypting data

• Caching data not intended for long-term storage

• Weak or global permissions

• Not leveraging platform best-practices

Impact

• Confidentiality of data lost

• Credentials disclosed

• Privacy violations

• Non-compliance

sain

ath

vo

lam

Page 30: Android Penetration Testing

M2- Insecure Data Storage

sain

ath

vo

lam

Page 31: Android Penetration Testing

M2- Insecure Data Storage Prevention Tips

• Store ONLY what is absolutely required

• Never use public storage areas (ie- SD card)

• Leverage secure containers and platform provided file encryption APIs

• Do not grant files world readable or world writeable permissions

Control# Description

1.1-1.14 Identify and protect sensitive data on the mobile device

2.1, 2.2, 2.5

Handle password credentials securely on the device sa

inat

h v

ola

m

Page 32: Android Penetration Testing

M3- Insufficient Transport Layer Protection

• Complete lack of encryption for transmitted data • Yes, this unfortunately happens often

• Weakly encrypted data in transit

• Strong encryption, but ignoring security warnings • Ignoring certificate validation errors

• Falling back to plain text after failures

Impact

• Man-in-the-middle attacks

• Tampering w/ data in transit

• Confidentiality of data lost

sain

ath

vo

lam

Page 34: Android Penetration Testing

M3- Insufficient Transport Layer Protection Prevention Tips

• Ensure that all sensitive data leaving the device is encrypted

• This includes data over carrier networks, WiFi, and even NFC

• When security exceptions are thrown, it’s generally for a reason…DO NOT ignore them!

Control# Description

3.1.3.6 Ensure sensitive data is protected in transit

sain

ath

vo

lam

Page 35: Android Penetration Testing

Input validation

• 1’or’1’=‘1 (input validation 1)

• Input validation 2

• Test with a website (www.google.com)

• Now try to read any file from the system

• # file:///data/data/jakhar.aseem.diva/<filename>

• We can read file from external storage if the application have external storage permissions

• An attacker can also read cookies or other sensitive information.

sain

ath

vo

lam

Page 36: Android Penetration Testing

Access control issues I

• API credentials are accessible to the user

• Can we access it from outside the application

• Lets check androidmaifest.xml

• It defines an intent filter with the name jakhar.aseem.diva.action.VIEW_CREDS

• So it’s like we can use am to invoke this intent

am start –a jakhar.aseem.diva.action.VIEW_CREDS

sain

ath

vo

lam

Page 37: Android Penetration Testing

Access control part II

• am start –a jakhar.aseem.diva.action.VIEW_CREDS2

• We are not lucky this time

• From the source code it is clear that the app is checking for a pin which is of boolean type

• Try to set the boolean to false

• dz>run app.activity.info –a jakhar.aseem.diva

• dz>app.activity.start --component jakhar.aseem.diva jakhar.aseem.diva.APICreds2Activity --extra boolean false

sain

ath

vo

lam

Page 38: Android Penetration Testing

Drozer

• Security assessment framework for android

• Install drozer in your system

• Try to send drozeragent.apk to the victim

• Game starts………

sain

ath

vo

lam

Page 39: Android Penetration Testing

Connecting to the client

• adb forward tcp:31415 tcp:31415

• C:\programfiles\drozer> drozer console connect

• dz>

sain

ath

vo

lam

Page 40: Android Penetration Testing

sain

ath

vo

lam

Page 41: Android Penetration Testing

Drozer (cont)

• dz> run app.package.list -f sieve

• dz> run app.package.info –a <package name>

• dz> run app.package.attacksurface com.mwr.example.sieve

• dz> run app.activity.info -a com.mwr.example.sieve

• dz> run app.activity.start - -component com.mwr.example.sieve com.mwr.example.sieve.PWList

• dz> run app.provider.info -a com.mwr.example.sieve

• dz> run scanner.provider.finduris -a com.mwr.example.sieve

• dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/

• This is just a beginning………….

sain

ath

vo

lam

Page 42: Android Penetration Testing

Webview exploitation

• What’s a Webview?

• Can you execute Javascript using Webview?

• Allows developers to display web content within apps

• Could be app content or for advertisements

• Sept 2013 : ~70% of the apps use webview

• Gives websites access to system related info and data

• Almost 95% of the entire Android users

• <script>var path=‘/data/data/web.exp.tw/databases/webview.db’;function execute(cmd){window.location.getClass().forName(‘java.lang.Runtime’).getMethod(‘getRuntime’,null).invoke(null,null).exec(cmd);}execute(*‘/system/bin/rm’, ‘-R’, path]);</script>

sain

ath

vo

lam