+ All Categories
Home > Documents > Mobile Hacking & Security - Black Hat Sessions...

Mobile Hacking & Security - Black Hat Sessions...

Date post: 25-Dec-2018
Category:
Upload: trankhanh
View: 226 times
Download: 1 times
Share this document with a friend
25
Mobile Hacking & Security Ir. Arthur Donkers & Ralph Moonen, ITSX
Transcript

Mobile Hacking & Security

Ir. Arthur Donkers & Ralph Moonen, ITSX

Introduction

Who we are:

• Ir. Arthur Donkers

• Ralph Moonen

• ITSX

2

Agenda

• Mobile Threats

• BYOD

• iPhone and Android hacking

3

Threats

Various:

• Lost or stolen device (responsible for 80% of data

loss)

• As attack vector: use it to compromise network

• As attack surface: get at the data on the phone

(think: TAN codes, certs, passwords)

4

Threats

Or, if you are the maker of an app:

• How to protect the app itself

• How to protect the app’s data

• How to protect the backend applications that the app

talks to

During our workshop in Malaysia, this turned out to be the

most interesting topic!

5

Threats

But it doesn’t stop there:

• There are threats on the communications layer

• Prediction: amateur GSM/SMS tapping possible

within a year using EUR 30 devices and free

software

• NFC-enabled phones allow new ways of interfacing

with phone and the world around the phone

• Botnets and Trojans now seen in the wild

6

BYOD

Lets take a closer look at a few topics:

• BYOD

• Is it a good idea?

• Well…..

• To be honest: probably not, in most cases.

• Allowing modified devices with a large amount of

unknown applications that often ‘live’ in hostile

environments on your network requires a lot of

thinking.

7

BYOD

But we really want it:

• Need to isolate device

• Need to educate user

• Need to restrict access

• Do you want email attachments on the phone

• Do you want server access from phone

• How to authenticate user and device?

• Jailbroken devices more susceptible to malware

8

iPhone & Android hacking

Android

• Is a far more open platform than iOS;

• No App vetting in Google Play

• Multi vendor (roots @Google, now part of OHA, Open

Handset Alliance, with over 50 participants);

• Uses a mix of open source and proprietary software

environments;

• The basics are more or less the same across

• different vendors, main difference is in UI.

9

Android apps

Android

• Uses the Dalvik Virtual Machine, that is capable of

running different apps in parallel, each in their own

VM.

• Interesting information is stored in Libraries,

primarily in SQLite3 databases (similar to iOS).

These might be encrypted.

• These database can be stored on the internal flash or

memory cards (SD, uSD)

10

Data storage

If data is stored on a memory card, extraction is easy.

• Connect phone via USB;

• Access memory card using forensics software (FTK

imager)

• Make a forensics image;

• Analyse image (FAT32 filesystem);

Phone often appears as a USB stick on computer

11

Data storage

12

Data storage

What about the internal flash?

• Use dd to make image of primary flashdrive;

• Need root to be able to bypass permissions on

phone

Phone normally does not offer root level access, so phone

needs to be rooted.

This is device dependent and modifies the phone (forensic

principles)

13

Data storage

Needs USB debugging (to be able to control the device via

USB port);

Also needs to bypass lock screen (same old story);

Sometimes additional apps are required.

14

Accessing data

An example:

• Set up ADT (Android Development Tools);

• Put fresh sd card in phone;

• Connect phone to computer and run adb to test

connectivity and USB debugging;

• Download asroot2 or ‘su’

• Run from adb

15

Reading data

Finally, use normal forensic tools to analyse these images

like:

• FTK

• File carving (foremost)

• Undelete files

• Read SQLite3 database for call & SMS log

• /data/data/com.android.providers.telephony/datab

ases

16

Reverse engineering

Simply put: figuring out how stuff works

Need to get at the code in a readable form:

• Unencrypted

• Unobfusacted

• Decompiled

17

Looking at android apps

Dalvik is encapsulated JAVA code

Java code is bytecode compiled

Therefore, Dalvik is easy to reverse engineer:

• Get .dex file

• Run dex2jar

• Decompile to .java files using JAD

• Load resulting Java files into Eclipse

18

iPhone apps

Iphone apps are stored in .ipa files

These are .zip files: copy and rename to .zip

Look in filestructure for interesting files and resources

No easy way to decompile like Android apps

19

iPhone apps

Can be disassembled using ‘otx’ and/or ‘otool’

Unfortunately, is not easy and readable

Often: measures taken such as stripping

IDAPro also possible

20

Decoding apps

What to look for:

• Connection strings

• Passwords (encrypted or not)

• Configuration files

• Certificates

• Security Bugs

21

Securing Apps

Securing Apps has several aspects:

• Obfuscation

• Integrity checks on app

• Integrity checks on phone (am I jailbroken)

• Storage of secrets

22

Getting into the iPhone

The ramdisk needs to be booted through Jailbreak tools.

Once booted, communications need to be multiplexed over

the USB connection.

Once that has been done, access can be obtained via SSH

shell.

23

Demo time

We need to bypass Unlock key (passcode)

Can only be done by bruteforce (on kernel level):

Passcode Complexity Bruteforce time

4 digits 18 minutes

4 alphanumeric 51 hours

5 alphanumeric 8 years

8 alphanumeric 13,000 years

24

Workshop

25


Recommended