Parche acumulativo para IE
Rompiendo la norma de publicar los parches el segundo martes de cada mes, Microsoft ofrece un parche acumulativo para Internet Explorer que corrige tres vulnerabilidades, dos de ellas ya conocidas y comentadas.
La desconocida está en el manejo de eventos de DHTML y permite descargar un archivo al disco duro, en la ubicación que el atacante decida, sin que el usuario reciba notificación alguna, simplemente pinchando un enlace especialmente construido al efecto. El archivo no se ejecuta. También puede aprovecharse a través de Outlook y Outlook Express, ya que usan IE para mostrar los correos en HTML. De hecho sería más fácil explotarlo así, pues el texto del e-mail podría tratar de convencer al usuario de que ejecutase el archivo.
Otro de los bugs que elimina es uno de éstos cinco. Cómo era necesario usar los cinco en conjunto, de momento, queda resuelta esa vulnerabilidad, pero hay que tener en cuenta que cualquiera de los otros cuatro que no se arreglan podría volver a ser peligroso en un futuro.
El tercero es el que más gracia me ha hecho. El fallo que corrige es el famoso URL spoofing que se usó en el intento de estafa a los usuarios del Banco Popular. Para corregirlo, se han cargado el estándar de construcción de URLs. Así, si escribimos en la barra de direcciones (o pinchamos en un enlace con) una URL completa (que son del tipo http(s)://usuario:contraseña@servidor), IE nos mostrará un mensaje como éste:
Pues nada, si Microsoft lo dice, pues el estándar no es válido. Normalmente, la parte usuario:contraseña@ no se visualiza en los navegadores modernos y no se usa mucho en la navegación normal. Aun así, es necesaria en algunas descargas a través del protocolo HTTP (en este caso, el navegador debe completar lo necesario de forma automática, por lo que IE fallará a partir de ahora), para identificarse en algunas listas de correo vía web y es un pilar básico del diseño de bastantes intranets.
También han publicado un documento con alternativas para solucionar que el navegador ya no sea capaz de autenticarse. En este artículo es divertido ver como en la parte del usuario se dice que no hay de qué preocuparse ya que ahora el navegador pedirá nombre de usuario y contraseña de forma automática, mientras que, en la parte servidor, se explica cómo debe hacerse para que este "automatismo" sea posible. Es necesario añadir un par de comandos en el código de la página en que sea necesario autentificarse, pero ésto sólo funcionará con el servidor web de Microsoft y sólo para IE en la parte cliente. Menos mal que también citan que puede hacerse a través de cookies, aunque, en este caso, la solución propietaria no sería excluyente, porque el resto de navegadores sí son capaces de autenticarse normalmente.
Pese a lo excepcional de la publicación de este parche, no han cumplido con lo de publicar en cuanto estuviesen disponibles, ya que se han entretenido en ponerlos en un paquete de "sólo" 3MB.
La desconocida está en el manejo de eventos de DHTML y permite descargar un archivo al disco duro, en la ubicación que el atacante decida, sin que el usuario reciba notificación alguna, simplemente pinchando un enlace especialmente construido al efecto. El archivo no se ejecuta. También puede aprovecharse a través de Outlook y Outlook Express, ya que usan IE para mostrar los correos en HTML. De hecho sería más fácil explotarlo así, pues el texto del e-mail podría tratar de convencer al usuario de que ejecutase el archivo.
Otro de los bugs que elimina es uno de éstos cinco. Cómo era necesario usar los cinco en conjunto, de momento, queda resuelta esa vulnerabilidad, pero hay que tener en cuenta que cualquiera de los otros cuatro que no se arreglan podría volver a ser peligroso en un futuro.
El tercero es el que más gracia me ha hecho. El fallo que corrige es el famoso URL spoofing que se usó en el intento de estafa a los usuarios del Banco Popular. Para corregirlo, se han cargado el estándar de construcción de URLs. Así, si escribimos en la barra de direcciones (o pinchamos en un enlace con) una URL completa (que son del tipo http(s)://usuario:contraseña@servidor), IE nos mostrará un mensaje como éste:
Error: Sintaxis no válida
Pues nada, si Microsoft lo dice, pues el estándar no es válido. Normalmente, la parte usuario:contraseña@ no se visualiza en los navegadores modernos y no se usa mucho en la navegación normal. Aun así, es necesaria en algunas descargas a través del protocolo HTTP (en este caso, el navegador debe completar lo necesario de forma automática, por lo que IE fallará a partir de ahora), para identificarse en algunas listas de correo vía web y es un pilar básico del diseño de bastantes intranets.
También han publicado un documento con alternativas para solucionar que el navegador ya no sea capaz de autenticarse. En este artículo es divertido ver como en la parte del usuario se dice que no hay de qué preocuparse ya que ahora el navegador pedirá nombre de usuario y contraseña de forma automática, mientras que, en la parte servidor, se explica cómo debe hacerse para que este "automatismo" sea posible. Es necesario añadir un par de comandos en el código de la página en que sea necesario autentificarse, pero ésto sólo funcionará con el servidor web de Microsoft y sólo para IE en la parte cliente. Menos mal que también citan que puede hacerse a través de cookies, aunque, en este caso, la solución propietaria no sería excluyente, porque el resto de navegadores sí son capaces de autenticarse normalmente.
Pese a lo excepcional de la publicación de este parche, no han cumplido con lo de publicar en cuanto estuviesen disponibles, ya que se han entretenido en ponerlos en un paquete de "sólo" 3MB.
2 comentarios
D4 -
Aldo -