Con este nuevo agujero Microsoft deja la puerta abierta para que
se puedan leer archivos de los sistemas de los usuarios mientras
visitan una página web con Internet Explorer. El problema, que
parte de una mala implementación en la máquina virtual de Java,
permite construir applets que tengan acceso a los ficheros
locales, incumpliendo de esta forma uno de los pilares básicos
en los que descansa la seguridad en Java.
Si bien no se trata, ni mucho menos, del primer agujero de
seguridad en la MV Java de Microsoft, éste tiene la
particularidad de que es muy fácil de reproducir. Cualquier
programador novel puede construir fácilmente un applet para
explotar la vulnerabilidad y conseguir acceder a ficheros
sensibles de los sistemas de los usuarios que visiten su web,
de ahí que se agrave el peligro potencial que ya tiene de por
sí el agujero.
La seguridad en los applets de Java
La potencia de los applets, entre otras características, reside
en la posibilidad de que el código de un programa viaje a
través de la red y pueda ser ejecutado en cualquier sistema.
Tanta versatilidad puede traer aparejada una serie de problemas
de seguridad: por ejemplo introducir virus, recoger información
confidencial del usuario, o utilizar la máquina donde se
ejecuta como pasarela para llevar a cabo otros ataques. Para
evitar estas situaciones los applets de Java poseen, por
diseño, una serie de limitaciones que a grosso modo se resumen
en que no pueden acceder al disco duro local ni utilizar otro
servidor distinto al de su origen.
Los applets nos llegan desde los servidores de Internet con un
código precompilado, lo que se denomina código byte, que es
ejecutado en nuestro navegador por un interprete como es la
Máquina Virtual de Java de Microsoft en el caso de Internet
Explorer. El que sea un lenguaje interpretado permite al código
byte ser independiente del sistema operativo y la plataforma
hardware. Un applet debería ejecutarse de igual forma en
Internet Explorer 5 para Windows que en Netscape bajo Linux,
será el interprete de cada navegador el encargado de procesar
el mismo código byte y que se ejecute adecuadamente bajo la
plataforma correspondiente.
El interprete tiene como una de sus misiones la de verificar el
código byte bajado desde el servidor para comprobar que no viola
los requisitos de seguridad impuestos por el lenguaje Java. La
realidad es que, si bien la mayoría de las implementaciones
cumplen los estándares Java, existen algunas diferencias que se
agravan en el caso de Microsoft y que pueden -suelen- tener
efectos nocivos.
La vulnerabilidad
El agujero consiste, como hemos explicado, en la permisividad
que presenta la Máquina Virtual de Java para que un applet pueda
leer ficheros del sistema local del usuario que lo ejecuta.
Las limitaciones, o condiciones, son que es necesario conocer
la ubicación y nombre del fichero, así como encontrarse dentro
del directorio de trabajo que tenga asignado la Máquina Virtual
de Java.
En el caso de Internet Explorer 4, el directorio por defecto es
“C:\”, lo que significa que todos los archivos del disco duro
pueden ser accesibles por un applet de Java. En el caso de
Internet Explorer 5 el directorio es “C:\Windows\desktop”, por
lo que el acceso se limita al contenido del escritorio, lo que
incluye sus subdirectorios. En el caso de sistemas Windows NT
el acceso a los ficheros vendrá condicionado por los permisos
que tenga el usuario que haga uso del sistema.
Además de estos directorios por defecto, serán accesibles todos
aquellos que estén en el ámbito de la variable CLASSPATH, esta
ampliación, si bien no es muy usual, suele darse en los sistemas
de los programadores de Java.
El exploit
Como ya adelantábamos, la peligrosidad de esta vulnerabilidad
se ve agravada por la sencillez de su puesta en práctica.
Mediante una simple función, getSystemResourceAsStream(),
un programador puede añadir una línea en el código de su
applet para leer un fichero, por ejemplo:
InputStream is = ClassLoader.getSystemResourceAsStream(fichero);
Una vez logrado el objetivo el atacante puede hacer que la
información viaje hacía su servidor web o que se envíe
adjunta por correo electrónico.
Para probar la vulnerabilidad podemos recurrir a un applet
demostrativo de Hiromitsu Takagi, uno de los participantes
en “Java House Mailing List”, una lista de discusión japonesa
sobre Java donde se descubrió el agujero.
http://java-house.etl.go.jp/~takagi/java/test/microsoft_insecurity/Test.html
En este applet se nos solicita un fichero local, por defecto
autoexec.bat, y muestra su contenido. Deberemos de tener en
cuenta la versión de nuestro navegador, si es Internet Explorer
4 estaremos situados en “C:\”., en el caso de la versión 5
el directorio de partida será “C:\Windows\desktop”, por lo
que seguramente será necesario modificar la entrada por defecto
y poner en su lugar otro nombre de fichero que se encuentre
en nuestro escritorio para poder visualizar la demostración.
Si solicitamos un fichero no accesible el applet responderá
con el mensaje “java.lang.NullPointerException”.
Parche
De momento Microsoft, conocedora del problema, no se ha
pronunciado sobre este importante agujero ni proporcionado
un parche para solucionarlo. Las soluciones pasan, mientras
tanto, por desactivar Java en Internet Explorer, utilizar
otro navegador como Netscape, o instalar el plug-in Java de
Sun para el navegador de Microsoft que se puede encontrar en
http://java.sun.com/products/plugin/index.html
Más información:
Código fuente del applet-demostración
Applet demostración
Acerca del applet y la vulnerabilidad
Java (Sun)
Java (Microsoft)
bernardo@hispasec.com
Deja un comentario