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:

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:

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.

Leer más...

MD5: Tocado, hundido y encima, muere matando

Noticia bomba que acaba de ser anunciada, el algoritmo MD5 del que ya existían sospechas muy muy fundadas sobre su vulnerabilidad frente a ataques de colisiones, y del que ya se habían publicado pruebas de concepto un tanto experimentales, ha sido definitivamente demolido.

Un grupo de investigadores han conseguido crear certificados X.509 falsos simulando ser una CA intermedia.

Una vez lanzada la bomba, las explicaciones: Por lo visto a día de hoy y pese a todas las señales de alarma algunas (¿muchas?) entidades de certificación siguen empleando el algoritmo MD5 en sus certificados digitales.
¿Para que se usa MD5 en un certificado digital? Muy sencillo, un certificado digital tiene asociados una serie de datos: Nombre, propósitos, en algunos tipos de certificado la dirección de correo, la clave publica y unos cuantos campos mas. Sobre esos datos se calcula el Hash de todos ellos y este hash es lo que firma la CA de turno para darle validez. (Mas información aquí)

Lo que han conseguido este grupo de investigadores es, a partir de un certificado 'normal' emitido por parte de una CA, adulterarlo para que el certificado se convierta en el de una CA intermedia (pero manteniendo la validez de la firma haciendo que el hash md5 de los campos coincida) y por consiguiente, convertirse en emisores de certificados que, a los ojos de cualquier navegador, serán completamente validos.

Mas esquemático:

• Los atacantes solicitan un certificado SSL a la CA (en esta parte hay 'cierto truco' ya que en la CSR (petición del certificado), 'les cuelan un pequeño gol')
  
• La CA les emite un certificado SSL valido EXCLUSIVAMENTE para autenticar un servidor web
• Los atacantes crean un certificado, pero en vez de tener los campos propios de un certificado SSL, lo modifican para que sea un certificado de CA (con capacidad para emitir otros certificados)
• Los atacantes crean una colisión en los datos del segundo certificado para que el MD5 coincida con los campos del certificado SSL que es autentico.
• Los atacantes ya tienen un certificado de CA que permite emitir certificados con el mismo grado de validez que la CA autentica
  

¿Que supone esto, a efectos prácticos? Sencillo, Phising a tutiplén que será amablemente certificado como 'sitio confiable' por parte de cualquier navegador.

¿Esta acabado el mundo PKI? NO, cualquier implementación PKI que haya tenido la precaución de usar SHA como algoritmo de hash, esta a salvo del ataque.

Según he comprobado, tanto los certificados del Dni Electronico y los de la FNMT emplean SHA como algoritmo de hash, así que se puede afirmar que están a salvo del ataque.

Leer más...

Interceptar con un proxy peticiones SSL de un iPhone

Como hemos repetido incansables veces, una de las partes más importantes de auditar aplicaciones móviles es auditar los servicios web con los que interactuan. Si la comunicación se hace utilizando HTTPS, no basta con configurar el proxy en el móvil, ya que las aplicaciones nativas hacen llamadas a la API exigiendo que el certificado sea válido.

La forma más sencilla de interceptar estas comunicaciones es añadiendo un certificado de confianza siguiendo los pasos que se describen a continuación:

1.- Se arranca el servidor proxy, en este caso "burp" y configurado para que genere certificados SSL:

Opciones del proxy Burp

2.- Usando Firefox se visita cualquier página en https para que muestre error de certificado y se pueda exportar mediante la opción de añadir una excepción, ver, pestaña detalles,  y pulsando sobre PortSwigger CA , darle a Exportar. El fichero generado ha de tener extensión ".cer" para luego ser importado en el móvil.

Exportar certificado de PortSwigger CA con Firefox

3a.- Una vez exportado se puede importar de tres formas distintas. La primera y más sencilla es mandar un correo adjuntando el archivo a nuestra propia dirección y cuando se reciba, abrir el adjunto para instalarlo tal y como se muestra en las tres capturas siguientes.

Correo electrónico con certificado adjunto

Propiedades del certificado previa instalación

Certificado finalmente instalado

3b.- Otra opción alternativa para añadir el certificado es utilizar la utilidad de Apple "Iphone Configuration Utility", añadiendo un nuevo perfil.

3c.- La última opción es colgar el certificado en un servidor web y acceder mediante Safari para descargarlo, lo que proporcionará el menú de instalación igual a la primera opción.


4.- Una vez instalado el certificado, se configura el proxy en los ajustes de la Wifi:

Una vez terminado el trabajo, se elimina desde Ajustes->General->Perfil->Eliminar.

Ajustes generales

Leer más...

Certificados SSL irrevocables

Uno de los pilares básicos en el 'mundo SSL/PKI' es la posibilidad de beneficiarse de poder contar con una entidad certificadora que, aparte de asegurar la identidad, sea capaz de gestionar posibles desastres revocando los certificados emitidos.

