Vulnerabilidades DNIe
Acabo de encontrar esto http://www.pentest.es/index_dnie.php
Me huele a campaña publicitaria de los chicos de Pentest, sobre todo por la última frase que aparece en el video. ¿Qué os parece?. Las pruebas que ha hecho son bastante triviales y el resultado lo demuestra, aunque tiene ideas buenas. Imagino que los que han hecho las pruebas para la certificación del chip habrá hecho bien su trabajo y han previsto cosas como estas.
- Conecta o crea cuenta para participar
- 798 lecturas
Twitter
Interesante
Me parece interesante las pruebas que se han hecho, sobre todo la de obtener el PIN por la fuerza bruta, que de ser cierto lo que se sospecha acerca del contador de PINSs erroneos, se podria realizar este ataque con un unlooper, ya que este es capaz de cortar la corriente en el momento preciso que queramos. El problema ahora mismo es que no se sabe como se realiza la autentificación del PIN.
Yo tambien realice mis pruebas, pero con la intencion de evitar usar el driver del DNIe y lo que hice fue capturar cambios de PIN e intrudir el PIN correcto como erroneo. Se ve claro como el driver pide desafio a la tarjeta. Despues de esto imagino que tarjeta y driver calcularan la respuesta donde influye el PIN y si coinciden quiere decir que el PIN es correcto.
Con esto digo que las comunicaciones no estan cifradas, sino que se usa un Challege/Response como metodo de autentificación del PIN. Cosa que no me gusta ya que nos restringe mucho a los programadores el desarrollar determinadas aplicaciones, por ejemplo por hardware.
Esa seria un manera teorica de romper la seguridad del DNIe, pero ¿y si en vez de jugar con el OS del DNIe jugasemos con el hardware o usasemos Glitching?
Aqui teneis un ejemplo de como leer el contenido de una tarjeta por hardware.
Eso si, no al alcance de cualquiera jeje.
http://www.youtube.com/watch?v=tnY7UVyaFiQ&feature=fvst
Tambien os dejo información de lo ocurrido con el DNIe Britanico
http://www.google.es/search?hl=es&q=DNIe+hackeado+12+minutos&meta=
Saludos.
El OS podría ser el eslabón débil
Hola,
yo elaboré el informe. Aunque en él poco o nada se aprecia del trasfondo de investigación que hay -no era ese el objetivo- ahora puedo comentar porque no se intentaron técnicas de Glitching o similares. La tarjeta, es decir el hardware, tiene una certificación CC de EAL5, realizada por el gobierno francés. Esto nos llevó a pensar que seguro que la tarjeta tiene un mecanismo de control y bloqueo en caso de que detecte condiciones de trabajo extrañas, por ejemplo fuera de un determinado rango de temperaturas o en condiciones eléctricas adversas. Es por eso que descartamos esa via desde el principio. Pero el Sistema Operativo, es una creación española, de la que ya llevamos varias versiones... ¿Qué se corrigió en cada versión? ¿Solo se realizaron mejoras funcionales...?
En las pruebas que realizamos, se detectaron patrones bien definidos en las diferencias de tiempos empleadas cuando los PIN son correctos y cuando no lo son. En mi humilde opinión, esto no debería ser así, sino que se deberían introducir mecanismos -fiables- para que los tiempos fueran aleatorios. Aunque esto que se ha detectado no es crítico de por si, hace sospechar que quizá, solo quizá, haya descuidos en el diseño del SO del DNIe que puedan ser aprovechados. Sin el código en la mano, es tremendamente complicado, pero también lo hace más interesante...
¿a que te refieres con eso
¿a que te refieres con eso de que -no era ese el objetivo-?.
Pues que la idea del documento
Pues que la idea del documento era reflejar un proceso, intuitivo, natural y espontáneo de analizar el DNIe, ya sea a nivel de diseño, pero sobre todo a nivel de implementaciones. Fuimos directamente a los temas que pensamos que podrían dar mejores resultados, o donde los vectores de ataque tendrían mayor probabilidad de éxito y siempre teniendo en cuenta lo reducido de nuestro presupuesto para este tema y la falta de material especializado para realizar según que pruebas. No se trataba de realizar un seguimiento de una certificación ni de seguir un manual determinado. Queríamos cojer el DNIe, ver como funcionaba, como podíamos comunicarnos con él, como trabajaba con nuestro sistema y como interactuaban todos estos elementos y buscar puntos débiles. Realizamos muchas pruebas, que luego consideramos que como no aportaban nada, no merecía la pena documentar. En una certificación se documenta todo, lo que sale bien y lo que sale mal. Este no era el objetivo de nuestras pruebas. Y siendo una prueba caja negra -no tenemos ni la lógica ni el código del SO- pues cuando llegamos a un punto que "no nos gusta" pues simplemente lo documentamos y lo dejamos reflejado, como es el caso del PIN. Pero en ningún momento concluimos que falla. Elaboramos hipótesis, nada más. Con el esquema lógico en la mano, todo se reduciría a decir, esto puede funcionar o esto no puede funcionar.
Por otro lado, no me cansaré de decir, que el objetivo básico del documento es demostrar que el contexto en el que se va a utilizar es el eslabón débil. Sus implementaciones deficientes en servidores web, los PC's de los usuario infectados de troyanos, etc. ¿Que eso ya "se sabía"? Probablemente la gente del sector TIC, en concreto los expertos en seguridad, sí. Pero el ciudadano de a pié no tiene ni idea. Si el gobierno le dice que el DNIe es inexpugnable, él no se plantea que una cosa es el DNIe y otra distinta sl PC de su casa... Ni tiene idea de que usando el DNIe en un ordenador público, puede dejar sus datos en ese sistema, etc,etc. Y sobre todo, lo que casi ningún ciudadano de la calle sabe, y probablemente pocos jueces, es que por muy seguro que sea el DNIe, es perfectamente viable suplantar la identidad de una persona en Internet y realizar operaciones con su DNI en su nombre. Y para ello, no hace falta ser un super experto en seguridad. Basta un keylogger y un programa de control remoto.
mmm...
Hola,
Lo he mirado por encima, muy rapidamente, y parece que asumen que el DNIe decrementa el contador DESPUES de comprobar el PIN. Esto es algo que se hacia hace 10 anyos, pero que dudo que hoy en dia alguien haga. Especialmente despues de pasar por una evaluacion CC EAL4+ o la que tenga en concreto el DNIe.
En fin, ahora no tengo tiempo pero cuando este en casa le echare un ojo mas concienzudamente. Prometo volver a comentar un poco mis impresiones ;)
@Guppy, obviamente con glitching (ya sea vcc, clock o incluso laser) tienes mas posibilidades de introducir un fallo. Aun asi, quiero creer que los desarrolladores lo habran tenido en cuenta y se habran hecho las pruebas pertinentes durante la certificacion y tb en la auditoria del software, vease uso de objetos con integridad protegida (checksums), double-checks de las variables sensibles para evitar glitching, etc.
En ese caso, necesitarias como minimo inyectar dos fallos (para saltarse las dos comprobaciones), o alterar un valor y su checksum, etc.
Bueno, que me enrollo... sigo trabajando, ya volvere cuando haya echado un ojo al paper.
Saludos
He encontrado un hilo
He encontrado un hilo de internautas.org en el que están debatiendo este informe.
http://foros.internautas.org/viewtopic.php?p=106550#106550
Todo apunta a que el informe es cuando menos "agresivo" y "poco documentado".
Desgraciadamente
Desgraciadamente en muchas ocasiones las ramas no nos dejan ver el bosque, lo que dice el informe es cierto y algo que ya se sabía, usar el eDNI en un ordenador comprometido es un serio problema de seguridad. Pero pensemos que en ocasiones meteremos el eDNI en un ordenador del que no controlamos su seguridad, por ejemplo, en un Cajero Automático que lo admita, en el Ayuntamiento, en el notario, en el Registro de la Propiedad, en el Juzgado, o en la misma Comisaría de Polícia, en todos esos casos, también somos responsables de lo que pase con nuestro eDNI.
El principal problema es que las políticas de certificación hacen responsable al usuario de todo lo que pase, incluso, ante la caída catastrófica de los algoritmos criptográficos utilizados, aunque éstos no han sido implementados o elegidos por el usuario y hay algunos que están cayendo en desgracia en este momento.
Pero la realidad es más cruda, incluso cuando hablamos de la seguridad de los ordenadores que son responsabilidad de los usuarios ¿cuántos ordenadores domésticos están en este momento infectados por malware de todo tipo?, la respuesta es aterradora, sobre todo, cuando consideramos que el eDNI es un generador de evidencias electrónicas que no tiene límite, lo mismo puede vender tu casa, que firmar tu declaración de la renta.
Las conclusiones del informe las hemos mantenido algunos desde hace mucho tiempo, incluso por responsables del proyecto, como D. José Luis Díez Aguado, director técnico del proyecto de DNI electrónico, que dejó bien claro que no era sano usar un eDNI en un ordenador inseguro. Pero tampoco es seguro su uso, si la operativa para el uso del eDNI no está bien diseñada, algo que también se escapa de nuestro control y de la que las políticas de certificación nos hace de algún modo responsables cuando usamos el eDNI.
Pentest solamente ha demostrado esto, no dice que el eDNI sea inseguro, pero avisa claramente de que en manos de usuarios con pocos conocimientos y en determinadas condiciones, puede llegar a ser un serio problema. Desgraciadamente mucha gente opina en foros sin tener mucha idea, o sin haber leído o comprendido lo que dice el informe, no en vano, opinar es gratis y en este caso dejarse llevar por los críticos al informe puede ser una mala idea.
Se está usando un sistema seguro en un entorno inseguro y eso tendrá problemas siempre, si no se tiene cuidado. La seguridad del eDNI nos puede llevar a pensar que cualquier operación realizada con el eDNI es intrínsecamente segura, cuando realmente no es así.
Por ejemplo, una aplicación maliciosa nos puede hacer creer que nos estamos autentificando inocentemente, cuando realmente estamos firmando la hipoteca de nuestra casa. En este caso el eDNI funciona perfectamente y es seguro, el problema está en que han engañado al usuario para que introduzca la contraseña de su eDNI, algo que deberá hacer siempre antes de usarlo, con independencia de que quiera autentificarse o firmar un documento, el contenedor es el mismo y dentro hay dos certificados distintos.
Un saludo, Fernando Acero
"Sobreinformación"
No me considero un usuario avanzado pero, a base de usar mi ordenador, tampoco soy ningún advenedizo; puedo entender casi cualquier cosa si me lo explican con claridad. Dicho esto, considero que usar una cosa como las tarjetas criptográficas en general y el dni electronico en particular no se puede considerar un uso elemental del ordenador. Hace unos años, participar en un foro como este era cosa de frikis; la tecnología era de_finales_de_siglo_XX y eso lo hacía sólo apto para usuarios avanzados. Todavía hoy se puede ver que los usuarios normales no hacen un uso "seguro" de su equipo, ¡Incluso usan sus tarjetas de crédito para pagar tasas en carreras populares a través de una simple conexión http! (no me lo estoy inventando). Creo que es responsabilidad de la Administración fomentar campañas de "alfabetización" y "sensibilización" de los usuarios; el equivalente a las campañas de la DGT. Que alguien pueda comprarse el coche más seguro del mercado no lo convierte en un conductor seguro. Que alguien tenga un dni electronico en su cartera, un PC y una linea ADSL no lo convierte en un usuario seguro. ¿Es insegura la conexión, el PC o el dni? Creo que lo inseguro es el usuario. Poco a poco todo cambiará, como los coches, las carreteras, el código de la circulación y la actitud de los conductores. El informe de Pentest es "sobreinformación" dirigida a incentivar el consumo de un producto. La información que necesita el usuario no aparece por ningún sitio. Mientras la Administración reacciona y empieza a impartir formación a los usuarios, los foros de Kriptópolis son un buen sitio por donde empezar.
he visto el vídeo
he visto el vídeo y así a simple vista (corregidme por favor) no parece un problema del dnie, sino del internet explorer y su famosa caché.
No creo que sea un problema
No creo que sea un problema de internet explorer, ya que sino me equivoco podemos volcar el contenido de cualquier programa cargado en memoria.
Ya sabeis que podemos obtener las conexiones con un simple sniffer y los datos del DNIe a traves de PC/SC, CSP, etc...
Respecto a la cache de IE, no habria problema, ya que las claves privadas del DNIe no pueden salir del chip.
En el video se muestra como acceden a la cuenta bancaria despues de haber retirado el DNIe del lector, y... ¿no puede ser que el problema pueda ser del banco por no solicitar una nueva autentificacion y firma al conectarte de nuevo?
Saludos.