Ataque SSLStrip en Tor destinado al robo de Bitcoins

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}
  • X: 8-20 caracteres en el rango [a-z2-7]. Este rango viene dado por el método de cifrado usado por Tor, Base32.
  • D: variable de datos.
  • #: número (pueden ser múltiples dígitos).
  • El resto de caracteres son literales que deben seguir ese mismo orden.

ASN.1 utiliza secuencias de números separadas por puntos para definir códigos específicos. Por ejemplo, 2.5.4.3 es el identificador del nombre común (aparece dos veces en la firma (common name)). El código 1.2.840.113549.1.1.11 identifica el método de cifrado, sha256 con RSA. Este último código puede variar ya que el método de cifrado cambia según qué versión de SSL sea utilizada por el servidor (otro 0-day, al permitir la identificación de librerías).

En un escenario en el que un determinado actor intercepte una serie de paquetes con certificado TLS del servidor, los cuales generen una firma, si esta firma coincidiese con el patrón de las de los servidores de Tor, este usuario podría identificar las conexiones como conexiones a la red Tor de manera fácil y rápida.

Este bug sigue sin tener una solución, y según el investigador, es conocido por los administradores de Tor desde hace ocho años.

Conexiones mediante Tor Bridges

Los bridges hacen uso de los denominados protocolos pluggable transport, que permiten ofuscar el tráfico de los usuarios de muy diversas formas. El problema es que muchos de ellos se han quedado obsoletos y rara vez se usan. Algunos de los ejemplos principales son:

  • Format-Transforming Encryption (FTE)
  • OBFS
  • Meek

El problema con los bridges reside en que Tor ha limitado las opciones a obfs4 y a uno solo de los métodos ofrecidos por meek, y ambos son posibles de detectar, por lo que esto, sumado a la vulnerabilidad explicada en el apartado anterior, hace posible el bloqueo total de las conexiones de Tor mediante la identificación de los paquetes.

Conclusión

Mientras que Tor sigue siendo una de las soluciones más efectivas (si no la que más) frente a campañas de censura y opresión, o simplemente para aquellas personas que se preocupan por su privacidad más que el usuario de Internet común, los fallos aquí descritos son de una importancia considerable y, según apuntan los investigadores, pueden existir muchos más a la par que el proyecto sigue siendo objeto de ataque por usuarios malintencionados, quizás por ser la solución principalmente implementada.

Desde hace algunos años se pueden leer noticias y comentarios de usuarios en Internet que apuntan a que en un futuro la red Tor podría dejar de gozar de su popularidad actual para dar paso a otras soluciones, como I2P, principalmente debido a la descentralización de esta última, una idea quizás no tan descabellada considerando los fallos de seguridad en la red Tor que poco a poco están dándose a conocer.

Más información

A mysterious group has hijacked Tor exit nodes to perform SSL stripping attacks

How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

Tor 0day: Stopping Tor Connections

Tor 0day: Burning Bridges

Comparte en tus redes: