الأربعاء، 7 ديسمبر 2011

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 java.sun.com/update/1.6.0/map-m-1.6.0.xml, this is done using HTTP. This is the content of the file:

<java-update-map>
<mapping>
<version>1.6.0_27</version>
<critical>1</critical> <url>http://javadl-esd.sun.com/update/1.6.0/au-descriptor-1.6.0_29-b110.xml</url>
</mapping>...
<mapping>
<version>1.6.0_28</version>
<critical>1</critical> <url>http://javadl-esd.sun.com/update/1.6.0/au-descriptor-1.6.0_29-b110.xml</url>
</mapping>
</java-update-map>

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:

<java-update>
<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
<moreinfo>http://java.com/infourl</moreinfo>
<AlertTitle>Java Update Available</AlertTitle>
<AlertText>A new version of Java is ready to be installed.</AlertText>
<moreinfotxt>More information...</moreinfotxt>
<url>http://javadl.sun.com/webapps/download/GetFile/1.6.0_29-b110/windows-i586/jre-6u29-windows-i586-iftw-rv.exe</url>
<version>1.6.0_29-b110</version>
<post-status>https://nometrics.java.com</post-status>
<cntry-lookup>http://rps-svcs.sun.com/services/countrylookup</cntry-lookup>
<predownload></predownload>
<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://
<urlinfo>0a8ddda613f0196beac748407767efebcaea83ca</urlinfo>
</information>
</java-update>

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 <=1.6.0.28 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...
Cheers!

Pwning Java update process 2007-Today (ES)

La semana pasada se hizo publico un troyano llamado FinFisher que estaba siendo comercializado exclusivamente a fuerzas de seguridad y agencias de inteligencia de distintas naciones para vigilar PCs y dispositivos mobiles.

¿Que tiene de interesante FinFisher?
Utiliza como vector de infección updates falsos de la aplicación iTunes, explotando una vulnerabilidad que reporté en 2008 y curiosamente Apple luego de 3 años, el 14 de Noviembre publico el parche para solucionarla.

Dos blogs cubrieron esta noticia en profundidad, les recomiendo que visiten Seguridad Apple y Krebs on Security quienes estuvieron informando del asunto.

¿Y el update de Java?
En la misma fecha que avisé del problema en Apple lo hice en Sun con la diferencia que ellos sacaron un parche el 3 de Diciembre del 2008. A principios del 2010 descubrí que era posible saltar las restricciones de este parche. Su primer sistema de actualización realizaba las siguientes acciones:

1) El updater obtiene por http de manera insegura el archivo java.sun.com/update/1.6.0/map-m-1.6.0.xml, que contiene lo siguiente:

<java-update-map>
<mapping>
<version>1.6.0_27</version>
<critical>1</critical> <url>http://javadl-esd.sun.com/update/1.6.0/au-descriptor-1.6.0_29-b110.xml</url>
</mapping>...
<mapping>
<version>1.6.0_28</version>
<critical>1</critical> <url>http://javadl-esd.sun.com/update/1.6.0/au-descriptor-1.6.0_29-b110.xml</url>
</mapping>
</java-update-map>

2) El updater compara su versión actual con el tag <version>, si es mas reciente procede a obtener el archivo en el tag <url> y preguntarle al usuario si desea instalar la nueva actualización.

3) El archivo contiene la siguiente información:

<java-update>
<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
<moreinfo>http://java.com/infourl</moreinfo>
<AlertTitle>Java Update Available</AlertTitle>
<AlertText>A new version of Java is ready to be installed.</AlertText>
<moreinfotxt>More information...</moreinfotxt>
<url>http://javadl.sun.com/webapps/download/GetFile/1.6.0_29-b110/windows-i586/jre-6u29-windows-i586-iftw-rv.exe</url>
<version>1.6.0_29-b110</version>
<post-status>https://nometrics.java.com</post-status>
<cntry-lookup>http://rps-svcs.sun.com/services/countrylookup</cntry-lookup>
<predownload></predownload>
<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://
<urlinfo>0a8ddda613f0196beac748407767efebcaea83ca</urlinfo>
</information>
</java-update>

4) Si el usuario confirma la actualización se descargara el binario que se encuentra en el tag <url>, en el caso que el archivo esté firmado por una entidad certificada ejecuta el binario, de lo contrario preguntaba al usuario si desea ejecutar el binario.

Luego del parche del 2008, SUN continuo utilizando la misma mecánica de update, todo vía HTTP con la excepción de una comprobación adicional.

5) Antes de ejecutar el archivo comprueba que el binario este firmado por una entidad certificante y sea un certificado de SUN.


Java update bypass:
Para saltar esta restriccion enviamos como binario el Java Web Start (javaws.exe) y como podemos controlar los argumentos con el tag <options> le pasamos una direccion que controlamos con un JNLP y bingo!

Esta técnica fue presentada en Blackhat y Defcon 2010 con la ultima version Java 1.6.0_22 y hasta hoy sigue siendo vulnerable en la ultima version de Java <=1.6.0.28.

El siguiente video demuestra la vulnerabilidad:



