Versão antiga do Java ainda domina PCs corporativos, diz estudo

Empresas ao redor do mundo ainda ignoram as atualizações de Java, aponta um estudo da empresa de segurança Websense. O relatório aponta que menos de um quinto dos computadores corporativos rodavam a última versão do software à época, a 7u25 - a atual é a 7u40.

A análise foi baseada em pedidos de atualização detectados pelo sistema Websense ThreatSeeker Intelligence Cloud, envolveu “múltiplas empresas” ao redor do mundo e foi feita entre 1 e 29 de agosto deste ano. E, entre outros dados, ela ainda revela que cerca de 40% das solicitações de update do Java vieram de PCs com a versão 6 instalada nos browsers.

Além de ser uma edição comprovadamente com brechas de segurança, o Java 6 SE teve o suporte descontinuado em abril de 2013 – e uma quantidade tão grande de computadores que ainda o têm instalado preocupa. E o perigo aumenta ainda mais graças à popularidade do plug-in: 83,6% dos navegadores nos PCs corporativos analisados o mantém Java ativo.

As brechas mais recentes do Java, que receberam os “nomes” CVE-2013-2473 e CVE-2013-2463, datam de junho deste ano. Ambas servem como porta de entrada para cibercriminosos e seus ransomware, por exemplo, que podem “sequestrar” uma máquina. Um exemplo de ferramenta que tira proveito dessas falhas do Java é o Neutrino Exploit Kit, que teve registrado um pequeno aumento no uso nas semanas em que o estudo foi feito pela Websense.

Problemas com Flash e o lado positivo – O Java, no entanto, não é o único esquecido pelas empresas. O plug-in Flash, da Adobe, encontra-se desatualizado em 40% dos navegadores nos PCs analisados pela empresa de segurança. Dessas, 25% das versões têm ao menos seis meses de idade, enquanto 20% têm um ano e quase 11% chega aos dois anos.  

Mas o estudo da Websense ainda tem um lado positivo, por incrível que pareça. Se comparados com as análises divulgadas no começo deste ano, os dados apontam para uma redução no número de computadores com a versão 6 do plug-in – de 70% para 40% do total. Com isso, dá para ver que, de todas as “múltiplas” empresas analisadas pela companhia, ao menos algumas veem as questões de segurança com um pouco mais de urgência.

Fonte: Revista Info

Read More

Nova vulnerabilidade do Java 7 abre portas para ataque de 10 anos de idade

Falha permite a crackers contornar a sandbox do software e executar um código arbitrário no sistema subjacente.

 

Pesquisadores da empresa de pesquisa de vulnerabilidades Security Explorations afirmam ter identificado uma nova vulnerabilidade no Java 7, que pode permitir a atacantes contornar a sandbox (mecanismo de segurança) do software e executar um código arbitrário no sistema subjacente.

A vulnerabilidade foi divulgada na quinta-feira (18) para a Oracle, juntamente com o código prova de conceito (PoC), disse Adam Gowdiak, CEO e fundador da Security Explorations, em uma mensagem no fórum Full Disclosure.

De acordo com Gowdiak, a vulnerabilidade está localizada na Reflection API (application programming interface), um recurso que foi introduzido no Java 7 e que tem sido fonte de muitas vulnerabilidades críticas no software até o momento. A empresa de segurança confirmou que o código de exploração PoC funciona no Java SE 7 Update 25 e versões anteriores, disse.

O novo problema identificado pela Security Explorations pode permitir a crackers executar um ataque "clássico", conhecido há pelo menos 10 anos, disse Gowdiak. Este tipo abordagem costumava ser usada para afetar a máquina virtual (VM) Java em seus primeiros dias, no final dos anos 90, disse via e-mail.

"É um desses riscos os quais deve-se proteger, em primeiro lugar, quando novos recursos são adicionados ao Java no nível VM núcleo", disse Gowdiak. É surpreendente descobrir que a proteção contra este tipo de ataque não foi implementada para a Reflection API no Java 7, quando estava sendo desenvolvido, disse.

O pesquisador afirma que a vulnerabilidade permite a atacantes violar uma característica fundamental da segurança da VM - a segurança do seu sistema de tipagem.

