Pregunta:
¿Es posible recibir datos falsos de torrents?
user156092
2017-08-14 04:09:22 UTC
view on stackexchange narkive permalink

Al descargar un archivo a través de un torrent, ¿qué pasará si algunos de los pares me envían fragmentos falsos?

Además, ¿alguno de los pares puede enviarme un archivo falso completo? Por ejemplo, si descargo un archivo .torrent que debería descargar un archivo con suma hash A, y un par me envía un archivo con suma hash B, ¿el cliente de torrent lo notará y lo bloqueará?

La idea de que esto es posible fue parte de la defensa de Ross Ulbricht en el juicio de la ruta de la seda.Argumentaron que el material se colocó en su computadora mientras estaba descargando el Informe Colbert: https://motherboard.vice.com/en_us/article/78xdva/defense-in-silk-road-trial-lays-out-its-full-teoría-del-perpetrador-alternativo
Creo que vale la pena señalar que había organizaciones que se creía que contaminan rastreadores al compartir intencionalmente fragmentos defectuosos.La idea no era conseguir que descargaras un archivo malicioso, sino simplemente hacer que descargar torrents fuera desagradable y lento.
La mayoría de los ataques prácticos apuntarán al archivo .torrent en primer lugar.Es mucho más fácil hacer que el usuario descargue un torrent que distribuya malware y demás, que corromper un torrent limpio al encontrar colisiones SHA1.
Tres respuestas:
Encombe
2017-08-14 04:47:06 UTC
view on stackexchange narkive permalink

Sí, un cliente lo notará y bloqueará.

Un torrent se divide en partes, una pieza se divide en trozos.
Cada pieza tiene su hash SHA1 incluido en los metadatos .torrents.

Si un par envía fragmentos falsos o corruptos, esto se detectará cuando se haya recibido todo el fragmento y la comprobación de hash falle.
Un par que envíe repetidamente datos incorrectos será bloqueado, pero hay algunos libertad de acción porque la corrupción puede ocurrir naturalmente a veces en una transferencia de datos.
Un buen cliente tiene heurísticas para averiguar exactamente qué pares enviaron datos incorrectos comparando los fragmentos enviados en el fragmento que no pasó la verificación de hash, con los fragmentos en la misma pieza cuando se ha vuelto a descargar y ha pasado el control de hash.