Esto, que parece algo obvio, se sigue haciendo mal en pleno 2013. Seguimos suspendiendo en algo que debería estar totalmente estandarizado y ser cumplido con la máxima rigurosidad.

Según leo de un artículo recientemente publicado por netcraft, algunas CAs reconocidas (aprobadas por Microsoft, Mozilla, etc) emiten certificados que son virtualmente irrevocables.

Veamos porque:

De entrada los navegadores hacen de su capa un sayo y cada uno verifica el estado de los certificados como le da gana.

Existen dos formas de verificar si un certificado está vigente o ha sido revocado:

-Usando CRLs: son ficheros donde aparecen los certificados revocados, el navegador debería descargar ese fichero y comprobar

-Usando servicios OCSP: Mucho más óptimo que lo anterior, se lanza una llamada a un servicio OCSP preguntando por un certificado y el servicio responde si es o no es válido.

Para implementar cualquiera de las formas anteriores, una CA debe poner esa información como parte del certificado que emite en el campo (extensión) apropiado. De esa forma, cuando se presenta un certificado al navegador, este tiene a mano alguno de estos dos métodos para verificar.

Como decía al principio, cada navegador tiene su propia forma de comprobar la validez de un certificado:

Firefox solo usa OCSP para comprobar la validez de los certificados digitales salvo que sea un certificado EV. Esto significa que si solo hay disponible CRLs, no se valida nada. Además solo valida el certificado del servidor, no comprueba la validez de toda la cadena

Explorer hace mejor las cosas y en este caso si comprueba tanto uno como otro método.

Google Chrome no implementa ninguno de los métodos estándar (salvo para certificados EV) y apuesta por gestionar una lista de certificados revocados propia que mantiene a base de updates. (Obvio pensar que esto funciona para grandes CAs pero habría que ver que sucede con otras locales)

Safari por defecto directamente no comprueba nada salvo que sea un certificado EV

Por si esto no fuese ya alarmante, algunas CAs directamente emiten certificados en los que no añaden ninguno de los métodos anteriores. Directamente generan un certificado totalmente irrevocable. Esto, que ya resulta poco aceptable para una implementación PKI 'casera', no tiene disculpa posible a nivel profesional.

Netcraft cita varios ejemplos de certificados así, y uno de ellos, el de https://sede.malaga.es/ ha sido emitido por la FNMT

Otro ejemplo de certificado 'casi' irrevocable es el de https://accounts.google.com en este caso es solo 'casi' porque al menos implementa el sistema de CRLs, lo que significa que Explorer sí lo puede verificar pero Firefox no.

[Referencias]

Would you knowingly trust an irrevocable SSL certificate?

How certificate revocation (doesn’t) work in practice

Leer más...

Errores SSL en navegadores, cuales son y su solución: sec_error_untrusted_issuer

Con esta imagen de la izquierda me dio la bienvenida el servidor de loterías y apuestas (juegos.loteriasyapuestas.es) cuando traté de autenticarme con Firefox para jugar la quiniela de todas las semanas.

Para evitar añadir una Excepción como índica el último botón del mensaje suelo abrir IE8 de mi Windows7 con el que este problema no se reproduce (ya contaremos el motivo). Pero hoy decidí arreglarlo.

El código de error que se muestra "sec_error_untrusted_issuer" indica que el emisor del certificado SSL que se encuentra en el servidor no es una de las entidades de confianza de Firefox, que han superado la política necesaria para que su certificado raíz sea incluido en la aplicación por defecto.

Firefox, a diferencia de Internet Explorer u Chorme y al igual que opera, mantiene un contenedor independiente al sistema operativo de certificados raíz que pueden validar si se ha firmado o no un certificado y si se puede identificar el servidor web de forma segura.

En la gran mayoría de casos este problema se produce cuando se ha generado un certificado raíz, un certificado público y la clave privada específicamente para un sistema con el único objetivo de que la comunicación entre servidor y cliente sea cifrada perdiendo la posibilidad de validar la identidad del sistema. Esto se hace así porque en general se cobra por la firma de certificados y poca gente utiliza alguna de las opciones gratuitas que hay en Internet. Si nos encontramos con eso no quedará más remedio que aceptar la excepción.

Para el caso de la web que cubre mis necesidades ludópatas tenía otra solución. Lo primero que observe y que siempre se ha de comprobar son las propiedades del certificado. Donde entre uno de los parámetros se especifica quién es el emisor.

Por lo tanto, si quisiera que Firefox pudiese comprobar correctamente la validez de este certificado (y evitar el error) sería necesario que tuviese instalado el certificado raíz de la FNMT en su repositorio que puede ser consultado mediante la navegación por los menús: Herramientas->Opciones->Avanzado->Cifrado->Ver Certificados->Autoridades, debería mostrar una pantalla similar a la siguiente, donde no hay referencia a la FNMT.

