Vulnerabilidades en Tor dejan al descubierto los servicios ocultos

Vulnerabilidades en Tor ponen en peligro el anonimato en los servicios ocultos

Lo más probable es que todos sepamos de la existencia de Tor, tengamos ciertas nociones sobre su funcionamiento y hayamos tenido la curiosidad de acceder a un servicio oculto. Pero, ¿somos conscientes de la existencia de vulnerabilidades en Tor que pueden poner en peligro el anonimato en los servicios ocultos?

Hace unas semanas publicamos el artículo Servicios ocultos en Tor, ¿cómo consiguen pasar desapercibidos? donde explicamos con detalle los entresijos del protocolo utilizado en los servicios ocultos en Tor.

Sin embargo pasamos por alto un elemento fundamental que permite a los usuarios de Tor acceder a los servicios ocultos. Se trata de la base de datos distribuida donde se almacenan los descriptores que contienen la información necesaria para llegar a dichos servicios.

Realmente no es una base de datos como tal, sino una tabla hash distribuida (distributed hash table, en adelante DHT) entre ciertos nodos en Tor que cumplen una serie de características que comentaremos a continuación. Estos nodos especiales actúan como directorios de servicios ocultos (hidden service directories, en adelante HSDirs) y serán los responsables de los descriptores que almacenen. Es decir, cuando un cliente se conecte a un servicio oculto, tendrá que acudir a los HSDirs correspondientes (responsables del servicio) para descargar su descriptor y poder localizarlo para establecer la conexión.

De esta forma, en este artículo nos centraremos principalmente en el papel que juegan los HSDirs en el funcionamiento de los servicios ocultos en Tor. Comenzaremos con unos conceptos necesarios para entender algunas vulnerabilidades en Tor que afectan a estos servicios, y terminaremos viendo cómo el proyecto Tor pretende mitigar los ataques vistos hasta el momento.

Directorios de servicios ocultos en Tor (HSDirs)

Como se ha mencionado más arriba, estos directorios son nodos especiales en Tor porque, aparte de su función y responsabilidad, cuentan con unos flags o características que les permiten ser HSDir en la red Tor.

Cualquier nodo en Tor puede recibir un conjunto de flags en función de la posición que ocupe en un circuito (e.g., Guard, Exit, BadExit), en función de las propiedades del circuito (e.g., Fast, Stable), o bien en función del rol que desempeña (e.g., Authority, HSDir). Puede consultarse el documento de especificación Tor directory protocol, version 3 para obtener más información sobre todos los posibles flags en Tor.

Estos flags son asignados por las autoridades de directorio (directory authorities), otros nodos especiales que cuentan al menos con el flag Authority. Básicamente se encargan de mantener y publicar información de los nodos disponibles en la red Tor, de tal forma que los clientes puedan consultar esta información y construir sus circuitos en Tor. El número de autoridades de directorio oscila entre 9 y 10, aunque puede consultarse en tiempo real a través del servicio web Atlas.

Volviendo a los HSDirs, en un principio solo se necesitaban 25 horas para que un nodo pudiera obtener el flag HSDir y convertirse en un directorio de servicios ocultos, un requisito bastante fácil de cumplir. Pero al descubrir ciertas vulnerabilidades en Tor relacionadas con la facilidad de montar un nodo HSDir, decidieron añadir requisitos más restrictivos en la versión de Tor 0.2.6.9 liberada el 11 de junio de 2015:

  • Por una parte se requiere que el nodo consiga el flag Stable (al menos 7 días para ello).
  • Y por otra parte se requiere que el nodo se mantenga activo durante un mínimo de 96 horas (uptime), al contrario que ocurría antes únicamente con 25.
Número de nodos en Tor con el flag HSDir asignado (01/01/15 - 26/07/15)

Número de nodos en Tor con el flag HSDir asignado (01/01/15 – 26/07/15)

Llegados a este punto se sabe: qué es un HSDir, qué almacenan, y cuál es su misión (entre otras cosas). Pero aún no se ha hablado de los clientes, es decir, dado un servicio oculto, ¿cómo saben a qué HSDir tienen que dirigirse para descargar el descriptor correspondiente y poder conectarse a él?

HSDirs responsables de un servicio oculto

En el último artículo sobre Tor se detallaron los pasos dados por un cliente al conectarse a un servicio oculto. Sin embargo se trató por encima la descarga del descriptor necesario para establecer la conexión.

Antes de detallar este proceso, cabe mencionar que todo nodo en Tor cuenta con un fingerprint que se obtiene a partir del SHA1 de la clave pública asociada al nodo.

Ahora bien, para que resulte más sencillo entender cómo un cliente localiza los HSDirs responsables de un servicio oculto, por una parte se toman los fingerprint de todos los nodos HSDir disponibles en Tor y se posicionan en un círculo que abarque todo el rango posible (i.e., 00..000 – FF..FFF). Y por otra parte, sobre este mismo círculo, se posicionan también 2 posibles identificadores del descriptor buscado que son calculados por el cliente a partir del SHA1 de cierta información del servicio oculto:

Posicionamiento de los HSDirs y los identificadores del descriptor

Posicionamiento de los HSDirs y los identificadores del descriptor

A partir de estos identificadores, el cliente ya es capaz de localizar los HSDirs que almacenan el descriptor asociado al servicio oculto. Pero antes de explicar cómo se localizan, a continuación se muestra la fórmula utilizada para calcularlos y el significado de cada una de las variables:

descriptor-id = sha1(permanent-id | sha1(time-period | descriptor-cookie | replica))
  • descriptor-cookie se trata una variable opcional, un secreto compartido entre un servicio oculto y sus clientes que impide el cálculo de los identificadores y por tanto el acceso no autorizado al mismo. Con ello se consigue que el listado de puntos de introducción quede cifrado y, para un cliente que desconozca este secreto, sea imposible acordar un punto de encuentro con el servicio oculto.
  • El valor de time-period cambia cada 24 horas, y es el responsable de que los identificadores, y por tanto los HSDirs responsables de un servicio oculto, cambien periódicamente.
  • replica se trata de una variable de tipo entero que toma dos posibles valores: 0 y 1. De esta forma se consigue generar un par de identificadores (utilizando ambos valores) distribuidos en diferentes partes del círculo.
  • Y por último, la variable permanent-id tiene un valor fijo y se obtiene a partir de los primeros 80 bits del SHA1 de la clave pública del servicio oculto.

Una vez calculados ambos identificadores, el cliente ya tiene a su disposición 2 conjuntos de 3 HSDirs donde poder consultar el descriptor necesario para llegar al servicio oculto. Estos 3 nodos HSDir se toman, en sentido horario y de forma consecutiva, a partir de los 2 identificadores:

HSDirs responsables de un servicio oculto

HSDirs responsables de un servicio oculto

Finalmente el cliente elegirá, de forma aleatoria, un HSDir de los 6 posibles para conectarse al servicio oculto. En caso de que fallara la primera petición, el cliente seguiría intentándolo de forma aleatoria con el resto de HSDirs hasta que diera con un nodo disponible.

Vulnerabilidades en Tor

Una vez visto en detalle el funcionamiento de los servicios ocultos y descubierto el potencial que esconden, conviene tener muy presente las vulnerabilidades en Tor que puedan poner en peligro estos servicios y sobre todo el anonimato que proporciona Tor, tanto a los usuarios como a los propios servicios ocultos.

A continuación se muestra un listado de algunas vulnerabilidades en Tor, existentes hoy en día, que podrían ser aprovechadas para atacar a los servicios ocultos:

  • Las claves RSA-1024, utilizadas por los servicios ocultos, se consideran débiles. Y aunque un ataque a las mismas no fuera la mejor opción para un atacante, ya que un ataque de correlación sería más factible y menos costoso, habría que considerar la posibilidad de incrementar la longitud de las claves y/o utilizar un algoritmo de clave pública diferente.
  • Facilidad para obtener el flag HSDir y convertirse en un directorio de servicios ocultos. Aunque en la versión de Tor 0.2.6.9 se añadieron más restricciones para conseguir este flag, aún sigue siendo viable para un atacante; requiriendo por tanto medidas adicionales para dificultar este proceso e incrementar el coste que le supondría al mismo.
  • Los HSDirs responsables de un servicio oculto son predecibles. A partir de la fórmula vista en el apartado anterior, un atacante perfectamente podría averiguar los 6 nodos HSDir responsables de un servicio oculto en un momento determinado del tiempo. Estos nodos deberían de ser impredecibles en cualquier momento para evitar algunos ataques que se comentan a continuación.

Posibles ataques en servicios ocultos

