1 Concordia University Concordia Institute for Information Systems Engineering (CIISE) Security...

1

Concordia University

Concordia Institute for Information Systems Engineering

(CIISE)

Security Evaluation of J2ME-CLDC

Computer Security Laboratory

2

Project: Security Evaluation of J2ME CLDC

Architecture Recovery of J2ME-CLDC

Security Evaluation of J2ME-CLDC

Security Hardening of J2ME-CLDC

Standardization

Semantics

3

Preverifier

Java code Compact(JCC)

Operating System

Device Hardware

MIDP

CLDC

KVM

Mobile Information Device

Romizing

J2ME application(MIDlet)

Architecture of J2ME CLDC

4

Security Evaluation of J2ME CLDC

What do we want to do ??

How do we do it ??

Reported results.

Specifications Implementations

Evaluate current specifications. Propose modifications. e.g. CLDC 1.0 & 1.1, MIDP 1.0 & 2.0.

Test for conformance. Look for vulnerabilities. e.g. Sun’s RI, phone emulators, phones.

Specifications Implementations

Understand design concepts. Study security model.

Code inspection. Security testing. Attack scenarios.

Security vulnerabilities. Security evaluation report for J2ME-CLDC

5

System Components Study(JTWI Mandatory APIs)

Study of Specification Documents

Study of Related Publications

Reverse Engineering

Code Reading

Use of Reverse Engineering Tools

Static Code Analysis

Security Code Inspection

Code Security Analysis Tools

Security TestingTest Cases Design Based on:Lost of Flaws, Specifications,

Common Vulnerabilities

Risk AnalysisMethodology to Classify and

Assess Vulnerabilities

Security Evaluation: Major Steps

6

Trusted

Untrusted

Assign MIDlets toProtection Domains

Protected(i.e. http)

Resources

Unprotected(i.e. Graphics)

J2ME CLDC Security Model Description: MIDP Security

SecurityPolicy

Which domain can access what & what is

the mode of access (allow or ask user) ?

Unprotected resources can be accessed by

any MIDlet

ApplicationManagement

System(AMS)

DownloadingMIDlets

??

Assigning MIDlets to protection domains

In sun’s RI, protected resources & protection domains are defined in class Permissions.java

alias: net_access javax.microedition.io.Connector.http, javax.microedition.io.Connector.socket, javax.microedition.io.Connector.https,

alias: send javax.wireless.messaging.sms.send

alias: application_auto_invocation javax.microedition.io.PushRegistry

alias: multimedia_recording javax.microedition.media.control.RecordControl, javax.microedition.media.control.VideoControl.getSnapshot

domain: minimum

domain: maximum allow: net_access allow: application_auto_invocation allow: send allow: multimedia_recording

domain: trusted allow: net_access allow: application_auto_invocation allow: send allow: multimedia_recording

domain: untrusted session(session): net_access oneshot(oneshot): send Example of a policy

7

J2ME-CLDC Security Model Evaluation

Permissions

Asking the user whether to allow a MIDlet to call security sensitive APIs.

The user is always aware of attempts to use security-sensitive APIs.

Allowing MIDlets in the untrusted protection domain to call protected APIs.

Risk of having the user answer automatically without checking the displayed messages.

The strict procedure of assigning MIDlets to protection domains can be circumvented by a asking permission from the user.

Programmers are not provided with the ability to define new permissions.

Permissions are atomic (granting permission or not with no fine tuning).

8


Protection Domains

Assigning the appropriate protection domain to a MIDlet

It is often the case that a program written by a trusted developer can make a wrong behaviour.

The task will be more complicated if the signer is a third party.

Protection Domains are not standardized

To deploy a MIDlet, developer would have to ask a different protection domain for each different manufacturer or operator.

What happens when the set of a MIDlet’s required permissions cannot fit in any protection domain ?

Security Policy

The manufacturer is the only party that can modify the security policy file.

9


Record stores Protection

Non-shared record stores can be accessed or modified only from MIDlets creating them.

Shared record stores can be accessed from any MIDlet on the device.

MIDlets can not share their record stores with only a specific subset of MIDlets.

Record stores are vulnerable to any attack from outside the RMS.

Record stores can be accessed from the device’s utilities (without using a MIDlet).

Record stores can be manipulated as files (copied, renamed, deleted, etc.).

No encryption method is specified to protect sensitive record stores on the device.

10

Results of Vulnerability Analysis

Networking vulnerabilities: SSL Implementation predictable random numbers.

Unauthorized SMS Sending bypassing user permission.

Shared Storage Vulnerabilities: Exposed internal APIs bypassing security checks.

Denial of storage taking up all storage space.

Unprotected Data sensitive RMS data not sufficiently protected.

KVM related vulnerability: Buffer Overflow native method names not checked for length.

Intellectual property rights vulnerability: Transferring Files from Device MIDlets copied from phones.

MIDlet lifecycle vulnerabilities: Ill-Behaved MIDlets assumptions about MIDlet behaviour.

Low level security issues (safety) Exceptions & large JAD files.

Multi-threading Vulnerabilities: Access to the device display access not synchronized.

11

SSL Implementation Vulnerability

