Três vulnerabilidades que devem ser corrigidas na base Oracle
Administradores de sistemas e todas as frontes de TI ficarão ocupados na correção das vulnerabilidades da Oracle através de seu portfólio gigantesco, com o lançamento da semana passada do Critical Patch Update (Atualização de correção crítica) trimestral da empresa. Especialistas em segurança alertam as empresas a terem atenção redobrada com esse último CPU, que aborda cem alterações que afetam dez grupos diferentes de produtos, com uma ou mais vulnerabilidade em cada grupo aberta à exploração remota.
Curta, no Facebook, a Fan Page do IT Web
Uma observação particular das correções de vulnerabilidades feitas pela Oracle foram duas falhas com uma pontuação do Cvss (Common Vulnerability Scory System – sistema que mede as características e grau de impacto de vulnerabilidades; N. da T.) de 10.0, uma para o produto database Core Rdbms e uma para o componente JRockit, da Oracle Fusion Middleware, bem como outra falha do MySQL com uma pontuação de 9.0 Cvss. Segundo a Oracle, a correção mais crítica do JRockt foi na verdade parte da uma ampla correção Java SE Critical Patch, para múltiplas vulnerabilidades que afetavam o Java Runtime Environment, algumas das quais os especialistas em segurança esperam que avaliem vulnerabilidades zero-day descobertas pela Security Explorations no mês passado.
“Muitos esperavam que a Oracle corrigisse o Java Runtime Environment (JRE), o que fizeram com o Java Runtime Environment Version 7 Update 9 e Version 6 Update 37”, explicou Marcus Carey, pesquisador de segurança da Rapid7. “Meu conselho é que todos que usam Java façam a atualização imediatamente”.
Segundo Wolfgang Kandek, CTO da Qualys, o Java é uma peça frequentemente negligenciada do software dentro do processo de correção de muitas empresas, uma oportunidade que muitos invasores não falham em tirar vantagem.
“Em nossas pesquisas dentro do ciclo de atualização de vulnerabilidades, frequentemente vemos o Java ser um dos aplicativos mais lentos a serem atualizados, ficando para trás em muitos ciclos de correção. Os invasores se adaptarem à esse realidade, e muitas explorações moderna têm primeiro ataques com base no Java, já que vulnerabilidades conhecidas podem ser exploradas com segurança”, observou Kankek.
Enquanto isso, na fronte da base de dados, a maior vulnerabilidades dentro das cinco nomeadas dentro do grupo de produtos Core Rdbms foi uma falha descoberta pelos pesquisadores da Application Securit, Inc. em 2010, em relação à maneira que o Oracle 11 g lidava com protocolo de login.
“Chamamos de quebra de roubo de senha e é uma vulnerabilidade no protocolo de login apresentada quando lançaram o 11 g”, explicou Josh Shaul, CTO da Application Security, falando sobre a falha que permite que os invasores adivinhem senhas com base em informações enviados para o cliente pela base de dados.
Segundo ele, a empresa tinha anteriormente deixado a entender para o Application Security que não lançaria uma atualização CPU para a falha, o que levou a empresa de segurança a planejar meticulosamente a explicação da falha para sua base de clientes e o público em geral. A Oracle mudou o curso de sua decisão, o que levou a Application Security a revelar apenas parcialmente alguns detalhes da vulnerabilidade em sua conferência realizada na Argentina, no mês passado, e atrasar mais informações detalhadas sobre a descoberta até que o CPU fosse lançado.
“A Oracle demorou na decisão porque é um problema de protocolo, o que significa que impacta não apenas a database, mas todos os clientes. Mas Shaul explicou que apesar de isso nos remeter a uma falta de sensibilidade em autenticação Oracle, é melhor do que uma vulnerabilidade no ambiente.
Carey alerta que apesar de sua pontuação Cvss ser baixa, a outra grande vulnerabilidade da database no MySQLmerece a mesma preocupação dos usuários. “Essa me assusta mais do que qualquer outra”.
A razão disso é que segundo uma pesquisa recente da Rapid7, metade das instâncias de implantação MySQL não usam controle de acesso com base no host. E com tantos sistemas de gerenciamento de conteúdo, como o WordPress usando o MySQL na internet, há uma oportunidade para uma grande ameaça de malware, se os invasores se aproveitaram de vulnerabilidades 9 ou 10, que têm um grande potencial de exploração remota.
“Temo que possa acontecer um grande surto de MySQL sendo explorado em larga escala e já que muitos sistemas de gerenciamento de conteúdo usam isso, pode-se encontrar invasores inserindo conteúdo malicioso na base de dados para renderizar e explorar várias pessoas”.
Além dessas vulnerabilidades severas apontadas pelos especialistas, há dúzias de outros potenciais para problemas se não forem avaliados a tempo. Segundo Chris Eng, vice-presidente de pesquisa da Veracode, ele priorizará o exame dos riscos específicos para a base instalada dentro de seus ambientes e os dados processados por esses aplicativos.
“Se você tem problemas sérios no servidor de gerenciamento de documentos de dados, mas o está usando para documentos sem muita importância, pode não ser tão crucial que a correção seja feita imediatamente. Talvez você tenha algumas vulnerabilidades cross-site-scripting, em um produto Oracle implementado e que foi revelado ao público. Nesse caso é importante realizar a correção, mesmo se a severidade for baixa, porque já foi revelada”.
Tradução: Alba Milena, especial para o IT Web | Revisão: Adriele Marchesini
