Dos errores diferentes en un fork del protocolo de investing con apalancamiento de la Purple de Gains podrían haber permitido a los traders obtener un beneficio del 900% en cada operación, independientemente del precio del token negociado, según un informe del 19 de abril de la firma de seguridad blockchain Zellic. Uno de los errores existía en una versión anterior de Gains pero fue parcheado posteriormente. El otro solo se encontró en un fork del protocolo.
Según Zellic, su particular informó a los desarrolladores de los forks de Gains Gambit Trade, Holdstation Trade y Krav Trade sobre la vulnerabilidad, y estos equipos de desarrollo se han asegurado de que sus protocolos no contengan tales dos fallos. Sin embargo, Zellic advirtió que otros forks de Gains aún podrían ser vulnerables.
Según su sitio world-wide-web oficial, Gains Network es un ecosistema de productos de finanzas descentralizadas (DeFi) en Polygon y Arbitrum. El nombre oficial de su aplicación de buying and selling con apalancamiento es «gTrade». Ha facilitado más de USD 25 mil millones en volumen de derivados desde su creación en mayo de 2023, según la plataforma de análisis blockchain DefiLlama.
Zellic afirmó que varias aplicaciones de investing DeFi populares derivan del código foundation de Gains Community, incluidas las mencionadas anteriormente Gambit Trade y Holdstation, así como muchos otros protocolos. Descubrieron el exploit mientras estudiaban un fork en distinct, pero declinaron nombrar en cuál lo descubrieron.
Según el informe, los contratos de Gains Network permiten a los usuarios abrir una orden de buying and selling de mercado, de reversión o de momentum. Una orden de mercado compra o vende un activo de inmediato, independientemente del precio.
Cuando un usuario solicita abrir una operación de momentum o de reversión, el contrato inteligente registra una «orden» que contiene datos sobre a qué precio está dispuesto el usuario a negociar. Una vez que se alcanza este precio, cualquier usuario puede llamar a la función executeLimitOrder para llenar la orden. El usuario que llama a la ejecución no tiene que ser el mismo que colocó la orden. Los usuarios que llaman a la ejecución reciben una pequeña «tarifa de ejecución» por desempeñar este papel.
Esto permite a los usuarios colocar órdenes límite (momentum) y órdenes límite de parada (reversión) de manera related a como lo harían en un exchange centralizado, pero sin necesidad de una entidad centralizada para realizar el llenado de órdenes.
Cuando un usuario coloca una orden, puede establecer un precio de toma de ganancias, un precio de prevent-loss o ambos. La intención de este diseño es permitir a los traders salir automáticamente de una operación rentable en el punto de toma de ganancias o de una operación perdedora en el punto de halt-loss.
Un mistake en el fork de Gains permitía obtener una ganancia del 900% en las órdenes de compra
En el fork de Gains que estudió, Zellic descubrió que cuando se abría una orden, el precio de prevent-decline se almacenaba en la variable «currentPrice» utilizada para calcular las ganancias y pérdidas. Esto significaba que si un usuario podía establecer el quit-reduction por encima del precio de apertura, automáticamente podían obtener ganancias de cualquier operación.
Por ejemplo, consideremos un escenario en el que el precio de Bitcoin (BTC) era de USD 63,000 y el usuario ingresaba USD 62,000 como precio de apertura y USD 64,000 como cease-reduction. En este caso, si el precio caía a USD 62,000, la orden se llenaría. Pero el precio estaría inmediatamente por debajo de su end-reduction, desencadenando una salida automática.
Además, el prevent-decline establecido por el usuario se registraría como el precio real. Esto significaba que el usuario obtendría una ganancia de USD 2,000, aunque la ganancia correcta debería haber sido aproximadamente de USD . Esto podría haber permitido a un atacante obtener ganancias en cada operación y eventualmente agotar el protocolo de todos sus fondos.
Para prevenir este exploit, el protocolo contenía una verificación que lanzaba un mistake «wrong_sl» si el usuario intentaba establecer su prevent-loss por encima de su precio de apertura en una orden de compra.
Sin embargo, los investigadores descubrieron que esta verificación podía ser eludida en ciertas circunstancias.
Cuando un usuario abría por primera vez una orden, establecía el precio al que deseaba abrir la operación, que luego se registraba en la variable «openPrice». En este punto se realizaba la verificación. Sin embargo, la función utilizada para ejecutar una orden cambiaba esta variable al valor de «a.Rate», que period el precio precise más el impacto del precio debido a la orden abierta.
Esto significaba que si el usuario ingresaba un precio de apertura extremadamente alto, un ejecutor podía eludir la verificación simplemente ejecutando la orden. Esto también permitía al ejecutor llenar la orden a un precio de apertura por debajo del precio originalmente establecido.
Como ejemplo, Zellic consideró la concept de un atacante que coloca una orden para comprar un token a USD 100000e10 (USD 1 cuatrillón) y establece un end-loss a USD 1 menos que esto o USD 999.999999999999 billones. Una vez realizada la orden, el atacante luego ejecuta su propia orden, lo que hace que openPrice cambie de USD 100000e10 a cualquiera que sea el precio real después de tener en cuenta el impacto del precio de la operación.
La operación luego se ejecuta y se abre. Si el precio de apertura resultante está por debajo del end-decline que se estableció originalmente, ahora se puede cerrar ejecutando el prevent-reduction. Cuando el atacante ejecuta su propio prevent-decline, obtiene ganancias de la diferencia entre el precio de cierre y el precio del quit-reduction.
La operación habría resultado en una ganancia del 900% para el atacante, afirmó Zellic.
Este defecto no estaba presente en Gains Community en el momento en que el equipo de Zellic lo descubrió. Solo existía en la versión bifurcada que estaban investigando. Sin embargo, en el proceso de estudiar este problema, se encontraron con un segundo error que estaba presente en una versión anterior de Gains en sí mismo.
El segundo error permitió una ganancia del 900% en órdenes de venta
El segundo error permitió a los traders obtener una ganancia del 900% en órdenes de venta, independientemente de la acción del precio.
Cuando se cerraba una operación en la bifurcación de Gains, convertía el punto de cease-decline o get-earnings del usuario en una variable llamada «int», que luego se usaba para calcular la ganancia en términos porcentuales. Pero si un usuario ingresaba un valor de prevent-loss o get-gain que fuera exactamente 2^256-1, los cálculos resultantes habrían hecho que «int» se volviera negativo.
Esto se debía a que 2^256-1 es el valor máximo para números positivos en Ethereum, lo que hace que cualquier valor por encima de él se «desborde» o vuelva a comenzar en cero y porque el cálculo sumaba el precio de apertura a su complete. En el lenguaje de programación Solidity, 2^256-1 también se conoce como «type(uint256).max.»
Según Zellic, siempre que un atacante utilizara un apalancamiento outstanding a 9x, podrían obtener una ganancia del 900% con este exploit:
“Consideremos una orden de venta, con currentPrice como sort(uint256).max. El valor resultante de diff sería openPrice + 1 (int(kind(uint256).max) = -1 ), y por lo tanto, el porcentaje de ganancia sería casi igual a 100 * apalancamiento. Por lo tanto, si el apalancamiento es outstanding a 9, la función devolverá la ganancia como 900%.”
Había una verificación en el contrato que intentaba evitar que se ingresara 2^256-1 como choose-financial gain. Sin embargo, esta verificación solo se realizaba en el momento en que se abría por primera vez la orden. Si el usuario cambiaba su punto de get-earnings después de que se abriera la orden, podían eludir la verificación e ingresar 2^256-1 como el consider-earnings, lo que les permitía obtener una ganancia automática del 900% cada vez que operaban.
Este segundo defecto sí existía en una versión anterior de Gains pero posteriormente se parcheó. La versión actual no contiene este defecto, ya que realiza la verificación cuando se actualizan tanto el just take-earnings como el stop-decline, así como cuando se establecen por primera vez.
Según informes, Zellic informó a todas las bifurcaciones mencionadas anteriormente sobre estos dos fallos de seguridad y contactó a la Crypto Security Alliance en un intento de encontrar otros protocolos que puedan verse afectados por ellos. Sin embargo, advirtió que algunas bifurcaciones de Gains aún pueden contener estos errores, poniendo los fondos de los usuarios en riesgo de ser drenados.
Noticias Blockchain se puso en contacto con Gains Network, Gambit Trade, Holdstation Trade y Krav Trade para obtener comentarios, pero no recibió respuesta al cierre de esta edición.
Gains Network afirma que proporciona el «precio real al contado» de los activos listados, en contraposición a lo que considera precios menos precisos basados en contratos perpetuos. También afirma ofrecer un buying and selling de divisas top-quality en comparación con competidores.
Aclaración: La información y/u opiniones emitidas en este artículo no representan necesariamente los puntos de vista o la línea editorial de Noticias Blockchain. La información aquí expuesta no debe ser tomada como consejo financiero o recomendación de inversión. Toda inversión y movimiento comercial implican riesgos y es responsabilidad de cada persona hacer su debida investigación antes de tomar una decisión de inversión.
