Pwning Java update process 2007-Today

Last week a Trojan appeared on the news, named FinFisher is being sold exclusively to law enforcement and intelligence agencies of different nations for monitoring PCs and mobile devices.

What is so interesting about FinFisher?
It uses as an infection vector, fake updates in the iTunes application exploiting a vulnerability that I reported in 2008 and interestingly Apple three years after on November 14 published patch to solve it.

Two blogs covered this story in depth, I recommend you to visit Seguridad Apple & Krebs on Security who were reporting on the matter.

And the Java update?
On the same day that Apple was alerted about the problem, I did it with SUN with the difference that they published a patch on December 3, 2008. In early 2010 I discovered that it was possible to bypass the restrictions of this patch. Their first update system worked like this:

1) The updater requests in a insecure way the file, this is done using HTTP. This is the content of the file:

<critical>1</critical> <url></url>
<critical>1</critical> <url></url>

2) The updater compares it's version with the tag <version>, if it's a newer release, it downloads the file defined in <url> then the user gets a notification regarding a new update available.

3) The file contains the following content:

<information version="1.0" xml:lang="en">
<caption>Java Update - Update Available</caption>
<title>Java Update Available</title>
<description>Java 6 Update 29 is ready to install. Click the Install button to update Java now. If you wish to update Java later, click the Later butto
<AlertTitle>Java Update Available</AlertTitle>
<AlertText>A new version of Java is ready to be installed.</AlertText>
<moreinfotxt>More information...</moreinfotxt>
<options>/installmethod=jau SP1OFF=1 SP2OFF=1 SP3OFF=1 SP4OFF=1 SP5OFF=1 SP6OFF=1 SP7OFF=1 SP8OFF=1 SP9OFF=1 SP10OFF=1 SP11OFF=1 MSDIR=ms5 SPWEB=http://

4) If the user confirms the update, the binary set in the <url> tag will get downloaded, if it's signed by CA it will be executed, if not the user will have to confirm the execution.

After the 2008 patch, SUN kept the same update implementation using HTTP with the exception of one more validation step.

5) Before executing the file it compares that the binary is signed by SUN...

Java update bypass:

To bypass this restriction we send the Java Web Start (javaws.exe) binary as payload and since we can control the arguments with the tag <options> we put an address with a JNLP under our control & Bingo!

This technique was presented at Black Hat & Defcon 2010 with the last version of Java 1.6.0_22 and still today the last version Java <= remains vulnerable.

The following video demonstrates the vulnerability:

Important Dates:
  • 2007 It was first presented at ekoparty (Itunes/Java vulnerable).
  • 2008 We presented Evilgrade at Troopers, Shakacon & H2HC.
  • By the end of 2008, We got in touch with the vendors. SUN publishes the patch. We release Evilgrade 1.0 to the public.
  • 2010 We presented Evilgrade 2.0 at Defcon/BlackHat, and we release it to the public.
  • 2011 Apple fixes the iTunes flaw, SUN still has no clue about their bug.
While there was not an a initial contact with the company, shouldn't they do their homework and learn where researchers publish our work?
Or should we wait for FinFisher 2.0 release so they are forced to patch it?

Think about it...


Click here for comments
December 14, 2011 at 2:18 PM ×

The latest version at the time of your posting was 1.6.0_29 and 1.6.0_30 was just released Monday IIRC.

Are those affected?

Selamat alex_mayorga dapat PERTAMAX...! Silahkan antri di pom terdekat heheheh...
Post a Comment
Thanks for your comment