Se ha detectado un repunte de ataques contra Java SE Runtime
\nEnvironment, que aprovechan vulnerabilidades de este software e instalan
\nmalware, ensombreciendo por aplastante mayor\u00eda a los ataques contra el
\nAdobe Reader que \u00faltimamente parec\u00eda el preferido por los atacantes.<\/p>\n
Venimos avisando desde hace algunos meses que los ataques contra Adobe
\nReader en forma de archivo PDF especialmente manipulado viene siendo
\nla t\u00f3nica habitual entre los atacantes. Desde el Microsoft Security
\nIntelligence Report descubren que, desde el segundo trimestre de 2010,
\neste tipo de ataques se ha visto totalmente ensombrecido por los ataques
\ncontra Java SE Runtime Environment (JRE), aprovechando sus numerosas
\nvulnerabilidades.<\/p>\n
Hace unos d\u00edas Oracle, propietaria de los productos de Sun tras su
\ncompra, publicaba una actualizaci\u00f3n de la plataforma JRE que correg\u00eda 29
\nproblemas de seguridad, la mayor\u00eda bastante graves. Esta es la t\u00f3nica
\nhabitual en la JRE desde siempre. Ahora que Oracle se ocupa de sus
\nactualizaciones, la situaci\u00f3n parece haber empeorado. Oracle ha incluido
\nel software en su ciclo trimestral de actualizaciones, lo que arrastra a
\nla m\u00e1quina virtual de Java en el desastre (y oscuridad) t\u00edpica de Oracle
\nen cuesti\u00f3n de gesti\u00f3n de fallos.<\/p>\n
Los fallos que est\u00e1n siendo aprovechados en concreto son: CVE-2008-5353,
\ncon 3.560.669 ataques detectados, CVE-2009-3867 con 2.638.311 y
\nCVE-2010-0094 con 213.502. Los ataques PDF apenas llegan a las decenas
\nde miles.<\/p>\n
\u00bfPor qu\u00e9 los atacantes prefieren ahora atacar la Java? Siempre ha
\nsido un objetivo muy apetitoso. A trav\u00e9s de applets, los navegadores
\ndescargan c\u00f3digo y lo ejecutan en local con la m\u00e1quina virtual. Esto
\nya de por s\u00ed no es muy buena idea. Aunque la seguridad de Java est\u00e9
\ndise\u00f1ada desde un principio para (a trav\u00e9s de varios niveles como la
\nsandbox donde se supone que se “encierra” el c\u00f3digo), limitar su
\nimpacto, las vulnerabilidades descubiertas permite eludir esta
\nprotecci\u00f3n y ejecutar otros c\u00f3digos.<\/p>\n
Adem\u00e1s JRE est\u00e1 muy presente en casi cualquier sistema operativo y
\narquitecturas, y esto ofrece mucha flexibilidad. Por ejemplo, a los
\ncreadores de kits de explotaci\u00f3n: incluyendo el aprovechamiento de
\nalguna de estas vulnerabilidades, podr\u00edan infectar por igual diferentes
\nplataformas.<\/p>\n
Otra de las razones se encuentra en la p\u00e9sima idea de Sun de mantener
\nlas versiones antiguas en el sistema (por compatibilidad). Con la
\naparici\u00f3n del Update 10 a finales de 2008 decidi\u00f3 (por fin), modificar
\neste comportamiento. Desde entonces, cuando se actualiza la JRE, el
\nmismo instalador elimina la anterior. Pero hist\u00f3ricamente, este perenne
\nalojamiento de versiones ha inculcado a los usuarios que, adem\u00e1s de que
\nactualizar Java no sirve de mucho y es un proceso tedioso, consume
\nimportantes recursos en el sistema (cientos de megas por versi\u00f3n).<\/p>\n