Un torrent se basa en TCP (o uTP), ¿verdad?¿Por qué la corrupción ocurriría naturalmente en una transferencia de datos?
Es posible que desee tener en cuenta que SHA-1 está un poco roto y explicar la colisión frente a la segunda preimagen, etc.
@Oddthinking TCP tiene una suma de comprobación deficiente.
@Oddthinking Simplifico un poco mi respuesta para que sea breve.Cosas que pueden causar corrupción;Sumas de comprobación débiles de TCP / UDP, errores del cliente, disco defectuoso, memoria defectuosa y controladores defectuosos.
A menos que el SHA1 esté roto: https://shattered.io/
@Oddthinking Además, TCP tiene sólo dos números de serie de paquetes de 16 bits, por lo que no es inútil predecirlo y falsificarlo.
Bueno.Me sorprendería que un cliente diera margen de maniobra contra el bloqueo inmediato porque pensaba que el cliente o la fuente podrían tener un disco defectuoso.mala memoria o controladores defectuosos, o el cliente puede tener un error, o la suma de comprobación de TCP pasó datos corruptos o SHA1 fue descifrado y la fuente estaba siendo atacada.
@Oddthinking Su primer comentario hizo una buena pregunta.Puedes leer un poco cómo le va a uTorrent aquí: http://www.netcheif.com/Articles/uTorrent/html/AppendixA_02_12.html ** bt.ban _ ***
Con respecto a la rotura de SHA1: el proyecto shattered.io tenía más de 100 GPU calculadas durante un año para generar su colisión SHA-1.Eso hace que la inyección de datos falsos en una descarga de torrent no sea factible, a menos que uno tenga acceso a una gran cantidad de potencia de procesamiento o sea un torrent de larga duración.
@Encombe Hay información realmente valiosa en algunos de los comentarios aquí.Es posible que desee editarlo en su respuesta.
Si bien una colisión SHA1 es poco probable, es muy posible.Entonces, esta respuesta es, en el contexto de una solicitud de seguridad, simplemente incorrecta.
@TwoThe: El atacante necesita más que una colisión SHA1, necesita una segunda imagen previa para atacar un torrent específico.SHA-1 sigue siendo bastante fuerte en contra de eso (aunque con tantos trozos para elegir es casi como un escenario de colisión).Sin embargo, los protocolos deben cambiar a una mejor función hash tan pronto como sea posible, y ningún trabajo nuevo debe usar SHA1.
Los comentarios no son para una discusión extensa;esta conversación ha sido [movida al chat] (http://chat.stackexchange.com/rooms/63915/discussion-on-answer-by-encombe-is-receiving-fake-torrent-data-possible).
Jeremy Kato
2017-08-14 21:55:03 UTC
view on stackexchange narkive permalink

Agregando a la respuesta de Encombe en cuanto a la probabilidad de que ocurra una "falsificación" falsa: Es abrumadoramente improbable que tal situación pudiera o ocurriría, aunque es posible.

SHA-1 es un método antiguo para el hash de archivos y no se recomienda para un nuevo uso, pero podría decirse que está bien como está ahora.

Escenario 1: Se produce un error: si otro usuario le envía un fragmento o un fragmento incorrectos (tal vez se produzca un error de uno en un millón y los datos se corrompan en tránsito ), los valores hash no coincidirán y el fragmento se rechazará. Es casi imposible que un fragmento tenga el mismo hash después de estar dañado.

Escenario 2: un usuario malintencionado intenta enviarle un archivo falso: suponiendo que nuestro Los atacantes saben lo que están haciendo, aún sería muy poco probable. Imagine la dificultad de incluso calcular un archivo falso que tiene el mismo hash SHA1: y los hash de los fragmentos de su archivo falso tendrían que coincidir con los hash de los fragmentos del archivo original. Yo diría que la cantidad de tiempo que tomaría crear un archivo de este tipo lo haría casi imposible, incluso si usara un método de hash más débil como MD5 debido a la gran dificultad de hacer tantos hash conflictivos y superpuestos.

Es mucho más probable que corra el riesgo de que alguien coloque un torrent "trampa" en línea diseñado para contener un virus o contenido malicioso, pero que habría sido creado por atacantes y también sembrado por ellos ( más cualquiera que cayera en la trampa).

Tener hash SHA-256 o más sería genial, pero las probabilidades de que un ataque de este tipo tenga éxito son astronómicamente bajas.

"y tener fragmentos que también coincidan con los valores hash de los fragmentos originales". ¿Por qué y?Si uno puede enviar fragmentos falsos de forma indetectable, eso podría ser suficiente para realizar algún tipo de ataque DOS.
1) Los ataques de DOS no están relacionados: esa es la diferencia entre que alguien le envíe una carta falsificada por correo y le envíe 100.000 cartas por correo. 2) La razón por la que es tan difícil es porque generar incluso una sola colisión SHA-1 lleva mucho tiempo.El .torrent describe qué tan grande es el archivo, qué es el hash SHA-1 y otros metadatos.Imagínese, para crear un archivo de colisión, necesitaría crear uno de la misma longitud exacta y tener el mismo hash SHA-1 que el original.Ahora imagina que los fragmentos del archivo falsificado ahora tienen que coincidir con los originales.Es básicamente imposible.
Eso sin mencionar que un archivo de ingeniería de este tipo, en el mejor de los casos, probablemente sería datos basura inofensivos.Crear un archivo que colisione con el original, cumpla con los otros requisitos de coincidencia y aún tenga un virus sería absurdamente difícil.Los atacantes nunca podrían imaginar que algo tan complicado funcione realmente.
Le sugiero que lea lo que dije nuevamente.
Disculpas, ¿te refieres a la redacción de la oración que citaste?Lo he editado para que tenga más sentido, lo siento si sonó gracioso.
* si * un actor malintencionado pudiera de hecho sustituir un fragmento por otro, entonces un actor malintencionado podría usar eso para impedir la propagación del torrente.No es necesario que ese fragmento sea un dato válido (y mucho menos un virus) ni que la suma de comprobación del archivo sea correcta; eso es simplemente complicar demasiado la imagen.
Eso es cierto, pero después de enviar demasiados fragmentos incorrectos, los demás compañeros te bloquearán.Y esto solo ralentizaría la propagación del torrente;no le permitiría difundir un archivo completamente diferente.
¿Cómo sabrán que es un fragmento incorrecto si el hash coincide?
Porque cuando vuelva a armar el archivo, el hash de todo el archivo no coincidirá y su programa torrent se dará cuenta de que necesita verificar manualmente el contenido.Y nuevamente, todo lo que hace esto es ralentizar los torrents de algunas personas, por lo que no solo es poco probable que alguien tenga la capacidad computacional para hacer esto, sino que es poco probable porque esencialmente no tendría ninguna motivación para hacerlo.
de nuevo se confunde con '¿es esto un ataque válido?' y 'esto es práctico'.Desafortunadamente, carece de la información y el contexto para responder a la segunda pregunta (como todos nosotros).Vale la pena señalar, aunque se está volviendo cada vez más viable si alguien decide que es una ventaja: https://arstechnica.com/information-technology/2017/02/at-deaths-door-for-years-widely-used-sha1-function-está-ahora-muerto /
¿Quieres hablar práctico?Su artículo afirma que el costo de hacer que ocurra una sola colisión es de $ 110,000.El ataque tomó más de 9 quintillones de hashes SHA-1 del archivo.Has señalado todos estos puntos para demostrar que puedes gastar cientos de miles o millones de dólares para incomodar una parte del torrente de alguien.Teóricamente es posible, pero en este momento sería mejor que apuntas un microondas a la computadora de alguien y esperas que provoques una interferencia corrupta.
"¿Quieres hablar práctico?"No, digo explícitamente que siento que es una discusión inútil. "incomodar un trozo del torrente de alguien" Sólo estás limitado por tu imaginación.
Para citar las mejores respuestas en Security SE: la seguridad no tiene sentido sin un modelo de amenaza.Si hay una amenaza, todavía no es evidente cuál sería más allá de la molestia..... Y dijiste que no tenemos la información para responder si es práctico o no - señalé que sí.De hecho, es bastante claro si observa la evidencia que proporcionó.La seguridad teórica no significa necesariamente mucho o de lo contrario todo el mundo se comunicaría por medio de una sola vez.
"señaló que lo hacemos mucho. Es bastante claro, de hecho, si miras la evidencia que proporcionaste". Entonces, ¿está consciente de que $ 100,000 es básicamente un cambio tonto (y que disminuye drásticamente año tras año)?¿También sabe que esto no se limita a una sola descarga, sino que podría usarse para envenenar cualquier descarga de un torrent (o similar)?
Cont.Además, ¿se da cuenta de que los torrents (y otros mecanismos de descarga que usan SHA1 como hash) se utilizan en software legítimo, donde incluso un solo día de inactividad podría causar mucho daño? Imagínese si pudiera tomar una actualización del sistema operativo (especialmente una solución de seguridad para, por ejemplo, software aleatorio) o el lanzamiento de Battle.net el primer día sin conexión¿Me podría valer $ 100,000?¿Qué pasa con $ 10,000 a medida que bajan los costos?$ 1,000?¿Qué tal comprometer el sistema de actualización interno de Facebook?
Anonymous
2017-08-14 21:40:32 UTC
view on stackexchange narkive permalink

