Seguridad en las transacciones en el protocolo Bitcoin - Ataque Eclipse - Criptotendencias - Noticias de bitcoin, criptomonedas y blockchain

Seguridad en las transacciones en el protocolo Bitcoin – Ataque Eclipse

Las transacciones en el protocolo Bitcoin, un enfoque del ataque Eclipse, su modo de operación, la explotación que incide en la cadena de bloques P2P y las contramedidas para su mitigación.

La regulación de Bitcoin podría evitar un colapso financiero según investigadores
Comparte este post en tus redes sociales

En esta entrega, daremos un espacio a los tipos de ataque que en su momento fue sometido el protocolo Bitcoin y bajo los cuales, gracias a la implementación de políticas de seguridad implementadas por la comunidad de desarrolladores, la gran mayoría de ellas se han mitigado.

Con la reciente actualización del Bitcoin Core a la versión 0.19.0.1, se han establecido mejoras significativas en cuanto a la seguridad del protocolo. Sin embargo, como cultura general y técnica es importante mencionar estos ataques que nos ayudará a tener una mejor comprensión de cómo funciona su operación en la red.

Las transacciones

Primeramente, debemos recordar que básicamente una transacción está compuesta de los hashes de las transacciones previas y de la clave pública de la persona que recibirá ese monto tranzado, todo ello estará firmado por un emisor (pagador).

 

La clave pública refiere a la dirección de quien recibirá el monto acordado y la clave privada del emisor (pagador) firma la transacción en su conjunto y la comunica a toda la red P2P.

La verificación de las transacciones se fundamenta en que prácticamente cada moneda que se haya gastado es verificable en la cadena de bloques, es decir, está expuesta al escrutinio y validación por los nodos que conforman la red P2P.

Por lo tanto, cualquier par o nodo en la red (incluyendo lógicamente el receptor final) que reciba una transacción, revisará la firma, el formato y la validación de los campos (ingresos, egresos y las comisiones de los mineros). Cada nodo verifica que los bitcoins entrantes no hayan sido gastados con antelación, para ello revisa el historial de transacciones hechas en la red y hace su correspondiente confirmación en la red.

Con esta acción se previene un doble gasto de bitcoins en la red, esta es la razón principal por la que las transacciones son públicas y se valen del sincronismo en la comunicación entre los nodos que conforman en ecosistema cripto.

A modo de ejemplo, a medida que las transacciones de una criptomoneda se van propagando a la red, podemos ver en la siguiente figura cómo se van registrando las transacciones entre varios emisores y receptores en la cadena de bloques.

 

Habiendo visto a grosso modo el cómo se sustentan las transacciones, veamos ahora cómo se propagan en la red.

La propagación de las transacciones en la red Peer to Peer de Bitcoin

Los pares en la red Bitcoin están identificados por sus direcciones IP. Por lo tanto, un nodo con una dirección IP pública puede iniciar hasta 8 conexiones salientes con otros nodos de la red, y aceptar hasta 117 conexiones entrantes, estas conexiones se establecen mediante TCP, un nodo puede determinar si su par tiene una IP pública mediante una comparación con la cabecera del paquete y la versión del mensaje del nodo bitcoin.

En este sentido, la información en la red entre pares se propaga mediante dos servicios: Los DNS seeders que no son más que servidores que responden a consultas DNS provenientes de los nodos bitcoin con una lista de direcciones IP, hay que resaltar que esta lista no está autenticada ni cifrada. El seeder obtiene estas direcciones periódicamente haciendo consultas indexadas en la red bitcoin.

La red tiene 6 seeders que son invocados bajo dos situaciones:

1.- Cuando un nodo nuevo se agrega a la red por primera vez, ésta trata de conectarse a los seeders para obtener una lista activa de direcciones IP.

2.- Cuando un nodo existente se reinicia y se reconecta con sus pares.

El segundo servicio o recurso, son los mensajes addr, que contienen hasta 1000 direcciones IP y sus respectivos sellos de tiempo, los cuales son usados para obtener información proveniente de sus pares. Los nodos aceptan mensajes addr no solicitados, sin embargo, este mensaje es requerido solo cuando se establece una conexión saliente hacia un nodo y este le responde con hasta tres mensajes addr cada uno contentivo de hasta 1000 direcciones aleatorias seleccionadas de sus tablas.

Entonces, ¿Cómo ocurre el ataque Eclipse a estas redes P2P?

El ataque de Eclipse (Eclipse Attack)

Este tipo de ataque tiene un enfoque interesante, en la cual se pretende monopolizar las conexiones de los nodos en el sistema, tal como lo muestra la investigación de Ethan Heilman y otros [1].

