Introducción
Un ataque eclipse es un ataque relativamente simple que un actor malintencionado puede implementar para interferir con los nodos de una red. Como sugiere el nombre, el ataque tiene como objetivo oscurecer la visión de un participante de la red peer-to-peer, con el fin de causar una interrupción general o prepararse para ataques más sofisticados.
Los ataques de Eclipse pueden parecer similares, en la superficie, a los ataques de Sybil. Si bien comparten ciertas similitudes (el actor malicioso inundará la red con pares falsos), su objetivo final es, en última instancia, diferente. Un ataque eclipse tiene como objetivo un solo nodo (por razones explicadas en una sección posterior), mientras que un ataque Sybil es un ataque a toda la red diseñado para jugar con el sistema de reputación del protocolo.
El concepto se analiza detalladamente en el artículo de 2015 Eclipse Attacks on Bitcoin's Peer-to-Peer Network, en el que investigadores de la Universidad de Boston y la Universidad Hebrea informan sobre los hallazgos de sus experimentos sobre los crecientes ataques de eclipse, así como posibles contramedidas para combatirlos.
Cómo funciona un ataque de eclipse
Los mineros de Bitcoin requieren equipos especializados para generar nuevos bloques, pero los nodos no mineros (o completos) se ejecutan fácilmente con una potencia computacional mínima. Esto ayuda a la descentralización de Bitcoin, ya que cualquiera puede activar un nodo en un dispositivo de baja especificación. El software mantiene una base de datos de transacciones que sincroniza con sus pares inmediatos, para permanecer en sintonía con la red.
Un factor limitante para muchos nodos es el ancho de banda. Aunque hay una enorme cantidad de dispositivos que ejecutan el software, el dispositivo promedio no puede conectarse directamente a muchos de ellos debido a las limitaciones establecidas en el software Bitcoin (que sólo permite un máximo de 125 conexiones).
En un ataque eclipse, el actor malintencionado se asegurará de que todas las conexiones del objetivo se realicen a nodos controlados por el atacante. La entidad primero inundará al objetivo con sus propias direcciones IP, a las que la víctima probablemente se conectará al reiniciar su software. Se puede forzar un reinicio (es decir, con un ataque DDoS al objetivo) o el atacante puede simplemente esperar a que ocurra.
Una vez que esto ha ocurrido, la víctima desprevenida queda a merced de los nodos maliciosos: sin visión de la red más amplia, el atacante puede proporcionarles datos incorrectos.
Consecuencias de un ataque de eclipse
Si un atacante está gastando recursos para alejar a un par de la red, probablemente tenga un motivo para hacerlo. Hay varios ataques sucesivos que pueden lanzarse más fácilmente una vez que un nodo ha sido asfixiado.
Gastos dobles de confirmación 0
Si una persona acepta una transacción sin confirmaciones, corre el riesgo de realizar un doble gasto. Es posible que la transacción se haya transmitido, pero hasta que se haya incluido en un bloque (y, por lo tanto, comprometido en la cadena de bloques), el remitente puede crear fácilmente una nueva transacción que gaste los mismos fondos en otro lugar. Si la nueva transacción tiene una tarifa más alta, es probable que un minero la incluya antes que la original, invalidando la anterior.
Algunas empresas e individuos aceptan estas transacciones de confirmación 0. Consideremos un comerciante, Bob, que vende vehículos de alta gama. Él no se da cuenta de que Alice ha eclipsado su nodo y no sospecha nada cuando hace un pedido de un automóvil deportivo de lujo. Ella crea una transacción, que Bob luego transmite a la red. Satisfecho de que el pago esté en camino, le entrega las llaves del auto y Alice sale corriendo.
Por supuesto, la transacción no se transmitió a la red; Bob simplemente la transmitió a los nodos maliciosos de Alice, que no la transmitirán a los nodos honestos. Mientras esta transacción permanece en el limbo, Alice gasta los mismos fondos en la red (real), ya sea en otra parte o en una dirección de su propiedad. Incluso si finalmente se ve la transacción inicial a Bob, será rechazada porque las monedas ya se han gastado.
Gastos dobles de confirmación N
El doble gasto de confirmación N es similar al de confirmación 0, pero implica más preparación. Muchas empresas prefieren esperar un cierto número de confirmaciones antes de marcar un pago como válido. Para evitar esto, el atacante debe eclipsar tanto a los mineros como al comerciante. Una vez que el atacante ha configurado la orden con el comerciante, transmite una transacción a los mineros (eclipsados). La transacción se confirma y se incluye en la cadena de bloques, pero esta cadena de bloques no es la cadena que observa la mayoría de la red, ya que el minero está aislado.
A partir de ahí, el atacante transmite esta versión de la cadena de bloques al comerciante, quien entrega los productos creyendo que la transacción ha sido confirmada. Una vez que los nodos eclipsados se reincorporan a la red real, la cadena de bloques que erróneamente creen que es válida queda huérfana de aquella en la que el resto de la red ha estado trabajando (esto tiene algunas similitudes con un ataque del 51%).
Debilitar a los mineros competidores
Un nodo eclipsado seguirá funcionando, ajeno al hecho de que ha sido segregado de la red. Los mineros continuarán extrayendo bloques dentro de las reglas establecidas por el protocolo, pero los bloques agregados se descartarán a medida que se sincronicen con pares honestos.
En teoría, un ataque de eclipse a gran escala contra los principales mineros podría usarse para facilitar un ataque del 51%. Tal como están las cosas, el costo de hacerse cargo de la mayor parte del poder de hash de Bitcoin es simplemente demasiado alto incluso para los atacantes más ingeniosos: a ~80TH/s, la entidad necesitaría más de 40TH/s para intentar tal maniobra.
En un escenario hipotético en el que este poder de hash se distribuye entre 10 partes (de modo que cada una posee 8TH/s), el atacante puede reducir significativamente los requisitos para un ataque del 51 % cortando a estas partes de la red. Si cinco son eclipsados, 40TH/s se eliminan de la carrera para encontrar el siguiente bloque, y el atacante ahora sólo necesita adquirir un poco más de 20TH/s para tomar el control.
Otro sabotaje que se puede lograr eclipsando objetivos incluye la manipulación de nodos para una minería egoísta o la ingeniería de carreras entre mineros para encontrar el siguiente bloque.
Mitigación
Con suficientes direcciones IP, un atacante puede eclipsar cualquier nodo. El método más sencillo para evitar que esto suceda es que un operador bloquee las conexiones entrantes y solo realice conexiones salientes a nodos específicos (como aquellos que otros pares han incluido en la lista blanca). Sin embargo, como señala el artículo de investigación, este no es un enfoque que funcione a escala: si todos los participantes adoptan estas medidas, nuevos nodos no podrán unirse a la red.
Los autores proponen algunos ajustes al software de Bitcoin, algunos de los cuales se han integrado desde la publicación del artículo. Estos hacen que los ataques de eclipse sean más costosos a través de modificaciones menores en el código, como la selección aleatoria de nuevas conexiones y una mayor capacidad para almacenar direcciones.
Pensamientos finales
Los ataques de Eclipse se llevan a cabo a nivel de red de igual a igual. Implementados como un ataque independiente, pueden resultar una especie de molestia. Su verdadera efectividad es potenciar otros ataques que impactan financieramente a los objetivos o brindan al atacante una ventaja en el frente minero.
En la naturaleza, todavía no se han producido consecuencias graves por un ataque de eclipse, pero la amenaza sigue existiendo a pesar de las contramedidas integradas en la red. Como ocurre con la mayoría de los vectores de ataque que existen para Bitcoin y otras criptomonedas, la defensa más fuerte será aquella que haga financieramente prohibitivo que partes malintencionadas los intenten.
