Caracas, 18/02/2013Ing. Félix López

Consideraciones de Seguridad para Implementación de Java Applets.

En los últimos meses han sido descubiertas nuevas vulnerabilidades de java especialmente sobre la implementación para ejecución de applets, éstas han ocasionado una gran cantidad de opiniones, algunas incluso recomiendan la desinstalación de java por completo. Sin embargo, el principal problema de tomar medidas como la anteriormente mencionada es que no se dispone de alguna solución alternativa en el mercado con la cual se pueda sustituir los applets para algunos casos específicos.

La verdadera importancia de la vulnerabilidad radica en que bajo algunas circunstancias, se les puede permitir a los applets salir de la SandBox en la que se ejecutan y por tanto pasan a comportarse como un ejecutable con la permisología del usuario que lo ejecute.

Partiendo de una situación en la que no se pueda dejar de utilizar los java applets en los entornos que están actualmente en uso, y basándome en los análisis y recomendaciones realizados por el equipo de Hispasec, el cual considero particularmente bastante acertado, menciono a continuación posibles controles de seguridad que ayudarían a mitigar la vulnerabilidad más reciente.

1. En primer lugar y aunque parezca muy obvio, señalaré la imperiosa necesidad de evitar la ejecución de applets con versiones antiguas de java. La razón supongo que está de más explicarla y ¿Porqué es importante mencionarlo? Pues como muchas personas han criticado, Oracle se encarga de lanzar nuevas versiones de su JVM, sin embargo, el proceso de actualización no desinstala las versiones anteriores y permite que coexistan varias versiones simultáneamente. Esta lógica en ocasiones también es aplicada por algunos administradores de sistemas pero evidentemente queda latente la posibilidad de evitar que se implementen las mejoras de seguridad.

La forma de cumplir con este control es mantener las versiones de java actualizadas y eliminar las versiones antiguas.

2. En segundo lugar me referiré a la configuración de seguridad de java que por defecto se instala con nivel “Alto” desde su version 7u10, la cual establece que se preguntará al usuario siempre que se intente ejecutar un applet “no confiable” (que no está firmado electrónicamente) y que además se mostrará una alerta si se encuentra una versión de java más reciente. En su lugar se recomienda la configuración de seguridad “Muy Alto” la cuál evitará la ejecución de applets no confiables y se emitirá una alerta cuando se bloquee alguno.

Esta medida se configura desde el panel de control de java que regularmente se encuentra en la carpeta “bin” de la instalación de java. Para sistemas Windows se podría encontrar en “%JAVA_HOME%\bin\javacpl.exe” y para sistemas Linux podríamos encontrarlo en “$JAVA_HOME/bin/ControlPanel”. En la pestaña de “Seguridad” se debe colocar el nivel de seguridad en “Muy Alto” y guardar los cambios.

3. Como complemento al punto anterior podemos evitar la ejecución de applets autofirmados ya que para la mayoría de los casos es poco usual que una entidad de certificación raíz, firme electrónicamente applets.

Este punto lo podemos aplicar desde el panel de control de java, en la ficha “Avanzado” se debe desactivar la opción “Permitir el otorgamiento de acceso elevado a aplicaciones autofirmadas”.Es importante mencionar que al momento de realizar este documento, note que es estrictamente necesario desactivar esta opción para que funcione correctamente el bloqueo de los plugins firmados por autoridades no confiables, ya que me fue posible saltar la restricción “Muy Alta” si se mantenía esta opción activa mediante una invocación por el objeto HTML <applet>.

4. Ahora bien, teniendo en cuenta que ya mencionamos que sólo deberíamos permitir la ejecución de applets confiables (firmados electrónicamente con certificados dentro de alguna cadena de confianza), d ebemos prestar especial atención a las autoridades de confianza con las que java verifica. Desde la configuración avanzada del panel de control se pueden configurar dos (2) comportamientos; que java verifique contra su propia lista de autoridades o que además de sus autoridades también se confíen en las autoridades del navegador (Por defecto se encuentra habilitado el segundo). Partiendo de esto y suponiendo que sólo se utilizarán applets muy puntuales, podemos implementar una lista blanca simulando dicho comportamiento mediante la eliminación de autoridades que no se utilizarán y dejando o añadiendo únicamente las autoridades que autenticarán los applets de interés. Con el fin de no afectar las autoridades del navegador se podría deshabilitar el uso de las autoridades del navegador y finalmente sólo depurar las autoridades del TrustStore de java.

Este control se puede implementar inicialmente desde la ficha “Avanzado”, desactivando la opción “Usar los certificados y claves del almacén de claves del explorador” y posteriormente depurar las autoridades de confianza mediante la utilidad keytool, accediendo al TrustStore con el password por defecto “changeit”. Para sistemas Windows se podría encontrar el TrustStore en “%JAVA_HOME%\lib\security\cacerts” y para sistemas Linux podríamos encontrarlo en “$JAVA_HOME/lib/security/cacerts”. Además, de ser necesario también podríamos configurar una lista negra en el archivo “blacklist” que se encontrará en el mismo directorio que el archivo “cacerts” anteriormente mencionado.

5. Como último control referente a las configuraciones de java haré referencia a la posibilidad de administrar todas estas configuraciones directamente desde los archivos que guardan los valores, esto es altamente útil para entornos corporativos en los que además de realizar la configuración de forma centralizada y luego distribuir a los equipos de los usuarios; también podremos bloquear estas propiedades para que el usuario no pueda modificarlas. La configuración se puede realizar desde dos tipos de archivos, uno del Sistema que aplicará de forma global y otro que se especifica para cada usuario del sistema.

El archivo por usuario se puede encontrar en el caso de sistemas Windows en “%APPDATA%\Sun\Java\Deployment\deployment.config” y en el caso de sistemas Linux en “$HOME/.java/deployment/deployment.config”.El archivo del Sistema se puede encontrar, en el caso de sistemas operativos Windows en “%WINDIR%\Sun\Java\Deployment\deployment.config” y en el caso de sistemas Linux no logré ubicar un archivo de sistema.Estos archivos permiten la utilidad de bloquear algunos valores con la propiedad “locked” en valor “true”, así como también definir dos líneas, con una se definirá el archivo de

propiedades y otra donde se definirá si son obligatorias:

deployment.system.config=file\:C\:/WINDOWS/Sun/Java/Deployment/deployment.propertiesdeployment.system.config.mandatory=true

6. Finalmente, resulta interesante agregar otro control en una capa diferente que escape de las configuraciones de java. Debido a que el applet es invocado desde el navegador resulta de gran utilidad poder controlar algunas variables más allá de java, en este caso podemos aprovechar las bondades de funcionalidades del navegador o de plugins para restringir los dominios autorizados para invocar applets. La medida mencionada en este último control dependerá netamente del navegador que se esté utilizando, en el que se logre crear una lista blanca de dominios autorizados para la ejecución de applets.

Para Chrome se dispone del plugin “NotScripts”.Para Firefox existe un plugin de gran trayectoria llamado “NoScript”.Y en el caso de Internet Explorer, el propio navegador implementa zonas de seguridad, sin embargo ya que no funcionan en todos los casos, el CERT de Estados Unidos publicó un archivo “.reg” que al importarlo en Windows permite deshabilitar (activando el kill bit) la mayoría de los CLSIDs conocidos para Java (http://www.kb.cert.org/vuls/id/636312). Es importante destacar que existe la disponibilidad que el archivo no esté completo, por lo que para aplicar este control se recomienda el uso de otro navegador.