Demo de ataque DNS y troyanización

31 de julio de 2008 Por

En relación con la vulnerabilidad del DNS que les comentábamos el otro día, les traemos un video de demostración de cómo aprovechar la vulnerabilidad del DNS descubierta recientemente para provocar una intrusión en un sistema, aprovechando los servicios de actualización automática:

http://www.infobyte.com.ar/demo/evilgrade.htm

Para los que se pierdan un poco, lo que Francisco Amato (Infobyte) hace primero es realizar un ataque Kaminsky para envenenar la cache del DNS utilizado por la víctima para que java.sun.com resuelva a la dirección de su equipo.

Una vez hecho esto, lanza el servicio evilgrade, que emula el servicio de actualización de la máquina virtual de Java, por lo que cuando desde el equipo víctima se pretende realizar la actualización, la solicita al servidor malicioso en lugar de hacerlo al original de Sun, con lo que evilgrade contesta con un paquete de actualización que es ejecutado por la máquina víctima, ejecutando un “Remote Shell” mediante el cual se consigue acceso al equipo.

Como prueba de la intrusión, Amato deja en el escritorio un fichero de texto con la palabra “Owned” para constatar que el equipo ha sufrido una intrusión.

Como curiosidad, y para remarcar la seriedad del problema, el propio creador de la Metasploit Framework ha sufrido un envenanamiento de la web www.google.com debido a que el DNS de su proveedor (AT&T) no estaba parcheado correctamente (como, podría añadir, seguramente todos los de los principales proveedores de Internet, nacionales e internacionales).

Nada más. Sigan temblando :P

“Eso no va conmigo”

29 de julio de 2008 Por

Siempre que abordarmos un proyecto de auditoría de ISO 27002 o la implantación de un SGSI nos sigue sorprendiendo la actitud de ciertos directivos, que presionados por la urgencia del día a día, y por el seguimiento de indicadores puramente productivos, digamos que no contemplan (por no decir que desestiman o dejan de lado, que queda más feo) los riesgos a los que sus procesos de negocio se encuentran expuestos desde el punto de vista de la seguridad. Para ser justos, también nos encontramos con gerencias que están preocupadas por estos aspectos, o que ven por ejemplo —como siempre recalcamos en este tipo de proyectos— la viabilidad de trasladar las medidas de seguridad que se implantan para tratar datos de carácter personal al resto de la información que tratan sus organizaciones, y que a fin de cuentas es la que de verdad es importante para ellos desde el punto de vista del negocio. Pero insisto, todavía son “los menos”.

Si me permiten la expresión, a veces “se me pone la carne de gallina” cuando detectamos las barbaridades que en algunos casos se cometen gestionando esta información, y estoy hablando de grandes organizaciones, no de PYMES: envíos de documentos confidenciales a través de cuentas de webmail (Hotmail, Yahoo!, Gmail, etc.) porque el servidor de correo corporativo tiene una limitación en los ficheros anexados, redes corporativas —con acceso por parte de proveedores externos— sin segmentar, inexistencia de acuerdos de confidencialidad firmados con terceros, etc.

Incluso en el ámbito de auditorías de seguridad lógica comprobamos que sí, efectivamente, la empresa dispone de un IDS, pero que simplemente está “dejado caer”, sin que se haya configurado adecuadamente, o sin que nadie esté dando aunque sea un vistazo a las alertas que se puedan estar generando. O que cuando lanzamos las auditorías automáticas de vulnerabilidades, nadie (ya sea el departamento de sistemas o la empresa externa que dice estar gestionando la seguridad de la red auditada) detecta el aluvión de escaneos de puertos. Y no voy a entrar en el apartado de las medidas de seguridad de los CPDs, en la ausencia de control en el acceso a la información en soporte papel en salas de archivo de uso compartido, o en el espeluznante capítulo de la información confidencial en equipos portátiles, que tan acertadamente describió nuestro compañero Alberto Rivas.

Parece ser que esos riesgos no van con ellos; aparentan creer (por los hechos los conocerás, que decía aquél) que la información de su negocio no le interesa a nadie. Por desgracia, las cosas no son exactamente así, y siempre hay gente interesada en tu información.

Y esta es una PYME.

Vulnerabilidad en DNS “disclosed”

24 de julio de 2008 Por

Si nos siguen regularmente, sabrán que solemos dejar un par de días, como poco, entre entrada y entrada. Lunes, miércoles y viernes suele ser la periodicidad que personalmente más me gusta. Pero hay ocasiones, como esta, en las que las circunstancias imponen un cambio de planes. Ni que decir tiene que para aquellos que no la leyeron ayer, les recomiendo que le echen primero un vistazo a la entrada anterior, sumamente interesante y un fiel reflejo de la seguridad de las organizaciones y los riegos de carácter práctico que implica la movilidad y la portabilidad, tanto a nivel de datos de carácter personal como de cualquier otro tipo.

Pasemos ahora a eso que ha alterado el orden natural de publicación y hará que este viernes no vaya a haber ninguna entrada. Ya tienen bastante con lo que tienen, hasta la semana que viene.

Empecemos con una pequeña introducción. Hace unas semanas, tal y como avisamos aquí mismo, Dan Kaminsky informaba de un peligroso problema de seguridad en el servicio de DNS; no creo que nadie necesite que le explique para qué sirve el DNS, ni de cuál es su criticidad en el marco de Internet. El problema era de una importancia tal que dió de plazo aproximadamente un mes para desvelar los detalles técnicos del problema, hasta el 6 de agosto, en la conferencia que daría en Black Hat, tiempo que los proveedores deberían aprovechar para parchear sus sistemas. Cosa que la mayoría de grandes proveedores no han hecho, todo sea dicho.

Hace un par de días, Halvar Flake se puso a especular sobre el problema. Y parece que se acercó bastante. Ese mismo día, la gente de Matasano publicó en su blog una interesante entrada en su blog, dando muchos detalles sobre la vulnerabilidad, y violando —al parecer— el acuerdo que habían alcanzado con Dan Kaminsky. Aunque eliminaron la entrada y pidieron disculpas, Internet no olvida, y su entrada se encuentra tanto en Google, como en otros blogs, en Slashdot, PC World ya ha hablado de ello y vayan ustedes a saber dónde o quién más. En otras palabras, el problema es casi oficialmente de carácter público y es probable (aunque no seguro) que Dan Kaminsky aclare finalmente los detalles.

La explicación que les voy a dar no pretende ser técnicamente profunda, pero espero que les sea suficiente; por supuesto, si detectan algún error, hagánmelo saber. Seguiré básicamente, pero no al pie de la letra, los pasos que Matasano describía en su entrada. Como conceptos básicos, deben conocer qué es un servidor DNS, y la estructura recursiva que el protocolo tiene. Si el servidor A no conoce la dirección IP para www.victim.com, preguntará a uno de mayor nivel, y así sucesivamente. Veamos ahora dos tipos de ataques clásicos sobre el DNS.

a) DNS Forgery. Este ataque se basa en hacer creer al servidor DNS que www.victim.com no tiene la IP 1.2.3.4, que es la legítima, sino que es 4.3.2.1, que en realidad apunta a www.evil.com. De este modo, cuando alguien le pregunte al servidor DNS por la IP de www.victim.com, éste devolverá la IP de www.evil.com. Imaginen ahora que www.victim.com es la web de un banco y www.evil.com reproduce fielmente su interfaz. Seguro que ven el problema.

La idea es la siguiente. Cuando Pepe pide la dirección de www.victim.com, si su servidor DNS Pepe_DNS no tiene su dirección IP, preguntará a Alguien_DNS por dicha IP, y así recursivamente. Esa solicitud lleva asociado un query id (QID), que sirve para autenticar la respuesta. La intención del ataque es devolverle a Pepe_DNS la IP de www.evil.com como si fuese la de www.victim.com, antes de que el servidor DNS legítimo lo haga, con la gracia de que además, Pepe_DNS guardará esa dirección IP en caché durante un tiempo, por lo que muchas de las siguientes consultas devolverán la IP de www.evil.com.

