Nodos de la red Monero enfrentan una nueva amenaza

Desarrolladores de Monero discutieron durante una reunión este 29 de julio sobre las implicancias de ProxyMark, un método que permitiría vincular la dirección IP real de un nodo de Monero conectado al protocolo de comunicación Tor con las transacciones que ese mismo nodo transmite.

ProxyMark fue expuesto en un estudio publicado el 8 de julio pasado por un equipo de investigadores de la Universidad de Correos y Telecomunicaciones de Pekín, en China. El hallazgo de ese equipo se concentra en un detalle puntual del diseño de Monero: la forma en que un nodo se comporta cuando transmite sus propias transacciones a través de Tor.

Tor es una red que permite transmitir datos ocultando la dirección IP real de quien los envía. Cada conexión pasa por tres computadoras intermediarias elegidas al azar entre miles de voluntarios: un repetidor de entrada (o de guardia), uno intermedio y uno de salida. Cada una conoce solo el paso anterior y el siguiente, nunca la cadena completa, salvo el repetidor de guardia, que sí ve la dirección IP real de quien inicia la conexión, aunque no el contenido transmitido.

Monero puede usar Tor como cliente que se conecta a otros nodos, o publicando un nodo propio como servicio oculto, identificado por una dirección ‘.onion’ que permite conectarse a él sin conocer su dirección IP real.

Un nodo de Monero configurado para transmitir sus propias transacciones a través de Tor no las difunde de inmediato a toda la red. Primero las envía en exclusiva a dos pares «proxy» (intermediarios que reenvían el tráfico) salientes, y recién después esos dos nodos la propagan al resto de los participantes. Ese diseño busca reducir la exposición del nodo de origen añadiendo una capa de anonimato, pero es justamente el cuello de botella que ProxyMark aprovecha: si un atacante ocupa esas dos conexiones salientes, puede capturar la transacción antes de que se mezcle con el resto del tráfico de la red.

El ataque a ese nodo combina tres etapas, de acuerdo con el estudio:

• Primero: detecta si el par que se conecta es un nodo cliente de Tor o un nodo de servicio oculto.

• Segundo: identifica cuál transacción se originó en ese par y no llegó por otro camino.

• Tercero: cruza esa identificación con una técnica de sincronización horaria (una especie de «marca de agua» insertada en los mensajes que el software intercambia de forma periódica) que un repetidor de entrada de Tor bajo control del atacante puede detectar, vinculando así la dirección ‘.onion’ (el identificador que Tor asigna a los llamados servicios ocultos) del nodo con su dirección IP real.

Aunque el mecanismo no vulnera ninguna herramienta criptográfica central de Monero, si tiene éxito, expone algo que para esta red es un pilar: la privacidad de quién envía una transacción. Lo que ProxyMark ataca es el camino que esa transacción recorre por la red antes de llegar a la cadena de bloques, y la posibilidad de que ese camino delate quién la originó.

Hasta el momento, no hay evidencia de que ProxyMark haya sido ejecutado contra la red Monero. La investigación surge de pruebas controladas en la red de pruebas y en la capa principal de Monero, no de un ataque real detectado contra usuarios de la red. Es decir, la falla fue detectada y demostrada de forma experimental, pero no consta ningún caso de explotación efectiva.

Por otro lado, el paper de los investigadores especifica que el ataque ProxyMark no afecta dos mecanismos de Monero:

• La direcciones sigilo, que generan una dirección de un solo uso para cada pago recibido, de modo que nadie pueda vincular esa transacción con la dirección pública que una persona comparte.

• RingCT (Transacciones confidenciales Ring), la función obligatoria desde 2017 que oculta el monto de cada transacción de Monero mediante compromisos criptográficos verificables.

¿Qué dicen los desarrolladores de Monero?

En la reunión de Monero Research Lab del 29 de julio, el desarrollador identificado como «jpk68» resumió que «es básicamente un mecanismo de tres pasos que intenta correlacionar las transacciones salientes con identificadores de Tor, y luego esos identificadores con direcciones IP».

Para que esas tres etapas funcionen en la práctica, el ataque depende de tres debilidades concretas en la forma en que Monero implementa hoy su conexión con Tor, según lo discutido en esa reunión.

Una de ellas, señalada por el colaborador «tevador», ya fue corregida hace más de un año. Hasta entonces, un nodo de servicio oculto agregaba siempre su propia dirección ‘.onion’ al final de la lista de pares que comparte periódicamente con sus vecinos (una lista con un tope de 250 direcciones), y esa repetición en la misma posición era justamente lo que le permitía a un atacante confirmar que ese par era un nodo de servicio oculto y obtener su dirección, el primer paso del ataque. El desarrollador «vtnerd» solucionó esto mezclando el orden de esa lista, aunque «tevador» advirtió que la dirección propia del nodo sigue apareciendo en todas las respuestas, solo que ahora en una posición distinta, lo que retrasa la identificación sin impedirla del todo. Por eso propuso otra solución: «insertar la propia dirección de forma aleatoria antes de truncar la lista a 250 pares», para que en algunas respuestas quede directamente afuera.

Las otras dos debilidades comentadas fueron:

• Sesgo en la selección de pares: un nodo prefiere como conexión saliente a los pares que informan una «altura de bloque» más alta (cuántos bloques dicen tener sincronizados), un dato que nadie verifica. Un atacante puede falsearlo para que sus propios nodos maliciosos parezcan más confiables y así ocupar esas conexiones, el paso necesario para capturar la transacción en la etapa 2. El desarrollador «syntheticbird» lo calificó como el problema más grave.

• Ausencia de límite de frecuencia en los mensajes de sincronización horaria: un atacante puede enviar todos los que necesite para completar la marca de agua de la etapa 3 sin que el nodo objetivo corte la conexión.

El ex líder de Monero calmó las aguas

Riccardo Spagni, ex mantenedor principal de Monero, sostuvo que se trata de «un ataque de develamiento de dirección IP enfocado en Tor». Con esa distinción, Spagni remarca que el problema no compromete la privacidad de quién es dueño de esa dirección IP en el mundo real (algo que exigiría, además, poder asociarla con una persona concreta), sino apenas la posibilidad de vincular una dirección IP con la dirección ‘.onion’ que un nodo eligió mantener en secreto usando Tor.

También calificó la ejecución del ataque de «totalmente inviable» dado el volumen de capacidad de repetidores de guardia de Tor que exigiría, cercano al de un actor estatal. Ese cálculo depende de cuántos de esos repetidores controle el atacante entre los miles que existen en toda la red Tor, ya que solo si el nodo de Monero elige, al azar, a uno de los repetidores maliciosos como su puerta de entrada, el atacante llega a ver su dirección IP real.

El propio estudio respalda el cálculo de Spagni: con 1.000 máquinas maliciosas operando repetidores Tor de 20 MB/s cada una, la probabilidad de ubicar en la práctica a un nodo de servicio oculto llega al 46%, y baja al 27% si el objetivo es un nodo cliente de Tor.

Finalmente, los desarrolladores de Monero discuten posibles mitigaciones: controles de sensatez sobre las listas de pares que un nodo recibe, límites de frecuencia para los mensajes de sincronización horaria y una eventual extensión del protocolo Dandelion++ (que hoy protege la privacidad de red sobre direcciones IPv4 comunes) hacia el tráfico que circula por Tor. Ninguna de esas propuestas tiene, por ahora, una fecha de implementación confirmada.