Si llevas algo de tiempo en seguridad, con certeza habrás visto cómo el mundo de los Exploits Kits o el malware han utilizado bugs de Java para conseguir la ejecución de código remotamente. Muchos de esos exploits están en los arsenales de los Metasploit de los pentesters para que estos puedan conseguir acceso a los equipos que no han tomado la precaución de mantener actualizado el framework de Java. Aún así, el riesgo de que aparezca un 0day y te afecte es muy alto, y por eso Java ha intentado poner medidas paliativas para que un administrador gestione listas blancas de sitios a los que va a permitir que ejecuten Applets de Java o no.
Las medidas que actualmente se pueden aplicar para crear listas de seguridad son dos, tal y como se explica en el blog de Eleven Paths y vamos a ver cómo funcionan y cómo se pueden configurar cómodamente con JavaRuleSetter.
Deployment Rule Set y Exception Site List
Para que nos hagamos una idea, la primera de ellas es una forma de conseguir que un Applet se ejecute automáticamente sin generar ninguna alerta por medio de la firma digital del mismo. No son sencillas de configurar ya que hay que generar un fichero XML con un formato concreto, hay que firmarlo digitalmente y ubicar los ficheros en determinadas ubicaciones, pero permiten que se hagan despliegues de aplicaciones a través de Internet por medio de Applets en modo lista blanca. Esta configuración requiere permisos de administrador en la máquina y está disponible a partir de Java 7u51.
Figura 2: Configuración de nivel de seguridad en Java y Exception Site List |
La segunda de las configuraciones de seguridad es la Exception Site List, que permite indicar un conjunto de sitios de lista blanca a los que se les permitirá rebajar el nivel de seguridad. El número de alertas y las restricciones que tendrán esos Applets dependerán del nivel de seguridad que se haya elegido en la configuración de Java en el sistema. Estas configuraciones se pueden hacer a nivel de usuario y están disponibles a partir de la versión de Java en Enero de 2014. Su funcionamiento es muy similar al bloqueo de ActiveX que introdujo Internet Explorer 8 hace tiempo.
Figura 3: Árbol de decisión en la ejecución de Applets dependiendo de la configuración de seguridad |
Al final, el árbol de decisión sobre la ejecución de un Applet Java hoy en día es bastante complejo, y dependiendo de la configuración del nivel de seguridad de Java, la lista de sitios de excepción y las Deployment Rule Set que se hayan configurado, el resultado a la hora de proteger el sistema contra la explotación de un ataque proveniente de un Applet malicioso puede ser muy distinto.
JavaRuleSetter
Para hacer esto mucho más sencillo, desde el laboratorio de Eleven Paths hemos publicado una herramienta llamada JavaRuleSetter que permite gestionar las listas blancas como si de un firewall se tratara. Para ello, la herramienta configura una regla por defecto en la que se activa el nivel alto o muy alto de seguridad en Java y cualquier Applet que venga a ejecutarse debe cumplir los requisitos de esos niveles o estar en la lista blanca.
En este ejemplo, con la regla por defecto que activa el máximo nivel de seguridad, cualquier intento de ejecución de un Applet será bloqueado, tal y como se aprecia en la imagen siguiente donde se intenta ejecutar un Applet proveniente de Java.com.
Para conseguir que se pueda ejecutar, basta con meter una regla con la excepción para ese sitio, tal y como se ven en la imagen siguiente.
A partir de este momento, con esta herramienta, cualquier administrador que requiera utilizar Java en su día a día, puede reducir cualquier riesgo de ataque añadiendo únicamente el permiso de ejecución de Applets Java en las URLs de los sitios con los que deban trabajar sus empleados. Por supuesto, si se quiere configurar una regla de despliegue para que no salga absolutamente ninguna alerta, se puede crear una regla en Advanced Mode para ajustar la granularidad que se quiera.
La herramienta está escrita en Java - faltaría más - y por tanto es totalmente funcional en plataformas OS X y GNU/Linux, con las que el equipo de QA de Eleven Paths ha hecho las pruebas pertinentes. Esperamos que os sea de utilidad y consigáis fortificar un poco más vuestros equipos de trabajo.
Saludos Malignos!
Es decir, nos bajamos un ejecutable vuestro y lo instalamos alegremente... Sin ver el código ni nada más.
ResponderEliminarY quién nos dice que no sea un troyano? :-)
Buen blog!
Además sus ejecutables basados en Java y .NET están ofuscados, ¿qué no quieren que veamos? ¿Qué? ¿Qué diantres es eso de "propiedad intelectual de Telefónica Digital"? :P
ResponderEliminarTu eres tonto
ResponderEliminarJava es un coladero, pero desde hace unos meses java ya no instala plugins en el navegador por defecto, tienen que ser activados por el usuario, por lo tanto ya no existen applets ¿o si?
ResponderEliminarEste comentario ha sido eliminado por el autor.
ResponderEliminar