Claro que para hacer eso, necesito saber el QID de la petición, o la respuesta será descartada. Antes, cuando los QIDs eran consecutivos, algo así podía resultar sencillo. Ahora los QIDs se generan aleatoriamente (¡vaya!). Imaginen ahora que puedo hacer que Pepe_DNS pida no una, sino 1000 veces la IP de www.victim.com; hay 1000 veces más QIDs, y sólo tengo que adivinar uno de ellos. Imaginemos además que empiezo a preguntarle a Pepe_DNS como resolver direcciones que controlo; podré acceder a los QIDs y eventualmente, con suerte y algo de tiempo, quizá consiga predecir la semilla de generación de los QIDs.

La solución básica para eso es lo que hace DJBDNS, que es combinar el QID con el puerto de petición del cliente DNS, con lo que aumentamos la seguridad de 16 bits a 32 bits, haciendo la cuestión de adivinar sensiblemente más complicada.

b) DNS RRset poisoning. Este ataque está basado en la estructura de los paquetes de respuesta del DNS. La idea es que en la respuesta que recibo del servidor, además de la información solicitada, existe una parte del paquete que puede contener información adicional “de interés”. Por ejemplo, si yo pregunto por www.evil.com, Pepe_DNS puede contestarme con la IP de www.evil.com y en el campo de “información de interés” darme la IP de www.victim.com, que por supuesto no es la IP legítima.

Claro que alguien se preguntará porqué podría alguien pedir la IP de www.evil.com. Imaginen que acceden a un blog, que tiene una imagen alojada en www.evil.com. Con sólo eso, ya estamos intentando resolver www.evil.com, y el resto ya lo saben. La solución a esto es muy sencilla, al menos en el nivel teórico: no hagas caso del campo “informacion de interés”, excepto si contiene información sobre el dominio sobre el que he preguntado; es decir, que si pregunto por www.evil.com, puede interesarme mail.evil.com, pero no mail.victim.com.

c) Pasemos finalmente al ataque de Dan Kaminsky, que está basado en una combinación de los dos anteriores ataques. Imaginemos que preguntamos por aaaaa.victim.com. Seguramente el servidor legítimo, que es más rápido, le conteste diciéndo que no existe tal dominio (NXDOMAIN). Sigamos intentándolo con aaaab.victim.com, con aaaac.victim.com, de manera recursiva, hasta que llegado un determinado punto, seremos más rápidos y conseguiremos que Pepe_DNS crea que xgsdty.victim.com tiene la dirección 4.3.2.1.

Claro que xgsdty.victim.com es una dirección inexistente, y aunque en la práctica tenemos un DNS “poisoned” (envenenado), no parece servir de mucho ya que nadie va a preguntar por la IP de xgsdty.victim.com. Pero ahora, mediante la técnia del segundo ataque descrito, podemos decirle a Pepe_DNS cuál es la IP de www.victim.com, incluyendo su dirección en la “información de interés”, que sí que nos aceptará por pertenecer al dominio victim.com.

Dicho de otra forma, se trata de conseguir que Pepe_DNS acepte como respuesta legítima una respuesta ilegítima de nivel 3 (xgsdty.victim.com), que aunque no sirva de nada, incluya información sobre la IP de otros dominios de nivel 3 (www.victim.com) del mismo dominio de nivel 2 (victim.com). Tomando un ejemplo más real, si consiguimos que el servidor acepte como válido un paquete que le dice que tazxvb.google.com tiene como IP 1.2.3.4, éste aceptará como válida cualquier información adicional sobre google.com: www.google.com, mail.google.com, etc.

Les dejo a ustedes sacar las conclusiones sobre qué pasaría si el DNS que habitualmente utilizan piensa que www.google.com tiene la IP de www.evil.com. Bien. Pues les adelanto que la mayoría de DNS son (aún) tristemente vulnerables (pueden comprobarlo en el blog de Dan Kaminsky). Ah. Y no saben lo peor, o lo más divertido, depende de su gusto por la ironía; que su DNS no sea vulnerable no significa que estén a salvo, gracias a la estructura jerárquica del servicio de DNS de Internet.

¿No les parece fascinante, y a la vez, un problema “de cagarse”? Nada más. Buen fin de semana a todos.