Para instalar el certificado raíz la FNMT ha publicado unas instrucciones muy sencillas de seguir que consisten en descargarlo de su pagina web e importarlo desde esta misma ventana. Finalmente debería indicarse que se confía en la autenticidad y finalmente seleccionarlo y pulsar sobre "Editar" para aceptar las casillas para las que se quiera utilizar.

Con la importación hecha correctamente no volveré a tener avisos de advertencia ni cuando haga mis apuestas ni cuando entre en muchos otros servicios web  que se ofrecen al ciudadano y que están firmados por la FNMT.

El procedimiento en Opera es similar y se deberá importar para evitar la alerta.Configuración->Opciones->Avanzado->Seguridad->Administrar certificados->De autoridades:

Para finalizar, comentar que en el caso de Chrome o de Internet Explorer antiguos al utilizar el contenedor de certificados del sistema operativo con descargar el archivo y hacer doble click sobre él se importará automáticamente siguiendo los pasos hasta finalizar. Aunque en Chrome son algo más paranóicos y comprueba que no accede a la lista de revocación (CRL),  ya que la FNMT no la publica, y por lo tanto avisa de que no se puede comprobar pese a tener el certificado raíz correctamente instalado.

Leer más...

Yo soy Vodafone.es, Y orangemail.es, Y Mixmail.com

Les comprendo, supongo que cuando han leído el titulo y han visto la foto que lo acompaña (el GRAN Freud) han pensado que definitivamente he perdido la cabeza y padezco algún tipo de trastorno de personalidad múltiple.

Bien, es posible, pero antes de emitir un veredicto déjenme darles una explicación.

Primero de todo, definamos un contexto sobre 'como se es algo en Internet'. La forma mas comúnmente aceptada de probar la identidad online son los certificados digitales. Es la forma de, por ejemplo, tener la certeza de que cuando navegamos en la web de Caja Madrid estamos en ese sitio ya que, vía SSL, sabemos que alguien ha certificado que eso es correcto.

Definido el marco de lo que es una identidad Online, imagino que en este punto el ávido lector se estará preguntando ¿Significa esto podrías tener certificados SSL de Vodafone, Mixmail y Orangemail? Respuesta rápida: Si, pero mejor explicarlo.

Los certificados SSL 'normales' (no los EV) con el paso del tiempo se han convertido en algo tan fiable como la palabra de un político. Ya hicimos una demo de lo fácil que es obtener uno para un sitio que manifiestamente iba a albergar Phishing (El certificado de ese post ya caducó, obviamente no lo vamos a renovar).

El proceso de petición de un certificado SSL normal conlleva una parte de verificación mínima bastante pobre. Muchas entidades certificadoras tienen como único paso de verificación que seas capaz de controlar una de las cuentas de correo que ellas designan como 'fiables'. A través del Twitter de @hdmoore llegué a un curioso post donde se comentaba como en muchos webmails la cuenta 'ssladmin' no estaba bloqueada y como muchas entidades de certificación la tienen como cuenta-de-verificación. No pude resistirme a probar como estaban algunos webmails nacionales. Aprovechando que soy cliente de Vodafone (pese a la extrema torpeza de @vodafone_es) hice la prueba y ... Vaya ! resulta que si puedo registrar ssladmin@vodafone.es, después probamos en Orangemail y Mixmail con idéntico resultado (probablemente haya muchos otros sitios pero con esto, suficiente).

El siguiente paso es localizar una entidad certificadora que tuviera a ssladmin como cuenta de correo en el protocolo de verificación, nuevamente recurrimos a Comodo por sus amables certificados de 90 días gratis.

Vodafone España tiene como website para clientes canalonline.vodafone.es desde donde se puede gestionar toda la operativa de clientes Vodafone. Así que me dispuse a solicitar un certificado para ese dominio. Como se puede ver en la captura, para verificar que yo tengo legitimidad sobre vodafone.es, Comodo tan solo me pide que responda a un email en alguna de esas cuentas, como yo gestiono ssladmin@vodafone.es puedo solicitar un certificado para Vodafone.es y CUALQUIER subdominio.

Una vez hecho eso, con enviar un CSR hecho vía OpenSSL, ya pude disponer de mi certificado aceptado en *todos* los navegadores para canalonline.vodafone.es. 100% factible para ataques Man-in-the-middle.

Disclamer: Dado que el propósito NO es hacer algo ilegal, acto seguido destruimos la clave privada asociada a ese certificado, de forma que NO es usable.

Aquí en formato Crt (PEM) el certificado obtenido.

¿Veredicto?

Leer más...

MD5, Certificados y viceversa

Poco a poco se van conociendo más detalles sobre el ataque criptográfico que está tras el certificado 'rogue' que emplea Flame.

Sergio de los Santos, lo ha bordado en sus explicaciones sobre el affaire aquí y aquí. Poco más hay que añadir a sus explicaciones.

No obstante, si que merece la pena repasar un poco la teoría de este tipo de ataques, los diferentes tipos y sus vectores.