A partir de estas vulnerabilidades, un atacante podría llevar a cabo cualquiera de los siguientes posibles ataques descubiertos hasta el momento:

  • Ataques de denegación de servicio. Dado que los HSDirs responsables de un servicio oculto son predecibles, un atacante con mínimos recursos podría bloquear/censurar por completo un servicio oculto en cualquier momento.
    Para ello el atacante tendría que montar 6 nodos en Tor, obtener los flags HSDir, y generar de forma aleatoria tantas claves RSA-1024 como fueran necesarias para conseguir posicionarlos como nodos HSDir responsables del servicio oculto. Una vez posicionados, el atacante impediría el acceso al servicio oculto simplemente no devolviendo a los clientes el descriptor solicitado.

    Control de los HSDirs responsables de un servicio oculto

    Control de los HSDirs responsables de un servicio oculto

  • Obtención de direcciones .onion y estadísticas. Simplemente con montar un nodo HSDir, un atacante ya podría empezar a recoger direcciones .onion durante días a partir de los descriptores que fuera almacenando. Además no tendría ni que llevar a cabo el ataque anterior, ya que el nodo sería responsable de nuevos servicios ocultos cada 24 horas.
    Aparte de las direcciones, un atacante también podría obtener estadísticas sobre el número de peticiones recibidas por servicio oculto, el número de servicios ocultos observados, el número de servicios ocultos por días observados, etc. De hecho, en la última conferencia de seguridad Chaos Communication Congress (CCC) que tuvo lugar a finales de 2014, se presentó la ponencia Tor: Hidden Services and Deanonymisation donde se mostraron estadísticas muy interesantes como resultado de un experimento llevado a cabo durante 6 meses con 40 nodos HSDir.
  • Desanonimización de servicios ocultos. Como pudo verse en el último artículo sobre Tor, para permitir la comunicación entre un cliente y un servicio oculto se establecen un par de circuitos con el punto de encuentro, uno desde cada extremo. En el circuito establecido desde el servicio oculto, el primer nodo o nodo de entrada (guard node) es crítico ya que es el único que realmente conoce la dirección IP de la máquina que ofrece el servicio.
    Por ello, para que este ataque sea satisfactorio y se consiga la dirección IP, es imprescindible que el servicio oculto elija como nodo de entrada un nodo controlado por un atacante y que la comunicación (atacante – servicio oculto) discurra por un punto de encuentro elegido por el mismo. Dadas estas condiciones, el atacante podría desenmascarar al servicio oculto mediante un ataque de correlación que permitiría al nodo de entrada identificar un patrón de tráfico específico enviado por el punto de encuentro.
    Este ataque se encuentra perfectamente descrito en la sección VI del estudio Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization y muy bien resumido en el artículo Tor, servicios ocultos y desanonimización.
  • Desanonimización de usuarios. Este caso es muy similar al anterior, con la salvedad de que el punto crítico del ataque se encuentra (a priori) en el nodo que realmente conoce la dirección IP del usuario, el primer nodo o nodo de entrada utilizado para conectarse al servicio oculto.
    De esta forma, un atacante que tuviera el control de todos los HSDirs responsables de un servicio oculto podría saber cuándo un cliente pretende conectarse, y mediante un ataque de correlación, podría desvelar su identidad al reconocer en el nodo de entrada (controlado por el atacante) un patrón de tráfico específico enviado desde el HSDir que recibió la petición del cliente.
    Sin embargo, este ataque tiene la ventaja de no requerir un nodo de entrada para llevarlo a cabo, ya que con monitorizar la entrada a la red (ya sea a través de un ISP, un punto de acceso malicioso, etc.) sería suficiente para realizar un ataque de correlación y desanonimizar un usuario.
    En la conferencia de seguridad Hack In The Box que tuvo lugar en Ámsterdam a finales de mayo de 2015, se presentó este ataque en la ponencia Non-Hidden Hidden Services Considered Harmful: Attacks and Detection y se advirtió de un mayor riesgo de desanonimización en usuarios de servicios ocultos que en usuarios de Tor que no utilizan este tipo de servicios.

Servicios ocultos en el futuro

Parte de los ataques y vulnerabilidades en Tor vistas en el apartado anterior fueron identificados en abril de 2013 en el artículo Hidden Services need some love. Se recogieron una serie de ideas para mejorar la escalabilidad, seguridad y rendimiento de los servicios ocultos, y se hizo un llamamiento a los desarrolladores de Tor para que empezaran a trabajar en estos aspectos.

Fruto de este trabajo de investigación, a finales de noviembre de 2013 se creó la propuesta Next-Generation Hidden Services in Tor (actualmente en borrador) que describe el diseño y la especificación de una nueva generación de servicios ocultos. Desde el proyecto Tor aseguran que la propuesta hará que estos ataques sean prácticamente imposibles y esperan que en 2016 finalice su implementación.

Mientras tanto, a corto plazo se liberará la versión de Tor 0.2.7.x con una nueva mejora (#15963) para los servicios ocultos que dificultará aún más la obtención del flag HSDir, requiriendo de forma adicional el flag Fast.

 

Con estos dos artículos espero haber despejado cualquier tipo de duda acerca de los servicios ocultos en Tor, tanto en su funcionamiento como en el riesgo que suponen para el anonimato que proporciona Tor. En cualquier caso, si ves algo que no haya quedado muy explicado, algún error en el artículo, o simplemente quieres aportar algún detalle, no dudes en pasarte por los comentarios.

Pedro Castillo
0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *