Security CS 4720 Mobile Application Development CS 4720 The - - PowerPoint PPT Presentation

CS 4720

Security

CS 4720 – Mobile Application Development

CS 4720

The Traditional Security Model

• The Firewall Approach
• “Keep the good guys in and the bad guys out”

2

CS 4720

Distributed System Security

3

• “Islands of Security”

CS 4720

Security with Web Services

• These models were just fine when corporations

had their own networks

• If you needed in, you used a VPN
• Now the open Internet is used as the main

network

• How does this change the security model?
• Consider this: how do you access a web

service?

4

CS 4720

Security with Web Services

5

• Firewall security happens at

the network layer

• But now we need access on a

per-application basis

• How can we achieve that?

CS 4720

Security with Web Services

6

• Web services are designed to penetrate

firewalls, since they use port 80

• Application-level security is needed to

examine:

– Who is making a request – What info is being accessed – What services is being addressed

• IP based security is still needed though!

CS 4720

Application Security 101

• What are some basic things you do to protect

your system at the application level?

• Catch exceptions and don’t show detailed error

messages

• Hide interfaces
• “Don’t trust your users”
• Encryption

7

CS 4720

Application Security 101

8

• Well… shoot.
• Web services:

– Have publically announced interfaces! – Must return detailed exceptions to debug systems! – At some level, must trust users!

• We need security that is basically content-

aware

CS 4720

System Security

9

• Human: social engineering attacks
• Physical: “steal the server itself”
• Network: treat your server like a 2 year old
• Operating System: the war continues
• Application: just discussed
• Database: protecting the data

CS 4720

Content-Aware Security

• Must be able to inspect content of network

traffic

• Must be able to make authorization decisions
• Must be able to make authentication decisions
• Must be able to verify data as valid for this

transaction

• Must also deal with confidentiality and privacy

concerns (encryption, message integrity, audit)

10

CS 4720

Web Service Security Concerns

• Unauthorized Access: people view info that

they shouldn’t from a message

• Unauthorized Alteration: an attacker modifies

part of a message

• Man-in-the-Middle: an attacker sits in-between

two parties and views messages (or alters them) as they pass by

• Denial-of-Service: flood the service with so

many messages that it can’t keep up

11

CS 4720

Application Level Security

• Refers to security safeguards built into a

particular application and operate independently from the network level security

• Authentication
• Authorization
• Integrity / Confidentiality
• Non-repudiation / Auditing

12

CS 4720

Authentication

• Verifying that the requester is the requester…
• … and that the service is the service
• This requires a mechanism of “proof of

identity”

• What are some ways accomplish this?
• Username / password
• Signed Certificates
• Authentication Applications

13

CS 4720

A little closer to home

• Netbadge (or more

accurately, PubCookie or Shiboleth)

• http://www.pubcoo

kie.org/docs/how- pubcookie- works.html

14

CS 4720

Authorization

• Now that we know who you are, what are you

allowed to do?

• Permissions
• Role-based security
• How does this work in a database system?
• How about an operating system?

15

CS 4720

Integrity / Confidentiality

• What happens if a message is:

– Captured and reused? – Captured and modified? – Monitored as is passes by in a passive manner?

• How do we verify a message hasn’t been

tampered with?

– Digital signature

• How do we verify it hasn’t been viewed?

– Encryption

16

CS 4720

Non-repudiation / Auditing

• When we’re charging to use a web service,

how do we prove you used the service so we can charge you?

• How do we track your activities?
• Digitally signed logs, effectively
• Also saves the certificate used to perform the

transaction (like a signature on a receipt)

17

CS 4720

Mobile Security

• Questions to ask yourself as a developer:

– Is the mobile backend as secure as the app itself? – Is data encrypted whenever and wherever it’s stored? – Does the app use HTTPS encryption – and enforce it? – Has the app binary been scrubbed of sensitive information? – Have steps been taken to thwart reverse engineering and analysis?

18

CS 4720

Mobile Security

• What are the “bad guys” after?

19

CS 4720

Mobile Security

• Personal data stored on the device

– Not just name and address! – Passwords – Confidential documents – Financial information

• Sensor data

– GPS location (to track people) – Microphone / Camera (espionage)

• False installs (for ad hits, for instance)

20

CS 4720

Mobile Security

• Now we know what we are up against
• So… how do we stop them?
• What are some “best practices”?
• What features of the platforms should we be

utilizing?

• Where are the attacks coming from (where are

the weak points)?

21

CS 4720

Mobile Security

• Core Features / Best Practices

