BTC también tiene el Bosque Oscuro: exponer bots maliciosos en la cadena

Autor: Tal Be'ery

Fuente:

Traducción: Blockchain vernáculo

Los investigadores de Zengo revelaron que los bots maliciosos estaban monitoreando la existencia de direcciones aleatorias inseguras en BTC cadenas de bloques e inmediatamente las explotaron para cometer robos, causando millones de dólares en pérdidas, una de las cuales ocurrió el 23 de noviembre de 2023.

Como parte de la investigación en curso de Zengo X en el campo de la seguridad de la cadena de bloques, investigamos el caso de los 139 BTC recientemente perdidos, que ascendían a unos 5,5 millones de dólares en ese momento. Sin que lo supiéramos, al hacerlo, abrimos BTC caja de Pandora del Bosque Oscuro.

En 2020, los investigadores de Paradigm Dan Robinson y Georgios Konstantopoulos publicaron una influyente entrada en el blog titulada “ETH Workshop is a Dark Forest” ( Workshop es un bosque oscuro): revelando los bots que acechan en la oscuridad de los grupos de memoria de ETH Workshop, monitoreando las transacciones pendientes y tratando de capitalizar las lucrativas oportunidades que crean. **

Hoy, revelamos que este fenómeno no se limita a ETH blockchains, sino que también se aplica a BTC blockchains (y posiblemente a muchas otras).

1, este caso de tarifas excesivas

El 23 de noviembre, un acuerdo de BTC llamó la atención de BTC analistas. **Esta transacción estableció un récord para el pago de tarifas, pagando más de $3 millones (83 BTC) por la transferencia de $2 millones en BTC. **

Aunque la explicación inmediata de estas tarifas exorbitantes (que generalmente se supone que son menos de $ 10) es culparlas a algún tipo de error de escritura manual, como ha sucedido en el pasado, los usuarios no tardaron en afirmar que eran los propietarios originales de X (antes de Twitter) y que de alguna manera fueron pirateados. **

El propietario de la cuenta X demuestra criptográficamente que realmente posee la dirección BTC firmándola con la clave privada asociada.

2, nuestra investigación ha comenzado

A medida que comenzamos a investigar este exorbitante acuerdo de tarifas con más profundidad, surgen algunos hechos más sutiles pero interesantes.

Transacciones marcadas (Fuente: mempool.space)

Lo anterior muestra algunas ideas interesantes:

CPFP: Son las siglas de “Child Pays For Parent”, lo que significa que la entrada de esta transacción es la salida de otra transacción no confirmada. En este caso, significa que mientras la primera transacción estaba esperando en el mempool, se produjo la transacción cobrada en exceso. Según los datos del explorador, en realidad se envió en el mismo minuto que la transacción anterior. **El coste es exactamente el 60% del total gastado (83,65 / 139,4), por lo que es poco probable que sea un error, sino más bien el resultado de algún tipo de acción automatizada. **

RBF deshabilitado: el remitente de la transacción ha deshabilitado la opción “Reemplazar por tarifa” (RBF) o ha evitado que otras transacciones sobrescriban la transacción con una tarifa más alta. Además, otro usuario de X se dio cuenta de que inicialmente había varias transacciones candidatas por exceso de tarifa, que se sustituían entre sí por el pago de una tarifa más alta (ya no es visible en el explorador, ya que la información de la transacción reemplazada se borró en un corto período de tiempo).

3. Situación real: Supongamos primero

Con base en los datos, hay varias hipótesis posibles para explicar esta transacción de sobrecargo:

El propietario original pagó de más por un error tipográfico: la declaración del propietario sobre X fue solo para salvar las apariencias, ya que afirmar que había sido hackeado suena más aceptable que admitir que es torpe.

Nota: Esto no parece muy plausible, ya que la transacción se envió mientras la transacción anterior aún estaba en el mempool (ver CPFP arriba), lo que requería experiencia técnica, y la naturaleza exacta de la tarifa (exactamente el 60% de la tarifa total) no coincide con la entrada incorrecta o la teoría torpe general.

La clave privada del propietario original fue hackeada: el atacante reveló la clave privada y esperó a que el propietario enviara fondos a la dirección.

