Con más de 20 juegos, numerosos socios y unos ingresos anuales que superan los 100 millones de dólares, FortuneJack es líder en el sector de los videojuegos descentralizados. En el corazón de este ecosistema se encuentra JackToken, un token de utilidad para videojuegos diseñado para ofrecer a los usuarios oportunidades de staking, participación en los beneficios y desarrollo de juegos. Más allá de su función como moneda, JackToken permite a FortuneJack apoyar a estudios de videojuegos descentralizados e incubadoras, impulsando así la innovación en la industria de los videojuegos.

Para garantizar la seguridad y el correcto funcionamiento de sus contratos BEP20 JackToken, de staking y de vesting, FortuneJack se ha asociado con AuditOne para llevar a cabo una auditoría exhaustiva de los contratos inteligentes. Estos mecanismos son esenciales para el ecosistema:

• El staking permite a los usuarios bloquear sus tokens, lo que contribuye al funcionamiento de la red y, a cambio, les permite obtener recompensas.
• El periodo de carencia garantiza que los tokens se distribuyan de forma gradual a lo largo del tiempo, lo que fomenta el compromiso a largo plazo y reduce los riesgos de liquidación.

La tecnología blockchain aporta un nivel adicional de fiabilidad, al eliminar los puntos únicos de fallo y las modificaciones no autorizadas. Sin embargo, incluso la tecnología más sólida requiere un escrutinio minucioso. Ahí es donde entró en escena AuditOne: para garantizar que estos contratos inteligentes mantuvieran la confianza de la comunidad.

La amenaza de los ataques DoS: una vulnerabilidad oculta

Una de las vulnerabilidades más alarmantes detectadas durante la revisión de AuditOne del proyecto JackToken fue una amenaza de denegación de servicio (DoS). Este problema podía alterar el mecanismo de retirada del contrato de staking, bloqueando los fondos de los usuarios y minando la confianza en el protocolo. 

A continuación se explica cómo podría desarrollarse este exploit y cómo se mitigó:

Imagina a un atacante que posee una pequeña cantidad de JackToken, pero que pretende alterar todo el mecanismo de staking. Así es como podría aprovechar la vulnerabilidad:

1. Creación de numerosas direcciones: El atacante genera múltiples direcciones utilizando el código de operación CREATE2, una técnica que permite la creación predecible de nuevas direcciones.
2. Distribución de pequeñas participaciones: Se transfiere una pequeña cantidad de JackToken a cada una de estas direcciones.
3. Ampliar el stakersArray: Estas direcciones se utilizan para apostar tokens repetidamente, lo que amplía enormemente el stakersArray.

Cuando los usuarios legítimos intentan retirar sus tokens apostados, la función de retirada debe recorrer el array `stakersArray`, que está sobrecargado. Esta sobrecarga podría superar el límite de gas, lo que provocaría que la transacción fallara o se revirtiera, bloqueando de hecho los fondos de los usuarios.

Desglose de las causas fundamentales y las vulnerabilidades

El problema no se debió a los contratos inteligentes de JackToken, sino a una integración con el contrato Staking20 de Thirdweb. La causa del problema radicaba en la ausencia de un requisito mínimo de participación, lo que dejó al sistema expuesto a posibles abusos. Esta vulnerabilidad permitió que incluso cantidades mínimas de tokens ampliaran exponencialmente el stakersArray, lo que podía paralizar el mecanismo de staking.

La estrategia del atacante

1. Creación de direcciones: Mediante el código de operación CREATE2, el atacante genera numerosas direcciones nuevas de forma predecible para cada depósito.
2. Transferencia de tokens: Se transfiere una pequeña cantidad de JackToken a cada dirección de nueva creación.
3. Depósito de tokens: Estos tokens se depositan en el contrato de staking mediante la función STAKE.
4. Repetición del ciclo: El atacante repite este proceso, lo que provoca que el tamaño de stakersArray aumente considerablemente.

Repercusiones para los usuarios

Cuando los usuarios legítimos intentan retirar sus tokens apostados, la función de retirada recorre el array «stakersArray», cuyo tamaño es excesivo. Este proceso puede superar el límite de gas, lo que provoca que las transacciones fallen o se reviertan, bloqueando de hecho los fondos de los usuarios.

Un análisis en profundidad de los mecanismos

‍

1. Staking20.sol: se ha invocado la función stake. 
2. JackStaking.sol - Se llama a la función _stake. Esta actualiza el

lastStakeTimes y llamar a la función _stake en Staking20.sol.

3. Staking20.sol: se ha llamado a la función _stake. 

‍

• Comprueba que el importe de la apuesta no sea cero.

‍

require(_amount != 0, "Apostar 0 tokens"); - solo comprueba que ≠ 0

‍

• Si el participante actual [_stakeMsgSender] no tiene ningún «amountStaked», se añadirá un nuevo [_stakeMsgSender] a la matriz «stakersArray».
• La transferencia del token se llevará a cabo correctamente mediante safeTransferBEP20.
  ‍

En esta situación, los clientes habituales apuestan sus tokens sin sospechar nada. Sin embargo, cuando una persona intenta retirar la totalidad de la cantidad apostada, puede encontrarse con problemas debido a las acciones del atacante.

El proceso de retirada implica recorrer el _stakersArray. Dado que el atacante ha ampliado considerablemente este array, la operación también puede superar el límite de gas, lo que provocaría que la transacción fallara o se revirtiera. La gravedad de este problema depende de la intención del atacante y de los recursos que destine a perturbar el protocolo.

La solución: subir la apuesta

AuditOne recomendó implementar una cantidad mínima de staking en la función _stake. Al exigir a los usuarios que apostaran al menos un token (ajustado según los decimales del token), el protocolo impidió de forma efectiva que los atacantes se aprovecharan del mecanismo de staking. Esta solución, sencilla pero eficaz, garantizó que los usuarios legítimos pudieran seguir apostando y retirando tokens sin interrupciones.

Otros retos a los que se enfrentan

Aunque el problema relacionado con los ataques de denegación de servicio (DoS) era el más urgente, la auditoría también identificó otras áreas susceptibles de mejora:

• Falta una comprobación del parámetro `maxVestingTime` en la función `addVesting`.
• Un error en la lógica de LastStakeTime que podría prolongar innecesariamente los periodos de staking.
• Bibliotecas AccessControl heredadas que no se utilizan.
• Oportunidades de optimización del consumo de gas.

Estos hallazgos críticos, junto con la vulnerabilidad de denegación de servicio, se resolvieron minuciosamente para crear un sistema más resistente y seguro.

Descubre el análisis completo de estos y otros datos en nuestro vídeo de análisis detallado.

Comprueba tu contrato inteligente de forma gratuita: https://services.auditone.io/security-checklist
Reserva tu consulta gratuita sobre seguridad:

Google Calendar: https://calendar.app.google/Ai15eyQhiV5c1pBXA
Telegram: https://t.me/m_ndr