¡Vacaciones!

Estimados lectores,

Como cualquier blog que se precie y como (casi) todo hijo de vecino, nosotros también nos largamos de vacaciones. Eso significa, entre otras cosas, que no habrá nada nuevo por estos lares hasta la primera semana de septiembre, cuando nos encontremos en plena depresión postvacacional, por lo que si nos siguen regularmente pueden ahorrarse la visita hasta entonces. El año pasado no cogimos vacaciones, pero este año toca; el sprint final de julio ha sido especialmente intenso (en realidad, para la mayoría de nosotros todavía no ha acabado), y septiembre promete mantener el mismo nivel. Más allá de que este blog sea colectivo y corporativo, lo admito: necesito unas vacaciones.

Puesto que sé que a todos ustedes les encanta seguir trabajando en vacaciones, y como Sandra Bullock en La Red, llevarse el portátil a la playa (hay pocas cosas menos sensatas, si uno se estima su portátil), les he traído un par de libros a raíz de una entrada en en el blog de Félix Haro. En estos momentos estoy leyendo uno de ellos y está resultando muy interesante; va en la línea de lo que ya hemos comentado alguna vez por aquí: ten cuidado con lo que dice Google de ti, o tú le dices, porque Google no olvida y no sabes quién puede llamar a su puerta dentro de unos años preguntando por ti.

Afortunadamente, no tendrán —si no quieren— que gastarse un euro, ya que está disponible en Internet gratis por la patilla, en la página personal de su autor Daniel J. Solove. El título es The future of reputation: gossip, rumor and privacy on the internet. Probablemente prefieran empezar por el anterior libro de este mismo autor, también disponible a través de su página web, The digital person. Technology and privacy in the information age, pero les dejo eso a su elección. Claro que ambos están en inglés, pero es inglés académico y eso no debería ser un problema.

Yo les recomendaría que se alejasen de cualquier dispositivo electrónico durante un tiempo, que es básicamente lo que tengo intención de hacer yo a partir de este viernes, pero allá ustedes. Al menos, para aquellos que no tienen vacaciones, espero que esos libros les ayuden a sobrevivir a este agosto.

Nada más. Como diría el bueno de Pedro Erquicia, les espero en septiembre, para contarles en profundidad las cosas que pasan a lectores como usted. Buenos días y felices vacaciones.

* * *

Me apunta José Selvi antes de colgar el cartel de “Cerrado por vacaciones” que dentro de un par de días tiene lugar la final del “Capture the Flag” de DEFCON, en la que participa el equipo español “Pandas with gambas” (su foto “de familia”), en la que que intentarán arrebatar el trofeo a los campeones de los dos últimos años, los veteranos 1@stPlace (su foto “de familia”, algo más seria).

Mucha suerte!

Vulnerabilidad en DNS “disclosed”

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.

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

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?

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…]

Malas prácticas, directamente.

malas_practicas.jpg

Gracias a Patricia por el enlace.

Niveles y medidas de seguridad

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…]

Share this (y dos)

Hace algo más de un par de semanas les comenté la resolución de la AEPD contra la empresa Iniciativas Virtuales. Aunque pueden leer el texto completo de la entrada, al igual que la resolución [pdf], la idea era que esta empresa ofrecía a sus usuarios registrados la opción de mandar “recomendaciones” a amigos, conocidos, familiares, etc., recomendándoles el servicio. Como suele ser habitual, existía un sistema de puntos que fomentaba las recomendaciones.

Lo primero que diré es que me ha sorprendido, cuando a mí me parece un caso “meridianamente” claro, la defensa que algunas personas hacen de esta iniciativa, argumentándose en aspectos más bien etéreos como que en el correo electrónico no se indica que éste sea publicidad (¿es eso necesario?), o que la voluntad de emitir el correo no procede de la propia empresa sino de un particular (o eso parece ser). Y esa es básicamente toda la defensa que en mi opinión se puede hacer de la actividad denunciada. Sin embargo, creo que es obvio que asumir como válidas cualquiera de estas razones abre la puerta de la impunidad al spam. Como resulta evidente, yo sí estoy de acuerdo con la multa impuesta, por las siguientes razones, ordenadas de manera aleatoria:

1) Tal y como indicó Félix Haro en su entrada sobre la resolución, y como se indica en ésta, la empresa no tiene medio de contactar con el particular que al parecer envía el correo, y que sería en su caso el responsable último (o co-responsable, dado el beneficio económico del “recomendador” y el “recomendado”). Yo no voy a entrar en cuestiones de estrategia comercial (si personalizas los mensajes con los datos que tus usuarios han consentido en darte, es posible que sus amigos se sientan más dispuestos a aceptar sus “invitaciones”), sino en el hecho de que realmente, nadie parece saber quién es dicho usuario (calidad del dato, ¿anyone?). La empresa no lo sabe, el usuario que recibe el correo no lo sabe, y por tanto, es normal que la responsabilidad acaba recayendo sobre la empresa.

De la misma forma que la responsabilidad de que tu coche vaya a 200 km/h un viernes por la noche recae sobre tí si no eres capaz de identificar al conductor. Más allá de leyes y regulaciones concretas, y esto es una opinión completamente personal, me parece una cuestión de sentido común y evitar el “mangoneo”, la picaresca y la impunidad al cometer ciertos delitos.

2) Las infraestructuras y desarrollos los pone la empresa a disposición del usuario “recomendador” con el único propósito de mandar correos comerciales, cuyo texto está ya predefinido: “¡Hola!, este es un mensaje de tu amigo Internauta 123, que está disfrutando de las ventajas de …Y…, y te manda este mensaje” (de la resolución: “lo único que han de hacer [los usuarios] es reenviar el propio correo comercial de Iniciativas Virtuales utilizando incluso la misma IP de la entidad”). No creo que Gmail o Yahoo, aún pudiendo ser utilizadas para el envío de spam, pudieran ser comparadas con este sistema de propósito único, y no encuentro muchas otras razones que la comercial.

3) El correo que recibe el “amigo” contiene un botón que enlaza con la página de la empresa; sí eso no es un reclamo comercial, no sé lo que es.

4) El correo que recibe el “amigo” incluye la posibilidad de no seguir recibiendo publicidad, lo que a) deja bien claro que se trata de una comunicación de publicidad, y b) hace sospechar que el e-mail de dicha persona está siendo tratado, y que incluso es posible que sea receptor de futuras comunicaciones comerciales. No se me ocurre ninguna otra razón por la que alguien podría ofrecer dicha publicidad.

Imagino que hay más, pero a bote pronto se me ocurren esas. Pensando bien, es muy posible que la empresa no fuese la responsable directa del envío comercial, pero por supuesto es la promotora, responsable indirecta y parte interesada en el proceso, de eso no tengo ninguna duda. Y pensando mal, la empresa está intentando aprovechar una laguna legal (de las que la AEPD tiene unas cuantas, sobre todo en aspectos interpretativos) para sacar un rédito económico y comercial. En ambos casos, hay una razón suficiente para calificar la comunicación como comercial y por tanto, ser susceptible de sanción.

Estirando un poco este caso, ¿qué pasa entonces con los sistemas de recomendación de, por ejemplo, los periódicos digitales y/o blogs (con publicidad en forma de banners o Adwords)? Sin ir más lejos, ElPaís.com permite enviar una noticia cualquiera a un amigo, sin más que proporcionar la dirección de correo electrónico del destinatario, y sin que exista ningún tipo de control sobre éste o la identidad del remitente; afortunadamente no hay signos de que exista algún tipo de tratamiento o almacenamiento de las direcciones proporcionadas. No obstante, también en este caso las infraestructuras son proporcionadas por el periódico digital, y me llama la atención que el correo no incluye la noticia, sino un enlace a la página de ElPaís.com, lo que apunta a una motivación más comercial que informativa (ya que en la página existe visualización de banners o registro de tráfico, por ejemplo). Y sí, aunque dicha motivación sea más difusa que en el caso de Iniciativas Virtuales, existe. ¿Qué opinan ustedes?

ISO/IEC 27005:2008

Me informa un compañero de que el pasado miércoles se publicó, tras muchas esperas, el que viene a ser el estándar ISO de Gestión de Riesgos de Seguridad de la Información. Esto es, la ISO/IEC 27005:2008, Information technology – Security techniques – Information security risk management. Algo que quizá traiga algo de estandarización a un área con tanta metodología dispar, y quizá no, pero que sin duda será un punto a tener en cuenta.