– Executing in a sandbox – Utilizing system level permissions – Implementing application permissions – Encrypted or “hardened” file system – Remote policy management – Remote device locating / wipe

22

CS 4720

Executing in a Sandbox

• Both iOS and Android run on a Unix-based

kernel

• Apps are given their own user id and execution

space with each app running in a VM

• By default, one app cannot touch another

app’s data

23

CS 4720

Permissions

• Android: permissions declared up-front on

install

• iOS: permissions requested ad hoc during

execution

• In both cases, the main problem is an

uninformed (or misinformed) user

24

CS 4720

Permissions

• Example: The app wants to access your

location… why?

• Does it have a purpose for the functionality?
• If it does, does the author communicate the

benefits of this feature appropriately?

• What is the challenge to do this between

Android and iOS?

25

CS 4720

Encryption / Hardened File System

• What if you just don’t trust Google / Apple?
• For Android, the OS is open source
• Blackberry offered a hardened version for a

long time – that one reason it was adopted as the platform of choice for the government

• https://copperhead.co/android/

26

CS 4720

Policy Management

• Ever been issued a laptop as a part of an

internship?

• What could you do with/on that machine?
• What protections were on that machine?

27

CS 4720

Policy Management

• You don’t expect to get to use your personal

machine for work stuff…

• … but many (most? all?) people don’t want to

have two phones!

• A large problem with mobile security in a

corporation is BYOD (Bring Your Own Device)

• How do you keep things separate?

28

CS 4720

Policy Management

• MDM (Mobile Device Management)
• Can put specific usage policies on a device (if
• wned by company)
• Can partition away business operations

– Can run basically like a virtual machine on the same device

• http://www.apple.com/iphone/business/it/

29

CS 4720

Compression and Obfuscation

• Java bytecode, unlike fully compiled code, is

relatively easy to reverse engineer

• Further, we tend to leave lots of “clues” in our

code

– Variable names – Class names – Method names

• It’s relatively easy to “rebuild” a Java app!

30

CS 4720

Compression and Obfuscation

• Java programmers also tend to leave a lot of

“cruft” behind…

– Debug messages (logging that’s not needed) – Lots of extra white space – Lots of comments

• Sometimes, you have to get that .apk as small

as possible…

31

CS 4720

Compression and Obfuscation

• ProGuard

– detects and removes unused classes, fields, methods, and attributes from your packaged app – optimizes the bytecode – removes unused code instructions – obfuscates the remaining classes, fields, and methods with short names

32

CS 4720

ProGuard

33

CS 4720

ProGuard

34

public void onCreate(Bundle paramBundle) { super.onCreate(paramBundle); WL.createInstance(this); WL.getInstance().showSplashScreen(this); WL.getInstance().initializeWebFramework(getAppl icationContext(), this); }

CS 4720

ProGuard

35

public void onCreate(Bundle paramBundle) { super.onCreate(paramBundle); com.worklight.androidgap.b.a.a(this); com.worklight.androidgap.b.a.b(); com.worklight.androidgap.b.a.b(this); com.worklight.androidgap.b.a.b().a(getApplicati

• nContext(), this);

}

CS 4720

Stack Traces?

• What do you do when a user (or app) submits a

stack trace for you to debug?

• Ever run of ProGuard generates a mapping.txt

file that contains info on how to undo the

• bfuscation
• This file can be uploaded to Google Play with

your .apk and Google will handle it for you!

36

CS 4720

mapping.txt

37

cs4720.cs.virginia.edu.sensorexample.AccelSensor -> cs4720.cs.virginia.edu.sensorexample.AccelSensor: android.hardware.SensorManager mSensorManager -> a android.hardware.Sensor mSensor -> b double maxValue -> c void <init>() -> <init> void onCreate(android.os.Bundle) -> onCreate void onAccuracyChanged(android.hardware.Sensor,int) ->

• nAccuracyChanged

void onSensorChanged(android.hardware.SensorEvent) ->

• nSensorChanged

void onResume() -> onResume void onPause() -> onPause boolean onCreateOptionsMenu(android.view.Menu) ->

• nCreateOptionsMenu

CS 4720

Passwords?

• ProGuard can make things harder…
• … but a password can’t be encrypted, per se,

since you have to use it!

• Options?

– Lock your keys in another encrypted box (or DB) – Have the user provide it in some way – public/private key handshake

38

CS 4720

Above All Else

• Common Sense!!!!
• Store hashes of passwords if possible
• Use built-in encrypted stores (like KeyStore or

Key Chain) for credentials

• Don’t “over reach” on permissions
• Don’t trust your users - validate all input
• Don’t expose extra functionality
• Don’t run anything as admin

39