"Como resultado do ataque, pode-se realizar operações arbitrárias de conversão de tipo entre tipos de dados do Java como um inteiro e um ponteiro", disse ele por e-mail. "Em Java, as operações de conversão de tipo precisam seguir regras rígidas, para que a memória seja acessada de forma segura."

Gowdiak criticou a implementação da Reflection API no passado, dizendo que o recurso não parece ter sido submetida a uma revisão de segurança completa.

Ele acredita que a presença desta nova vulnerabilidade no Java 7 levanta dúvidas sobre a eficácia da garantia de segurança de software da Oracle e práticas de revisão de código de segurança. "Uma enorme quantidade de bugs passam despercebidos por essas políticas e procedimentos", disse ele.

Fonte: IDG Now

Como diz o Ditado: "Recordar, é viver", mais uma vez provando, que estudar falhas antigas, pode fazer a diferença na vida de um Analista de Segurança...

Read More

Como invadir um Windows [2]

Voltei com mais um método de invasão do nosso querido Windows.

Dessa vez vou abordar o segundo caso do post anterior, os ataques que exploram alguma vulnerabilidade através do browser da vítima. Para este exemplo a vítima precisa ter instalado o temido java, caso contrário não vai funcionar.

Lembrando: estes casos iniciais que estou mostrando aqui só vão ocorrer em um ambiente controlado. Acho que ninguém seria burro o suficiente para clicar em um link do tipo http://xxx.xxx.xxx.xxx:8080/QeuYsz, mais para frente vamos aprender como camuflar esse tipo de coisa para dai sim ficar mais convincente. ;)

Vamos então iniciar o Metasploit com o comando msfconsole e acessar nosso exploit:

use exploit/multi/browser/java_signed_applet
show options

OBS: Neste caso temos ali em Exploit Target quais alvos ele pode exploitar. Nesse caso apenas 32bits, se você tentar em um 64bits pode ser que nada aconteça.

Vamos preencher os campos necessários como sempre, SRVHOST e URIPATH e executar:

Iniciado e funcionando! Agora precisamos que a vítima entre neste endereço. Como estamos em um ambiente controlado, para facilitar vamos apenas digitar isso no navegador ;)

Assim que a página carrega em branco, ou com um Loading... escrito eu recebo um aviso de que uma aplicação java está pedindo permissão para ser executada:

Agora você me pergunta: Quem seria o idiota que executaria esta aplicação de um site estranho que nem carregou? A resposta é simples e eu já falei ela no início deste post. Como é um teste controlado está tudo certo e num teste real tem grandes chances de não funcionar, mas imagine isso aparecendo em um site que se parece muito com o site do banco da vítima, grandes chances dela clicar, mas veremos isso mais para frente, veja o que aparece no seu terminal se a pessoa liberar a execução:

Neste caso não caimos direto no meterpreter, precisaremos interagir com a sessão, mas sabemos que deu certo por que está escrito ali session 1 opened...

Para acessarmos essa sessão do meterpreter primeiro temos que confirmar o id da sessão listando todas as sessões abertas com o comando sessions -l, e depois interagindo com o comando sessions -i [id_da_sessão]:

Agora sim! Está ai! Vou rodar alguns comandos para confirmar que está tudo certo:

Tudo funcionando perfeitamente, estou novamente com controle da máquina alvo. Com isso já vimos dois dos principais tipos de ataques, aguarde que já já vem mais e depois vamos melhorar estes ataques para daí sim poder partir para a pós exploração.

Bons estudos!

Read More

Como funcionam as infecções por applets Java

O que são

Um java applet é um programa desenvolvido na linguagem Java que pode ser incluído em páginas de internet na criação de aplicações para a web. Quando um navegador (que possua a tecnologia Java) recebe um applet em Java, o plug-in do Java do navegador irá transferi-lo para o sistema, sendo executado pela Máquina Virtual Java (JVM, componente do Java Runtime Environment).

Os applets em Java são incluidos nos navegadores utilizando a tag <APPLET>, podendo este ser complementado por argumentos.

Para a aplicação na Web, os applets carregam arquivos com a extensão .jar. Esta extensão indica uma compressão de vários arquivos em um só (como arquivos .Zip). Isso se deve ao fato de que os applets normalmente necessitam de vários arquivos para sua execução (arquivos .class, imagens, assinaturas digitais, etc). No caso da tag <APPLET>, o argumento “code=” especifica qual aplicação dentro do arquivo .Jar será executado no navegador.