Desde el famoso ataque del 2008 a MD5 hasta hoy, el término 'colisiones' se ha empleado concienzudamente para definir un tipo de ataque. Erróneamente mucha gente asocia este ataque como el único del que puede adolecer un algoritmo de 'hashing', e incluso confunde este ataque con otros.

De entrada, vamos a poner en liza los actores de esta película:

Dato1 --> HashDato1

Dato2 --> HashDato2

Donde 'Dato' puede ser cualquier cosa que se pueda resumir en un hash, puede ser un fichero o puede ser los campos de un certificado digital.

Ataques a algoritmos de hash

De entrada, hay que comentar que todos los algoritmos de hashing son vulnerables a este tipo de ataques. Evidentemente en su resistencia a este tipo de ataques estriba lo mas o menos aptos. Lo que define su resistencia es lo 'computacionalmente factible' que resulta ejecutarlos.

En el momento que un dato de tamaño arbitrario X ha de ser resumido en un hash de longitud fija, se abre la puerta a que existan diferentes tipos de datos que resulten en una mismo hash.

Ataque de tipo 'Primera preimagen' : Tomando como referencia los actores mencionados anteriormente, un ataque de 'primera preimagen' es aquel en el que, conociendo HashDato1, un atacante es capaz de generar un mensaje (Dato2) capaz de generar el mismo hash.

Ataque de tipo 'Segunda preimagen': En este caso el dato a tener en cuenta es 'Dato1' y el ataque estriba en la capacidad de generar un Dato2 que compute en un hash idéntico al de Dato1

Ataque de tipo Colisiones: En este tipo de ataques, el atacante tiene el control sobre Dato1 y Dato2 y mediante la manipulación de ambos, es capaz de generar un Dato1 y Dato2 diferentes entre si, pero que computen en un mismo resultado ante la función de hash.

Los ataques de tipo 'Preimagen' son los menos frecuentes y mas costosos a nivel computacional, y además los más dañinos. El poder generar un Dato2 con su correspondiente HashDato2 idéntico a HashDato1 a partir de simplemente un Dato1 o HashDato1, sería realmente dañino y motivo para anular cualquier tipo de algoritmo de hashing.

Los ataques de tipo 'colisiones', como se ha podido ver en el affaire Flame y en el incidente del 2008, si son factibles pero requieren que el atacante mantenga el control sobre Dato1 y Dato2. 

Y aquí está la clave de todo el asunto. Tanto en el caso Flame como en el anterior, el atacante tenía el control de ambos datos. ¿Cómo? Muy fácil, a la hora de pedir un certificado digital, la CA de turno no genera un certificado y te lo da, tu tienes que enviar lo que se conoce como CSR (Certificate Signing Request), es decir una petición de certificado con unos datos que controlas tu.

Y aquí está la gracia del asunto, empleando sofisticados ataques, pudieron generar un CSR 'ninja' que, una vez procesado por la CA, generaba un certificado perfectamente válido pero que, oh sorpresa, los campos podían ser modificados por los de otro certificado que generase el mismo hash que los campos entregados a la CA en el CSR

Por eso ha sido posible vulnerar ambas CAs y subvertidas para que generen certificados fraudulentos, porque empleaban un algoritmo de hash deficiente y porque los atacantes manipularon de forma realmente ingeniosa las peticiones de certificado para conseguir llevar a cabo un ataque de tipo 'colisiones'

Leer más...

Fraude online con firma digital y SSL

A la hora de hablar de fraude online, una de las cosas mas peligrosas es adoctrinar al usuario con falsos axiomas que son explicados, generalmente, de forma dogmática.

En concreto, se puede encontrar abundante documentación en la red (en muchos casos emitida por organismos oficiales o grupos de seguridad) donde se indican aspectos que, mas que ayudar, pueden suponer un problema por ser totalmente inexactos en algunos casos y falaces en otros.

En este post vamos a demostrar como dos de los tópicos mas escuchados sobre la prevención del fraude online son directamente falsos:

• Una pagina cargada bajo SSL cuyo certificado digital provenga de una entidad de confianza (que el navegador cargue sin emitir errores) y en la que aparezca el famoso 'candado' puede ser considerada segura
• La firma digital y en concreto, el DNI Electrónico, es la 'herramienta definitiva' contra el fraude

La realidad:

• Un certificado digital para un servidor SSL emitido por una CA reconocida, se puede obtener sin ningún esfuerzo o proceso de verificación y en muchos casos, gratis por una larga temporada
• Tanto el DNI electrónico como los certificados de la FNMT, son poderosas herramientas para identificarse y autorizar procesos online, pero esas herramientas, sin una educación previa, se vuelven contra el usuario, pudiendo servir para hacer fraude con validez legal (la firma digital está reconocida en España como análoga a la manuscrita por la ley)

Como la forma mas pedagógica de plantear un concepto es mediante un ejemplo, hemos creado 'La Agencia Pituitaria', hecha a imagen y semejanza de la original.

