Vulnerabilidad en TrueCrypt

21 de julio de 2008 Por

El pasado viernes, Bruce Schneier publicó en su blog un análisis sobre una vulnerabilidad encontrada en la versión 5.1a de Truecrypt, la última en el momento de realizar este análisis (la última es ya la 6).

Según se reflejó en el análisis, Schneier y su equipo de la Universidad de Washington encontraron diversos problemas de seguridad en el uso de sistemas de ficheros ocultos sobre plataformas Windows, que podrían permitir en algunos casos detectar la existencia de dicho sistema o de ficheros contenidos en éste, y en el peor de los casos la recuperación de información.

Según puede leerse en el paper, debido a la naturaleza de determinadas funcionalidades del propio Windows o de aplicaciones habituales en dichos sistemas, es posible producir esta fuga de información. Schneier diferencia 3 tipos de vectores de ataques:

1) A través del sistema operativo. Por ejemplo, la existencia del software Truecrypt deja rastro en el registro de Windows, así como la existencia de las unidades de red en las cuales ha sido montado. Esto pondría de manifiesto la existencia de sistemas de ficheros cifrados pero no aportaría ninguna información extra, salvo que se encontraran en el sistema de ficheros abierto accesos directos que apuntaran a la unidad de la que ya hemos averiguado que se trata de una unidad cifrada. De esta manera, sí que podriamos obtener algo más de información sobre los ficheros que hay el sistema de ficheros cifrado/oculto. Recordemos que el propio sistema operativo guarda estos accesos directos en sus menús de inicio como “últimos ficheros abiertos”, por lo que no es necesario que hayan sido creados de forma manual, sino que el propio sistema los crea con tan solo acceder a alguno.

2) A través de una aplicación primaria. Por ejemplo, el autosalvado de herramientas como Microsoft Word, programas muy habituales en todos los sistemas Windows. El autosalvado de Word hace, “por seguridad”, una copia temporal del fichero con el que estamos trabajando de forma periódica, con el fin de poder recuperar la información en caso de fallo del sistema. Sin embargo, dicha copia es guardada en un directorio temporal del sistema operativo (por ejemplo C:\Users\UserName\AppData\Roaming\Microsoft\Word\), que a no ser que estemos optando por un cifrado completo del disco, estará almacenada sin cifrar. Una vez finalizada la edición del documento, este se encarga de eliminar el temporal del documento, ya que la información ya ha sido almacenada en su ubicación original, pero evidentemente Word no realiza un borrado seguro de los datos contenidos en el documento temporal. Esto significa que realizando una recuperación de ficheros borrados de un disco duro podriamos llegar a recuperar el documento, aunque realmente dicho documento esté presente en un pendrive cifrado del que no disponemos. Como podemos ver, este vector de ataque es uno de los más graves que podemos encontrar, ya que recuperariamos el contenido entero de un fichero cifrado.

3) A través de una aplicación no primaria. Por ejemplo, Google Desktop y la funcionalidad que tiene para poder recuperar estados anteriores de los documentos. Evidentemente, si tenemos instalado Google Desktop en nuestro equipo, éste podría indexar y cachear el contenido de un sistema de ficheros cifrado que tuvieramos montado y sobre el que estuvieramos trabajando. De esta manera, al igual que ocurría con el anterior vector de ataque, podriamos recuperar información completa sobre el contenido cifrado con tan solo acceder a la cache de Google Desktop, sin ni tan siquiera necesidad de recuperar la información borrada.

Haciendo un análisis de los problemas de seguridad mostrados en el paper, algunos de ellos pueden tener solución por parte de los desarrolladores del software, pero dada la naturaleza de los fallos gran parte de ellos me parecen difícilmente corregibles por dichos desarrolladores. Pienso que es más una tarea del administrador del equipo en el que va a ser ejecutado TrueCrypt el realizar una configuración adecuada para que este tipo de problemas no se produzcan.

¿Y qué pasa si ejecutamos nuestro Pendrive cifrado en un equipo sobre el que no tenemos el control? Bueno, incluso si no existiera ninguna vulnerabilidad en el software nunca deberiamos escribir una contraseña en un ordenador no confiable, puesto que la vulneración del cifrado sería tan inmediata como instalar un KeyLogger en el equipo que capture nuestra contraseña de cifrado en el momento de teclearla.

¿Recomendaciones?

  • Si hablamos de un equipo que tiene cifrada una unidad: mi recomendación es un cifrado completo del disco, así se evitan problemas con ficheros temporales y cachés, puesto que ellas estarán a su vez cifradas por estar contenidas en el disco.
  • Si hablamos de un dispositivo tipo pendrive que se mueve de aquí para allá sin control del equipo en el que se ejecuta: intentar no tener toda la información en una sola “unidad”, sino separada por cliente, proveedores, proyectos o como mejor se adapte a cada uno, utilizando contraseñas diferentes para cada unidad. De esta manera si en un sitio se pincha para ver la información del cliente X y un intruso captura la contraseña o accede a los datos, será siempre a datos a los que realmente ya debería tener acceso, ya que por eso se ha tecleado la contraseña.
  • Solución super-paranoica: mi pendrive es por un lado un LiveCD con Linux y por otro lado tiene una unidad TrueCrypt. Si necesito acceder a la información y no me fio del entorno, puedo arrancar desde USB con el Pendrive, y de esta manera al montar la unidad cifrada tengo la seguridad de que estoy arrancando un sistema operativo confiable; a partir de ahí copio la información, bien al disco del equipo local, bien a otro equipo, por medio de comunicaciones cifradas.

Seguiremos informando cuando TrueCrypt de una respuesta a este paper.

Internet *no* es una fuente de acceso público

18 de julio de 2008 Por

Hace unas semanas, un conocido tecnólogo-gurú 2.0 se quejaba de que una empresa seguía mandándole correos electrónicos de publicidad a pesar de los reiterados intentos de cancelar una presunta suscripción. Como respuesta a su comentario, algunas personas le sugirieron que esa publicidad era legítima debido a que su correo estaba publicado en su blog, y por tanto en una fuente de acceso público.

Con apelar al sentido común, se da uno cuenta de que si esto fuese efectivamente así, se estaria legitimando el 95% del envío de spam; al fin y al cabo, no hay más que navegar un poco para hacerse con una cantidad nada despreciable de correos electrónicos. Pero como no quiero que se fíen de mi palabra, les muestro lo que dice el punto j) del artículo 3, “Definiciones”, de la LOPD:

Artículo 3. Definiciones.

j) Fuentes accesibles al público: aquellos ficheros cuya consulta puede ser realizada, por cualquier persona, no impedida por una norma limitativa o sin más exigencia que, en su caso, el abono de una contraprestación. Tienen la consideración de fuentes de acceso público, exclusivamente, el censo promocional, los repertorios telefónicos en los términos previstos por su normativa específica y las listas de personas pertenecientes a grupos de profesionales que contengan únicamente los datos de nombre, título, profesión, actividad, grado académico, dirección e indicación de su pertenencia al grupo. Asimismo, tienen el carácter de fuentes de acceso público los diarios y boletines oficiales y los medios de comunicación.

Antes de que se me adelanten, creo que considerar Internet en su conjunto un medio de comunicación es algo excesivo, así que en mi opinión queda claro, ¿no?

Nada más esta vez. Buen fin de semana a todos.

–

Actualización: Se me olvidó añadir que el reglamento añade “Las guías de servicios de comunicaciones electrónicas, en los términos previstos por su normativa específica”, aunque eso no modifique el razonamiento realizado.

¿Es un fichero no automatizado o es Superman?

16 de julio de 2008 Por

Después de unos días de abandono personal del blog, por cuestiones de salud y de trabajo, vengo a comentarles hoy una cuestión sobre el nuevo Reglamento de Desarrollo de la LOPD, también conocido como RDLOPD, que me parece no sólo curiosa, sino incluso fascinante. Veamos como introducción la definición de fichero y de fichero no automatizado, según el punto k) y n), respectivamente, del artículo 5:

Artículo 5. Definiciones.

k) Fichero: Todo conjunto organizado de datos de carácter personal, que permita el acceso a los datos con arreglo a criterios determinados, cualquiera que fuere la forma o modalidad de su creación, almacenamiento, organización y acceso.

