Desde enero de este año la red Tor ha visto cómo su característica más distintiva, la privacidad proporcionada a sus usuarios, ha sido puesta en jaque por un grupo de actores maliciosos que han estado añadiendo servidores utilizados para ejecutar ataques SSLStrip en sitios de criptomonedas a los que accedían los usuarios, habiendo llegado a controlar más del 23 por ciento de los nodos de salida de la red Tor, siendo 380 el número máximo de nodos que este grupo llegó a controlar en su momento más álgido.

Según Nusenu, los atacantes estaban ejecutando ataques de «Man in the Middle» para manipular el tráfico que llegaba a los nodos de salida de la red, de manera que lograban eliminar la capa de seguridad proporcionada por HTTPS, convirtiendo las conexiones en HTTP y deshaciéndose así de la capa de cifrado.

Como se explicaba al principio de esta publicación, el objetivo de este ataque eran los sitios de criptomonedas, en particular Bitcoin, ya que los atacantes buscaban poder reemplazar las direcciones transmitidas mediante HTTP a servicios de Bitcoin que permiten a los usuarios enviar esta criptomoneda de una dirección a otra, dividiendo los fondos en sumas muy pequeñas para transferirlas a través de miles de direcciones intermediarias, ello antes de volver a unir estos fondos en la dirección de destino. Al reemplazar esta última a nivel de tráfico HTTP, los atacantes lograban robar los fondos del usuario víctima sin el conocimiento de éste o el servicio de Bitcoin.

El investigador destaca no el ataque en sí, sino más bien la escala lograda por el grupo. Explica Nusenu en su blog que, basándose en las direcciones de email utilizadas en los servidores maliciosos, se localizaron al menos nueve clusters de nodos de salida destinados al ataque, todos ellos añadidos durante los últimos siete meses.

Aparentemente la capacidad del grupo ha disminuido considerablemente desde el último proceso de «limpieza» llevado a cabo por los administradores de la red Tor. No obstante, los atacantes siguen teniendo el control de más del 10 por ciento de los nodos de salida (a fecha del 8 de agosto de 2020), y el investigador señala que es muy probable que el grupo continúe con el ataque ya que el proyecto Tor no cuenta con un proceso de verificación exhaustivo a la hora de decidir quién puede unirse a la red.

A este fallo no solo debemos añadirle que uno similar ya tuvo lugar el 2018, cuando se identificó al menos un proxy Tor-to-Web que estaba reemplazando direcciones de Bitcoin de manera desapercibida, sino que, además, el proyecto Tor parece no estar dándole la importancia necesaria a una serie de vulnerabilidades bastante graves reportadas por sus usuarios. Concretamente, Dr. Neal Krawetz publicó varias vulnerabilidades de la red Tor no solventadas por el proyecto. Dichas vulnerabilidades son descritas a continuación.

Identificación de usuarios mediante la barra del navegador

El uso de JavaScript permite identificar el ancho de la barra del navegador de los usuarios. Cada sistema operativo tiene un tamaño por defecto de esta barra, por lo que un atacante puede identificar cuál es la versión del sistema. Este bug permitiría la identificación concreta de los usuarios de la red Tor.

Dr. Neal Krawetz explica que este fallo fue reportado hace tres años y que sigue sin tener una solución.

Bloqueo de las conexiones a la red Tor

Los motivos por los que se puede querer bloquear las conexiones a la red Tor pueden ser muy variados, desde seguridad en una red empresarial, hasta la censura de gobiernos represivos. Ahora bien, bloquear todos los nodos de Tor no es una solución efectiva, ya que para empezar existen los llamados bridges, que son nodos de Tor no públicos los cuales son solicitados por los usuarios que lo necesiten, como aquellos en cuyo país el proyecto Tor está censurado. Sin embargo, el proceso de bloqueo resulta ser mucho más sencillo cuando existe una firma distintiva en los paquetes de los nodos de Tor.

Tras el análisis de estos paquetes, el investigador explica que la firma de los servidores de Tor tiene la siguiente estructura:

{{[2],#,{1.2.840.113549.1.1.#,NULL},{{{2.5.4.3,"www.X.com"}}},{"#Z","#Z"},{{{2.5.4.3,"www.X.net"}}},{{1.2.840.113549.1.1.1,NULL},D}},{1.2.840.113549.1.1.#,NULL},D}