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!
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?
ليست هناك تعليقات:
إرسال تعليق