UPDATE: El servidor en el que hicimos las pruebas ya no está online

Nuestra agencia, es mas generosa que la original ya que ofrece al ciudadano la posibilidad de solicitar una 'ayuda especial' de 400 euros.

La hemos creado de la forma mas fidedigna posible, hemos conseguido un certificado SSL que aceptará cualquier navegador sin mostrar ningún tipo de advertencia, cortesía de Comodo, que ofrece para todo el mundo certificados digitales gratuitos durante 90 días, con solo rellenar un formulario y dar una dirección de correo electrónico. Incluso la URL de nuestra agencia https://phishing.security-projects.com contiene el termino 'phishing' para dejar mas claro el objetivo del certificado (aun así obtuvimos el certificado en 5 minutos).

Otro aspecto que hemos implementado, es la firma digital para la solicitud de los 400 euros, solicitando al usuario que la petición sea firmada o bien con el DNI Electrónico o con el certificado de la FNMT.

El objetivo final era crear una web de apariencia idéntica a la de un organismo oficial, dándole credibilidad con un certificado digital valido, y que implementara el concepto de 'fraude con firma digital' haciendo que el usuario firme digitalmente a ciegas el hash SHA-256 de un fichero cuyo contenido otorga el control de su patrimonio a SbD. Técnicamente, al firmar el resumen unívoco del fichero con un certificado reconocido, lo firmado adquiere validez legal

Como no todo el mundo dispone de certificados digitales, o tal vez no se presten al experimento, hemos creado una presentación online con el funcionamiento detallado de la web. (Click para verla a pantalla completa)

Y el contenido del fichero que se firma durante la transacción es este

Nota: La firma digital solo está implementada para Mozilla Firefox, la enorme biodiversidad de versiones y métodos criptográficos cambiantes en Internet Explorer hubieran multiplicado por 4 el trabajo así que decidimos no implementarla, no obstante, esto no supone que Internet Explorer ofrezca mayor protección, simplemente una dosis extra de trabajo.

Leer más...

HSM (Hardware Security Modules): ¿Necesidad o lujo?

Aprovechando que hace poco he recibido un curso sobre dispositivos hardware dedicados a tareas criptográficas, me gustaría compartir con vosotros algunas ideas.

Los dispositivos HSM (Hardware Security Module), sirven de ayuda en entornos en los que hay una necesidad de tráfico cifrado. A grandes rasgos, permiten generar claves para certificados de clave pública, permitiendo rutinas con un grado de aleatoriedad muy alto, así como almacenar las contraseñas de acceso a determinados certificados.

Principalmente se pueden adquirir en dos formatos, o una tarjeta PCI que se "pincha" en el servidor concreto o un appliance al cuál se accede vía red para las operaciones criptográficas.

Las causas por las que se hacen útiles estos dispositivos son dos: Seguridad y Rendimiento

• Seguridad: En aquellos servidores web que llevan a cabo su actividad mediante el protocolo criptográfico SSL, los certificados de clave pública como el que contiene la clave privada (key) son almacenados en el sistema de ficheros del mismo. Evidentemente se ajustan los permisos de dichos ficheros para que sólo sean accesibles por el usuario que ejecuta el servidor Web (y evidentemente root) protegiendo lo máximo posible el acceso a dichos ficheros. Sin embargo, si dicho servidor se viese comprometido, sería posible sacar esos certificados fuera del mismo pudiendo suplantar el servidor por parte de un usuario malicioso dando lugar a un mega-phising (con certificado válido si además hacemos coincidir el nombre del dominio con el que aparece en el certificado original). Evidentemente, y por defecto, esto no es tan sencillo, puesto que además el certificado de clave privado está protegido mediante una clave. Al arranque del servidor web, o le metemos la contraseña mediante la entrada estándar o harcodeamos en algún otro fichero la contraseña del certificado privado o, lo configuramos sin contraseña. La otra opción, es utilizar un módulo HSM para custodiar dicha contraseña, como indicábamos antes. De esta manera, si el servidor es comprometido remotamente, pueden llevarse los certificados, pero no la contraseña que los protege, puesto que se encuentra en el HSM. De la misma forma, si no tenemos HSM configurado, la contraseña que protege el certificado, en algún momento se encuentra en memoria, de manera que haciendo un dump de la misma podemos dar con la contraseña. Utilizando módulos HSM, la contraseña no sale del dispositivo, sino que se le pasa el certificado cifrado mediante su API, y nos devuelve el resultado ya descifrado para poderlo utilizar por la aplicación en concreto.
  

• Rendimiento: Además de permitir la generación y custodia de la contraseña de los certificados, efectúan las operaciones criptográficas, que suelen ser tareas que consumen muchísimos ciclos de CPU (debido a la necesidad de generar números primos de gran tamaño), mediante un procesador aparte especializado, de manera que libera al servidor de ese tipo de tareas. En general, la efectividad de los módulos HSM, es mayor en criptografía de clave pública (o asimétrica), que en criptografía simétrica. En las sesiones SSL se hace uso de ambos tipos de criptografía: al principio de la sesión se utiliza clave pública o asimétrica y una vez negociada la clave a utilizar, se utiliza clave simétrica como se ve en la siguiente figura.

