12 mayo 2008

FNMT: Insecure by default

Antes de la llegada del DNI-E, el certificado digital expedido por la FNMT mediante su organismo Ceres era el mecanismo mas habitual para tener “presencia online” frente a la administración publica. Se emplea tanto por particulares para labores tales como presentar la declaración de la renta online, como por parte de las empresas privadas para hacer diversos tramites de índole administrativos.

Para obtener el certificado digital, se realiza la petición por Internet y para obtenerlo, simplemente hay que presentarse en una de las oficinas dispuestas a tal efecto para recogerlo.

Los detalles sobre la generación de la petición de certificado han sido ampliamente discutidos en Internet y no pretendo en este punto ser demasiado técnico, baste decir que, tanto Firefox/Mozilla como Internet explorer disponen de mecanismos para la generación de las claves privadas y cursar la petición de certificado de forma online. Ambos navegadores generan las claves privadas y las almacenan internamente en sus “key stores” y nunca son entregadas de forma online, lo que se envía es la parte publica que a su vez es firmada por la CA correspondiente.

Pese a disponer ya de DNI-E, me entró la curiosidad por evaluar como funcionaba la petición de certificados online de la FNMT y ver como habían configurado la plantilla para solicitar certificados desde Internet Explorer. Imaginé que, dada la criticidad del asunto, y que estábamos hablando de mi “identidad online”, la seguridad seria extrema o cuanto menos, lo menos laxa posible. Mi sorpresa fue al comprobar que durante el proceso, la FNMT dejaba “por defecto” un nivel de protección sobre las claves criptográficas bastante pobre.

Antes de explicar el fallo, voy a explicar someramente como funcionan los mecanismos de protección de Windows para almacenar certificados digitales y sus claves privadas. Windows implementa un sofisticado sistema “a capas” para proteger este tipo de datos bastante complejo, a modo de resumen, podemos decir que las claves privadas de los certificados están cifradas internamente empleando como contraseña una derivación basada en PCKS#5 de la contraseña que emplea el usuario para iniciar sesión en Windows. Esto hace que, si un usuario no ha iniciado sesión en el equipo, a priori no pueda acceder a ese tipo de datos. Para los mas avezados e inquietos dejo un enlace sobre como funciona DPAPI y como protege Windows los datos sensibles. DPAPI

Una vez explicada la seguridad del almacenamiento, voy a explicar la seguridad en el uso de las claves privadas (y aquí viene lo emocionante). Windows a la hora de almacenar una clave privada asociada a un certificado en su “key store” dispone de tres niveles de seguridad:

* Bajo: La clave privada se empleara a discreción en función de que cualquier aplicación requiera su uso y sin intervención alguna por parte del usuario

* Media: Para emplear la clave privada del certificado el usuario deberá aceptar un popup informativo

* Alta: El usuario especificara una contraseña que será requerida siempre que la clave privada sea empleada

En este punto con el background necesario, retomamos el origen del documento; la petición de certificados de la FNMT. Durante el proceso de solicitud del certificado, la FNMT dispone de un formulario para generar las claves privadas en nuestro PC. A diferencia de Firefox que dispone de su propio mecanismo interno, Internet Explorer hace uso de un componente ActiveX llamado Xenroll (al menos en Windows 2000/XP, en Vista / Internet explorer 7 el componente ActiveX cambia). Este componente ActiveX se ocupa de la generación de las claves en función de los parámetros empleados en el formulario. Durante el proceso de petición del certificado al usuario se le pide que seleccione un nivel de seguridad para esa clave privada y aquí es donde viene mi sorpresa al encontrarme esto:

x

Como se puede observar en la captura de pantalla, el nivel por defecto (y que, entiendo, mucha gente por desconocimiento aceptara) es “Medium/Medio”,(mi versión de windows es inglesa) lo que significa que para emplear la clave privada del certificado, únicamente habrá que aceptar un popup. A esto hay que unirle el hecho de que para poder realizar backups del certificado y la clave privada, durante la creación de las claves, son marcadas como exportables, lo que nos lleva, finalmente, a que para obtener una copia del certificado y la clave privada únicamente hay que aceptar un popup de confirmación como este:



Windows, con su consabida amabilidad para la creación de todo tipo de maldades tiene un interesante juego de funciones que permiten enviar “eventos” a las aplicaciones gráficas, estos eventos pueden ser texto o directamente teclas: Enter, Shift etc etc

Resumiendo:

* Tenemos un certificado digital cuya clave privada es exportable

* La clave privada esta protegida únicamente con un proceso de confirmación

* Windows nos permite enviar señales a las aplicaciones gráficas


Con todo eso en la mano, me decidí a programar una aplicación que escaneara el contenido del contenedor criptográfico del usuario en busca de certificados cuya clave privada fuera exportable, y una vez localizados, intentara hacer una exportación del certificado y su clave privada en un fichero en formato PKCS#12 sin contraseña, que se puede re-importar en cualquier otro PC. El resultado es CertDump. Esta herramienta permite exportar el certificado de la FNMT con sus claves privadas sin intervención alguna del usuario. Lo que hace básicamente es, previo a pedir que se exporte la clave privada, genera un nuevo thread que espera un pequeño intervalo de tiempo y, pasado ese intervalo, envía la señal ENTER con lo que, en caso de que el certificado este protegido con un nivel “Medium/Medio”, el popup será aceptado y la exportación se podrá realizar. El fichero resultante una vez re-importado permite usurpar la identidad online a todos los efectos.

Aquí se puede ver la captura de CertDump exportando el certificado de la FNMT:

x

