El 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!