A morte do Java nas empresas está próxima?
Uma bomba Zero-Day que explodiu no começo de janeiro a respeito do Java foi um começo que muitos pesquisadores de segurança precisaram para retomar discussões a respeito da linguagem. É a continuidade de uma onda que começou ano passado depois de uma onda de vulnerabilidades que fez com que o Computer Emergency Readiness Team (Cert), do Departamento de Segurança Nacional, sugerisse nesta semana que usuários desabilitassem o programa em seus navegadores de internet.
Curta, no Facebook, a Fan Page do IT Web
Mas desabilitar o Java não é uma opção simples para empresas que dependem pesadamente do software para rodar aplicações críticas de negócios.
“Para muitos usuários domésticos, é verdade que você pode desinstalar o Java sem afetar sua experiência online”, diz Liam O Murchu, pesquisador da Symantec. “Mas para negócios o Java é usado para aplicações muito mais pesadas. Então, de uma perspectiva corporativa é muito mais difícil dizer ‘ok, eu vou desabilitar o Java’, porque é algo necessário ao seu dia a dia”.
Então a pergunta é, sem quebrar essas aplicações, como as empresas podem mitigar o risco de explicações do Java se tornarem um vetor que invasores buscam para iniciar ataques que comprometem bases de dados? E, mais, as empresas deveriam questionar sua dependência ao Java, de maneira geral?
“O que realmente está chamando a atenção das pessoas é que os ataques atuais são usados em pacotes de exploração web a partir de vulnerabilidades Zero-Day o que é incomum”, diz O Murchu. “O que vemos normalmente em ataques de vulnerabilidades do tipo Zero-Day é que são utilizados de forma direcionada. Mas, neste caso, a abertura foi usada, pela primeira vez, em um ataque em massa.”
Do seu lado, a Oracle respondeu com mais rapidez a esse ataque em particular do que a problemas descobertos em agosto, entregando um patch em questão de dias para endereçar a vulnerabilidade no Java 7 Atualização 10 que permitia execução remota e não autorizada em sistemas infectados. Com o boletim de segurança, a fabricante também trocou as configurações de segurança em Java para “alta” por default em seu plug-in de software.
“As configurações altas de segurança requerem que usuários autorizem expressamente a execução de applets [software aplicativo que é executado no contexto de outro programa] mesmo que sejam sem assinatura ou autoassinados”, escreveu Eric Maurice, diretor da área de segurança da Oracle, em um blog corporativo. “Como resultado, usuários não suspeitos que estejam visitando sites maliciosos serão notificados antes de um applet rodar e terão a habilidade de negar a execução de applets potencialmente maliciosos. Note também que o Java SE 7 Atualização 10 traz a habilidade de usuários facilmente desabilitarem o Java em seus navegadores através do painel de controle”.
A reação imediata de muitos gestores de TI que recebem a sugestão de desabilitar o Java é “não se eu quiser manter o meu emprego”. “Mas essa não é uma verdade universal como se pensa”, disse Wolfgang Kandek, CTO da Qualys.
Como ele e outros especialistas que defendem uma menor exposição ao Java dentro das empresas explicaram recentemente, na maioria dos casos, desabilitar capacidades do client do Java nas máquinas de usuários não, necessariamente, causam estragos em aplicações de negócios. “Há uma importante distinção que precisa ser feita entre o Java interno do navegador e o muito conhecido Java que roda dentro do ecossistema”, disse Jo DemEsy, analista da Stach & Liu. “Essa vulnerabilidade não afeta aplicações web que utilizam o Java do servidor, o que é, de longe, o uso mais comum do Java dentro da linguagem de programação. A vulnerabilidade se aplica ao Java rodando em usuários web que tenham baixado um applet malicioso de Java. Esse tipo de implementação é muito menos comum [para aplicações corporativas].”
Mesmo se a empresa tiver de rodar um applet Java ao lado do client para manter certas aplicações críticas de negócios rodando, há formas de mitigar o risco de vulnerabilidades baseadas em Java de web. Muito disso é exposto em políticas de configuração, procedimentos e diretrizes.
“É muito chato, mas realmente funciona”, diz Steve Santorelli, diretor do Team Cymru. “Isso vai ajudar a determinar para os usuários quais sites você pode ir e quais tecnologias relacionadas a Java você pode instalar em sua máquina. Mas isso envolve muito tempo com listas brancas, listas negras e lidar com alertas e todo o suporte técnico necessário”, pontuou.
Por sorte, muitos fabricantes de browsers aliviaram a carga com características para torná-lo mais fácil de apoiar e reforçar as políticas. É o caso do Google Chrome e do Firefox com a funcionalidade “Click-to-pay” para plug-ins de browsers.
Mas antes que as organizações pensem em atividades do tipo, é preciso fazer uma análise para entender exatamente qual a dependência em relação ao Java e poder, consequentemente, criar políticas de restrição.
“Isso vai custar algum dinheiro e fontes de recursos”, ele disse. “Mas é a única forma de desenvolver uma estratégia. Um inventário vai encontrar instâncias do Java sendo usados no lado do client e, pior, aplicações que dependem de versões antigas do programa”, disse Kandek, CTO da Qualys.
*Texto editado