Personalmente estimo que si bien el nivel Medio/Medium esta relativamente bien para ciertos certificados menos críticos, en el caso de algo tan importante como la identidad digital, debería haberse habilitado, por lo menos, el nivel máximo de seguridad. Adicionalmente, una vez terminadas mis practicas con el certificado digital, decidí, por higiene, solicitar la revocación del certificado, teóricamente ( y según la DPC de la FNMT en su apartado 9.12 ) las listas de revocación de certificados se generan cada 24H pero yo, puedo constatar, que pude seguir accediendo a mis datos fiscales en hacienda durante al menos 2 días Esto quiere decir que, si por las razones que fueran, un certificado fuese comprometido, y aun habiéndolo revocado, el uso fraudulento del certificado para, por ejemplo, alterar los datos fiscales, solicitud de becas fraudulentas etc, podría seguir siendo posible por un periodo de tiempo excesivo.

Ante todo lo expuesto aquí, mi recomendación para los usuarios del certificado de la FNMT es que, una vez hayan completado el proceso de petición y lo tengan instalado en su PC, procedan a hacer la exportación del certificado y sus claves, almacenen el backup en un medio offline (pen USB, CD-rom), borren el certificado digital tal y como ha quedado tras la petición, y procedan a re-importarlo en su PC teniendo MUY en cuenta no marcar la casilla que hace las claves privadas exportables y por supuesto, marcando la opción máxima de seguridad asociando un PIN al uso de la clave privada asociada al certificado.

Con respecto a la FNMT, mi humilde recomendación pasa por modificar la plantilla de petición de certificado, ya que si bien la opción low/baja aparece deshabilitada, (bien!) deberían hacer lo propio con la opción Medium y hacer que Xenroll por defecto, cuando llame a CryptGenKey(), lo haga forzando a emplear el nivel máximo de seguridad.

8 comments :

On Egin dijo...

Me ha parecido interesante tu artículo, pero das por hecho que absolutamente nadie se va a leer el manual de solicitud del certificado, donde explica la diferencia entre medio y alto. Una cosa sí, es un error que pongan como opción por defecto el nivel medio.

On Egin dijo...

Por cierto, he llegado hasta aquí desde le diario digital 20 minutos. Te recomiendo que leas el artículo porque han entendido bastante mal lo que explicas en la web. Califican a CertDump como "troyano" y culpan a Windows de "una protección inadecuadamente baja".

http://www.20minutos.es/noticia/378330/0/vulnerabilidad/certificados/digitales/

Yago Jesus dijo...

Respecto a lo primero, efectivamente habrá (y me consta que hay) quien se habrá preocupado de averiguar por su cuenta, pero dado que estos certificados son, digamos, "para el común de la ciudadanía" habrá gente que dará por hecho que "esta bien por defecto". Tal y como enlazo al final del post, el asunto es forzar a CryptGenKey() (en la plantilla de solicitud del certificado) a que haga uso de CRYPT_FORCE_KEY_PROTECTION_HIGH
para que necesariamente, la clave privada lleve pin. Sobre lo de 20 minutos, yo entiendo que se refiere a que cualquiera puede copy-pastear mi código en un troyano, no que certdump lo sea.
Un saludo y gracias por tu comentario

Gonzalo Asensio dijo...

Hola, buenas.

En primer lugar como siempre sensacional amigo Yago Jesús.

Esta claro que gracias a este tipo de estudios altruistas podemos saber/conocer los peligros "by default" a los que nos exponemos diariamente en la red de redes.

Mi mas sincera enhorabuena.

Ánimo y sigue con tu inquietud en la seguridad!

Anónimo dijo...

Cuando se utiliza una clave privada en software, por mucho que se proteja con contraseña, llegará un momento en que tendrá que estar en memoria para poder hacer el proceso de firma. Vamos, que sería capturable.

Además, si te meten un troyano el el PC de una manera trivial te pueden capturar la contraseña de la clave.

Mi duda es para casos como el del DNI electrónico. Si mediante un troyano te capturan el PIN, se podría hacer un programa que accediera a la tarjeta sin que el usuario se enterara.

Realmente, habría que ir pensando en lectores PIN Pad en los que el PIN no pasa nunca por el PC.

Anónimo dijo...

Tengo una duda sobre los certificados.

¿Se puede exportar un certificado en el modelo de seguridad mas alto?

Si la respuesta anterior es no. ¿Podria ser posible que el nivel de seguridad se haya elegido para poder exportar el certificado a otras maquinas?

Si con el nivel alto de segurida se puede exportar el certificado estoy de acuerdo que es un error importante ya que mucha gente no se preocupa de estos posibles riesgos.

El articulo me ha parecido muy interesante.

Yago Jesus dijo...

Hola, sobre tu pregunta, son conceptos diferentes; nivel de seguridad / exportabilidad de los certificados. -Me explico- Tu puedes tener una clave privada NO exportable con un nivel de seguridad bajo, y esa clave privada se podrá usar indiscriminadamente sin advertencia, pero SIEMPRE en ese mismo PC, sobre el papel (bugs futuros aparte) nunca podría "salir" de ese PC. Por contra, tu puedes tener una clave privada con un nivel ALTO y esa clave ser exportable, lo que significa que, si alguien conoce el PIN de la clave SI puede extraerla de tu PC. En resumen, la mejor de las opciones: 1- clave privada NO exportable y 2- PIN en esa clave

Arturo Quirantes dijo...

Gracias por un artículo interesante. Yo también he descubierto esta web vía Mercé, y estoy encantado. Espero seguir leyendo más y mejor aquí. Por cierto, he adaptado el artículo de la FNMT para mi boletín sobre criptografía (www.cripto.es/enigma.htm)

Saludos cordiales, y enhorabuena de nuevo

(PD: Ojo, la imagen de "verificación de la palabra" no aparece en mi versión de Firefox, he tenido que usar Internet Explorer -!puaj!)