Client Server

ClientHello(..., random1, …)

ServerHello(..., random2, …)

Certificate

ServerHelloDone

ServerKeyExchange

ClientKeyExchange

ChangeCipher(…, Premaster, …)

Finished

ChangeCipher

Finished

Random1 + Random2

+

Premaster

Master secret

Random1 + Random2

+

Premaster

Master secret

SSL Handshake:

12


Pseudo-Random Number Generator Algorithm:

Seed_init

UpdateSeed()SystemTime

Seed_1 GenerateData() Random_1

Seed_2


GenerateData() Random_2

Seed_3


GenerateData() Random_3

13


Attack Scenario:

Client Attacker

2Encrypt every possible value with the server public key and compare it with the challenge

3[correct_value] client_public_key

OK

1 Nonce (random number)

2 [Nonce] server_public_key

1Determine a close interval of the nonce (random) value.

Challenge

Encryption keys can be guessed.

14

Unauthorized SMS Sending Vulnerability

The Phenoelit Hackers group discovered a vulnerability on Siemens S55 phones.

The idea: Asking another question and keeping the buttons functionalities.

The user will unwittingly authorize the SMS sending.

15


Siemens implementation of permission screens includes a serious flaw:

The permission screen is not protected!

All permission screens (SMS, HTTP, etc.) can be overwritten by other items.

Other Siemens phones are vulnerable to this flaw:

S55 2128 MC60 CF62

16


Applicability on other phones:

MIDP RI is not vulnerable to this flaw.

MIDP RI prevents any modification of the permission screen until an answer is received from the user:

Void PermissionDialog(...){ ...........

PermissionForm.setCommandListener(this);displayManager.preemptDisplay(token, this, form, true);

}

Locks the display

private void SetAnswer(...){ .............

displayManager.donePreempting(preemptToken); notify();

}

Motorola V600 and Nokia 3600 Phones are not vulnerable to this flaw.

Unlocks the display

17












18

Shared Storage Vulnerabilities

MIDP defines a system of persistent storage, composed of Record Stores.

Each MIDlet suite can own one or more Record Stores, and since MIDP 2.0

Record Stores can be shared between MIDlet suites.

A Record Store is a group of records, which are byte arrays.

Record Store ARecord 1Record 2Record 3

Record Store B Record Store N

Record Store ARecord 1Record 2

Record Store B Record Store N

Record 1

Record 1Record 2

MID

let

Sui

te 1

MID

let

Sui

te 2

19

Shared Storage Vulnerabilities A Record Store is identified by a unique name, which is a concatenation of the Vendor Name, the MIDlet Suite Name, and the Record Store Name.

Two Record Stores can have the same name as long as they belong to different MIDlet suites.

Record Stores on the device storage are managed by the Record Management System (RMS).

Device Storage

RMS

MIDlet suite X Storage

Other MIDlets

Record Store A (private)

Record Store B (shared: Read only)

Record Store C (shared: Read/ Write)

20

Shared Storage Vulnerability: Exposed Internal APIs

The following figure shows the organization of APIs and native code in Sun’s

open source reference implementation concerning persistent storage.

High level MIDP API

class RecordStore

Low level API

class RecordStoreFile

Java and Native code

e.g.

read()

write()

Devicehardware

Security checks

Programmer

Bypass security checks

Should be protected from access by

developers.

21

MIDlet X Storage

Shared Storage Vulnerability: Exposed Internal APIs

By calling the method deleteFile() of the class RecordStoreFile, one

MIDlet was able to delete a Record Store that belongs to another MIDlet.

Malicious MIDletRecordStoreFile

Class

getUniqueIdPath(Vendor, MIDlet Suite, Record Store)

String s

deleteFile(s)

Malicious MIDlet

Record Store A

A MIDlet can delete storage data of another MIDlet.

22

Shared Storage Vulnerability: Denial of Storage In the specifications, no limit is put on the amount of storage that can be assigned to each MIDlet.

A malicious MIDlet can execute an attack by eating up all the storage space available for Record Stores (attack successful in Sun’s

reference implementation).

Malicious MIDlet

MIDlet X

MIDlet Y

Available Storage for the RMS

A MIDlet can deny other MIDlets storage space.

23

Shared Storage Vulnerability: Unprotected Data

Record Stores are put on the device storage.

There is no provision in MIDP for encryption of sensitive data.

Data are not protected from attacks by other software on the device (e.g. Nokia 3650 FExplorer application).

Device Storage

RMS

J2ME Applications Other Applications

on the Device

24

Shared Storage Vulnerability: Example (Nokia 3650)

All persistent data of a MIDlet is stored in rms.db file.

rms.db is located in the same directory as Jad and Jar files.

C:\system\midp\<vendor>\<domain>\<midlet_name>\

The same steps can be followed to transfer rms.db file.

It is possible to tamper with the MIDlet’s persistent data.

25












26

char str_buffer[512]; /* shared string buffer */