La idea detrás de este ataque consiste en ofuscar al nodo víctima para que no vea a los nodos honestos de la cadena de bloques, sino que solamente reciba conexiones entrantes y salientes de los nodos maliciosos, esto con la intención de perpetuar transacciones de doble gasto.

Es decir, el atacante podría poseer un gran número de direcciones IP a su disposición y controlar un conjunto de computadores que corran nodos en la red, por ejemplo, una botnet controlada por un proveedor de servicios de Internet, de esta manera, el atacante puede dirigir una denegación de servicios que obligue a la víctima a reestablecer el software cliente Bitcoin mediante una actualización de servicios (upgrade).

Recordemos que un nodo cliente Bitcoin almacena las direcciones IP que han sido anunciadas por la red, mediante el intercambio de messages addr entre los pares, estos mensajes contienen la dirección IP asociada al nodo y sus respectivos sellos de tiempo. Se emplean dos tablas para almacenas estas direcciones públicas, las tried tables y las new tables. La tabla tried contiene a su vez 64 buckets que progresivamente van guardando hasta 64 direcciones IP de aquellos nodos con los cuales se han establecido conexiones en el pasado, inclusive los sellos de tiempo.

La tabla new contiene 256 buckets, cada una contiene hasta 64 direcciones IP únicas.

Cuando se establece por primera vez conexión con un nodo, éste se almacena en la tabla tried, si la tabla está llena, se reescribe en una posición aleatoria, y se descarta la dirección IP que estuvo en ese lugar. Esto deja en evidencia que para el atacante es importante hacer que el nodo victima establezca comunicación con la dirección IP de un nodo malicioso desde la tabla tried, para ello inunda esta tabla con direcciones bajo su control.

De esta manera, cuando el nodo víctima, se vea forzado a reiniciarse, la selección del nodo a quien establecería conexión está supeditada a aquellas direcciones IP de reciente sello de tiempo, y como el atacante ha inundado la tabla tried con direcciones IP bajo su control y la tabla new con direcciones inexistentes, tendrá la garantía de que la víctima efectivamente establecerá conexión con un nodo bajo el control del atacante.

El ataque de Eclipse tiene entonces los siguientes pasos:

1.- Explotar la política de conectividad que usa la red Bitcoin entre sus pares P2P, aplicando estrategia de llenado de direcciones IP basura a las tablas new y de IP comprometidas por el atacante a las tablas tried.

2.- Reiniciar al nodo víctima, bien sea aplicando denegación de servicios o alguna técnica que provoque el cuelgue del sistema operativo o la memoria de los nodos.

3.- Tomar el control de las conexiones entrantes y salientes del nodo víctima, tomando en cuenta la probabilidad de éxito y la condición de selección aleatoria de las IP comprometidas provenientes de las tabla tried.

4.- Con los puntos 1, 2 y 3, se explota la vulnerabilidad en la política de conexiones y se logra eclipsar a la víctima (monopolización de la conectividad de ella con el resto de los nodos de la red).

Hay un conjunto de implicaciones y contramedidas que se pueden derivar de este ataque en particular:

Implicaciones:

El atacante puede incrementar la ventaja de selfish mining, reduciendo la potencia de minado en los nodos honestos de la red

El atacante puede ejecutar transacciones de doble gasto, inclusive si éstas han sido confirmadas con 6 bloques consecutivos.

Contramedidas

Asegurar que se utilicen hashes para validar el uso de las direcciones IP, en el mismo bucket y en la misma localidad en la tabla tried. De esta manera se evita que el atacante reuse las mismas direcciones IP más de una vez para llenar la tabla.

Implementar políticas que eviten dar prioridad a aquellas direcciones IP que tengan un sello de tiempo más reciente, lo cual incrementaría la probabilidad de conectarse a la dirección IP del atacante.

Implementar un mecanismo de comprobación que la dirección IP existe, mediante la ejecución de un ping, antes de sobre escribir la dirección existente en las tablas tried y new.

Implementar añadir más buckets de manera que sea más difícil ejecutar este tipo de ataque.

Para cerrar este artículo, citemos a Andreas Antonopoulos en su libro Developing Bitcoin Systems Securely – Mastering Bitcoin_Programming the Open Blockchain 

“In simple terms: don’t take control of keys away from users and don’t take transactions off the blockchain.”

En la próxima entrega seguiremos viendo otros tipos de ataques conocidos en la red P2P que emplea el protocolo Bitcoin.

Referencias:

[1]  Eclipse Attacks on Bitcoin’s Peer-to-Peer Network
Ethan Heilman and Alison Kendler, Boston University; Aviv Zohar, The Hebrew University of
Jerusalem and MSR Israel;
Sharon Goldberg, Boston University

https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/heilman

Únete a nosotros en Telegram y Twitter; además puedes escuchar nuestros Podcast

Abre una cuenta en Binance y recibe 10% de descuento en comisiones con nuestro Link