Bug de aprobación en Hedgey Finance

El 19 de abril de 2024, el protocolo DeFi de vesting y distribución de tokens Hedgey Finance sufrió exploits duales en Arbitrum (~42,6 M$) y Ethereum (~2,1 M$) por una pérdida combinada de 44,7 M$. El bug era una verificación de parámetro ausente en una sola función de contrato.

Qué ocurrió

Hedgey proporcionaba campañas de vesting y reclamación: los proyectos podían bloquear tokens en contratos de Hedgey y dejar que los destinatarios reclamaran su parte según los calendarios de vesting. La función de contrato createLockedCampaign era responsable de configurar nuevas campañas y aceptaba varios parámetros que describían los términos de lockup de la campaña.

La función validaba la mayoría de esos parámetros, pero no la configuración claimLockup, que determinaba qué transferencias y aprobaciones de tokens se adjuntaban a cada reclamación. Al enviar una llamada createLockedCampaign con un claimLockup malicioso, el atacante podía hacer que el contrato emitiera aprobaciones sobre los tokens de la víctima a una dirección elegida por el atacante.

Un préstamo flash financió el capital temporal necesario para configurar la campaña maliciosa y disparar el patrón de aprobación. Una vez que las aprobaciones existían on-chain, el atacante llamó a transferFrom y drenó tokens —USDC, NOBL, MASA, BONUS— de cuentas cuyos propietarios habían interactuado alguna vez con los contratos de Hedgey.

Consecuencias

• Hedgey pausó los contratos afectados y envió un mensaje on-chain al atacante solicitando la devolución de fondos y ofreciendo trato de sombrero blanco.
• El equipo migró a un contrato de campaña rediseñado con validación explícita en cada parámetro.
• El atacante no respondió a la oferta de recompensa; los fondos fueron lavados.

Por qué importa

Hedgey reforzó la verdad poco glamurosa de que cada parámetro de entrada es parte de la frontera de confianza, particularmente en protocolos que toman configuración de callback de los usuarios. Un único campo no verificado en una función setter privilegiada basta para comprometer todo un protocolo; la respuesta defensiva es allowlists de parámetros con denegación por defecto, verificación formal de cobertura completa de parámetros e invariantes a nivel de contrato que no puedan ser violados por ninguna combinación de entradas.