¿Seguridad o portabilidad?

23 de julio de 2008 Por

Hoy en día, los dispositivos móviles se han convertido en un medio tremendamente eficaz para acceder a la información desde cualquier lugar donde podamos necesitarla. Para sus usuarios, la facilidad de acceso independientemente del lugar donde nos encontremos, con el fin de aportar y utilizar la información en seminarios, reuniones, discusiones y negociaciones, para simplemente realizar trabajos durante tiempos muertos en viajes o durante periodos de ausencia de la oficina por otros motivos, así como la posibilidad de tener la oficina en casa, son simplemente herramientas imprescindibles cuando se realiza un trabajo que requiere permanente atención y disponibilidad personal.

Desde el punto de vista del empresario, la tecnología móvil es un medio de facilitar a sus empleados acceso a los datos de la compañía, tanto de negocio como de producto, que potencia de un modo notable las capacidades de negociación y decisión de aquellos. Sin embargo, es muy fácil ver las ventajas, pero resulta menos frecuente pensar en los inconvenientes y riesgos que tal tecnología aporta.

Consideren un Centro de Proceso de Datos. El empresario sabe cuán alto es el presupuesto que le dedica, y considera que es una inversión y un gasto cuyos retornos no siempre están claros o son fácilmente evaluables. No obstante, sí que suele ser consciente de que la seguridad de sus datos es algo como mínimo importante y que el acceso a esta información debe ser controlado y justificado: datos de negocio, de diseño de productos, de estrategias de mercado y desarrollo de la compañía son críticos para la supervivencia de ésta y por otra parte, cada día más, también la protección de los datos personales de sus empleados y colaboradores resulta ser importante, si no se quiere tener un incidente público y encontrarse frente a una fuerte multa y/o un problema de reputación.

Supongamos por tanto que la compañía en cuestión ha invertido un gran presupuesto en almacenamiento de datos, teniendo los sistemas protegidos con tecnologías RAID en los discos duros, haciendo “mirroring” sobre un sistema paralelo con procesador y copia de datos en línea, para dar continuidad a los procesos en caso de recuperación de desastres. Todo esto se encuentra en dos salas separadas y estancas, protegidas con medios de detección y extinción de incendios, protección contra invasión de aguas y gases, paredes y puertas resistentes al fuego, alarmas de intrusión lógica o física, control de accesos, etc. Además hay un sistema de cajas fuertes que guardan las copias de los datos realizadas diariamente. O sea, una fortuna cada mes.

Pues bien, toda esta tecnología y ese gasto mensual, además de la dedicación y el cuidado de un equipo de profesionales especializados en su explotación y control, se ven anulados de repente cuando un empleado hace una copia de datos a su sistema portátil —cuya necesidad no siempre está justificada—, sistema que muy frecuentemente carece de los medios adecuados de protección de la información copiada, creando así un nuevo riesgo en un ambiente externo a la seguridad de sistemas descrita. Esto tendrá como consecuencia la necesidad de un nuevo gasto en seguridad adicional que, por resultar engorrosa para el usuario no especializado, con mucha frecuencia acaba no utilizándose: contraseñas de arranque en BIOS, llaves con certificados digitales, controles biométricos, etc.

A lo largo de las auditorias se detectan de manera reiterada los mismos problemas en diferentes empresas, que aportan riesgos importantes e innecesarios a la información, y ponen en evidencia que la seguridad centralizada no es suficiente.

Por ejemplo. El ciclo de solicitud de un usuario para el acceso a la información suele incluir las firmas y autorizaciones necesarias para otorgar dicho acceso; no siempre se incluyen las funciones que un usuario puede ejecutar, pero al menos si suele incluirse a que bases de datos va a acceder. Una vez ganado el acceso, resulta fácil conseguir volcar una copia de los datos, bien por falta de impedimentos (controles técnicos u organizativos), bien por autorización “tácita” del administrador, que se dice a sí mismo que si tiene acceso autorizado, entonces es que debe poder —estar autorizado a— copiar los datos (tremendo error). En otros casos, el volcado está autorizado debidamente, pero una vez los datos están en los sistemas personales, copiar estos o “sincronizarlos” con una PDA o similar, que el administrador ni siquiera sabe que existe, es bastante más fácil. Con ello, alguien que trabaja con un acceso autorizado, acaba teniendo una copia propia de la información.

