-
Las carteras afectadas podrían reflejar un balance superior al real.
-
ZenGo notificó a las compañías afectadas sobre la vulnerabilidad hace tres meses.
Desarrolladores de la cartera de criptomonedas ZenGo revelaron este jueves 2 de julio una vulnerabilidad que exponía a varias carteras de Bitcoin a ataques de doble gasto. Esto pues las carteras reflejaban un incremento de balance por transacciones no confirmadas, que no decrecía cuando las transacciones eran canceladas.
ZenGo señala en su reporte que se trata de un conjunto de vulnerabilidades a las que denomina «BigSpender» y que afecta a carteras de Bitcoin conocidas, entre las cuales menciona a Ledger Live, BRD y Edge. Estas vulnerabilidades «pueden exponer a los usuarios a ataques de gastos dobles y múltiples (de allí el nombre BigSpender) y potencialmente impedir que gasten su balance», dice el reporte.
El riesgo de doble gasto
La principal vulnerabilidad que aprovecha BigSpender, según ZenGO, es que las carteras vulnerables no estaban preparadas para la opción de que una transacción pueda ser cancelada a través de la funcionalidad Replace by Fee (RBF) -explicada más abajo- e implícitamente asumían que sería finalmente confirmada.
Una de las consecuencias de esta falla es que el balance de la cartera aumenta con una transacción entrante no confirmada. Aún si la transacción es cancelada, en la cartera vulnerable no se refleja la cancelación y el balance queda falsamente aumentado.
Aprovechando esta falla, los potenciales atacantes pueden enviar a la víctima potencial una transacción con comisiones mínimas, para retrasar la confirmación de esta. Solicitarían bienes o servicios a cambio de los fondos enviados y cancelarían inmediatamente la transacción. Las carteras vulnerables no restituirían el balance de acuerdo a la cancelación y este quedaría reflejando un valor mayor que el real.
Si el receptor de la transacción entrega el producto correspondiente, habría sido robado sin advertirlo, por la falla de su cartera.
Cancelación de transacciones
Para que el atacante pueda cancelar una transacción, la envía con comisiones mínimas y la marca como reemplazable. La primera condición garantiza que dicha transacción demorará en ser confirmada, mientras que la segunda condición permite reemplazar la primera transacción por otra que envíe las mismas monedas, pero con comisión mayor –para acelerar su confirmación-. Este método es posible gracias al protocolo Replace by Fee o RBF.
El atacante coloca como salida de esa segunda transacción, otra dirección diferente a la de la cartera de la víctima potencial. Al ser confirmada esta, la primera transacción enviada queda anulada. Usando RBF, se envían los fondos a una dirección diferente de la original, pero que esté bajo control del atacante.
Tanto los desarrolladores de carteras como los usuarios deben asegurarse de que su cartera haga un manejo adecuado de las transacciones RBF, señala ZenGo. Los usuarios deben comprobar que una transacción está confirmada antes de entregar cualquier producto o servicio, mientras que los desarrolladores deben asegurarse de que las transacciones pendientes no incrementen el balance de la cartera antes de que estén confirmadas.
Otras modalidades de los ataques
Una segunda modalidad de este ataque consistía en hacerlo repetitivo para inflar artificialmente el balance que refleja la cartera vulnerable y poder reclamar más bienes o servicios. Un atacante podría, con 10 dólares en saldo, realizar un gasto por un producto de hasta mil dólares.
Aun si la víctima advierte que está siendo atacada y no entrega ningún producto a cambio de los supuestos fondos recibidos, aún puede ser víctima de un tercer tipo de ataque, similar a una denegación de servicio.
En este escenario, como la cartera tiene el balance incorrecto fallaría en algunas acciones, por ejemplo, en la función “Enviar todos los fondos”. También habría fallas cuando la cartera intente extraer fondos de una transacción no existente, refiere ZenGo.
Protección ante el ataque
Como protección y mitigación, desde ZenGo recomiendan a los usuarios utilizar solo carteras que manejen las transacciones marcadas con RBF de manera correcta, es decir, sin reflejar el saldo antes de la confirmación.
En caso de usar una cartera vulnerable, el usuario debe verificar en un explorador de bloques que la transacción haya sido confirmada antes de entregar cualquier bien o servicio.
Los desarrolladores, por su parte, deben verificar el comportamiento de sus aplicaciones respecto a cancelaciones y transacciones con RBF. Un correctivo podría ser colocar las transacciones pendientes aparte de las confirmadas y no sumarlas al balance total antes de que todo esté en orden. Si la transacción es cancelada, esto debe reflejarse en el historial de transacciones del usuario.
Para contribuir a la corrección de la solución, ZenGo puso a disposición de los desarrolladores una herramienta en su GitHub.
En la tabla siguiente aparecen los detalles de las carteras vulnerables respecto a los tres ataques y las nuevas versiones de las mismas que corrigen la vulnerabilidad.
Como se aprecia en la tabla, las carteras BRD y Ledger Live cuentan con nuevas versiones que resuelven las fallas detectadas, mientras que la cartera Edge continúa con la vulnerabilidad básica, si bien se encuentra en proceso de corrección. Se recomienda a los usuarios actualizar a las últimas versiones para protegerse de la vulnerabilidad.
CriptoNoticias reportó que en diciembre pasado el equipo de Kraken Security Labs encontró una vulnerabilidad grave en las carteras frías de criptomonedas KeepKey, que les permitió extraer semillas, con solo tener acceso físico a la billetera durante aproximadamente 15 minutos. Los analistas de Kraken Security Labs señalaron que, para identificar la vulnerabilidad, realizaron un ataque de falla de voltaje o voltage glitching mediante el cual lograron extraer la semilla encriptada.