Los torrents dependen en gran medida de la función hash SHA-1: los torrents se dividen en partes del mismo tamaño y el hash SHA-1 de cada pieza se guarda en la sección de información del torrent, que a su vez está identificado y, por lo tanto, protegido por su SHA-1 hash.

SHA-1 muestra signos de debilitamiento. Por ejemplo, a principios de este año, se publicó un ataque que permite a una gran organización, como un actor estatal o una corporación, o una persona adinerada, producir dos bloques de datos diferentes con el mismo hash SHA-1. Sin embargo, esto no es lo mismo que encontrar una colisión para un bloque de datos existente, y principalmente por esta razón, el ataque solo podría usarse prácticamente contra los hashes de las piezas por ahora e incluso entonces no sería posible tomar sobre un torrent de terceros, tendría que producir el suyo propio. Por ahora. Podría ser que un ataque de colisión completo no esté lejos. Cada año aumenta la posibilidad de que alguien tenga en secreto un ataque completo de SHA-1.

Para aprovechar el ataque actual, se podría producir un torrent que ofrezca contenido benévolo a la mayoría de las personas, y que se marque como 'confiable' en sitios de indexación de torrents, pero un individuo objetivo puede ser engañado para que descargue un dato malicioso, como un virus.

Sin embargo, los autores del ataque también publicaron una forma de fortalecer SHA-1. La idea es detectar posibles colisiones SHA-1 y modificarlas de tal forma que los diferentes bloques de datos vuelvan a tener un hash diferente. Técnicamente, este SHA-1 reforzado es diferente de SHA-1, pero dado que, hasta donde sabemos, todavía no existe un ataque completo de SHA-1, por ahora, los archivos no maliciosos con toda probabilidad tendrán el mismo hash SHA-1 reforzado y regular. por lo que el software que se basa en SHA-1 seguirá funcionando y solo los archivos maliciosos tendrán diferentes hashes. Pero esta solución solo ayudará si el software la usa y, hasta ahora, la biblioteca de software más popular para descargar torrents no ha solucionado su implementación.

Actualmente, se está trabajando en una segunda versión de la especificación BitTorrent, que utilizará la función hash SHA-256 más segura. Sin embargo, esta versión se encuentra actualmente en su etapa de redacción y lo ha estado durante una década. Hasta que esté hecho y la versión 1 quede obsoleta, esto no ayuda a nadie.

Es difícil enfatizar demasiado lo débil que se está volviendo SHA-1. Y los ataques publicados contra SHA-1 no cuentan toda la historia. A pesar de años de estudio intensivo del predecesor de SHA-1, un ataque contra él completamente desconocido para el público apareció en la naturaleza. Entonces, la respuesta probablemente sea .



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...