| Kriptópolis alojado en |
| Zilos-Veloxia Network |
| Tu mejor defensa: |
| Bufet Almeida |
Fallo en Microsoft Crypto API revela información y facilita ataques y spam
Enviado por admin el 3. Abril 2008 - 16:20.
Un fallo de diseño en la validación remota de certificados X.509 posibilita a un atacante obtener información relevante sobre el usuario que abre un email o un documento con Microsoft Office 2007, Microsoft Outlook 2007 y Microsoft Windows Live Mail 2008. No se descarta que otros productos de Microsoft que utilicen la misma API criptográfica puedan estar también afectados.
El problema ha sido descubierto por el investigador alemán Alexander Klink, y puede ser explotado por un atacante para generar peticiones HTTP a hosts y puertos arbitrarios sin que el usuario tenga conocimiento ni se le presente la opción de evitarlo. De esta manera un 'spammer' puede comprobar si una dirección email existe y cuándo es abierto un correo firmado con S/MIME y desde qué IP. También es posible saber cuándo y desde qué IP se abre un determinado documento mediante Office. El atacante puede también acceder así a otras máquinas y redes desde la máquina de la víctima o incluso a otras máquinas ocultas dentro de su propia red...
La Crypto API permite la conexión a las URIs y puertos indicados en el propio certificado para obtener los certificados intermedios de la cadena de validación, sin tener en cuenta que las peticiones pueden ser maliciosas (un aspecto que debería probablemente haber sido especificado en el RFC correspondiente, evitando así implementaciones como la que nos ocupa). Las conexiones se desencadenan tan pronto como se abre el documento (en Outlook basta con el panel de vista previa) y además no se solicita permiso al usuario. Para colmo, las conexiones dirigidas a intentar validar el certificado ocurren aunque la firma S/MIME no sea válida, y se repiten a intervalos de tiempo indeterminados.
El impacto real de esta vulnerabilidad reside en que puede utilizarse como mecanismo de control sobre quién (qué IP) abre qué cosas y cuándo. Heise habla abiertamente del "retorno de los Web Bugs" y nos recuerda que el FBI ha utilizado mecanismos semejantes y podría también utilizar éste, dando así pábulo a las teorías conspiranoicas.
Según el descubridor, no son vulnerables ni Lotus Notes, ni Mozilla Thunderbird, ni las aplicaciones de email de Apple, ni los clientes basados en OpenSSL.
Microsoft ha sido informado, pero la solución no parece inminente.
Referencias:
- Microsoft Crypto API X.509 Certificate Validation Remote Information Disclosure Vulnerability [SecurityFocus].
- HTTP over X.509 (S/MIME) - Microsoft Outlook [Security Advisory AKLINK-SA-2008-002].
- HTTP over X.509 (S/MIME) - Windows Live Mail [Security Advisory AKLINK-SA-2008-003].
- HTTP over X.509 - Microsoft Office 2007 [Security Advisory AKLINK-SA-2008-004].
- Web bugs return using digital certificates [Heise].
- HTTP over X.509 — a whitepaper [Cynops].
Espero que no haya nigún nuevo efecto cruzado
Ole, y ahora que está a punto de empezar la campaña de declaración de la renta, veremos si alguna nueva sorpresa "cruzada" y se lía algo peor con la presentación telematica de la renta, los certificados X.509 de la AEAT, la cripto API y el M$$$.
¡JA JE JI JO JU!
Y yo me pregunto, al hilo del comentario sobre que el RFC debería haber especificado cierto aspecto... ¿este error se debe a una mala implementación, a haber hecho alguna chapuzilla o a que simplemente el RFC es lo suficientemente ambiguo para dejar hueco para la vulnerabilidad y además es difícil darse cuenta de ella?
Por cierto, para el anónimo anterior, se puede hacer la gestión de la renta mediante Linux. Por supuesto no tienes por que tenerlo instalado ni nada, pero ya que lo comentas me gustaría decir que se puede hacer con el pingüino (a mi me salvó el año pasado por que la entregué el último día a última hora).
Sobre el RFC
La verificación de CRL's es una opción que normalmente no se utiliza: Las Autoridades de Certificación "serias" ofrecen -normalmente mediante pago- El uso de servidores de CRL's, en los que los clientes "pata negra" pueden comprobar si un certificado está o no revocado
Lo normal es pues NO comprobar los CRL. Entre otras cosas porque es un servicio remoto, normalmente de pago y que solo te dice si alguien ha pedido a la CA la revocación de un certificado, no si realmente el certificado ha sido usado por su verdadero dueño
Lanzarse pues a comprobar una CRL sin siquiera haber comprobado que la CA es "fiable" es cuando menos imprudente: Abre la puerta a que cualquier fake-CA te empiece a simular usuarios, y tú te lo "comas con patatas" "porque viene firmado digitalmente"
Viene a ser lo mismo que creerse que la conexión es segura porque "usas https". Cierto: el canal es seguro. ¿pero sabes quién está al otro lado del canal seguro?
jonsito
Queridos redmonianos:
Os comió la lengua el gato?
Ya estáis tardando en decir que esto tampoco tiene ninguna importancia.
Ahora no se trata de una beta :O
Muy fuerte
A ver si me he enterado:
- Me genero mi propia "fake-CA"
- Le añado las CRL's que me interesen
- Creo mi propio certificado
- Firmo con él un correo
- Me hago con una lista de spamming
- Mando cientos de millones de correos "firmados"
- Cuando el pardillo abra el correo, automáticamente se intentará verificar la CRL
- Mi servidor de CRL's dirá que todo está bien, y de paso apuntará la IP, y demás datos que el cliente tenga a bien darme
- !y todo esto de forma automática en el pardillo que recibe el correo!
Nomelopuedodecreer
- Primero y fundamental: solo se deben verificar las CRL's de aquellos certificados
a) Válidos
b) De CA's reconocidas en mi lista de CA's
c) Y además solo las CRL's reconocidas en la CA, y que yo previamente tengo almacenadas junto a dicho CA, no en lo que me diga el Certificado
d) y por precaución solo se debería verificar la CRL si el usuario lo pide
Cuando escribí pam_pkcs11 esta secuencia era (y es) de obligado cumplimiento. No conozco ningún código abierto que no lo haga
El que un criptoapi no siga esta secuencia es demencial. El que además lo haga automáticamente, de forma reiterada y sin siquiera avisar al usuario raya en lo delictivo
Me dejas sin palabras. Es una locura, se mire por donde se mire.
Y todavía hay gente (y gobiernos) que venden sistemas de PKI con software propietario y sin publicar especificaciones
Jonsito cabreado
Y más
Y además hay quien les permite crear estándares para que luego los implementen como les salga del nabo.
Vale, estoy dormido
Despues de volver a leer, y de tomarme una tila, me he dado cuenta de que no había entendido bien: el problema no se refiere a la verificación de CRL's, sino a la de la cadena de CA's indicada en el certificado.
Dejo al admin la opción de llamarme tonto o borrar los mensajes anteriores :-)
En cualquier caso el problema es similar: no se debería intentar verificar ningún certificado que no proviniera de una CA autorizada. Al menos se debería informar al usuario que dicha CA no está reconocida, y preguntarle si desea continuar.
Ahora no tengo a mano el RFC, por lo que no sé en este momento cuál es el protocolo para verificar la cadena de CA's de un certificado. El hecho es que OpenSSL lo hace correctamente
Mi evolution lo hace; no veo por qué Microsoft no lo va a poder hacer Voy a ver si encuentro el RFC...
El origen del problema:
Googleando he encontrado este documento:
http://support.microsoft.com/kb/816895/es
En el se explica que Microsoft se encontró con el problema de que cuando había una cadena de CA's, el certificado se marcaba como inválido porque faltaban las CA's intermedias en la lista de CA's autorizadas
- La solución de Microsoft: autorizar la cadena de CA's que incorporaba el certificado sin preguntar
- La solución estandard: presentar una ventana al usuario, pidiéndole que autorice a añadir todas las CA's intermedias a la lista de CA's autorizadas. Esto hace que en los menús del firefox y familia, las diversas sub-CA's se desplieguen en forma de arbol.
El problema residía -y reside- pues en obtener la cadena de CA's de una forma fiable, partiendo del contenido del certificado.
Hay dos formas:
- Seguir la cadena desde la autoridad raíz hacia abajo
- Utilizar las extensiones que permiten a una CA especificar dónde localizar las listas de CA's subordinadas
Me imagino que el ataque puede venir en que si yo consigo que una CA raíz me reconozca a mí como CA subordinada, nada me impide crear "fake Sub-CA's" en las que incluya extensiones que indiquen puntos (URL's) de validación de mis CA's. Si el software me hace caso, y sigue las extensiones, el usuario quedará "fichado". No conozco a fondo el RFC, e ignoro si es obligatorio hacer caso a estas extensiones en el proceso de verificación.
Pero intuyo que no, ya que OpenSSL no "pica". Entiendo que el uso de URL's para indicar CA's confiables no estaba pensado para esta situación, sino para que las Autoridades Raiz pudieran confiar unas en otras: es decir, solo usar las URL's en el certificado de la autoridad raíz, no en las autoridades delegadas
Sigo estudiando :-)
CA subordinada
Si consige alguien eso, no solo puede crear "fake Sub-CA's", puede emitir certificados de todo tipo falsos pero válidos y cargarse PKIX de base.
fake CA
Bueno, cargarse, cargarse... hasta que la CA padre le incluya en las listas de revocación, o le expire el certificado :-)
Esto, de hecho ya ha ocurrido con algunas CA's que tienen políticas "alegres" de emision de certificados y de CA's subordinadas. No creo que el PKI se haya caído: simplemente le digo a mi sistema que no confíe en ellas
Porque siempre nos queda el recurso que todos debíamos usar: confiar solo en aquellas CA's que conocemos y/o necesitamos: Mi lista de CA's admitidas en Evolution, Firefox, y OpenOffice, es muy restringida
Y por supuesto mi sistema no es como Windows: antes de aceptar nada automáticamente siempre pregunta.
Paranoico que es uno
Opinar