20 sept 2009

Persiste un agujero en la seguridad SSL de Microsoft Internet Explorer

El navegador Safari de Apple para Windows tiene el mismo problema pero Safari para Mac, Firefox y Opera han arreglado el problema.

Microsoft aún no reconoce una debilidad en su navegador Internet Explorer que fue señalada hace siete semanas, la cual permite a los atacantes secuestrar las que se suponen sean sesiones Web seguras.

La compañía dice que aún está evaluando si existe la debilidad, pero Apple, que basa su navegador Safari para Windows en el código de Microsoft, dice que Safari para Windows tiene esa debilidad y que la razón es el código de Microsoft. Si Microsoft no arregla el problema, Apple no puede arreglarlo por si mismo, dicen en Apple. Apple ya ha arreglado el problema en Safari para Macs.

"Microsoft actualmente está investigando una posible vulnerabilidad en Windows. Una vez que nuestra investigación este completa, tomaremos las medidas apropiadas para ayudar en la protección de los clientes," dijo un portavoz de Microsoft en un correo. "No tenemos nada más que compartir en este momento."
La debilidad puede ser explotada por ataques "hombre en el medio" (MitM) en el que se engaña al navegador haciendo que establezca sesiones SSL con servidores maliciosos en lugar de los servidores legítimos con que los usuarios se quieren conectar.

Las versiones actuales de Safari para Mac, Firefox y Opera ya se ocupan del problema, que está relacionado con la forma en que los navegadores leen los certificados x.509 que son usados para autentificar a las máquinas involucradas en establecer las sesiones SSL/TLS. En julio pasado dos charlas separadas presentadas por los investigadores Dan Kaminski y Moxie Marlinspike en la Conferencia Black Hat advertían sobre como podría ser usada la vulnerabilidad usando lo que ellos llaman ataques de prefijo nulo. Los ataques incluyen conseguir que las CA (Autoridad Certificante) firmen certificados para los nombres de dominio asignados a propietarios legítimos de dominios y hacer que los navegadores vulnerables interpreten los certificados como autorizados para distintos propietarios de dominios.

Por ejemplo, alguien podría registrar  www.hacker.com. En muchas implementaciones x.509 la autoridad certificante firmará certificados para cualquier solicitud del dominio raíz hacker.com, sin importar ningún prefijo de subdominio que sea agregado. Es ese caso, la autoridad firmaría un certificado para bestbank.hacker.com, ignorando el subdominio bestbank y firmándolo basado en el dominio raíz hacker.com, dice Marlinspike.

Al mismo tiempo, los navegadores con la falla que él describe, leen los certificados x.509 hasta llegar al caracter nulo, como el 0. Si tal navegador lee bestbank.com\0hacker.com, dejará de leer en el 0 e interpretará que el certificado autentifica el dominio raíz bestbank.com, dijo el investigador. Los navegadores sin la falla identifican correctamente el dominio raíz e ingresan o no basándose en este.

Un atacante podría explotar esta debilidad estableciendo un ataque de hombre en el medio e interceptando las solicitudes de los navegadores vulnerables para establecer conexiones SSL. Si el servidor atacante atrapara una solicitud para bestbank.com, podría responder con un certificado autentificado para bestbank.com\0hacker.com. El navegador vulnerable interpretaría al certificado como autorizado para bestbank.com y establecería una sesión segura con el servidor atacante. El usuario que solicitó la sesión con bestbank asumirá naturalmente que la conexión establecida es con bestbank.

Una vez que se establece el enlace, el servidor malicioso puede pedir las contraseñas y usuarios de autenticación las cuales los atacantes pueden explotar para irrumpir en las cuentas del usuario en bestbank y manipular los fondos, dice Marlinspike.

En algunos casos los atacantes pueden crear lo que Marlinspike denomina certificados comodín los cuales autentificarían a cualquier dominio. Esos certificados usan un asterisco como sub-dominio seguido por un caracter nulo y seguido por un dominio raíz registrado. Un navegador vulnerable que iniciase una sesión SSL con bestbank.com interpretaría a un certificado marcado con *\0hacker.com como proveniente de bestbank.com porque aceptaría automáticamente el * como legítimo para cualquier dominio raíz.

Esto se debe a "una idiosincrasia en la forma en que los Servicios de Seguridad de Red (NSS) hacen coincidir a los comodines," dice Marlinspike en un documento detallando el ataque. Tal comodín encajará con cualquier dominio, dice.

Las diferencia entre los que ven los usuarios en sus pantallas cuando alcanzan el sitio buscado y cuando alcanzan el sitio de imitación del atacante pueden ser sutiles. Las URLs en el navegador podrían revelar que se llegó al sitio equivocado, pero muchos usuarios no verifican eso, dice Marlinspike.

Un portavoz de Microsoft dice que Internet Explorer 8 destaca los dominios para hacerlos visualmente más evidentes, impresos en negro mientras que el resto de la URL está en gris. "La barra de dirección mejorada de Internet Explorer 8 ayuda a los usuarios a asegurarse más fácilmente que le están dando información personal sólo al sitio en el cual confían," dijo un vocero de Microsoft en un correo.

Marlinspike dice que la vulnerabilidad de caracter nulo no está limitada a los navegadores. "Esta lleno de cosas que no son navegadores y son vulnerables. Outlook, por ejemplo, usa SSL para proteger su usuario/contraseña cuando se conecta por SMTP y por POP2/IMAP. Probablemente haya un sinnúmero de otros SSL basados en Windows, VPNs, clientes de chat, etc. que son también vulnerables" dijo en un correo.

Traducción: Raúl Batista - Segu-info
Autor: Tim Greene
Fuente: Netkorworld

Suscríbete a nuestro Boletín

0 Comments:

Publicar un comentario

Gracias por dejar un comentario en Segu-Info.

Gracias por comentar!