Tal vez han escuchado sobre los problemas de seguridad generados por los plugins de Java y el Java Runtime Environment (JRE). Algunos investigadores de seguridad reportaron que los atacantes están aprovechando las vulnerabilidades de este popular lenguaje de programación.
Tod Beardsley, Ingeniero en Rapid7, dijo: "Los usuarios deberían deshabilitar los plug-ins de Java para los navegadores. A diferencia de Flash, HTML5 o incluso PDF, no es la tecnología omnipresente en la Web ... Deshabilitar la funcionalidad innecesaria siempre es un buen consejo - Así se reduce la posibilidad de ataques".
Tal consejo puede ser muy útil para los usuarios finales, pero no para las empresas debido a que una
serie de aplicaciones empresariales comunes, como las
conferencias y la colaboración se basan en el tiempo de ejecución de
Java, y algunas aplicaciones de centros de datos se ejecutan en Java,
dice Scott Crawford, director de investigación de la firma analista de
la industria Asociados Enterprise Management.
Ese no era el caso hace algunos años. Wolfgang
Kandek, CTO de Qualys, dice que los navegadores web solían ser un objetivo
prioritario para los atacantes hasta que los fabricantes de navegadores
desarrollaron mejores defensas de seguridad. Los
atacantes cambiaron su atención a otros programas como Flash y PDF,
pero Adobe ha puesto una gran cantidad de recursos en el fortalecimiento de sus productos. Ahora parece que Java está en la mira.
SystemsExperts' Hill ve muchas organizaciones que están eliminando las dependencias de applets de Java. "Ahora
la gente está desarrollando aplicaciones web enriquecidas con técnicas
Ajax para Java que se ejecutan en el servidor y no en el lado del cliente", dice.
¿Cómo se puede asegurar Java?
Unos pocos antecedentes.
Oracle, empezando por Sun, ha avanzado el desarrollo del ecosistema de Java en varias áreas, incluyendo el lenguaje de programación del lado del servidor y el entorno JRE generalizada del lado del cliente, pero los atacantes continúan exponiendo las vulnerabilidades de seguridad graves en el JRE. La mayoría de estas vulnerabilidades están limitadas a las plataformas más comunes, tales como MacOS y Windows, pero ya que Java se utiliza en una amplia variedad de plataformas para el software de cliente, el impacto de vulnerabilidades no puede entenderse bien.
Aquí intentaremos a hablar de la última serie de vulnerabilidades de seguridad de Java y ofrecer algunas medidas para mejorar la seguridad de Java.
En
los últimos tiempos, parece que al igual que Oracle lanza un parche
para la vulnerabilidad expuesta más recientemente Java, los atacantes
encuentran una para explotar. Otra
vulnerabilidad grave fue identificado septiembre de 2012; permite que
un atacante pueda aprovechar una característica de seguridad núcleo de
la JRE de Java, seguridad de tipos, para escapar del sandbox de Java. Un atacante puede comprometer totalmente la seguridad de un sistema mediante la explotación de esta vulnerabilidad.
Peor
aún, los parches de seguridad de Java pueden estar dando a los atacantes más
oportunidades de explotar: Se cree que la vulnerabilidad JRE que se
informó de agosto 2012 puede haber sido introducida por un parche
anterior. El
error en el sub-componente AWT de Java también podría permitir la
ejecución de código en el sistema local, lo que evitaría la caja de
arena y dar lugar a un sistema que está siendo comprometida. Cuando
el proceso de actualización de software de Oracle expone nuevas
vulnerabilidades de seguridad, la fuerza del ciclo de vida de desarrollo
de software de Java entra en cuestión. No
todos los errores se pueden prevenir, pero parece claro un ciclo de
vida de desarrollo de seguridad más fuerte que se necesita para ayudar a
prevenir la introducción de nuevos errores de Java.
La realidad es que el problema de seguridad de Java no va a desaparecer. Las vulnerabilidades seguirán siendo encontradas, explotadas y parcheados por Oracle con velocidad variable y eficiencia. Para
ser justos, el proveedor de software se enfrenta a una tarea difícil,
ya que pretende fomentar el desarrollo de Java al intentar mantenerlo
seguro. Oracle se ha sumado a la deuda técnica de Java, lo que
resultará en un número cada vez mayor de las vulnerabilidades.
Métodos para asegurar Java.
Como ya se ha dicho, algunos expertos recomiendan deshabilitar Java, pero también se ha visto que es más fácil decirlo que hacerlo. A
pesar de que existen alternativas viables para el software como Adobe
Reader, no hay alternativas reales existen en la actualidad para el
entorno de ejecución de Java. La
realidad es que muchas aplicaciones empresariales se basan en Java,
para muchas organizaciones, desactivar Java simplemente no es una
opción.
Dicho
esto, el consejo estándar para asegurar cualquier software de
cliente se aplica al JRE también, incluyendo no instalar (o desinstalar)
el JRE si no es necesario, manteniendo el JRE hasta la fecha, la
eliminación de las viejas versiones y la implementación de parches gestión de la seguridad y los controles en el extremo del lado del cliente.
Pero considere controles adicionales específicamente para Java. Por
ejemplo, una empresa puede ejecutar el software JRE y necesaria en su
propia máquina virtual, ejecute el JRE con permisos reducidos (que ya
debe ser una política predeterminada independientemente) y permitir que
la lista blanca applets de Java para ejecutar en el JRE con el software
Noscript o similar. El
kit de herramientas de Mitigación Enhanced Experience se puede utilizar
para configurar de forma más segura el JRE en los sistemas Windows.
Las empresas también pueden compilar código Java en ejecutables nativos para evitar problemas con el JRE, pero esta acción negaría el "escribir una vez, ejecutar en cualquier lugar" beneficio de la utilización de Java. Teniendo en cuenta que la mayoría de los applets de Java se ejecutan en cualquiera de PCs o Macs, esto podría ser una medida razonable para algunas organizaciones, pero no iba a funcionar para todas las plataformas que ejecutan Java.
Las empresas también pueden compilar código Java en ejecutables nativos para evitar problemas con el JRE, pero esta acción negaría el "escribir una vez, ejecutar en cualquier lugar" beneficio de la utilización de Java. Teniendo en cuenta que la mayoría de los applets de Java se ejecutan en cualquiera de PCs o Macs, esto podría ser una medida razonable para algunas organizaciones, pero no iba a funcionar para todas las plataformas que ejecutan Java.
Si
pudiera ser compilado, esto ayudaría a reducir el número de sistemas en
una empresa que tiene un JRE instalado sólo por una aplicación. Todos
estos métodos requieren un esfuerzo significativo, pero podría reducir
el riesgo a un nivel aceptable para la mayoría de las empresas.
El entorno de ejecución de Java fue el resultado de esa necesidad de facilitar el desarrollo multiplataforma. Lamentablemente,
la reputación del ecosistema Java ha tenido un éxito significativo
debido al gran número de vulnerabilidades de seguridad expuestas en el
JRE y ciclo de vida de desarrollo de software de Oracle. Si
bien las organizaciones deben pensar largo y tendido acerca de
comprometerse con Java, por fortuna, hay maneras para que las empresas
para limitar el riesgo que representa para sus extremos por la JRE si se
trata de una necesidad de la empresa, y si no es absolutamente
necesario, sin embargo, no debe ser instalado.
0 comentarios:
Publicar un comentario