void invokeNativeFunction(METHOD thisMethod) {.....................................................NativeFunctionPtr native = thisMethod->u.native.code;if (native == NULL) {

/* Native function not found; throw error */..........................................................sprintf(str_buffer, "Native method ’%s::%s’’ not found",className, methodName(thisMethod));..........................................................fprintf(stderr, "ALERT: %s\n", str_buffer);}

Buffer Overflow Vulnerability (CLDC1.1)

Vulnerable Code in native.c file

27

public class HelloWorld {

public HelloWorld() {

// length of HelloWorldHello...World is is 2000 charHelloWorldHello...World();}public static void main(String arg[]) {HelloWorld hw = new HelloWorld();}

// the native method name is 2000 charpublic native void HelloWorldHelloWorld...();}

Possible attack

Buffer Overflow Vulnerability (CLDC1.1)

28












29

Redistribution of MIDlet Jar File

MIDlet provider server

“I want MIDlet x”1

2 Charging (if any)MIDlet x 3

4 Installing

- MIDlet x

Redistribution

- MIDlet x

Example: FExplorer application on Nokia 3600 phone provides options to send files through local protocols (Bluetooth, Infrared, SMS, e-mail)

30












31

Ill-Behaved MIDlet Vulnerability

MIDlet Lifecycle

A MIDlet is responsible of implementing the code necessary to shift itself

from one state to the other (e.g. the method pauseApp()).

This code can be called by the MIDlet itself or by the Application

Management System (AMS) on the device.

If this code was called by the MIDlet, it is up to the MIDlet to notify the AMS

with its state change (e.g. by calling the method notifyPaused()).

uninvoked(installed)

Constructror called

paused active

startApp()

pauseApp()

destroyed

destroyApp()destroyApp()

32

Ill-Behaved MIDlet Vulnerability

A MIDlet is assumed to be well-behaved (e.g. it will correctly implement and

call the previously mentioned methods).

A malicious MIDlet can make use of this assumption to create nuisances.

Examples of this are:

MIDlets not implementing an exit button.

MIDlets changing their states by calling a method, yet providing the

wrong notification to the AMS.

MIDlets not properly implementing the state-change methods.

The information supplied by the AMS to the user could differ from the actual MIDlet state.

33

MIDP 1.0, MIDP 2.0 and Exceptions

The type of exceptions thrown by some methods of MIDP 2.0 are different

from their counterpart of MIDP 1.0

This can make a MIDlet, originally written for MIDP 1.0 and calling one of

those methods, unable to catch the exception when run on MIDP 2.0

Example:

The method openRecordStore only throws exceptions of the

RecordStoreException class or of class that inherits from the latter in

MIDP 1.0, whereas it may throw exceptions of the

IllegalArgumentException class (which does not inherit from the

RecordStoreException class) in MIDP 2.0

A MIDlet that runs perfectly well on MIDP 1.0 could crash on MIDP 2.0 (safety issue).

34

MIDlet suite with big JAD

The size of the attribute MIDlet-Description of the (Java Application Descritptor) JAD

file is not restricted. It is thus possible to create MIDlet suite with very big JAD.

To download, install and execute a MIDlet suite with a JAD file included between

53KB and 66KB is possible, but trying to remove it from the emulator blocks the

latter.

However this problem only occurs with the emulator provided with Sun’s reference

implementation.

A MIDlet with a large JAD file could not be uninstalled.

35












36

Multi-Threading and Display Vulnerability

J2ME-CLDC supports multi-threading.

Some methods that manipulate resources shared between threads are not

declared as synchronized.

Examples of this are:

The setCurrent() method of the class Display.

This method enables a thread to get access to the device display (send a

Displayable class object to the screen).

Any access to the display using the setCurrent() method should be put in a

synchronized block, otherwise unwanted behaviour may occur.

37

Multi-Threading and Display Vulnerability

Device Display

Thread A

Thread B

Thread N

Synchronized Access ??

A thread can block display access from other threads.

38

Security Evaluation Methodologies

A security evaluation methodology provides a framework for systematically evaluating an IT product from the point of view security.

It provides criteria used to evaluate the degree of assurance that the software actually implements its security requirements.

Security assurance and security functions (security strength), e.g. Common Criteria.

Security Evaluation Methodologies

Security Evaluation Methodologies : Why ?

Repeatability of results: Different persons evaluating the same software should be able to reach the same conclusions.

Quantification of results: A methodology normally provides quantitative measures of software security.

Software reuse: Software components can be evaluated, certified, and reused knowing their security functionalities.

39

Risk Analysis of Vulnerabilities

List of Vulnerabilities

Evaluate Impact Evaluate Likelihood

The Severity of each vulnerability is proportional to its impact and likelihood

The MEHARI Approach

40

J2ME-CLDC security model lacks flexibility (e.g. permissions and protection domains).

Serious vulnerabilities exist in Sun’s open source reference implementation of MIDP 2.0 (e.g. SSL implementation).

Some phones could be vulnerable to serious security attacks like the Siemens SMS attack.

Coverage of the analysis ?

Common Criteria document on security functional requirements.

Conclusion and Future Work

41

Questions

1 Concordia University Concordia Institute for Information Systems Engineering (CIISE) Security...

Documents

Transcript of 1 Concordia University Concordia Institute for Information Systems Engineering (CIISE) Security...