Fechas:
  • 2007 Fue presentando por primera vez Evilgrade en ekoparty (Itunes/Java vulnerable).
  • 2008 Presentamos Evilgrade en Troopers, Shakacon y H2HC.
  • Fines del 2008, Nos pusimos en contacto con los vendors. Sun publico el parche. Lanzamos Evilgrade version 1.0
  • 2010 Presentamos Evilgrade version 2.0 en Defcon/Blackhat y publicamos version 2.0
  • 2011 Apple corrige vulnerabilidad en iTunes y Sun aun no se dio cuenta de su vulnerabilidad.
Si bien no hubo un contacto inicial con la empresa, no deberian hacer su tarea y enterarse en los medios donde los investigadores publicamos nuestros trabajos?
O hay que esperar a la version 2.0 de FinFisher para que lo resuelvan?

Para pensar...
Saludos!

Pwning Java update process 2007-Today (BR)

Na semana passada um Trojan apareceu na mídia, com o nome de FinFisher, este está sendo associado exclusivamente para leis e para agências de inteligência de diferentes nações para monitoramento de computadores e de dispositivos móveis.

O que é tão interessante sobre FinFisher?
Ele usa como vetor de ataque, atualizações falsas do iTunes, explorando uma vulnerabilidade que relatei em 2008, e curiosamente a Apple só agora, três anos depois, em 14 de Novembro publicou o patch para resolver.

Dois blogs analisaram com maior profundidade esta história, eu recomendo que você visite Seguridad Apple & Krebs on Security que trataram sobre o assunto.

E a atualização do Java?
No mesmo dia em que a Apple foi alertada sobre o problema, eu fiz isso com a SUN, à diferença é que eles publicaram um patch no dia 03 de Dezembro de 2008. No início de 2010 eu descobri que era possível “bypassar” as restrições deste patch. O primeiro update deles funcioanava desta maneira:

1) O atualizador faz a requisição do arquivo java.sun.com/update/1.6.0/map-m-1.6.0.xml, de forma insegura, pois isto é feito usando HTTP. Este é o conteúdo do arquivo:

<java-update-map>
<mapping>
<version>1.6.0_27</version>
<critical>1</critical> <url>http://javadl-esd.sun.com/update/1.6.0/au-descriptor-1.6.0_29-b110.xml</url>
</mapping>...
<mapping>
<version>1.6.0_28</version>
<critical>1</critical> <url>http://javadl-esd.sun.com/update/1.6.0/au-descriptor-1.6.0_29-b110.xml</url>
</mapping>
</java-update-map>

2) O atualizador compara sua versão atual com a tag <version>, e se for mais novo, procede a fim de obter o arquivo através da tag <url> então, pergunta ao usuário se ele deseja instalar a nova atualização.

3) O arquivo contêm as seguintes informações:

<java-update>
<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
<moreinfo>http://java.com/infourl</moreinfo>
<AlertTitle>Java Update Available</AlertTitle>
<AlertText>A new version of Java is ready to be installed.</AlertText>
<moreinfotxt>More information...</moreinfotxt>
<url>http://javadl.sun.com/webapps/download/GetFile/1.6.0_29-b110/windows-i586/jre-6u29-windows-i586-iftw-rv.exe</url>
<version>1.6.0_29-b110</version>
<post-status>https://nometrics.java.com</post-status>
<cntry-lookup>http://rps-svcs.sun.com/services/countrylookup</cntry-lookup>
<predownload></predownload>
<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://
<urlinfo>0a8ddda613f0196beac748407767efebcaea83ca</urlinfo>
</information>
</java-update>

4) Se o usuário confirmar, a atualização irá baixar o binário que está na tag <url> , já se o arquivo for assinado por uma entidade certificada, o binário é diretamente executado, caso contrário, irá solicitar ao usuário que execute o binário.

Após o patch de 2008, a SUN continua usando a mesma forma de atualização, ou seja, tudo via HTTP com exceção de uma verificação adicional.

5) Antes de executar o arquivo, é verificado se o binário é assinado por uma entidade certificadora e é um certificado da SUN...

Java update bypass:

Para “bypassar” esta verificação, enviamos como binário o (javaws.exe) e como nós podemos controlar os argumentos com a tag <options> passamos uma direção que nós controlamos com um JNLP e Bingo!

Esta técnica foi apresentada na Blackhat e na Defcon em 2010, com a última versão Java 1.6.0_22, e até hoje continua vulnerável na última versão do Java <=1.6.0.28.

O vídeo a seguir demonstra a vulnerabilidade:



Datas:
  • 2007 Foi apresentado pela primeira vez o Evilgrade na Ekoparty (Itunes e Java vulneráveis).
  • 2008 Apresentamos o Evilgrade na Troopers, na Shakacon e na H2HC.
  • No final de 2008, nós entramos em contato com os vendors. SUN publicou o patch. Lançamos a versão 1.0 do Evilgrade.
  • 2010 Apresentamos o Evilgrade versão 2.0 na Defcon/Blackhat e publicamos a versão 2.0.
  • 2011 Apple corrige vulnerabilidade no iTunes e a Sun não se deu conta de sua vulnerabilidade.
Não houve um contato inicial com a empresa, porém não deveriam estas fazer sua lição de casa e buscar na mídia onde os pesquisadores publicam os seus trabalhos?
Ou devem esperar a versão 2.0 do FinFisher para resolverem?

Para pensar...
Saudações!

(*) Traduzido por Jordan M. Bonagura (tw)