n) Fichero no automatizado: todo conjunto de datos de carácter personal organizado de forma no automatizada y estructurado conforme a criterios específicos relativos a personas físicas, que permitan acceder sin esfuerzos desproporcionados a sus datos personales, ya sea aquél centralizado, descentralizado o repartido de forma funcional o geográfica.

[Read more…]

Diferencias culturales en protección de datos

11 de julio de 2008 Por

A causa de la gestión de un proyecto europeo de protección de la privacidad de las personas y de la seguridad de sus datos en una empresa multinacional, tarea a la que llevo dedicado los últimos siete años de mi vida profesional, he tenido que estudiar las diversas leyes y normativas acerca de la protección de datos. Aunque están todas ellas basadas en la Directiva Europea y por tanto con textos legales muy similares, no sólo hay pequeños detalles que las hacen totalmente diferentes, sino que además la manera de interpretar y aplicar dichas leyes por los ciudadanos de cada país, convierten la protección de datos personales en algo muy dispar en requerimientos, riesgos y consecuencias, afectando de manera importante al coste de adaptarse a cumplirlas o simplemente ignorar que existen (ya que de todo hay en esta Unión Europea).

Si empezamos por el ámbito de aplicación, en algunos países se especifica que afecta a las personas físicas, en otros también a personas jurídicas, en otros además a todas las organizaciones legalmente establecidas, y para colmo existe un problema común ya que no hay manera de establecer el límite entre persona identificable y no identificable de una forma clara.

Otro punto a destacar es la manera en que la población de cada país percibe lo que son sus derechos; en algunos países se considera que la libertad de las personas es lo primero, y se entiende por tanto que esta libertad lo es tanto para ciudadanos como para empresas y entidades que puedan hacer negocio con los datos personales, lo que genera una situación opuesta a la pretendida por la ley. En otros países, pasadas épocas represivas hacen que el ciudadano perciba que eso de dirigirse al estado para ejercitar un derecho (los de acceso, por ejemplo) no estaría bien visto, y quién sabe si traería consecuencias negativas. En otras culturas, la libertad es un concepto ambiguo y por tanto uno ni se preocupa de sus datos personales.

A todo esto hay que añadir que el responsable de la privacidad de datos de una empresa no deja de ser un ciudadano más, que percibe los riesgos y requerimientos de cumplimiento legal de acuerdo a su propia cultura, ya no la del país donde se encuentra, lo que complica el asunto un poco más.

Si utilizamos los mismos parámetros para medir el grado de cumplimiento de la protección de datos, los resultados entre países son totalmente dispares, pero la percepción de riesgo es inversamente proporcional a éstos. Es decir, que quién mas riesgo pudiera tener por no haber hecho prácticamente nada en la protección de datos de carácter personal, percibe que tal riesgo no existe porque en su país no pasa nada si no se ocupa uno de estas cosas de la protección de datos. Como todo, esto tiene un coste en dedicación de recursos internos o externos, ya que si hay que solicitar un presupuesto para cumplir, es difícil que quien ha de aprobarlo perciba que es necesario y prioritario algo que en realidad piensa que no lo es.

Por ejemplo, en una gran empresa del Reino Unido, el responsable de protección de datos opina que poner nombres de los pacientes en las facturas dirigidas a la administración del hospital, no tiene ninguna implicación con la ley de protección de datos, pero por supuesto, el hospital requiere de inmediato la supresión de esta práctica. Y este es sólo un ejemplo; mientras que los hospitales del Reino Unido están en el punto de mira de la autoridad británica y se sienten vigilados, sin embargo ni siquiera los pacientes, los verdaderos afectados, se preocupan de que pasa con sus datos.

En el caso de incumplimiento ético y legal en la protección de datos, los empleados de la misma compañía tienen la obligación exigida por reglamento oficial, de reportar las incidencias producidas en su entorno, tanto si son motivadas accidentalmente, como intencionadamente, o la prohibición de tales prácticas, según el empleado se encuentre en Francia, España o Alemania, por ejemplo.

También en el ámbito de registro y documentación, las condiciones son dispares. La mayoría de los países europeos no exigen crear un documento que recoja las medidas de seguridad ni los ficheros y sistemas que los tratan, sin embargo otros como España, Italia o Polonia, exigen la creación y mantenimiento al día de su Documento de Seguridad y Política de Seguridad (no sé decirlo en polaco) o el Documento Programático y Disciplinare Technico respectivamente, con los costes y dedicación que este requerimiento conlleva.

Si registramos ficheros, las diferencias en los formularios son abismales y la reacción de las autoridades en el momento de aceptar o denegar el registro también. Un mismo fichero fue registrado en el Reino Unido en 48 horas, en España costó casi un mes, con requerimientos adicionales de información y en Portugal más de seis meses, tras sucesivas teleconferencias con la CNPD (autoridad portuguesa) y envío de documentación adicional. Otro ejemplo más de la disparidad de condiciones en esto de la protección de datos.

Por otra parte, en España tenemos fama de tener la ley mas restrictiva en protección de datos (léase la mas exigente) y sin embargo la Agencia Española, la AEPD, ha colaborado con la Polaca en la creación de su ley de protección de datos personales. El resultado final es una ley gemela de la nuestra, y un reglamento para chuparse los dedos, ya que el nivel de requerimientos de documentación de los sistemas informáticos raya la locura, además de sugerir que se implemente la seguridad de acuerdo a la ISO 17799. Eso sí, por el momento casi nadie conoce tal ley, y mucho menos el ciudadano polaco.

Si hablamos de Italia, el Garante (autoridad italiana) está haciendo auditorias por sectores para ver si consigue convencer a las empresas de que esto de la protección de datos va en serio. Sin embargo, el ciudadano italiano medio no sabe quién es el Garante ni a qué se dedica.

Y así sucesivamente, de tal modo que estandarizar normas y procedimientos dentro de una compañía multinacional es bastante fácil a la hora de escribirlos y publicarlos pero… ponerlos en práctica es una auténtica utopía. En unos países se considera vital y se agradece el soporte y en otros prácticamente estás molestando y creando problemas innecesarios. Y todos, bajo el mismo paraguas legal: la Directiva Europea.

Y si hablamos de controles y auditorias… eso lo dejaremos para otra ocasión.

Crítico: Vulnerabilidad en protocolo DNS

9 de julio de 2008 Por

Hace apenas algunas horas acaba de publicarse (http://www.kb.cert.org/vuls/id/800113) una vulnerabilidad en el diseño del protocolo DNS y en la implementación que de ella hacen muchos fabricantes que podría permitir a un atacante realizar envenenamiento de Cache DNS.

Según se puede leer en el reporte de la vulnerabilidad, el problema radica (entre otros no especificados) en el campo ID que sirve para identificar que la respuesta recibida es efectivamente una contestación a la petición DNS realizada. Dicho campo, según el protocolo, tiene 16 bits de longitud, lo cual se estima insuficiente para poder garantizar la seguridad. Además, la implementación que realizan la gran mayoría de desarrolladores no realiza una correcta “randomización” del puerto de origen de la petición, por lo que dado la facilidad de realizar ataques de Spoofing de tráfico UDP, la predictibilidad del puerto origen y el corto espacio de posibles IDs hace posible que un atacante remoto pudiera generar multiples paquetes para todos los posibles IDs con tan solo ser capaces de predecir el puerto de origen de la petición y de esta manera realizar un envenenamiento de la Caché del servidor DNS atacado.

Imagínense el impacto de algo así, bajo este ataque, no tenemos ninguna certeza de que ninguna de las webs que visitamos es la que dice ser, ni siquiera otros servicios tan críticos como actualizaciones de seguridad.

Por suerte todos utilizamos protocolos cifrados para nuestras comunicaciones y comprobamos los certificados SSL/fingerprint cuidadosamente para verificar que el sitio donde queremos acceder es realmente donde estamos accediendo, ¿verdad? :P

Según comenta el propio descubridor de la vulnerabilidad, Dan Kaminsky (http://www.doxpara.com/), que ha incorporado una herramienta en su web para que podamos verificar si somos vulnerables o no, el descubrimiento de la vulnerabilidad se ha mentenido en secreto por algún tiempo y ha sido coordinada con los principales desarrolladores de software de servicios DNS para que tuvieran preparadas las pertinentes actualizaciones de seguridad antes de dar a conocer al mundo la vulnerabilidad. Consecuencia de ello es que los principales fabricantes ya han publicado, casi simultáneamente con la publicación de la vulnerabilidad, los parches pertinentes. Entre ellos, podemos destacar el advisory de BIND (el servidor DNS más usado en Internet) y el de Microsoft (no por ser el segundo más usado, sino por relevancia de la marca).

Se recomienda a todos los lectores que verifiquen si su servidor DNS es vulnerable a este tipo de ataques (casi con toda seguridad lo será) y que apliquen los parches de seguridad a la mayor brevedad posible, ya que aunque se ha comentado que la ingeniería inversa de los parches publicados es realmente complicada, no es imposible, por lo que se espera la aparición en breve de herramientas automáticas que aprovechen estas vulnerabilidades, incluidas aquellas no documentadas en el advisory
oficial.

Se espera también que Dan Kaminsky de más detalles sobre las vulnerabilidades encontradas y los vectores de ataque en la próxima Black Hack USA que tendrá lugar este mes de agosto.

Saludos y a parchear.

Adivinando en VoIP

26 de junio de 2008 Por

Dice un viejo Hoax de internet que basta con que la primera y la última letra de una palabra estén bien puestas para que nuestro cerebro sea capaz de entender lo que tratamos de decir y, siempre según el Hoax, eso es porque nuestro cerebro no lee letra por letra, sino las palabras en su conjunto. Lean sino el siguiente fragmento:

«Sgeún un etsduio de una uivenrsdiad ignlsea, no ipmotra el odren en el que las ltears etsan ersciats, la uicna csoa ipormtnate es que la pmrirea y la utlima ltera esten ecsritas en la psiocion cocrrtea. El rsteo peuden estar ttaolmntee mal y aun pordas lerelo sin pobrleams. Etso es pquore no lemeos cada ltera por si msima preo la paalbra es un tdoo. Pesornamelnte me preace icrneilbe…»

Lo han entendido, ¿verdad? En realidad, lo dicho no es del todo cierto (tiene que ver con como de desordenadas estén las palabras, cosas de la teoría de grupos) pero me viene de perlas para contarles que investigadores de la Universidad Johns Hopkins han realizado con éxito un ataque contra tráfico de VoIP cifrado, utilizando el tamaño de los paquetes cifrados para hacer suposiciones bastante acertadas sobre las palabras y frases utilizadas en las conversaciones.

Según los investigadores, “[…] esto ocurre porque la tasa de muestreo es alta para para sonidos largos y complejos como ‘ow’ (NT: fonemas ingleses), pero baja para consonantes simples como ‘c’. Este método variable ahorra ancho de banda, mientras mantiene la calidad del sonido.”.

Aunque los paquetes VoIP son cifrados para prevenir ‘escuchas a escondidas’, con esto han demostrado que simplemente midiendo el tamaño de los paquetes sin decodificarlos se pueden identificar palabras completas e incluso frases con una tasa de acierto bastante alta. Dicho de otra forma, el software de escucha desarrollado no puede decodificar una conversación completa, pero si que puede utilizarse para buscar palabras o frases concretas dentro de los paquetes de VoIP cifrados.

Dicho esto, lo primero que me viene a la mente es que el ingenio humano no tiene límites, y lo segundo, una sensación de asombro increíble; señores, ya no hace falta ni que descifren el mensaje, basta con que lo escuchen cifrado para hacerse una idea de lo que está usted hablando con su colega de San Francisco.

De todo esto pueden extraerse muchas conclusiones, pero yo prefiero quedarme con una que ya se ha comentado por aquí, y es que no se puede basar la seguridad de un programa/algoritmo/protocolo y/o servicio en el oscurantismo; todos los proyectos de software libre que versan sobre VoIP (ekiga, OpenWengo, KPhone, etc) han dicho ya que van a modificar sus fuentes para evitar este tipo de ataques; skype todavía no ha dicho nada (hasta donde yo sé), aunque ni siquiera si todo esto va con él o no; es posible que este tipo de ataques no le influyan para nada, pero no lo sabremos nunca, su protocolo nunca ha sido hecho público al igual que sus aplicaciones.

Yo, a título personal, y en cuestiones de cifrado, no pienso dejar en manos de una no pienso dejar en manos de una implementación cerrada y propietaria la responsabilidad de mi seguridad; por esas mismas razones uso ahora GPG, libre y gratuito, y dejé de utilizar PGP allá por la versión 6.5.8.

Cosas del Software Libre. :-)

Malas prácticas, directamente.

23 de junio de 2008 Por

malas_practicas.jpg

Gracias a Patricia por el enlace.

Domótica sí, pero con calma…

20 de junio de 2008 Por

Ayer salió publicada en varios medios electrónicos la noticia de una cafetera que se puede conectar a Internet y que, ¡oh sorpresa!, tiene una vulnerabilidad que permite “hackear” la cafetera, y hacerle maldades como…

– Cambiar la presión del agua para conseguir un café mas fuerte o más “aguachirli”.
– Cambiar la cantidad de agua por taza, para producir “spressos” o tazones.
– Realizar cambios más profundos que hagan que nuestra cafetera tenga que acudir al servicio técnico.

Parece ser que, para colmo, y esto ya puede ser algo más serio (aunque lo del servicio técnico puede ser una broma de mal gusto) también se pueden utilizar alguna de esas vulnerabilidades para atacar máquinas con Windows XP que estén en el mismo segmento de Red.

[Read more…]

Niveles y medidas de seguridad

18 de junio de 2008 Por

Seguimos a vueltas con la LOPD, que es de lo que me gusta hablar. Quizá por eso no tengo amigos… Bueno, pelillos a la mar, nosotros a lo nuestro.

Hoy quería aclarar una confusión que habitualmente existe —o existía— en relación con los niveles de seguridad de los tratamientos que se declaran a la AEPD y las medidas de seguridad que hay que aplicar a los datos que integran dichos ficheros. Aclaremos, aunque no creo que sea necesario, que cuando hablamos de “Fichero” o “Tratamiento” no lo hacemos en un sentido lógico del término, sino en un sentido más bien conceptual; tal y como indica el RD 1720/2007, un “fichero” es, según el artículo 5:

k) Fichero: Todo conjunto organizado de datos de carácter personal, que permita el acceso a los datos con arreglo a criterios determinados, cualquiera que fuere la forma o modalidad de su creación, almacenamiento, organización y acceso.

Por tanto, un tratamiento denominado “Recursos Humanos” podrá estar formado, por ejemplo, por una base de datos, un par de documentos ofimáticos, y una carpeta de expedientes en soporte papel.

[Read more…]

Alan Turing

14 de junio de 2008 Por

El pasado día 7 fue el aniversario de la muerte de Alan Turing (1912-1954), sin duda uno de los mejores criptógrafos de la historia, y padre de la informática teórica que aún hoy se estudia en las universidades de todo el mundo (¿quién no recuerda la máquina de Turing y las pesadillas que ésta ha generado en muchos estudiantes de Informática, entre los que me incluyo?).

Sin duda, dos bombas marcaron el desarrollo de la Segunda Guerra Mundial: la bomba atómica (obvia y desgraciadamente conocida por todos) y la bombe de Turing, una máquina desarrollada en el famoso Bletchley Park británico, vital para romper los mensajes cifrados alemanes. Esta máquina, desarrollada por Alan Turing y mejorada por Gordon Welchman, permitió a los aliados descifrar el tráfico de las diferentes fuerzas y servicios alemanes (marina, tierra, aire…) sin que éstos fueran conscientes de que la seguridad de sus comunicaciones estaba rota, lo que permitió obtener información decisiva para el desenlace final de la Guerra.

Turing fue procesado por homosexual en 1952; esto, que hoy parece impensable para nosotros, truncó la brillante carrera del británico. Dos años después, moría por ingestión de cianuro: todo indica que Turing se suicidó comiendo una manzana envenenada. De esta forma, finalizaba su vida y comenzaba el mito del gran científico, aunque los homenajes y reconocimientos públicos han sido escasos y en muchas ocasiones tardíos; quizás el más conocido en el “mundillo” en el que nos movemos es el premio Turing —considerado el Nobel de la Informática—, otorgado desde 1.966 por la ACM a quienes hayan contribuido de manera trascendental al campo de las ciencias computacionales.

Sirva este humilde post para recordar al que sin duda fue uno de los mejores científicos del pasado siglo, y quizás uno de los menos conocidos fuera del ámbito de las matemáticas, la informática o la criptografía.