Authroot.stl y las paradojas sobre certificados
Windows Vista y 7 realizan una gestión dinámica de los certificados. Cuando se visita una web que no puede ser validada, el sistema se conecta a esta dirección:
y descarga los certificados que necesite para validar la cadena. Así, podemos ver como Windows viene cargado con una serie de certificados por defecto (muy pocos) y el número aumenta a medida que se navega por la red y se necesitan validar páginas. Sobre este asunto ya hablaron en su momento desde Security By Default.
A raíz de los incidentes de DigiNotar, gracias a los que se está cuestionando la validez de todo el sistema de SSL, esta gestión cobra especial importancia. A mi entender, y como intenté reflejar en la una al día Conversaciones sobre certificados, seguridad y pornografía se hace necesaria una gestión muy clara que no lleve a engaño al usuario y lo confunda aún más. Sin embargo, paradójicamente, ni el propio sistema de Microsoft para actualizar los certificados, se encuentra correctamente configurado para conseguir este objetivo. Me explico. Como he mencionado, un usuario se conecta a:
para descargar la lista de certificados raíz con los que actualizar su repositorio. Si se observa bien, esta dirección no está bajo conexión SSL, lo que indica que no va cifrada (esto tampoco es vital, puesto que no se transmite información crítica) pero lo que es peor, tampoco está validada. Por tanto, si un atacante en una red interna (una WiFi abierta o pública, por ejemplo) envenena los DNS o el tráfico, podría hacer que se descargara una lista de certificadores falsa. Entonces, podríamos sugerir que el sistema se conectara automáticamente a
para validar al servidor y no ser víctimas de estos engaños... Pero, nos encontramos con que esto da un error.
No es válido... el certificado está emitido a nombre de Akamai. El propio sistema de actualización de certificados contiene un error de certificados. Empezamos mal si no queremos confundir al usuario.
En todo caso, se puede optar por una solución diferente: firmar el fichero que se descarga. Así, aunque ese atacante engañara a la víctima y descargara desde un sitio falso, el contenido descargado estaría validado. Bueno, sí... y no. El fichero cab no está firmado... pero el interno sí... pero "mal". Veamos esto. Una vez extraído el authroot.stl, si lo lanzamos para comprobar la lista (que ha sido modificada últimamente bastante), nos encontramos con un mensaje descorazonador: "La lista de certificados de confianza no es válida". O sea, la lista de certificados de confianza... ¿no es de confianza?
Lo que ocurre es que el certificado usado para firmar este archivo, no está pensado para firmar archivos, y por tanto, da error. Se observa entonces que no ha sido firmado por un "farsante" sino que simplemente, en la definición del certificado, no se indica explícitamente el uso que se le ha dado y por tanto la validación se queja. En realidad está correctamente firmado y la autoría parece válida pero... el error está ahí y eso es lo que confunde.
En este caso, tanto la dirección de descarga como el fichero son válidos, y existe una explicación para los fallos visibles pero, como siempre: ¿quién explica las razones a un usuario normal y corriente? ¿cómo le haces entender que no importa que cuando descargas (a mano, claro) una lista de de certificados de confianza, te muestre el propio navegador que el sitio no es válido, y el propio sistema te indique que el fichero parece que no está firmado correctamente? ¿Es esta la forma de crear confianza en el sistema de confianza?
Autor: Sergio de los Santos
Fuente: Blog de Hispasec
http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab
y descarga los certificados que necesite para validar la cadena. Así, podemos ver como Windows viene cargado con una serie de certificados por defecto (muy pocos) y el número aumenta a medida que se navega por la red y se necesitan validar páginas. Sobre este asunto ya hablaron en su momento desde Security By Default.
A raíz de los incidentes de DigiNotar, gracias a los que se está cuestionando la validez de todo el sistema de SSL, esta gestión cobra especial importancia. A mi entender, y como intenté reflejar en la una al día Conversaciones sobre certificados, seguridad y pornografía se hace necesaria una gestión muy clara que no lleve a engaño al usuario y lo confunda aún más. Sin embargo, paradójicamente, ni el propio sistema de Microsoft para actualizar los certificados, se encuentra correctamente configurado para conseguir este objetivo. Me explico. Como he mencionado, un usuario se conecta a:
http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab
para descargar la lista de certificados raíz con los que actualizar su repositorio. Si se observa bien, esta dirección no está bajo conexión SSL, lo que indica que no va cifrada (esto tampoco es vital, puesto que no se transmite información crítica) pero lo que es peor, tampoco está validada. Por tanto, si un atacante en una red interna (una WiFi abierta o pública, por ejemplo) envenena los DNS o el tráfico, podría hacer que se descargara una lista de certificadores falsa. Entonces, podríamos sugerir que el sistema se conectara automáticamente a
https://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab
para validar al servidor y no ser víctimas de estos engaños... Pero, nos encontramos con que esto da un error.
No es válido... el certificado está emitido a nombre de Akamai. El propio sistema de actualización de certificados contiene un error de certificados. Empezamos mal si no queremos confundir al usuario.
En todo caso, se puede optar por una solución diferente: firmar el fichero que se descarga. Así, aunque ese atacante engañara a la víctima y descargara desde un sitio falso, el contenido descargado estaría validado. Bueno, sí... y no. El fichero cab no está firmado... pero el interno sí... pero "mal". Veamos esto. Una vez extraído el authroot.stl, si lo lanzamos para comprobar la lista (que ha sido modificada últimamente bastante), nos encontramos con un mensaje descorazonador: "La lista de certificados de confianza no es válida". O sea, la lista de certificados de confianza... ¿no es de confianza?
Lo que ocurre es que el certificado usado para firmar este archivo, no está pensado para firmar archivos, y por tanto, da error. Se observa entonces que no ha sido firmado por un "farsante" sino que simplemente, en la definición del certificado, no se indica explícitamente el uso que se le ha dado y por tanto la validación se queja. En realidad está correctamente firmado y la autoría parece válida pero... el error está ahí y eso es lo que confunde.
En este caso, tanto la dirección de descarga como el fichero son válidos, y existe una explicación para los fallos visibles pero, como siempre: ¿quién explica las razones a un usuario normal y corriente? ¿cómo le haces entender que no importa que cuando descargas (a mano, claro) una lista de de certificados de confianza, te muestre el propio navegador que el sitio no es válido, y el propio sistema te indique que el fichero parece que no está firmado correctamente? ¿Es esta la forma de crear confianza en el sistema de confianza?
Autor: Sergio de los Santos
Fuente: Blog de Hispasec
0 Comments:
Publicar un comentario
Gracias por dejar un comentario en Segu-Info.
Gracias por comentar!