Y alguien dirá, ¿y qué hay de la seguridad física? ¿y si me roban el servidor con HSM incluido (ya sea tarjeta o appliance)? Serían capaces de extraer de alguna forma la contraseña que protege el certificado privado, junto a los certificados del sistema de ficheros... Pues no. Una de las características de los dispositivos HSM es que han de ser tamper-resistant, de manera que si se fuerza la tarjeta para sacar la memoria donde se guarda la tarjeta, está se autodestruye y se borra evitando el compromiso.

Dado el precio de este tipo de dispositivos (suelen ser bastante caros), hay que plantearse claramente si es necesaria su adquisición. Aquellas organizaciones que tengan que cumplir con normativa legal FIPS-140-2 Nivel 3, Common Criteria CC EAL 4+, etc,.. o aquellos sitios en los que realmente tienen una alta sensibilidad ante la información que protegen.

Leer más...

Gestión de Certificados Digitales en Windows Vista y 7

Hoy vamos a explicar algo curioso sobre los 'pequeños' cambios que ha sufrido la gestión de certificados digitales en Windows.

En concreto me estoy refiriendo a la forma en la que Windows gestiona los certificados de CAs Raíz (root) en Vista y 7.

Tradicionalmente la gestión de CAs en Windows era similar a la que hace, por ejemplo, Firefox. Se dispone de un contenedor donde se almacenan las CAs raíz que Mozilla o Microsoft han designado como fiables tras procesos varios de aprobación, y el usuario final simplemente se desentiende. Esta gestión estática de certificados tiene sus cosas buenas y sus cosas malas, la parte buena es que tu, como usuario final, puedes revisar la lista y desinstalar cualquiera de esos certificados a tu criterio. La parte mala viene a la hora de incorporar nuevas CAs, normalmente es necesario liberar un parche o una actualización de software con las nuevas CAs.

Alguien en Microsoft debió decidir que esa forma tan estática de gestión no es optima y la cambiaron. Si observamos la lista de certificados de CAs raíz que vienen 'by default' en Windows observaremos que apenas hay unos pocos certificados (solo 12).

¿Microsoft se ha vuelto paranoica? Nada de eso, como prueba de concepto podemos navegar hacia la web de la AEAT https://www.agenciatributaria.gob.es/ y... ¡ Sorpresa ! podemos acceder vía SSL sin ningún warning porque el certificado, (emitido por la FNMT) ha sido considerado valido. ¿Que ocurre si volvemos a mirar el contenedor de certificados?

Vaya ! ahora aparece en el contenedor el certificado de la CA de la FNMT, y todo esto sin intervención alguna del usuario. De hecho apenas se puede encontrar rastro del suceso en el visor de eventos:

Si probamos a eliminar manualmente el certificado del repositorio y volvemos a navegar sobre la web de la AEAT, el proceso se repite y el certificado se carga en el contenedor.

Googleando y preguntando lo cierto es que no encontré información sobre este cambio en modo detallado, así que me puse a investigar un poco. Tirando de Wireshark vi esto:

Muy elocuente el UserAgent, sin duda. El caso es que parece que cuando a Explorer se le muestra un certificado que no es capaz de validar, descarga ese fichero Cab. ¿Y que hay dentro de ese fichero? Otro llamado authroot.stl que, tal y como vemos en MSDN, se trata de una lista de certificados de confianza firmada digitalmente por una CA de Microsoft. Así que el proceso está claro. Microsoft tiene una lista de certificados validos que gestiona dinámicamente a su aire y que va suministrando al usuario final cuando este encuentra un certificado que no puede validar. Si buscamos en el fichero authroot.stl

Podemos ver la lista completa de certificados que en ese momento Microsoft da por validos y entre ellos, el de la FNMT.

Particularmente creo que con algo tan serio como los certificados digitales que, no dejan de ser sobre lo que se articula la seguridad en Internet, merecen la máxima transparencia y rigor. Ya hemos visto que la lista de CAs válidas es consultable en un momento determinado, pero el hecho de que esa lista se modifique dinámicamente y sin visibilidad no es buena idea. Y mas cuando se escuchan algunas voces que siembran bastantes dudas. A eso hay que sumarle que, aunque se eliminen los certificados, Windows los volverá a cargar amablemente.

Realmente se puede deshabilitar la auto-actualización de certificados usando el editor de políticas de Windows:

Pero obviamente, la idea de tener que ir aprobando certificados a nivel de usuario, es menos recomendable si cabe.

No obstante, en aras de al menos tener cierto control sobre lo que sucede en nuestro almacén de certificados, he programado una pequeña herramienta llamada CertMon que monitoriza el almacén de certificados en Windows y, cuando detecta que se ha cargado un nuevo certificado, informa al usuario dando los datos de la CA.

