Protegerse contra el exploit 1day de IE

Vaya por delante que el 0day famoso que se utilizó en el ataque contra IE6 e IE7 en XP sin DEP ya no es tal 0day. Quizá habría que utilizar la tan traida referencia de 1day, porque ya se conoce mucha información de él.

La diferencia, aunque sutil, marca una enorme distancia. De poco sirve ya que el exploit, por unos más avezados expertos de seguridad, haya sido mutado para funcionar en un entorno con DEP, tal como funciona IE8. Esto es debido a que los administradores y usuarios avanzados tienen la información suficiente para implementar un workaround. Y, por lo tanto, no es necesario cambiar de navegador.

Una vez conocida la información del exploit, se sabe que es condición necesaria el contar con Javascript habilitado. Para evitar por tanto este tipo de ataques, en Internet Explorer, existen las zonas de seguridad. Éstas, en situación de peligro, pueden ser configuradas a necesidad, eligiendo las características que se desean deshabilitar en cada caso.

En una situación conocida de riesgo como ésta, a los administradores de una red Windows que cuenten con IE8 y Active Directory la solución es tan sencilla como aplicar una política que desactive JavaScript de las zonas de Internet y dejarlo habilitado únicamente para los sitios de confianza.

Internet Explorer es una herramienta pensada para trabajar, y para trabajar en las empresas, con lo que es tan sencillo como utilizar la opción adecuada de la política y distribuirla.


Figura 1: Políticas IE en Active Directory
Si no se cuenta con un AD, el usuario siempre puede establecer su propia configuración de seguridad en las herramientas de IE, en la pestaña de Seguridad.


Figura 2: Zonas de seguridad
Se desactivan los códigos script en la zona de Internet inhabilitando cualquier ataque desde un sitio no deseado.


Figura 3: Deshabilitación de código script
¿Esto significa quedarse sin javascript? No, significa que si necesitas javascript y el sitio es de confianza, como aplicaciones internas o sitios en los que se confía, basta con agregarlos a los sitios de confianza. Suena redundante, pero es lo que tiene a veces explicar lo evidente.


Figura 4: Sitios de confianza
Esta forma de trabajar debería hacer pensar de verdad a todos los que están pensando o han pensado en, siguiendo las menos afortunadas recomendaciones, cambiar de navegador. Esto, tal vez hubiera sido una alternativa cuando no se conociera información del fallo, pero nunca cuando se conoce, ya que se puede armar un workaround. La pregunta es... ¿Y si cambias tu empresa a un navegador no administrado con políticas? ¿Y si cambias a un navegador sin zonas de seguridad? ¿Y si cambias a un navegador que no tiene protecciones como el MIC, el Virtual Store, Anti XSS o una separación de procesos? ¿Es esa una buena opción?

He leído información al respecto en muchos sitios, pero me váis a permitir que me quede con el twitter de David Barroso que hizo al respecto hoy por la mañana.


Saludos Malignos!