La raíz de todos los problemas de seguridad de Java en el escritorio: la gente no lo actualiza
AbrahamEl título de esta noticia es el argumento que yo llevo haciendo años: el problema de seguridad de Java en el escritorio origina de un modelo de seguridad roto por parte de Oracle. Como han descubierto los sistemas operativos hace varios años, como han comenzado a descubrir los navegadores web más recientemente, los usuarios finales de los productos por norma general no se van a molestar en actualizar las aplicaciones que tienen instaladas. Por defecto, esas actualizaciones deben de suceder de modo transparente para el usuario, sin que él tenga que realizar ninguna acción e, idealmente, sin que tan siquiera se entere.
Debería haber alguna forma de desactivar las actualizaciones, cosa que puede ser útil en contextos empresariales. Pero para la inmensa mayoría de la población, para la "inmensa mayoría del área de la superficie de ataque" desde el punto de vista de los hackers, la actualización automática y transparente es la solución adecuada. Porque si no las actualizaciones no van a suceder. Y que no sucedan es malo tanto para ellos como para el resto de los usuarios de Java, ya que incrementa el área de la superficie de ataque, y por tanto los incentivos de los hackers para atacar a Java.
La noticia de hoy no es que yo piense esto; si seguís el portal y el podcast estáis hartos de oirme decir esto. La noticia de hoy es que, por fin, tengo números para respaldar esta afirmación (haced clic en la imagen para ver el gráfico con tamaño original):
;)
Ese gráfico ha sido desarrollado por una compañía de seguridad en base a las versiones de Java que la gente tiene instalada como plugin de su navegador web. Menos del 5.5% de la gente tiene actualizado Java a la última versión (Java 1.7.17, o Java 1.6.43). Aproximadamente el 75% de la gente tiene una versión de Java instalada que tiene un año o más de antigüedad. Aproximadamente el 50% de la gente tiene una versión con dos o más años de antigüedad. Y casi el 25% de la gente tiene una versión con tres o más años de antigüedad. También parecen quedar más de 8.5% de gente conversiones entre Java 1.0 y Java 1.4.
Ahora imagina que tu eres un hacker y que tu propósito es infectar equipos de usuarios para luego poder hacer ataques DDoS o para intentar robarles sus credenciales de acceso su banco. Y ves ese gráfico. Y te das cuenta que el 95% de la gente que tiene un plugin Java instalado en su navegador (según Oracle son 1,100,000,000 de personas) tiene una versión que es vulnerable a ataques conocidos. Ataques que encima ya han sido parcheados por Oracle. ¿Qué haces?. Pues os explico los pasos:
- Te bajas los últimos parches de seguridad publicados por Oracle a tu equipo
- Haces reingeniería inversa de esos parches y estudias su código. Por tanto, comprendes cual es la vulnerabilidad que parcheaban.
- Escribes un exploit para la vulnerabilidad y o bien lo distribuyes tú mismo (por ejemplo, usando el agujero de seguridad de Apache), o se lo vendes agente (como hace la gente de BHEK)
- Comienzas a infectar potencialmente los más de 1000 millones de equipos que no tienen Java actualizado a la última versión.
- Te compras una casa en la playa de algún país en el trópico y te dedicas a refrescar el saldo de la cuenta de tu banco en tu iPad mientras tomas mojitos en la playa
El paso 5 puede que sea un poco exagerado. Pero los otros cuatro son reales. También es posible saltarte los pasos 1 y 2 y, si no tienes suficientes conocimientos técnicos o no quieres llevar mucho trabajo) directamente comprar alguno de los Exploit Kits más comúnmente empleados por los hackers, como BlackHole Exploit Kit (BHEK) (que en el mercado negro tiene un precio de $1500 al año), o como Cool Exploit Kit (CEK) (que tiene un precio de $10,000 al mes; sí, $10,000 al mes, no al año). En este último caso, seguro que te vienen unos cuantos Zero-Day exploits que todavía no se conocen para Java en el exploit kit. Para al menos alguna de la gente que está detrás de estos exploit kits, el paso 5 de la lista no es una exageración.
Para terminar, una vez más, repetiré mi mantra: ¡Actualizaciones automáticas para Java ya!
Reader Comments (7)
Estoy parcialmente de acuerdo, coincido en todo, pero creo que la solución definitiva pasa por un cambio más profundo. Hay que matar al plugin de Java y echarlo de la web de una vez por todas.
En su momento el plugin fue una solución de compromiso para las limitaciones de la web en sus comienzos, pero hoy no tiene ningún sentido, va a contramano de todo.
Además, cada vez son menos los dispositivos (en particular los móviles, desde smartphones hasta tabletas) donde está disponible Java y el "bendito" plugin.
Gracias por lo que nos dio el plugin de Java cuando fue necesario, como lo hizo Flash en su momento también. Ahora pasemos al 2013 y a lo que viene.
Entiendo que es una posición polémica y extrema, pero creo que extender la agonía del plugin, en lugar de darle una muerte digna, solo erosiona y desacredita a la gran plataforma Java y no se lo merece.
Tu propuesta es irrealizable. Por un lado, rompe compatibilidad hacia atrás, lo cual nunca es buena idea. Por otro, ten en cuenta que Oracle (al menos de boca) sigue apostando por JavaFX, lo que implica ejecución a través del navegador. Así que está claro que lo que tú pides no lo vamos a tener. Actualizaciones automáticas, será complicado, pero es más realista.
@Abraham no es irrealizable, de hecho, los navegadores ya han bloqueado el plugin de Java reiteradas veces, ante los fallos de seguridad más críticos. Me consta que lo hace regularmente Mozilla y Google con su Chrome, y no me extrañaría que lo haga MS, Opera y Safari también. Así que es más realizable, sucede actualmente. Y en muchas empresas ha sido prohibido por normas de seguridad internas y externas (me consta).
¿Compatibilidad hacia atrás? ¿Con qué? Java jamás formó parte realmente de la web, ni flash, ... todo apunta a html5+/css/js, y en muchos casos, es la única opción disponible.
JavaFX, como bien dices, es una "apuesta"... una apuesta de Oracle que no apoya nadie y va a contramano de todo. Cuando tecnologías similares han fracazado y se están discontinuando (como Silverlight y Flash)... Oracle quiere insistir con un concepto que viene mal desde el principio.
Estoy de acuerdo con las actualizaciones automáticas, y las debemos tener. Y Oracle debe elmiinar todo "bloatware" de sus instaladores también. Pero el plugin tiene sus días contados. Si no lo mata antes Oracle, más tarde lo harán los browsers, solo que el daño para entonces será mayor para la plataforma. Recuerda lo que te digo. Ojalá me equivoque, todos se vuelquen a las aplicaciones de Escritorio de nuevo y abracen a JavaFX y a los plugins del browser como al hijo pródigo... sinceramente, esto si que no creo que pase. Ojalá me equivoque, pero yo lo dudo.
Java es una grandiosa tecnología de servidor. Android es una grandiosa tecnología móvil. El plugin ya es irrelevante, está bien que exista como algo opcional para algún ambiente de nicho que aún lo use, como cualquier tecnología legacy, pero veo contraproducente que sea instalado y activado por defecto al público en general, es buscarse problemas innecesarios. La mayoría (por lejos) de la gente no lo precisa, y un principio de seguridad básico, es jamás habiltar servicios que no se usan.
Hay un ámbito en el que todavía se usan applets (o ActiveX incluso), y es en cualquier proceso de firma digital, lo que implica básicamente a casi todas las webs de la administración pública donde puedas hacer una gestión. El combo HTML5/CSS3/JavaScript ha avanzado mucho en otros aspectos, pero sigue sin ser posible el firmar digitalmente algo con alguna de las claves privadas que tengas instaladas (al menos, de forma estandarizada). Y es una pena, porque estoy de acuerdo en que esos plugins deberían ir desapareciendo.
@gorlok, en general estoy de acuerdo con tu punto de vista. Menos en dos cosas. Primero, el que tiene que "desterrar" el plugin Java es Oracle. Y no lo va a hacer. No lo va a hacer porque sigue apostando por JavaFX, y hacer eso esperarle un tiro en la cabeza a JavaRX. Claro que técnicamente se puede hacer. Y algunos navegadores lo hacen. Pero Oracle no lo va a hacer, no por motivos técnicos, sino de negocio.
Segundo, Java si fue parte importante de la web en su día (antes del año 2000) y si sigue siendo parte importante. Un ejemplo bueno es el que menciona @adeteran. Esta misma semana yo he empleado un Applet del Estado para realizar ciertos trámites de modo electrónico. Sí que hay ciertos motivos en la línea de mantener compatibilidad hacia atrás que pueden servir de argumento para seguir manteniendo el plugin.
Y al hilo de toda esta discusión, es interesante leer la noticia de hoy:
http://www.javahispano.org/portada/2013/4/10/tienes-una-applet-firmalo-pronto.html
No es tanto como tú querías, pero menos da una piedra. Y no creo que Oracle vaya ir más allá de lo que ha ido con este paso.
@gorlok, yo estoy con Abraham. Piensa que si se aplicase la misma política que se aplica al plugin Java, es decir, deshabilitar el software, no habría software que se estuviese ejecutando, empezando por los propios navegadores y terminando por los sistemas operativos.
Incluso los sistemas operativos permiten a los usuarios elegir si actualizan o no, y dado que la mayoría ni siquiera es consciente de que tales problemáticas de seguridad existen o bien tienen el ajuste por defecto o bien se lo han deshabilitado (y cuando hablamos de Windows tendríamos que entrar en la problemática de las copias piratas y las claves de los productos que, en caso de realizar actualizaciones, acaban por no dejar usar el Windows), no son más que personas corrientes que compran herramientas para jugar, relajarse, dibujar, o para los hijos; así que hablarles de exploits, agujeros de seguridad, etc. no causa más efecto que una gran alarma.
Yo también creo que las actualizaciones automáticas son algo obligatorio hoy en día para la inmensa mayoría de consumidores, aunque también apuesto por la política de que exista una puerta atrás que permita un mayor control a las empresas en este sentido. Pero entiendo que las actualizaciones automáticas y silenciosas deben estar habilitadas por defecto en todas las piezas del software, no sólo en el Java o en el plugin de Java.
Y aún así nunca estaremos seguros del todo.
Todo el manejo de tokens y certificados de seguridad lamentablemente ES un parto, con o sin Java (y aún peor con ActiveX). A día de hoy no hay una sola solución que funcione bien para todos los escenarios sin problemas, y que encima sea multiplataforma y multibrowser, sería la panacea. Simplemente no existe eso. Con Java y el plugin es una de las mejores opciones, lejos de la ideal ni libre de problemas (para usuarios y desarrolladores por igual). Entonces, aquí tenemos soluciones parciales y de compromiso, que casi no mejoraron en muchos años. Es uno de los casos de situaciones de nicho que comentaba donde el plugin puede ser útil, aunque como una descarga opcional, en entornos controlados, que no se habilite por defecto, .. pero que veo lejos de la mayoría de los usuarios.
Coincidirán, que sería positivo que se "deprecaran" (perdonen esta palabra, pero para no decir que la maten) estas soluciones, así los fabricantes de navegadores con la w3c terminan de definir de una vez por todas una buena solución estándar, multiplataforma y segura, que sea útil para cualquier tecnología del lado del servidor, que brinde una solución satisfactoria y madura de una vez por todas para el manejo de tokens y certificados. Archivar al plugin de Java, podría ser un primer paso para empujar el desarrollo de una mejor solución que la actual, aunque reconozco que no es un paso necesario, ni es por culpa del plugin de Java que no haya mejores alternativas a la fecha.
Entiendo que Oracle no lo va a matar al plugin, por su apuesta a JavaFX (quijotesca para mi) como ustedes decían más arriba. Para mí en este caso Oracle comete un error, y creo que pierden una oportunidad de oro de cortar por lo sano para fotalecer a toda la plataforma.
PD: buen debate, aunque tengamos puntos de vista distintos en algún aspecto ;-)