La herramienta está disponible aquí

Leer más...

TurkTrust: Algunas reflexiones sobre el último 'CA Gate'

Sí, ha vuelto a suceder: Otra vez una CA ha vuelto a saltar a la luz pública por haber protagonizado un mini escándalo de certificados fraudulentos.

En este caso, la protagonista ha sido 'TurkTrust' entidad de certificación Turca que, tal y como reflejamos en otro artículo donde se analizó en manos de quién está la seguridad, es junto a ANCE las dos únicas CAs cuyo origen es un país musulmán.

En este caso el problema no ha sido un hackeo (como en el caso comodo y diginotar), mas bien un uso indebido de dicha CA.

Se puede encontrar en internet mucha información del asunto, pero tal vez la fuente mas expeditiva sea nakedsecurity donde explican lo sucedido realmente,

Resumido queda en esto:

1- A mitad de 2011, en teoría debido a un error interno y supuestamente no malintencionado, TurkTrust emitió dos certificados de CA subordinada en vez de un certificado normal a dos clientes (nótese que un certificado de CA subordinada permite, a la postre, crear certificados válidos para identificar hosts en internet sin control alguno)

2- Uno de esos certificados 'erróneos' fue revocado porque el cliente al que se le dio informó del error (es extraño que a raíz de ese error no se investigase si existían más certificados así). El otro certificado que se emitió a EGO (autoridad gubernamental del transporte) siguió activo.

3- Alguna mente iluminada en EGO que se dio cuenta del error (ellos dicen que no, pero yo no me lo creo) instaló este certificado mágico en un dispositivo CheckPoint que, entre otras capacidades, tiene la habilidad de interceptar tráfico SSL mediante MitM creando certificados al vuelo a partir de un certificado CA (el cómo usan estos dispositivos las organizaciones que no tienen uno de esos certificados mágicos da para otro post y ahora mismo como explicación, sobra).

4- A finales de 2012, la gente de EGO creó un certificado 'wildcard'  para *.google.com

5- Un usuario de la red de EGO estaba empleando Chrome como navegador y Chrome, resulta que usa Public key pinning que, muy groso modo, significa que Chrome sabe de que CAs puede esperar certificados para sitios como www.google.com y de cuales no.

6- A partir de ahí saltó la chispa que prendió todo este escándalo.

En mi humilde opinión, la historia de los certificados 'erróneos' que terminan en un dispositivo CheckPoint para interceptar tráfico SSL me suena excesivamente obvia como para creerme la explicación oficial de TurkTrust en la que tratan de explicar todo esto como un cúmulo de infortunios.

A partir de esto, me gustaría reflexionar sobre varias cosas. Mucha gente, a raíz de estos escándalos están poniendo en tela de juicio el modelo tradicional PKI / CAs.

Tal vez el más notable intento sea Convergence, que propone una ruptura con el modelo tradicional para cambiarlo por otro.

A mi modo de ver, pasado un tiempo de su lanzamiento, opino que no es el camino, el modelo tradicional de las CAs no es un modelo 'malo', simplemente el tiempo lo ha 'prostituido', se han admitido un desproporcionado número de CAs de confianza, los procesos de auditoría son excesivamente laxos y al final se confía más de la cuenta.

Frente a eso, hay otras propuestas que proponen mejorar el sistema, Google apuesta por el pinning y también proponen 'Certificate Transparency [PDF]' que, básicamente es un gran log público donde cada CA debe registrar cada certificado que emita, de esa forma si tu eres el dueño de ejemplo.com puedes consultar periódicamente que certificados para tus dominios hay en circulación.

Mi pequeña aportación a todo esto fue 'SSLCop' que tuve el placer de presentar en la pasada rootedcon, y que pretende ser una forma de reducir el número de CAs en las que confía tu navegador eliminado CAs por procedencia geográfica asumiendo, por ejemplo, que tu, si no eres Turco, no necesitas confiar en las CAs de ese país

Leer más...

Exportando claves privadas marcadas como no-exportables con Jailbreak

Que no os confunda el nombre de la herramienta de la que os vamos a hablar en este post. Aquí no encontrarás nada de iPhone, iPad o iPod, ni como cargar aplicaciones no oficiales ni demás. Os vamos a hablar de certificados digitales, y de como poder exportar la clave privada de los certificados cuando esta ha sido marcada como no exportable en el momento de su generación.

Si nos remontamos a nuestro primer post aquí en Security By Default, FNMT: Insecure by default, Yago nos presentó una herramienta programada por él mismo, CertDump, encargada de buscar en nuestro contenedor criptográfico certificados cuya clave privada fuese exportable y exportarla junto con su certificado en un fichero PKCS#12 sin contraseña (pudiendo así instalar el certificado en cualquier otro sistema).

