Reverse Engineering

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
3
Architecture of J2ME CLDC
J2ME application (MIDlet)
Preverifier
MIDP
CLDC
Java code Compact (JCC)
KVM
Romizing
Operating System
Device Hardware
Mobile Information Device
4
Security Evaluation of J2ME CLDC

• What do we want to do ??

• How do we do it ??

• Reported results.

• Security vulnerabilities.
• Security evaluation report for J2ME-CLDC

5
Security Evaluation Major Steps
System Components Study (JTWI Mandatory APIs)
6
J2ME CLDC Security Model Description MIDP
Security
alias net_access javax.microedition.io.Connecto
r.http, javax.microedition.io.Connector.socket,
javax.microedition.io.Connector.https, alias
send javax.wireless.messaging.sms.sendalias
application_auto_invocation javax.microedition.i
o.PushRegistryalias multimedia_recording
javax.microedition.media.control.RecordControl,
javax.microedition.media.control.VideoControl.getS
napshotdomain minimumdomain maximum
allow net_access allow application_auto_invoca
tion allow send allow multimedia_recording
domain trusted allow net_access allow
application_auto_invocation allow send
allow multimedia_recordingdomain 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 MIDlets 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 devices
  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
SSL Handshake
Server
Client
ClientHello(..., random1, )
ServerHello(..., random2, )
Certificate
ServerKeyExchange
ServerHelloDone
ClientKeyExchange
ChangeCipher(, Premaster, )
Finished
ChangeCipher
Finished
12
SSL Implementation Vulnerability
Pseudo-Random Number Generator Algorithm
Seed_init
13
SSL Implementation Vulnerability
Attack Scenario
Client
Attacker
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

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

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 A
Record Store B
Record Store N
Record 1
Record 1
Record 2
MIDlet Suite 1
Record 3
Record Store A
Record Store B
Record Store N
Record 1
Record 1
Record 2
Record 2
MIDlet Suite 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).

MIDlet suite X Storage
RMS
Record Store A (private)
Record Store B (shared Read only)
Record Store C (shared Read/ Write)
Device Storage
Other MIDlets
20
Shared Storage Vulnerability Exposed Internal
APIs

• The following figure shows the organization of
  APIs and native code in Suns 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()
Device hardware
Should be protected from access by developers.
Programmer
21
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 MIDlet
RecordStoreFile Class
MIDlet X Storage
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 Suns
  reference implementation).

Available Storage for the RMS
Malicious MIDlet
MIDlet X
MIDlet Y
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).

Other Applications on the Device
J2ME Applications
Device Storage
RMS
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\ltvendorgt\ltdomaingt\ltmidlet_namegt\
• The same steps can be followed to transfer rms.db
  file.

It is possible to tamper with the MIDlets
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
Buffer Overflow Vulnerability (CLDC1.1)
Vulnerable Code in native.c file
char str_buffer512 / shared string buffer
/ void invokeNativeFunction(METHOD thisMethod)
................................................
..... NativeFunctionPtr native
thisMethod-gtu.native.code if (native NULL)
/ Native function not found throw error
/ ...............................................
........... sprintf(str_buffer, "Native method
ss not found", className,
methodName(thisMethod)) .........................
................................. fprintf(stderr,
"ALERT s\n", str_buffer)
27
Buffer Overflow Vulnerability (CLDC1.1)
Possible attack
public class HelloWorld public HelloWorld()
// length of HelloWorldHello...World is is
2000 char HelloWorldHello...World() public
static void main(String arg) HelloWorld hw
new HelloWorld() // the native method name is
2000 char public native void HelloWorldHelloWorld.
..()
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
Redistribution
- MIDlet x
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

startApp()
uninvoked (installed)
active
pauseApp()

• 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()).

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 Suns 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
Thread A
Thread B
Device Display
Thread N
Synchronized Access ??
A thread can block display access from other
threads.
38
Security Evaluation Methodologies
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 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
Conclusion and Future Work

• J2ME-CLDC security model lacks flexibility (e.g.
  permissions and protection domains).
• Serious vulnerabilities exist in Suns 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.

41
Questions