1 concordia university concordia institute for information systems engineering (ciise) security...
TRANSCRIPT
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
J2ME-CLDC Security Model Evaluation
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
J2ME-CLDC Security Model Evaluation
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
SSL Implementation Vulnerability
Pseudo-Random Number Generator Algorithm:
Seed_init
UpdateSeed()SystemTime
Seed_1 GenerateData() Random_1
Seed_2
UpdateSeed()SystemTime
GenerateData() Random_2
Seed_3
UpdateSeed()SystemTime
GenerateData() Random_3
13
SSL Implementation Vulnerability
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
Unauthorized SMS Sending Vulnerability
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
Unauthorized SMS Sending Vulnerability
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
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.
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
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.
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
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.
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
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.
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
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.
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