Pues bien, la herramienta Jailbreak de iSEC Partners es capaz de realizar justamente la tarea complementaria: buscar en nuestro contenedor criptográfico certificados cuya clave privada fuese marcada como NO exportable y exportar seguidamente el certificado incluyendo su clave privada en un fichero PFX.

La técnica que utiliza consiste en el parcheo del Crypto Service Provider para deshabilitar la comprobación sobre los certificados sobre si son o no exportables. La clave privada se encuentra en el propio sistema de ficheros, y se podrá obtener siempre y cuando este no se encuentra cifrado o dicha clave se haya almacenado en cualquier solución "hardware" como por ejemplo una smartcard.

Dentro del fichero comprimido que descargamos nos encontraremos una .dll llamada jb_dll.dll, la cual se inyectará en el proceso del CSP. En el momento de la comprobación sobre si las claves privadas de nuestros certificados son exportables o no, la librería aplicará el parche, y durante ese proceso los certificados con claves privadas no exportables podrán exportarse satisfactoriamente.

Ahora bien, esta técnica no es para nada actual (actualmente la versión más actual de Jailbreak es la 3.4, pero incluso podemos comprobar como en el servidor de iSEC Partners tenemos la 2.0, del 2007). Es más, incluso fué aprovechada por varios creadores de malware para su difusión mediante bichos que eran capaces de exportar los certificados incluyendo sus claves privadas y enviarlos a servidores externos. La DLL por tanto pasó a considerarse como peligrosa por las firmas de Antivirus, de ahí que os pueda saltar el aviso de que se trate de una backdoor. En este enlace tenéis el informe de VirusTotal sobre jb_dll.dll.

Antes de comenzar, indicar unos pre-requisitos básicos que tienen que cumplirse para que esta herramienta realice su trabajo correctamente:

• jailbreak.exe, jbstore.exe y jbcsp.exe funcionan bajo:
• Windows XP SP2 x86
• Window 2003 SP1 x86
• Windows Vista RTM & SP1 x86
• Windows 7 x86
• En las versiones x64 de Windows Vista y Windows 7 únicamente funcionará la aplicación jbstore.exe
• Como comentamos anteriormente, para poder exportar la clave privada, esta debe encontrarse en el sistema de ficheros de la máquina. Dicho sistema de ficheros no debe encontrarse cifrado y necesitamos contar con permisos de acceso sobre él.

Comprobación de que el certificado tiene marcada la clave privada como no exportable

Mediante la consola de gestión de Microsoft (Microsoft Management Console, mmc.exe) añadimos los complementos referentes a los certificados:

Hacemos clic dos veces en el certificado del cual queremos exportar su clave privada, comprobando que se dispone de ella en el sistema de ficheros:

Seguidamente, con el certificado seleccionado, hacemos clic con el botón derecho -> Todas las tareas -> Exportar...

y comprobamos como la casilla de "Exportar la clave privada" se encuentra deshabilitada en el siguiente paso del Asistente:

Entra en juego el Jailbreak.

Utilizando Jailbreak

Dentro del .zip descargado nos encontraremos los siguientes ficheros, que describiremos a continuación:

1. README.txt: Información sobre la utilización de cada uno de los ejecutables de los que se compone la herramienta.
   
   
2. jb_dll.dll: DLL que realizará el trabajo del parcheo del CSP para marcar como exportables las claves privadas de los certificados.
   
   
3. jailbreak.exe y jailbreak.msc: Programa principal que requiere interacción por parte del usuario que lo ejecute.
   
Tras la ejecución de jailbreak.exe y el correspondiente parcheo por parte de la DLL, se invocará una instancia de la consola de gestión de Microsoft (Microsoft Management Console, mmc.exe) con los complementos referentes a los certificados del sistema ya cargados (vista definida mediante el fichero jailbreak.msc incluido en el ZIP de la herramienta). Una vez ahí, podremos acceder a los certificados y realizar la tarea de exportación, en la que se comprueba como la casilla de "Exportar la clave privada" se encuentra esta vez habilitada.


La marcamos, introducimos la contraseña que queramos y el nombre del fichero para exportar, y listo.


Tendremos un fichero .pfx que contendrá el certificado y su clave privada, listo para distribuir y utilizar...como queramos.
4. jbstore.exe: JBStore es una aplicación que se ejecuta por línea de comandos y que exporta todos los certificados del almacen "Personal" sin requerir la interactuación con la Microsoft Management Console como para el caso de la aplicación Jailbreak.
Es posible seleccionar tanto el almacen “Personal” del usuario actual o del equipo local indicándolo como parámetro (/user o /computer respectivamente):



5. jbcsp.exe: jbcsp es una aplicación que se ejecuta por línea de comandos y que exporta las claves que se encuentran dentro del CSP (Cryptographic Service Provider) pero que no están asociadas con un certificado.
   

Como veis, una tarea sencilla, limpia, ideal para procesos de backup o migraciones... Eso sí, esta aplicación debería formar parte de nuestra colección de "Herramientas que necesito subir a TU ordenador".

Leer más...