JNLP Application Security Assessment – Part 2 : Runtime Mapping of a JNLP Application

Hello All,

For Part 2 of our series we will map all actions that take place when a jnlp application is launched. Finally at the end of the post we will change the execution mode of our application from jnlp to a normal java application running locally on our workstation.

Step 1. Network traffic

The following is a network traffic extract that depicts what is happening from a networking point of view. Wireshark was used to capture the traffic.

All network communications.



Download of jnlp file.



Download of additional jars.





Step 2. Workstation activity.

In parallel to the above network interaction, events are taking place in the local workstation as well. To map those actions we will use two tools, Microsoft's Process  Monitor (ProcMon) and the native sun java plugin control panel. Prior to clicking the jnlp shortcut the following actions need to take place:

1. Enable the java console for every java application execution (java control panel -> advanced -> java console -> Show console).


2. Find out the location of the temporary internet files (java control panel -> general -> temporary internet files -> settings).


3. Start ProcMon and apply the following filters in order to eliminate "noise".


4. Process Name is "javaws.exe"


5. Path Starts With "whatever you gathered from point 2 above"

Now you are ready to the click the jnlp application link and launch it.

The first you are phased with is the java console popping on the background. You need to click on the console and press 5 in order to enable tracing of the application execution. This will give you a view of the application execution from the java vm standpoint. From this window you can gather the following information:

• java vm execution parameters parapeters as passed to the javaws.exe (passed and accepted - the two won't always map)


• all properties passed to the application.

So, for our test application this equates to the following:

From the ProcMon you can see that the jar files are being downloaded, placed in the java temporary internet files location and the jar indexes are being created. They will appear in XXXXXXXXX-XXXXXXXX & XXXXXXXXX-XXXXXXXX.idx format.

You can run the javaws.exe -viewer command in order to verify that all required files have been downloaded to the temporary folder.

You can gather which of the files in the temporary internet folder correspond to the tested application and collect them for further examination.

The reason for the above process is to be able to gather the jar files and later decompile them so that you can get access to the source code. Halfway down the process, I thought "why don't I download them from the webserver they are hosted one, since I have the links in the jnlp files" and gave up on the aforementioned method. While not applicable in this scenario it is recommended to get to to grips with the ProcMon executable since it has proven valuable in many occasions.

Apart from the downloaded and stored jar files, ProcMon will also show any other O/S level interactions of the jnlp application, they will appear as originating from the javaws.exe executable.

So at this point we have:

1. a list of all required jar files in order to execute the application


2. the name of the main class


3. the runtime arguments for the execution of the jnlp file.

Remember that the jnlp application is in its heart a normal java application. We can use all of the above data in order to change the execution model of the application from jnlp to a normal java application.

This will also give us more power as to how we will interact and attack its internals since there are options that while passed by manipulating the java-vm-args directive in the jnlp file they are discarded by the javaws.exe such as debug related options that require opening sockets for remote debugging.

So the process to change the execution model is the following:

1. Download all referenced jar files from the webserver they are hosted on and store them in a single folder


2. Extract them via jar.exe.-x


3. Create a batch file that will mirror the execution command gathered by the java console step described previously.

The good thing is that now our executable will change from javaws.exe to java.exe (or javaw.exe), thus supporting more options to be passed to the application, such as debug directives.

C:\analysis>.\..\wget.exe http://127.0.0.1:8080/gui.jar
--2011-08-28 15:08:57--  http://127.0.0.1:8080/gui.jar
Connecting to 127.0.0.1:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6204 (6.1K) [application/x-java-archive]
Saving to: `gui.jar'

100%[======================================>] 6,204       --.-K/s   in 0s

2011-08-28 15:08:57 (217 MB/s) - `gui.jar' saved [6204/6204]

C:\analysis>.\..\wget.exe http://127.0.0.1:8080/logic.jar
--2011-08-28 15:09:18--  http://127.0.0.1:8080/logic.jar
Connecting to 127.0.0.1:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2506 (2.4K) [application/x-java-archive]
Saving to: `logic.jar'

100%[======================================>] 2,506       --.-K/s   in 0s

2011-08-28 15:09:18 (97.0 MB/s) - `logic.jar' saved [2506/2506]

C:\analysis>"C:\Program Files\Java\jdk1.6.0_18\bin\jar.exe" xvf gui.jar
 inflated: META-INF/MANIFEST.MF
 inflated: META-INF/ZQYVES.SF
 inflated: META-INF/ZQYVES.DSA
  created: META-INF/
 inflated: com/jnlptest/JNLPFrame$1.class
 inflated: com/jnlptest/JNLPFrame$2.class
 inflated: com/jnlptest/JNLPFrame$3.class
 inflated: com/jnlptest/JNLPFrame.class
 inflated: com/jnlptest/TestJnlp.class

C:\analysis>"C:\Program Files\Java\jdk1.6.0_18\bin\jar.exe" xvf logic.jar
 inflated: META-INF/MANIFEST.MF
 inflated: META-INF/ZQYVES.SF
 inflated: META-INF/ZQYVES.DSA
  created: META-INF/
 inflated: com/jnlptest/Auth2Service.class

C:\analysis>type run.bat
java -Xnoclassgc -Djnlp.versionEnabled=true -esa com.jnlptest.TestJnlp

C:\analysis>

That is it for this part of the series. Tune in for the next part of the series.

./Z