Reverse Engineering

Reverse Engineering

Concordia University Concordia Institute for Information Systems Engineering (CIISE) Security Evaluation of J2ME-CLDC Computer Security Laboratory 1 Project: Security Evaluation of J2ME CLDC Architecture Recovery of J2ME-CLDC Security Evaluation of J2ME-CLDC Security Hardening of J2ME-CLDC Standardization Semantics 2

Architecture of J2ME CLDC Preverifier J2ME application (MIDlet) MIDP CLDC KVM Operating System Romizing Java code Compact (JCC) Device Hardware Mobile Information Device 3 Security Evaluation of J2ME CLDC

What do we want to do ?? Specifications Evaluate current specifications. Propose modifications. e.g. CLDC 1.0 & 1.1, MIDP 1.0 & 2.0. Implementations Test for conformance. Look for vulnerabilities. e.g. Suns RI, phone emulators, phones. How do we do it ?? Specifications Understand design concepts. Study security model. Implementations Code inspection. Security testing. Attack scenarios.

Reported results. Security vulnerabilities. Security evaluation report for J2ME-CLDC 4 Security Evaluation: Major Steps Study of Specification Documents System Components Study (JTWI Mandatory APIs) Study of Related Publications Code Reading Reverse Engineering Use of Reverse Engineering Tools Security Code Inspection Static Code Analysis Code Security Analysis Tools Security Testing Risk Analysis

Test Cases Design Based on: Lost of Flaws, Specifications, Common Vulnerabilities Methodology to Classify and Assess Vulnerabilities 5 net_access J2MEalias: CLDC Security Model Description: MIDP Security javax.microedition.io.Connector.http, javax.microedition.io.Connector.socket, javax.microedition.io.Connector.https, Which domain can alias: send access what & what is javax.wireless.messaging.sms.send the mode of access Assigning Downloading

alias: application_auto_invocation (allow or ask user) ? MIDlets to MIDlets javax.microedition.io.PushRegistry Assign MIDlets to protection domains Resources Protection Domains alias: multimedia_recording javax.microedition.media.control.RecordControl, javax.microedition.media.control.VideoControl.getSnapshot Trusted Application Protected Security Management (i.e. http) minimum Policy domain: System Untrusted

?? (AMS) domain: maximum allow: net_access In suns RI, allow: application_auto_invocation protected allow: send Unprotected resources & allow: multimedia_recording (i.e. Graphics) protection domain: trusted domains are allow: net_access defined in class allow: application_auto_invocation Permissions.java allow: send allow: multimedia_recording Unprotected resources domain: untrusted can be accessed by

session(session): net_access any MIDlet oneshot(oneshot): send Example of a policy 6 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). 7 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. 8 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. 9 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. 10 SSL Implementation Vulnerability SSL Handshake: Server Client ClientHello(..., random1, ) ServerHello(..., random2, ) Certificate ServerKeyExchange ServerHelloDone

ClientKeyExchange Random1 + Random2 + Premaster Master secret Random1 + Random2 ChangeCipher(, Premaster, ) Finished ChangeCipher + Premaster Master secret Finished 11 SSL Implementation Vulnerability

Pseudo-Random Number Generator Algorithm: Seed_init SystemTime UpdateSeed() Seed_1 SystemTime Random_1 GenerateData() Random_2 GenerateData() Random_3 UpdateSeed() Seed_2 SystemTime

GenerateData() UpdateSeed() Seed_3 12 SSL Implementation Vulnerability Attack Scenario: Client Attacker 1 Nonce (random number) 2 [Nonce] server_public_key

Challenge Determine a close interval of the nonce (random) value. 1 Encrypt every possible value with the server public key and compare it with the challenge 2 [correct_value] client_public_key 3 OK Encryption keys can be guessed. 13 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. 14 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 15 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(...) Locks the display { ........... PermissionForm.setCommandListener(this); displayManager.preemptDisplay(token, this, form, true); } private void SetAnswer(...) Unlocks the display { ............. displayManager.donePreempting(preemptToken); notify();

} Motorola V600 and Nokia 3600 Phones are not vulnerable to this flaw. 16 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. 17 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. Record Store A Record 1 Record 2 Record 3 MIDlet Suite 2 MIDlet Suite 1 A Record Store is a group of records, which are byte arrays. Record Store B