Estirando un poco del hilo, muy posiblemente la información acabará llegando a un dispositivo cuyo usuario no sabe que es eso del cifrado, ni le agrada la contraseña tan molesta para arrancar el sistema, ni tampoco es consciente de la cantidad de gente que trabaja vendiendo datos robados, o dicho de una forma más suave, procedentes “de fuentes desconocidas”. A todo esto, el responsable de los sistemas sin enterarse del problema y el empresario creyendo que tan alta factura mensual le asegura que sus datos están protegidos en casa.

Pues bien, aportando datos muy recientes se puede ver cuál es la realidad de esto que parece una exageración:

  • El Canal Historia (de pago) el domingo 20 de julio por la tarde, emite un documental sobre el espionaje. Sorprende saber que una compañía alemana de diseño de aerogeneradores, cuya eficiencia estaba muy por encima de sus competidores, fue denunciada por derechos de patentes cuando intentó comercializarlos en Estados Unidos. Había una empresa que tenía los mismos diseños y tecnología patentados allí. La investigación concluyó en que un grupo de expertos en espionaje industrial, ayudados por algunos empleados, habían copiado diseños y materiales y se habían adelantado en su fabricación y patente en USA. El resultado es que la compañía alemana tuvo que esperar diez años para entrar en el mercado americano y por supuesto hacer un expediente de regulación de empleo.
  • Última hora | EL PAIS | Internacional – 20-02-2008
    La policía brasileña investiga un posible espionaje industrial en Petrobras
    EFE
    «… en Río de Janeiro, Valdinho Jacinto Caetano, afirmó ayer en conferencia de prensa que los ladrones se apoderaron de uno de los cinco ordenadores portátiles que había en el contenedor y de las placas de memoria de otros dos.

    “En un robo común, la persona se lleva el ordenador entero para usarlo … lo que indica que sería espionaje industrial”, agregó. Pese a que ni la policía ni Petrobras han confirmado el contenido de las placas de memoria robadas, la prensa local afirmó que contenían datos geológicos de la cuenca marina de Santos, donde la petrolera descubrió un yacimiento de hidrocarburos …»

  • Última hora | EL PAIS | Internet – 18-07-2008
    Los portátiles robados son delatores
    EFE
    « Cientos de miles de ordenadores portátiles desaparecen cada año en EE UU, bien por robo o descuido. Sólo en los aeropuertos del país se pierden cada semana unos 10.000 aparatos, generalmente … en un estudio oficial.»
  • En uno de los periódicos de este fin de semana, las fuerzas aéreas americanas reconocen que en los últimos años les han robado algunos miles de PC’s (solo?).

Y así sucesivamente….. ¿Entonces, qué hacer? Las reglas no son difíciles de explicar pero son bastante difíciles de implementar:

  • Dar acceso a datos en lugar de dar copias de datos.
  • Minimizar accesos y copias.
  • Cuando las copias sean imprescindibles, resumir y seleccionar la información necesaria. Solicitar autorización para la copia y establecer un periodo tras el cual se destruya.
  • Si la información copiada es confidencial, cifrarla y proteger su acceso.
  • TODOS los dispositivos portátiles deberían tener una contraseña de arranque.
  • TODOS los programas de comunicación con otros dispositivos deberían estar protegidos con contraseñas.
  • La seguridad física de los dispositivos debería ser un motivo de incentivación, y la pérdida o robo por descuido un motivo de acción disciplinaria.
  • NUNCA un dispositivo portátil para uso profesional debe estar accesible a personas distintas del empleado (incluyendo la familia los amiguetes, etc).
  • Mantener un inventario de dispositivos autorizados y sus usuarios.
  • Hacer auditorías periódicas del contenido de los sistemas, en el momento que se conectan a la red.

Hay muchas mas reglas, pero la más básica es que la información solo debe almacenarse donde su seguridad esté garantizada. Y eso es todo por ahora. Seguiré dando el tostón.

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. :-)