Metasploit ha creado y hecho público un exploit que permite aprovechar una de las vulnerabilidades que Internet Explorer sufre en estos días y no ha corregido aún. En realidad ya existía un exploit público para este fallo, solo que ahora Microsoft lo ha reconocido. Ofrecemos algunas recomendaciones para mitigar el problema hasta que exista parche.
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.
Más Información:
When A DoS Isn't A DoS
http://www.breakingpointsystems.com/community/blog/ie-vulnerability/
Microsoft Security Advisory (2488013)
http://www.microsoft.com/technet/security/advisory/2488013.mspx[/size][/size]
Sergio de los Santos
ssantos@hispasec.com
FUENTE :http://www.hispasec.com/unaaldia/4444
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.
Más Información:
When A DoS Isn't A DoS
http://www.breakingpointsystems.com/community/blog/ie-vulnerability/
Microsoft Security Advisory (2488013)
http://www.microsoft.com/technet/security/advisory/2488013.mspx[/size][/size]
Sergio de los Santos
ssantos@hispasec.com
FUENTE :http://www.hispasec.com/unaaldia/4444