Nuestra opinión: Esto es poco probable porque RBF se adelantó a la transacción, lo que significa que varias partes conocen la clave privada.

La clave privada del propietario original es predecible: la clave privada se crea de alguna manera predecible, por ejemplo, mediante el hash de una frase de contraseña (“Brian-wallet”) o la selección de una clave de un conjunto que es demasiado pequeña (32 bits). Estos temas se discuten en profundidad en nuestra reciente publicación de blog.

Los atacantes están generando una colección de todas estas claves privadas predecibles y sus direcciones correspondientes, y cada vez que una transacción para enviar fondos a cualquiera de estas direcciones está en el mempool, son inmediatamente rápidos y se apresuran a enviar transacciones posteriores para transferir esos fondos a su dirección.

Esta última suposición lo explica todo: la respuesta inmediata (“CPFP” arriba) y las tarifas exorbitantes son lo que los atacantes tienen que hacer para derrotar a otros atacantes. El carácter “fijo” de la comisión (60%) se debe a la naturaleza automática de la operación, que es necesaria para vencer a las otras partes. La desactivación de RBF es otro mecanismo empleado por los atacantes para aumentar sus posibilidades de derrotar a otras partes.

Esta suposición también es coherente con el comportamiento pasado de la dirección en el extremo receptor de una transacción con una tarifa excesivamente alta. Muchas de las transacciones que fluyen hacia la dirección tienen las mismas características que esta transacción de alta tarifa (aunque no tan lucrativa como esta transacción multimillonaria).

El comportamiento de los atacantes es consistente (fuente: X/Twitter).

Esta conclusión es, por supuesto, una explicación muy aterradora y audaz que requiere más evidencia. **

4. Evidencia

Para verificar nuestras afirmaciones, decidimos generar una clave privada predecible, enviarle fondos y observar los resultados. Si nuestras suposiciones son correctas, entonces los fondos deberían ser robados inmediatamente. Para crear una clave privada no aleatoria y obtener la dirección generada, utilizamos la popular herramienta web de Ian Cloeman (que también ha funcionado bien en el pasado).

Establezca la clave privada en “1” (tenga en cuenta que la frase mnemotécnica generada se compone principalmente de la palabra “abandonar” con índice 0)

Usando esta herramienta, establecimos la clave privada en “1” y obtuvimos la dirección generada: bc1q4jgysxym8yvp6khka878njuh8dem4l7mneyefz. Comprobamos que no se había utilizado antes para descartar otras posibles explicaciones.

Luego enviamos una transacción de $10 a esta dirección… Como era de esperar, descubrimos que esto fue seguido por una transacción de tarifa exorbitante ($ 5, o 50%) que redirigió los fondos a otra dirección.

Además, observamos una feroz competencia entre múltiples partes que intentaban obtener una ventaja a través de RBF con tarifas más altas, que incluso ascendieron a casi el 99% de los fondos, pero estos intentos no tuvieron éxito debido a que la primera transacción deshabilitó RBF.

4 transacciones RBF, la última ofreció $9.87 de un total de $10 como tarifa.

5. Conclusión: Los monstruos existen

Si la frase semilla o la clave privada de un usuario se genera de manera predecible o está sujeta a una aleatoriedad no deseada, se explotará una vez que el atacante conozca los detalles exactos de la generación predecible. **

Como detallamos en nuestra reciente publicación de blog, la mayoría de los usuarios pasan por alto el problema de la generación segura de claves en las billeteras criptográficas, pero resulta ser un problema que afecta a las billeteras y causa grandes pérdidas.

Dado que los usuarios no pueden generar sus propias claves privadas, pero no pueden demostrar que las claves privadas son aleatorias, los usuarios no pueden verificar la aleatoriedad de sus claves y deben confiar en sus billeteras.

Este problema es otra manifestación de un problema central más grande que se basa en las billeteras de una sola parte. Para resolver este problema central, así como el problema específico de la aleatoriedad, debemos aceptar el hecho de que los usuarios necesitan confiar en algunas entidades externas y pasar a una arquitectura más robusta que reduzca la confianza en cada parte involucrada al aumentar el número de partes involucradas. **

Agregar participantes puede reducir la confianza requerida para cada participante y hacer que el sistema sea más sólido (consulte nuestra publicación de blog reciente para obtener más detalles).