Record 1 Record Store A Record 1 Record 2 Record Store B Record 1 Record 2 Record Store N Record Store N 18 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 19 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 Security

checks Java and Native code e.g. class RecordStoreFile Bypass security checks Should be protected from access by developers. read() write() Device hardware Programmer

20 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. RecordStoreFile Class Malicious MIDlet getUniqueIdPath(Vendor, MIDlet Suite, Record Store) String s deleteFile(s) MIDlet X Storage Malicious MIDlet Record Store A A MIDlet can delete storage data of another MIDlet. 21 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). Malicious MIDlet MIDlet X Available Storage for the RMS MIDlet Y A MIDlet can deny other MIDlets storage space. 22 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

Device Storage J2ME Applications RMS 23 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\\\\ The same steps can be followed to transfer rms.db file. It is possible to tamper with the MIDlets persistent data. 24 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. 25 Buffer Overflow Vulnerability (CLDC1.1) Vulnerable Code in native.c file 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); } 26 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...(); } 27 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. 28 Redistribution of MIDlet Jar File 1 I want MIDlet x MIDlet x 3 2 Charging (if any) MIDlet provider server 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) 29 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. 30 Ill-Behaved MIDlet Vulnerability MIDlet Lifecycle Constructror called uninvoked (installed) startApp() paused

active pauseApp() destroyApp() destroyApp() destroyed 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()). 31 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. 32 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). 33 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. 34 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. 35 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. 36 Multi-Threading and Display Vulnerability Thread A Thread B Thread N Device Display Synchronized Access ?? A thread can block display access from other threads.

37 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. 38 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 39 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.

40 Questions 41

Recently Viewed Presentations

  • Dementia, Age Related decline and Rural Psychiatric Management

    Dementia, Age Related decline and Rural Psychiatric Management

    DSM 5. Significant cognitive decline from previous level of performance in one or more complex cognitive domains (complex attention, executive functioning, learning and memory, language, perceptual motor, or social cognition) based on ... Patients with dementia - reasoning and language...
  • What is Needed to Support the Production of

    What is Needed to Support the Production of

    When the elastic recoil forces of the lung-thorax unit reach their resting state, expiratory muscles take over to effect further decreases in lung volume. The inspiratory force that is applied decreases over time. The expiratory force that is applied increases...
  • Solution Structure Determination by NMR and Distance Geometry

    Solution Structure Determination by NMR and Distance Geometry

    Pure Protein (0.3 mL, 0.5 - 1 mM; ~ 10 mg) 2. Sequence-specific resonance assignments 3. Sequence-specifice distance constraints disulfide bonds spin-spin coupling constants internuclear distance constraints from NOEs residual dipolar couplings hydrogen bonds standard bond lengths; bond angles 4....
  • Doing Cognitive-Behavioral Therapy With Depressed, Stressed ...

    Doing Cognitive-Behavioral Therapy With Depressed, Stressed ...

    Cognitive errors: double messages- self and others- note inconsistencies A number of people with panic disorder were found to have strongly influencing and significant life events which predisposed them to panic (loss separation, bereavement, health related concerns starting in childhood...
  • Fitness

    Fitness

    Cardiorespiratory Fitness. Cardiorespiratory fitness: ability of the heart and lungs to efficiently deliver oxygen and nutrients to the body's muscles and cells via the bloodstream. Increase in oxygen-carrying capacity of the blood. Improved extraction of oxygen from blood by muscles
  • Social Psychology - Faculty Server Contact

    Social Psychology - Faculty Server Contact

    Interdependent View of the Self Gender Differences in Defining the Self Women Men Knowing Ourselves Through Introspection Introspection Focusing on the Self: Self-Awareness Theory Self-Awareness Theory Causal Theories Judging Why We Feel the Way We Do: Telling More than We...
  • DEs Deficient Kidneys Oct 7, 2009 Renal Rotation

    DEs Deficient Kidneys Oct 7, 2009 Renal Rotation

    DE's Deficient Kidneys Oct 7, 2009 Renal Rotation Sandra Katalinic Pharmacy Resident
  • Midrostral Medulla - University of Michigan

    Midrostral Medulla - University of Michigan

    What functions lost? Tumor of falx cerebri at level of central sulcus - what gyri compressed & what functions affected? ANS: Tumor of posterior part of falx cerebri - medial occipital gyri, including lingula & cuneus. Function lost - vision....