Portada
mis comunidades
otras secciones
![Descubierto problema que podría permitir identificar servidores en TOR [ENG]](https://cdn.mnmstatic.net/cache/27/36/media_thumb_2x-link-2569872.jpeg?1456143786)
#11:
#10 De remoto no tiene nada
Te paso algunas referencias:
Paper del 2006 sobre el tema, super interesante:
http://sec.cs.ucl.ac.uk/users/smurdoch/papers/ccs06hotornot.pdf
Por si el paper es muy denso (no lo es), te pego aquí partes interesantes de el mismo:
Kohno et al. [24] used timing information from a remote
computer to fingerprint its physical identity. By examining
timestamps from the machine they estimated its clock skew:
the ratio between actual and nominal clock frequencies.
They found that a particular machine’s clock skew deviates
very little over time, around 1–2 parts per million
(ppm), depending on operating system, but that there was a
significant difference between the clock skews (up to 50 ppm)
of different machines, even identical models. This allows a
host’s clock skew to act as a fingerprint, linking repeated observations
of timing information. The paper estimates that,
assuming a stability of 1 ppm, 4–6 bits of information on the
host’s identity can be extracted
PoC relacionado con el paper:
https://gitlab.com/snippets/11402
La identificación a través del clock skew es algo que se ha estudiado, investigado, implementado y utilizado in the wild.
Se que os parece increíble, pero el juego del gato y el ratón que están jugando entre tor y la NSA va mucho mas lejos que descubrir tu IP. Han revelado identidiades de usuarios de TOR usando Machine Learning por el tiempo que pasa entre sus clicks en un texto determinado con hyperenlaces. Dicho esto, detectar el clock skew es un vector muy muy grande en un contexto como el que estamos hablando.
Lo que intento ilustrar con esto no es la importancia de este ataque en concreto, sino explicar la magnitud de todo esto, a los niveles a los que ha llegado la lucha por mantener el anonimato y como cosas mucho, mucho mas pequeñas que estas, son consideradas hoy en día una amenaza a tu privacidad: por ejemplo, tor browser te sugiere que no maximices la ventana del navegador para que no te identifiquen con tu resolución.
Entiendo que para un informático normal, lo que está pensando es que un bug es aquello que revela tu actual dirección de internet (i.e. IPV4 o similar), pero en la lucha por la privacidad del usuario, eso es solo la punta del iceberg, y los ataques reales que han hecho organismos como el FBI, como el de padding de protocolos, son MUCHO mas rebuscados y complejos, y terminan por identificar inequivocamente a una persona u organización, usando modelos estadisticos que correlacionan muchas de estas pequeñas fugas de información.
Te paso algunas referencias:
Paper del 2006 sobre el tema, super interesante:
http://sec.cs.ucl.ac.uk/users/smurdoch/papers/ccs06hotornot.pdf
Por si el paper es muy denso (no lo es), te pego aquí partes interesantes de el mismo:
Kohno et al. [24] used timing information from a remote
computer to fingerprint its physical identity. By examining
timestamps from the machine they estimated its clock skew:
the ratio between actual and nominal clock frequencies.
They found that a particular machine’s clock skew deviates
very little over time, around 1–2 parts per million
(ppm), depending on operating system, but that there was a
significant difference between the clock skews (up to 50 ppm)
of different machines, even identical models. This allows a
host’s clock skew to act as a fingerprint, linking repeated observations
of timing information. The paper estimates that,
assuming a stability of 1 ppm, 4–6 bits of information on the
host’s identity can be extracted
PoC relacionado con el paper:
https://gitlab.com/snippets/11402
La identificación a través del clock skew es algo que se ha estudiado, investigado, implementado y utilizado in the wild.
Se que os parece increíble, pero el juego del gato y el ratón que están jugando entre tor y la NSA va mucho mas lejos que descubrir tu IP. Han revelado identidiades de usuarios de TOR usando Machine Learning por el tiempo que pasa entre sus clicks en un texto determinado con hyperenlaces. Dicho esto, detectar el clock skew es un vector muy muy grande en un contexto como el que estamos hablando.
Lo que intento ilustrar con esto no es la importancia de este ataque en concreto, sino explicar la magnitud de todo esto, a los niveles a los que ha llegado la lucha por mantener el anonimato y como cosas mucho, mucho mas pequeñas que estas, son consideradas hoy en día una amenaza a tu privacidad: por ejemplo, tor browser te sugiere que no maximices la ventana del navegador para que no te identifiquen con tu resolución.
Entiendo que para un informático normal, lo que está pensando es que un bug es aquello que revela tu actual dirección de internet (i.e. IPV4 o similar), pero en la lucha por la privacidad del usuario, eso es solo la punta del iceberg, y los ataques reales que han hecho organismos como el FBI, como el de padding de protocolos, son MUCHO mas rebuscados y complejos, y terminan por identificar inequivocamente a una persona u organización, usando modelos estadisticos que correlacionan muchas de estas pequeñas fugas de información.
#7:
#4 Una franja horaria aparte ni siquiera te da suficientemente información para identificar el país donde esta en la mayor parte de los casos.
El título no dice lo contrario, de hecho erstoy de acuerdo con todo lo que dices, es tal y como lo explica el artículo y no veo que el título induzca a pensar lo contrario.
La realidad es que esto ha generado un debate interesante, tanto en hacker news, como en reddit netsec como en la mailing list de tor-onion. Este debate existe no por que sea un problema que vaya a revelar la identidad de todo tor, sino por que es un detalle poco conocido, que no se sabe aún a ciencia cierta a cuantos hidden services afecta (en mis experimentos a muchos) y que en muchos casos proporciona una información adicional sobre el servicio.
Además de revelear la zona horaria del servidor, que en el caso de los hidden services no es poco, revela el clock skew (error de reloj) de un servidor, lo cual es una huella bastante interesante para reconocerlo en el futuro o en el internet normal, fuera de tor.
El título no dice lo contrario, de hecho erstoy de acuerdo con todo lo que dices, es tal y como lo explica el artículo y no veo que el título induzca a pensar lo contrario.
La realidad es que esto ha generado un debate interesante, tanto en hacker news, como en reddit netsec como en la mailing list de tor-onion. Este debate existe no por que sea un problema que vaya a revelar la identidad de todo tor, sino por que es un detalle poco conocido, que no se sabe aún a ciencia cierta a cuantos hidden services afecta (en mis experimentos a muchos) y que en muchos casos proporciona una información adicional sobre el servicio.
Además de revelear la zona horaria del servidor, que en el caso de los hidden services no es poco, revela el clock skew (error de reloj) de un servidor, lo cual es una huella bastante interesante para reconocerlo en el futuro o en el internet normal, fuera de tor.
#1:
Ufffff... ni Linux, ni Tor, ni leches. Yo me piro a Windows, que al menos no me intentan engañar diciéndome que mi privacidad está asegurada.
Comentarios
#10 De remoto no tiene nada
Te paso algunas referencias:
Paper del 2006 sobre el tema, super interesante:
http://sec.cs.ucl.ac.uk/users/smurdoch/papers/ccs06hotornot.pdf
Por si el paper es muy denso (no lo es), te pego aquí partes interesantes de el mismo:
Kohno et al. [24] used timing information from a remote
computer to fingerprint its physical identity. By examining
timestamps from the machine they estimated its clock skew:
the ratio between actual and nominal clock frequencies.
They found that a particular machine’s clock skew deviates
very little over time, around 1–2 parts per million
(ppm), depending on operating system, but that there was a
significant difference between the clock skews (up to 50 ppm)
of different machines, even identical models. This allows a
host’s clock skew to act as a fingerprint, linking repeated observations
of timing information. The paper estimates that,
assuming a stability of 1 ppm, 4–6 bits of information on the
host’s identity can be extracted
PoC relacionado con el paper:
https://gitlab.com/snippets/11402
La identificación a través del clock skew es algo que se ha estudiado, investigado, implementado y utilizado in the wild.
Se que os parece increíble, pero el juego del gato y el ratón que están jugando entre tor y la NSA va mucho mas lejos que descubrir tu IP. Han revelado identidiades de usuarios de TOR usando Machine Learning por el tiempo que pasa entre sus clicks en un texto determinado con hyperenlaces. Dicho esto, detectar el clock skew es un vector muy muy grande en un contexto como el que estamos hablando.
Lo que intento ilustrar con esto no es la importancia de este ataque en concreto, sino explicar la magnitud de todo esto, a los niveles a los que ha llegado la lucha por mantener el anonimato y como cosas mucho, mucho mas pequeñas que estas, son consideradas hoy en día una amenaza a tu privacidad: por ejemplo, tor browser te sugiere que no maximices la ventana del navegador para que no te identifiquen con tu resolución.
Entiendo que para un informático normal, lo que está pensando es que un bug es aquello que revela tu actual dirección de internet (i.e. IPV4 o similar), pero en la lucha por la privacidad del usuario, eso es solo la punta del iceberg, y los ataques reales que han hecho organismos como el FBI, como el de padding de protocolos, son MUCHO mas rebuscados y complejos, y terminan por identificar inequivocamente a una persona u organización, usando modelos estadisticos que correlacionan muchas de estas pequeñas fugas de información.
Ufffff... ni Linux, ni Tor, ni leches. Yo me piro a Windows, que al menos no me intentan engañar diciéndome que mi privacidad está asegurada.
#1 sí te lo dicen.
#6 No solo te lo dicen, sino que te lo hacen Aceptar, Aceptar, Siguiente, Siguiente, Aceptar.
#1 A veces entro a Menéame solo para reírme...
#1 Yo creo que me voy a construir mi propio sistema operativo y navegador!
#1 en realidad con conectarte a meneame a buscar un poco de atencion te sirve cualquier cosa.
El problema no solo afecta a TOR, en realidad lo de "geolocalizar" por desfase horario también afecta a las VPN de toda la vida
@2366896
#9 Si, de hecho, como ya han apuntado varios expertos en los comentarios del artículo, la identificación por desfase horario es un ataque conocido y utilizado, y en todo caso esto es un vector adicional con el que obtener información de la hora en aquellos servicios donde se hayan prevenido otras conocidas fuentes de tiempo.
Al parece solo afecta a windows, según se está viendo. Hay alguna implementación de gzip muy extendida para windows que no respeta el formato gzip y usa tiempos locales en lugar de tiempos universales en la cabecera MTIME del gzip.
#14 No está tan lejos: una vez leí un 'relato' acerca de cómo se descubrió la ubicación de Bin Ladem a partir de unas rocas que salían al fondo de una foto que se hizo, el muy pendejo.
Hay gente muy 'imaginativa' por el mundo.
Voto positiffo por el curro de #0 y por hacerme caer una lagrimita al recordar el silk road
Bastante sensacionalista el titulo, solo PODRÍA identificar la franja horaria del servidor y en un 10% de los casos por que la mayoria de servidores no incluyen esa información (segun el articulo)
Una franja horaria aparte ni siquiera te da suficientemente información para identificar el país donde esta en la mayor parte de los casos.
#4 Una franja horaria aparte ni siquiera te da suficientemente información para identificar el país donde esta en la mayor parte de los casos.
El título no dice lo contrario, de hecho erstoy de acuerdo con todo lo que dices, es tal y como lo explica el artículo y no veo que el título induzca a pensar lo contrario.
La realidad es que esto ha generado un debate interesante, tanto en hacker news, como en reddit netsec como en la mailing list de tor-onion. Este debate existe no por que sea un problema que vaya a revelar la identidad de todo tor, sino por que es un detalle poco conocido, que no se sabe aún a ciencia cierta a cuantos hidden services afecta (en mis experimentos a muchos) y que en muchos casos proporciona una información adicional sobre el servicio.
Además de revelear la zona horaria del servidor, que en el caso de los hidden services no es poco, revela el clock skew (error de reloj) de un servidor, lo cual es una huella bastante interesante para reconocerlo en el futuro o en el internet normal, fuera de tor.
#7 Yo creo que el titulo si es un poco exagerado.
Y ciertamente es un problema, cualquier cosa que revele algo de información de algo que supuestamente pretende ser totalmente anónimo es un problema. Eso si me parece un problema poco relevante.
No se como puedas sacar una huella del reloj de una conexión que fuera relevante, hay muchos factores en una conexión como para que te valga de algo la hora que llega en una conexión o en varias conexiones con varias horas de referencia, no veo posible sacar ningun huella de eso, y más siendo la conexión comprimida y cifrada que añade aleatoriedad a la generación de paquetes.
Me suena a pajas mentales que se están montando por esos sitios para sacar remotas posibilidades de explotar el tema pero sin nada claro.
#4 "Franja horaria + idioma" sí pueden ser suficientes para identificar el país. Por ejemplo: "farsí + franja de Irán" vs. "farsí + franja de Nueva York".
No significa que vaya a ser suficiente en todos los casos, pero basta con que lo sea en unos cuantos para que ya sea un problema.
Ya que estamos, un motivo más para que todos los servidores funcionen en UTC, sin franjas horarias.
Teorema del Podría (versión mnm):
Todo enlace subido a Menéame, en cuyo titular aparezca un podría o derivados, su credibilidad será puesta en duda directamente proporcional al número de comentarios de meneantes que se percaten de dicho podría.
#3 Lo que viene a decir es que te da la hora y la fecha del sistema donde se ha comprimido, pero de ahí a que esos datos sean útiles para averiguar la identidad de un servidor...
Después de mirarlo un poco mas, parece que la vulnerabilidad afecta exclusivamente a Windows, bastante curioso.
#26 el problema es que nunca se ha dicho que sea algo general. Cuando publiqué la nota ya decía desde el primer momento que solo afectaba al 10% de servidores como mucho.
Realmente ha pedido haber malentendidos pero si lees la noticia verás que nunca ha pretendido ser amarillista: mas bien todo lo contrario.
Quizás ha faltado remarcar más algunos puntos, también todo esto ha sucedido en un contexto: encuentro que esto está sucediendo in the wild, escribo la nota y la envío a la mailing list de tor y luego a netsec de reddit para aclarar que pasa.
De hecho yo no me esperaba que tuviese mucha repercusión, cuando la vi en hacker news me quede un poco asombrado.
Creo que lo que ha pasado es que el hecho de que gzip mete fechas en las respuestas http comprimidas, sean fechas universales o locales es algo tan desconocido que ha generado muchas dudas: si lees netsec todo el jaleo era entorno al hecho de que gzip meta esos metadatos en si.
Ese asunto principalmente desconocido ha generado mucho interés, pero quiero dejar claro (y puedes leer el articulo) que nunca he dicho lo contrario y que yo nunca he pensado que afectase a todo el mundo: de hecho si lees el artículo verás que soy muy muy conservador, a diferencia de lo que dices tu.
El único problema es la entranilla, que con sus obvias limitaciones de longitud y de que lo lee todo el mundo, ha quedado como ha quedado, pero no considero que diga ninguna mentira ni sea demasiado pretenciosa ni amarillista. Tampoco considero que sea errónea.
#28 Te suena de algo la censura, por ejemplo?
El título induce a pensar que se podría identificar un servidor en TOR, cuando lo único que eventualmente se podría saber es la franja horaria.
Erronea.
Hace horas que en Hacker News le han explicado que se había flipado. Que no había ningún problema en el protocolo sino en la (una?) implementación de Microsoft.
La entradilla matiza un poco el post, pero erronea/sensacionalista.
https://tools.ietf.org/html/rfc1952
MTIME (Modification TIME)
This gives the most recent modification time of the original
file being compressed. The time is in Unix format, i.e.,
seconds since 00:00:00 GMT, Jan. 1, 1970. (Note that this
may cause problems for MS-DOS and other systems that use
local rather than Universal time.) If the compressed data
did not come from a file, MTIME is set to the time at which
compression started. MTIME = 0 means no time stamp is
available.
#20 Vamos a ver... pero si el problema se me ocurrio leyendo exactamente ese enlace
Es decir, desde el principio estaba claro que no había ningún problema con el "protocolo", mas bien con el formato. El formato gzip no expone tiempos locales.
Pero como siempre en seguridad, cuando existe una vulnerabilidad puede estar causada por un problema en el diseño o por un problema en la implementación. Es uno de los principios mas básicos y mas antiguos de la seguridad.
El problema que expongo es que leyendo esa especificación, leí también especificamente esto en la propia especificación:
Note that this may cause problems for MS-DOS and other systems that use local rather than Universal time.
Y me dió por pensar en los hidden services y me hice un pequeño PoC para probar rapidamente si todos los servidores devolvían la misma hora. Lo que yo esperaba ver, era que tal como dices, yo estaba equivocado y que vería la misma hora devuelta por todos los servidores, ya que en teoría usa horas universales.
Pues bien, con mi PoC en la mano me da por hacerme scripts que peinan google y va sacando las horas, y oh! sorpresa, NO son todas las horas universales.
¿Como puede ser, si estoy tan equivocado?
Pues resulta que algunas implementaciones, de hecho aún no se ha aclarado cuales por que requiere tiempo de hacer setup y pruebas, no respetan esa especificación y están devolviendo tiempos locales.
Entonces, me da por irme a tor, a mi lista de hidden services, y en unas pruebas rapidas empiezo a sacar horas locales de ALGUNOS de ellos.
¿Me explicas por favor como puede ser erronea si se basa en un resultado real de pruebas?
Yo ya conozco gzip alma de cantaro, lo conozco perfectamente, tanto que me he leído esa (a estas alturas odiosa) especificación 400 veces debido a mi trabajo en protocolos de escritorio remoto.
¿En que momento digo yo en todo el artículo que hay un problema en ningún protocolo?
¿En que momento digo yo en todo el artículo que hay un problema en gzip?
Y la mejor pregunta de todas...
¿Como puedo haberme "flipado" simplemente OBSERVANDO una realidad y explicando lo que VEO en un post?
Y aun mejor:
¿Si me he flipado y además es erronea, como puede ser que haya un PoC que me da la razón, que demuestra que lo que digo (ojo, lo que digo, lee bien lo que digo, no lo que crees que he dicho) es cierto?
Y aun mejor todavía:
¿Si esto que digo es tan rebuscado, inventado y flipado, como me explicas esto?: https://lists.torproject.org/pipermail/tor-onions/2016-February/000081.html
Donde, te cito textualmente:
"windowBits can also be greater than 15 for optional gzip encoding. Add
16 to windowBits to write a simple gzip header and trailer around the
compressed data instead of a zlib wrapper. The gzip header will have no
file name, no extra data, no comment, no modification time (set to zero), no
header crc, and the operating system will be set to 255 (unknown). If a
gzip stream is being written, strm->adler is a crc32 instead of an adler32."
En el proyecto tor se han preocupado activamente de rellenarlo con 0, por si acaso.
Todo esto por no hablar de los error de reloj que sirven para identificar servidores, pero como eso ya es muy rebuscado, pese a que hay un paper muy interesante que lo explica, mejor ya lo dejamos.
Entonces, en resumen:
1. La cabecera gzip incluye la fecha del servidor en formato universal? Si
2. Se puede usar la fecha de un servidor en formato universal para identificarlo? Si, con el error de reloj
3. algunas implementaciones de gzip incluyen la hora local en lugar de universal? Si
4. se pueden usar esas implementaciones para saber la hora local de un hidden service? Si
5. el articulo dice que haya algun error en un protocol o especificación? No
6. hay algun error en algun protocolo o especificacion? No, solo en algunas implementaciones que ponen en peligro a los hidden services que las utilicen
Me explicas por favor donde me he flipado o donde está el error?
#21 Con "protocolo" me refería al HTTP, que no tiene ningún leak per se. Con "haberse flipado" y "erronea" me refería a que no se puede generalizar que hay un leak en HTTP+GZIP, sino que solamente algunas implementaciones (Microsoft IIS?) sufren este problema. La entradilla es correcta, pero tanto el artículo como el titular dan a entender que "todos" los servidores tienen este problema.
Quizá "sensacionalista" sería más apropiado que "erronea".
Y lamento el uso de la expresión "fliparse", debería haber dicho algo como "en Hacker News ya han dicho hace horas que no es algo general, sino solo de MS; el titular es sensacionalista"
Ojo cuidao que con esfuerzo se podría captar en TOR la zona horaria del servidor final. ¡Inaceptable!. ¡Llega el momento de PRISM con su puerta trasera incluida de serie!.
ah, hay peña que no usa fecha UTC en los servidores?
Desde cuando identificar a pederastas es un problema?
#17 TOR es 'bastante más' que pederastas
#18 Mis mas humildes disculpas a los narcos, traficantes de armas, sicarios y terroristas del ISIS que puedan haberse sentido ignorados en mi anterior afirmación.
#17 ¿Esta buena la cerveza?