El día 8 de diciembre se hacía público un fallo en el procesamiento de Cascading Style Sheets (CSS) que permitía provocar una denegación de servicio (que Internet Explorer dejase de responder) de forma sencilla con sólo visitar una web. En principio, las denegaciones de servicio en navegadores no son del todo graves, sino más bien una incomodidad para el usuario. Además, son fáciles de provocar con JavaScript.

El problema con ciertas denegaciones de servicio es que a veces pueden ir más allá, y acabar en ejecución de código (no es la primera vez que ocurre). El hecho de que una aplicación deje de responder puede ser el indicio de que existe alguna forma de controlar el flujo de instrucciones. Si es así, el problema es muy grave. Y esto precisamente es lo que ocurrió el día 14. Algunos investigadores descubrieron cómo ir más allá y ejecutar código arbitrario en lo que parecía una simple denegación de servicio. Afectaba a Internet Explorer 6, 7 y 8.

Muy poco después, Nephi Johnson de breakingpointsystems.com, publicaba el código necesario para aprovechar la vulnerabilidad. El día 23 de diciembre el fallo se añade al popular Metasploit. La diferencia con respecto al anterior, es que ahora el exploit podía eludir DEP y ASLR en Vista y 7. Esto es relativamente sencillo últimamente, debido a la carga dinámica en Internet Explorer de librerías que no están marcadas para utilizar ASLR (en este caso mscorie.dll) y el uso de RoP (return oriented programming).

Ese mismo día Microsoft reconoce el fallo y comienza a trabajar en él para solucionarlo. No se tiene constancia de que esté siendo aprovechado por atacantes aún para instalar malware (aunque sin duda es lo más probable).

Damos algunas sugerencias para mitigar el fallo. En realidad, los consejos son válidos para intentar mitigar cualquier vulnerabilidad:Utilizar las zonas de seguridad de Internet Explorer. Si se eleva a “alta” el nivel de seguridad de la zona de Internet del navegador, se evitarían muchísimos de los ataques actuales. Esta posibilidad está disponible en las opciones del navegador. Si se tienen problemas para visualizar páginas legítimas, basta con añadirlas a la lista de confianza.

• Utilizar Enhanced Mitigation Experience Toolkit (EMET) de Microsoft. Esta herramienta permite que todas las DLL cargadas por un programa sean obligadas a usar ASLR. Esto quiere decir que serán colocadas en lugares aleatorios de la memoria y el exploit que intente apoyarse en ellas para funcionar, no lo hará.
• Ahora que están de moda las sandbox desde que Adobe la implementa en su lector, cabe recordar que existen programas que permiten “encapsular” en una sandbox otras aplicaciones. En concreto, por ejemplo sandboxie (gratuito) permite ejecutar el navegador dentro de un entorno virtual. Cualquier ataque no pasaría al entorno “real” del sistema.
• Existen aplicaciones como WehnTrus (gratuita) que permiten implementar ASLR en los sistemas operativos de Microsoft que no lo soportan, como Windows XP y 2003.

Fuente: Hispasec

Este martes Microsoft ha corregido un problema crítico de Internet Explorer y el último fallo conocido explotado por el gusano Stuxnet.

“El error más importante de este mes es sin duda la actualización de IE e también incluye una solución para el 0-day descubierto a principios de noviembre”.

El parche MS10-090 resuelve cuatro vulnerabilidades que podrían permitir la ejecutiva remota de código cuando un usuario ingresa a páginas maliciosas con IE6, IE7 e IE8. “La actualización de seguridad corrige las vulnerabilidades al modificar la manera en que Internet Explorer trata los objetos en la memoria en determinados procesos”.

Por otra parte, Microsoft ha corregido la última vulnerabilidad conocida relacionada con el gusano Stuxnet. El boletín MS10-092 afecta a Windows Vista, Windows Server 2008, Windows 7 y Windows Server 2008 R2 y fue calificado como importante, en lugar de crítico, al igual que la mayoría del resto de los 17 parches.

Cristian de la Redacción de Segu-Info