[Paradox]

(27 Feb 2018)gerardodinardo escribió:  No,no y no, lo suyo es dejar de usar utorrent y pasarse a otros clientes más seguros y mejor testeado. La vulnerabilidad ha sido encontrada tanto en las nuevas versiones como en las viejas.

Ehm, no.


Link de Bakabt

Duki3003 escribió:Update: Although the extent of the vulnerability of pre 3.x versions of uT is not yet fully explored, in consideration with a number of our user requests, we will be allowing uT 2.2.1, 1.8.5 and 1.6.1, however we still recommend that you consider migrating your torrents to another client regardless (if you haven't already done so). If you intend to keep using uT, set net discoverability to false, but if you choose to still use it, you're doing it at your own risk.

La vulnerabilidad NO ha sido confirmada para versiones pre 3.x. Se recomienda cambiar el cliente basados en una suposición.

Bob2004 escribió:As far as I am aware - and that chromium.org discussion seems to agree - these vulnerabilities are not known to affect any versions prior to 3.5, which was never whitelisted anyway. Indeed, I have tried some of the helpful demonstration exploits in the page you linked, and can confirm that none of them impact my install of uTorrent 3.3.1, even after restoring it to default settings. I'm still waiting for the web DNS rebinding vulnerability exploit to do anything (been running for ~15 minutes now), but the utorrent crash tests do not crash utorrent. Some of the buttons cause it to pop up a security prompt warning me that someone is trying to make changes to utorrent, but none of them actually do anything without my express permission. So why did you decide to remove versions which aren't affected from the whitelist?

Aquí podemos ver el primer usuario que testeó si la vulnerabilidad también afectaba a la versión 2.2.1. Los links para hacer esto son este y este. Cualquiera puede hacer la prueba.
Yo no lo hago porque soy bien vago y creo en las palabras de personas que no conozco del interné.

Paulo27ms escribió:I have yet to see anyone confirm the bugs are present in 2.2.1, various people have tested for them with the same methods as the bug founder however and they simply do not work (I can't get any of them to work either) as they do in newer versions (in which the bug was found).

Segundo usuario.

YukinoAi escribió:Did some testing on 2.2.1.

First, I confirmed that with "netstat -a" and net.discoverable=true showed that uTorrent RPC was listening on TCP 10000 and that net.discoverable=false made it stop listening on that port.

With net.discoverable=true, the test page caused a popup dialogue when testing port 10000 and the active listening port. "[Test] Trigger pin request" did something similar, crash test did nothing.

With netstat -a with net.discoverable=false, nothing happened on every test, on both TCP 10000 and the active listening port.

With net.discoverable=true both port 10000 and the active listening port are susceptible with to abuse via RPC. On the computer security danger level, that is a 10/10 avoid at all costs.

Tercero, y de paso recibimos información de cómo funciona exactamente el cambio de la configuración.

K as a utorrent 2.2.1 user for many years I am interested in this, so as all the info and the exploits are here so we can reproduce I have gone ahead and done so. I am in no way a professional, but all the notes are there to reproduce.
First, the utorrent web is not installed on 2.2.1 by default so nothing with utorrent web works on 2.2.1 by default, verified port is ignored and commands so no one can download stuff on your pc.
Second, Utorrent classic port 10000 is on by default on 2.2.1, can be disabled but does not fix problem just shifts it to default connection port. The Crash test page does not crash utorrent 2.2.1, and Trigger device transfer is ignored as feature not implemented on 2.2.1. All other options open a pop-up on utorrent if you want to allow or ignore (seems like the people that made utorrent knew about this probability and made that as a safety net) you also have an option for always deny as a check box, so no entry. The last exploit that makes it possible for people to get list of your download and download them from you states "invalid request", and after a minute it gives "This page is waiting for a dns update, and will then contact utorrent. This could take a while, get a coffee." left it running for 40+ minutes (got me couple of coffees) and still same thing posted image with errors that states the utorrent 2.2.1 is responding with a 400 Bad Request error leaving me to believe that 2.2.1 immune to this attack. I and manny other would like you guys at google to verify our findings.

Some websites tried to persuade people that setting Preferences → Advanced → net.discoverable = false resolves the problem. But it isn't true. This setting just disables port 10000. But you can execute the same actions using port which uTorrent uses for all incoming connections. For example, I use port 45705 for incoming connections, and a simple GET request to http://127.0.0.1:45705/fileserve/?callback=error crashes the program.

Aquí vemos en cambiar la configuración solo deshabilita el puerto 1000, pero siempre se pueden ejecutar las mismas acciones con otro puerto. Claro, en la última cita no se especifica con cuál cliente es cierto esto.
Por lo que, aún si el cambio de configuración no hace nada, en el caso de la versión 2.2.1 no importa pues ni siquiera es vulnerable al ataque en primer lugar.


Link original de donde se encontró la vulnerabilidad

Is this present in the pre 3.x versions of uTorrent? The torrenting community largely eschews 3.0+ because the only apparent work post-
2.2.1 has been to add advertisements, bloating 2.2.1's 391KB of torrenting perfection into a 1MB+ monstrosity. The last meaningful exploit that wasn't introduced by these 3.x additions was fixed in version 1.6.1, which was released in 2007. 1.6.1, 1.8.5, 2.0.4, and 2.2.1 are all recommended clients for this nearly unparalleled level of security to go with their stability and performance.

I've run your tests against 2.2.1 and only come up with the pairing and PIN requests bringing up popups that the requests were received. The crash and info leakage don't work as they do for 3.5.

K as a utorrent 2.2.1 user for many years I am interested in this, so as all the info and the exploits are here so we can reproduce I have gone ahead and done so. I am in no way a professional, but all the notes are there to reproduce.
First, the utorrent web is not installed on 2.2.1 by default so nothing with utorrent web works on 2.2.1 by default, verified port is ignored and commands so no one can download stuff on your pc.
Second, Utorrent classic port 10000 is on by default on 2.2.1, can be disabled but does not fix problem just shifts it to default connection port. The Crash test page does not crash utorrent 2.2.1, and Trigger device transfer is ignored as feature not implemented on 2.2.1. All other options open a pop-up on utorrent if you want to allow or ignore (seems like the people that made utorrent knew about this probability and made that as a safety net) you also have an option for always deny as a check box, so no entry. The last exploit that makes it possible for people to get list of your download and download them from you states "invalid request", and after a minute it gives "This page is waiting for a dns update, and will then contact utorrent. This could take a while, get a coffee." left it running for 40+ minutes (got me couple of coffees) and still same thing posted image with errors that states the utorrent 2.2.1 is responding with a 400 Bad Request error leaving me to believe that 2.2.1 immune to this attack. I and manny other would like you guys at google to verify our findings.

Más ejemplos.

(27 Feb 2018)Kumicho escribió:  Muchos no saben ni seedear. ¿Imagináis que baneo un cliente como uTorrent en el tracker?

La vulnerabilidad en teoría no afectaría en anda al tracker. Pienso que un baneo de uTorrent es innecesario. Aunque se debe aconsejar a todos los usuarios que cambien a versiones más estables, por su propio bien.

[Khaas]

Yo uso la 1.8.5 creo que fue la primera en admitir los magnets links. He probado todo tipo de test y ninguno me ha funcionado.
La primera web me sale un mensaje pero la segunda es que el utorrent ni reacciona.
Pero vaya que te pasas al qtorrent ese y se acabo el rollo total mi uso de utorrent se limita a bajar un capítulo a la semana dos como mucho y a lo mejor un juego y lo chapo.

PD: Y la linea esa que se nombra es que ni me sale directamente.

[quickbip]

entonces seria recomendable cambiar de cliente? alguno recomendado?

[Tonoss]

qbitorrent puedes usar mismamente

[Cerebrain]

Desde hace mucho tiempo que uTorrent está constantemente con vulnerabilidades, también que usaban los pcs conectados para minar bitcoin y así... hace tiempo que abandoné uTorrent, además que su interfaz ni es tan bonita, ya la tienen llena de publicidad. Mejor qbittorrent o Deluge.

[Piedra]

Yo me pasé a qbittorrent y al poner el torrent de Anitousen (Re seguro xd) no me descargaba nada, lo mismo con nhentai, frozen layer, nyaa, etc.

Así que me puse el Utorrent 3.5.3 y yasta, esa es mi triste historia con el qbittorrent, por lo menos era bonito y ordenado, pero no me descargaba nada :,v

PD:Soy demasiado vago para buscar una solución, y en teoría el 3.5.3 ya tiene el parche de seguridad :/

[Khaas]

Yo lo que hice en el qbittorrent que tampoco me descargaba nada fue quitar la opción de crear subcarpetas.

[gerardodinardo]

(07 Apr 2018)Piedra escribió:  Yo me pasé a qbittorrent y al poner el torrent de Anitousen (Re seguro xd) no me descargaba nada, lo mismo con nhentai, frozen layer, nyaa, etc.

Así que me puse el Utorrent 3.5.3 y yasta, esa es mi triste historia con el qbittorrent, por lo menos era bonito y ordenado, pero no me descargaba nada :,v

PD:Soy demasiado vago para buscar una solución, y en teoría el 3.5.3 ya tiene el parche de seguridad :/

Para eso tienes que ir a la ventana de ajustes en los del RSS y habilitar la opción que dice "Enable auto downloading of RSS torrents"

[yunier13]

que buena gente @gerardodinardo, pensé que dejarian pasar este tema de largo en UF.

[gerardodinardo]

estaba claro.