A tecnologia Java (da Sun/Oracle) pode ser comparada aos ActiveX (da Microsoft), com a vantagem daquela poder rodar em vários sistemas operacionais (multiplataforma), inclusive dispositivos como Handhelds, celulares e outros.

Como funciona o ataque

Applets em Java não podem ter acesso total à máquina de quem os executam devido a proteção de um Sandbox do Java. Porém, é possível que um applet em Java tenha acesso privilegiado ao sistema por duas maneiras:

1. Utilização de certificados digitais
   Quando é incluida, dentro do arquivo .jar, um certificado digital forjado, induzindo a vítima a aceitar o certificado e, consequentemente, executar o código malicioso.
2. Exploração de falha no Ambiente de Execução Java (JRE)
   Quando é encontrado algum exploit no JRE que permita passar pela proteção do Sandbox do Java.

A técnica de utilização de applets em Java para disseminação de malwares não é nova, tendo o seu conhecimento em 2000 com a prova-de-conceito Brown Orifice. Atualmente, bankers brasileiros estão utilizando esta técnica.

Detectando o ataque na prática:

Antes é necessário saber que o navegador é um programa que interpreta códigos de linguagens de desenvolvimento web, sendo a linguagem padrão o HTML. Cada código é passado para o navegador compreender e executar a ação necessária. O código em questão se refere à execução de um applet Java, devendo possuir a tag <applet> para que o navegador interprete a execução do mesmo, conforme o exemplo abaixo:

<applet name=”Nome do aplicativo” code=”arquivo.class” archive=”http://site.com/arquivo.jar” width=0 height=0><param value=””></applet>

Onde os itens mais importantes são os parâmetros archive= (normalmente é o endereço de um site, apontando a localização o arquivo .jar, sendo que este é uma espécie de arquivo compactado, pois possui diversos arquivos dentro) e o parâmetro code= (indicando o arquivo principal que possui os códigos que serão executados, estando este dentro do arquivo .jar).

Um parâmetro opcional existente na maioria das infecção por java applets é o param value=, que normalmente indica a localização do arquivo malicioso que será obtido pelo applet java através do comando getParameter(). Desta forma, o applet malicioso ficará encarregado de carregar e executar o arquivo computador da vítima. A minoria dos casos, os próprios arquivos .class dos applets java possuíam a localização do malware no seu próprio código.

Normalmente os navegadores emitem um aviso indicando que o site visitado está tentando executar uma aplicação Java, assim como é demonstrado no seguinte aviso do navegador Firefox:

Tela de prompt do Java para execução de aplicativo malicioso.

Como proteger deste tipo de ataque

Para evitar que os applets em Java sejam executados automaticamente, é necessário desabilitá-los no navegador:

• Internet Explorer
  (Aperte a tecla ALT para ver o menu, se necessário) Ferramentas, Opções da Internet. Na aba “Programas“, clique no botão Gerenciar complementos. Na lista, procure o Java. Selecione todas as opções do Java (usando SHIFT e CTRL, ou então uma de cada vez) e acione o botão Desabilitar. Reinicie o navegador. Se o Java não estiver sendo exibido, verifique se a opção “Todos os complementos” está selecionada no menu rotulado “Mostrar” na parte esquerda da tela. (A opção “Desativar scripts de miniaplicativos Java”, nas zonas de segurança não funciona, apesar do nome)
• Mozilla Firefox
  Acesse o menu “Firefox” e então “Complementos”. Clique em “Desativar” em todas as opções relacionadas ao Java nos plugins.
• Opera
  Menu Arquivo > Preferências Rápidas > Desmarcar “Habilitar Java”
• Google Chrome
  É preciso acessar o endereço chrome://plugins. O Java estará na lista. Basta desativar.

OBS.: Applets em Java dependem de que o JRE esteja instalado no computador para serem executados.

Sugestões de Leitura:

• Malware: Fighting Malicious Code. SKOUDIS, Ed.
• Oracle.com – Documentação Java
• Developer.com – Breaking the Sandbox Barrier

Creditos: Diogo Baptista(Linha defensiva)​

 

Read More