En cualquier caso, como saben las normas ISO son de pago, por lo que si quieren echarle un vistazo, van a tener que soltar algo de dinero. El texto de la norma pueden comprarlo en la página oficial ISO correspondiente.

(Por cierto, tengo pendiente mi opinión personal sobre la entrada del otro día (la resolución de la AEPD sobre los sistemas de “Envía esto a un amigo”, que les traeré en breve. No piensen que se me ha olvidado.)

Violencia de género: nivel alto (aunque no lo parezca)

No sé si han visto el telediario de Telecinco de esta mediodía. Si no ha sido así, y a falta de mayores investigaciones por parte de la AEPD y quien corresponda, el tema es para alucinar; ya verán como me dan la razón. Lo que más me ha llamado la atención era lo “normal” que parecía que algo así hubiese sucedido, como si aquello no fuese realmente con nadie (el video no incluye algunas de las entrevistas realizadas). Les anticipio un párrafo de la noticia (que es de ayer):

El equipo de ‘Reporteros’ de Informativos Telecinco ha localizado en las inmediaciones de los juzgados de violencia de género en Madrid seis bolsas con copias de expedientes en perfecto estado de denuncias de maltrato por parte de mujeres. Dichos documentos incluyen nombres de víctimas y agresores, informes médicos y psicológicos, diligencias originales, declaraciones de las víctimas, fotocopias de sus documentos de identidad e, incluso, sus domicilios impresos en solicitudes de órdenes de alejamiento.

En fin, disfruten con el video e intenten calcular qué repercusión económica y reputacional, entre otras, podría tener para una empresa privada algo de semejante magnitud:

Share this

Me gustaría pedirles su opinión sobre una resolución de la AEPD que he visto ya en varias páginas webs [Miguel ?ngel Mata, Félix Haro], la PS/00323/2007, y que puede sentar un bonito precedente en los típicos sistemas de “Envía/recomienda esta página a un amigo”. Ya sé que no es precisamente una novedad, pero creo que es muy interesante. Aunque los detalles concretos están en la resolución indicada, la cuestión es la siguiente:

La empresa Iniciativas Virtuales, dedicada a servicios de publicidad y marketing web, tiene un servicio que pone a disposición de los usuarios previamente registrados un sistema de recomendación a través del que enviar a tus familiares o amigos un correo ya confeccionado por Iniciativas Virtuales, a modo de invitación al servicio:

¡Hola!, este es un mensaje de tu amigo Internauta 123, que está disfrutando de las ventajas de… Y…, y te manda este mensaje.

Básicamente, y aunque esto es ajeno a la resolución, el servicio se basa en la recepción de publicidad y realización de encuestas comerciales por parte de los usuarios registrados, que son remunerados en función del volumen de publicidad recibido y encuestas realizadas. Es significativo indicar que el servicio, como suele ser habitual, dispone de un sistema de puntos que fomenta las recomendaciones: si yo te recomiendo el servicio y tú te apuntas, yo salgo beneficiado, por lo que me interesa “difundir” el servicio lo máximo posible.

Entonces, el usuario YYY (del que la empresa Iniciativas Virtuales sólo posee una dirección de e-mail y no es capaz de identificar) recomienda el servicio al usuario AAA a través de dicho sistema, y éste, al recibir la invitación, decide formular denuncia ante la AEPD por recibir publicidad no solicitada ni consentida. Ésta resuelve el caso con una sanción de 600 euros, entendiendo que efectivamente se trata de una acción comercial no solicitada, a pesar de que, tal y como Iniciativas Virtuales defiende, la iniciativa de enviar dicho e-mail no es suya sino del usuario particular YYY (que, aunque no lo diga, busca crear afiliados para incrementar sus puntos).

¿Qué piensan ustedes de esta resolución? ¿Es correcta?

Mí opinión se la diré en un próximo post, pero es interesante, sea cual sea su decisión, pensar cómo se aplica esta resolución al “Envía a un amigo” que hay en muchos blogs personales que contienen publicidad Adsense, y por tanto se benefician directamente del incremento del número de visitas, además del beneficio que indirectamente recibe el proveedor del blog.