La firma vacía que rompió Bonzo Lend: Un post-mortem del exploit de $9M en Hedera
2026/07/15 11:18:00
En matemáticas e informática, cero representa vacío: la ausencia absoluta de valor. Pero en el frágil y hiperconectado ecosistema de las Finanzas Descentralizadas (DeFi), un parámetro "cero" sin verificar recientemente se convirtió en una llave maestra digital. En cuestión de minutos, este único valor vacío sin verificar desbloqueó y vació más de $9 millones de una plataforma de préstamos destacada.
La víctima de este devastador exploit fue Bonzo Lend, el mayor protocolo de préstamo operando en la red Hedera. En julio de 2026, el protocolo vio cómo su Valor Total Bloqueado (TVL) se desplomaba un asombroso 77% en un instante. Mientras el pánico se extendía por la comunidad Hedera, los observadores se apresuraron a encontrar la fuente de la filtración.
Importante, este desastre no ocurrió porque el consenso de la red subyacente de Hedera fallara, ni tampoco porque los cálculos principales de préstamo de Bonzo Lend fueran incorrectos. En cambio, el desastre surgió de una vulnerabilidad de integración fatal: una falla crítica en la validación de firma dentro de su proveedor de fuentes de precios de terceros, Supra Oracles. Este es el post-mortem de cómo un pequeño error lógico relacionado con "nada" derribó a un gigante de DeFi.
Cronología del ataque: De $5 a $9,000,000 en segundos
La ejecución del exploit de Bonzo Lend fue brillante en su simplicidad, requiriendo un capital inicial mínimo y ocurriendo en solo unos pocos pasos transaccionales.
Para iniciar el robo, el atacante depositó una cantidad mínima y despreciable de garantía en Bonzo Lend: específicamente, 250 tokens SAUCE. En el momento del depósito, esta garantía valía solo unos pocos dólares, apenas suficiente para comprar una taza de café. Bajo las reglas normales del protocolo, este cambio de bolsillo permitiría al usuario tomar prestado solo una fracción de su valor en otros activos digitales.
Luego, el atacante inició la explotación eludiendo las verificaciones de validación del oracle de precios. Creó y envió una transacción de actualización de precio falsificada al contrato de validación del oracle. Esta transacción contenía datos altamente maliciosos: infló artificialmente el precio del token SAUCE en una asombrosa magnitud de 12 órdenes de magnitud, indicando efectivamente al protocolo que un solo token SAUCE valía de repente miles de millones de dólares.
Para impulsar este precio falsificado, el sistema requería una firma criptográfica de un nodo oráculo autorizado. En lugar de intentar romper la criptografía compleja o robar una clave privada, el atacante simplemente dejó el campo de firma completamente en blanco, enviando una cadena de ceros en lugar de una firma criptográfica.
Debido a una falla crítica en la lógica de validación, el contrato aceptó la firma en blanco como válida. Instantáneamente, el sistema de valuación de Bonzo registró los 250 SAUCE de garantía del atacante como un activo de valor monumental. Aprovechando esta riqueza repentina y artificial, el hacker retiró rápidamente 6.63 millones de USDC y 34.50 millones de HBAR envueltos (wHBAR) de los pools de liquidez de Bonzo, drenando exitosamente el protocolo antes de que se pudiera activar cualquier alarma.
Desmitificando la falla de "firma cero": cómo falló el código
Para entender cómo fue posible esta explotación, debemos desmitificar las matemáticas de las firmas digitales. En redes descentralizadas, las firmas criptográficas actúan como sellos de cera digitales. Cuando un nodo oracle publica una actualización de precio, firma los datos utilizando una clave privada. El contrato inteligente en el extremo receptor utiliza un algoritmo de verificación para confirmar que la firma coincide con la clave pública autorizada del nodo oracle.
Normalmente, si un usuario envía una firma inválida, la biblioteca de verificación intenta procesar la entrada y falla. Cuando las bibliotecas de verificación criptográfica encuentran entradas malformadas, vacías o completamente en ceros, no siempre generan un error activo. En cambio, muchas bibliotecas estándar están diseñadas para generar un valor predeterminado cuando no se puede analizar una firma. En contratos inteligentes, esta salida predeterminada es casi siempre una dirección nula representada por una larga cadena de ceros.
La vulnerabilidad fatal en el contrato de validación del oracle radicaba en cómo manejaba esta dirección nula predeterminada. El contrato estaba programado para verificar si el firmante recuperado coincidía con una dirección de nodo de oracle autorizada. Sin embargo, los desarrolladores olvidaron incluir una regla básica: rechazar cualquier entrada donde la longitud de la firma fuera cero o la dirección recuperada devolviera un valor nulo.
Además, si el estado del firmante autorizado dentro del contrato estaba sin inicializar o configurado de manera que permitía comprobaciones nulas, el contrato comparaba la dirección nula devuelta por la firma fallida con sus parámetros internos y declaraba una coincidencia. Debido a que la lógica de validación no logró distinguir entre una "recuperación de firma fallida" y un "firmante autorizado válido", el contrato trató la firma vacía como una luz verde absoluta, aprobando la fuente de precios falsificada.
El dilema del oráculo: por qué los bloques de DeFi son tan fuertes como su eslabón más débil
DeFi suele celebrarse por su "componibilidad": la capacidad de diferentes protocolos, tokens y herramientas para conectarse como "Lego financiero" para construir aplicaciones financieras complejas. Si bien la componibilidad permite una innovación rápida, también introduce fragilidad sistémica. Un solo defecto en un bloque fundamental puede derribar toda la pila estructural.
El exploit de Bonzo Lend ilustra perfectamente esta vulnerabilidad. Bonzo Lend era un protocolo de préstamo bien estructurado que había pasado auditorías de seguridad. Sin embargo, el protocolo tenía que confiar en su dependencia externa de oracle para proporcionar precios precisos. En el momento en que el sistema de validación del oracle aceptó el precio falso, los contratos de préstamo de Bonzo se ejecutaron exactamente como estaban escritos, permitiendo al usuario "rico" altamente respaldado tomar prestados activos.
La tabla a continuación desglosa la distribución de las responsabilidades estructurales durante el ataque, ilustrando dónde colapsó la línea defensiva:
| Componente | Rol sistémico previsto | Rendimiento durante el exploit | Lección estructural |
| Capa de Consenso de Hedera | Mantenga seguro el estado del libro mayor, ordene las transacciones y asegure la disponibilidad de la red. | Funcionó perfectamente sin tiempo de inactividad ni explotaciones a nivel de red. | Una capa de consenso de red segura no garantiza la seguridad a nivel de aplicación. |
| Supra Oracle | Proporciona datos de precios de activos firmados, criptográficamente verificados y precisos. | No se pudo rechazar una firma nula, se publicó un precio corrupto. | Las dependencias deben tratarse con paradigmas de validación de confianza cero. |
| Bonzo Prestar | Gestionar activos de depósito, monitorear relaciones de salud de préstamos y procesar préstamos. | Confío ciegamente en los datos de precio entrantes, sin limitar los picos repentinos de precio. | Los contratos inteligentes deben implementar lógica defensiva para sobrevivir a los fallos de dependencia. |
La intervención del sombrero blanco: una carrera de $1 millón contra el hacker
Mientras se desarrollaba la explotación en el libro público, tuvo lugar un evento secundario dramático. En las cadenas de bloques públicas, las transacciones son visibles en el "mempool" antes de que se finalicen. Esta transparencia permite a otros participantes, tanto maliciosos como éticos, analizar ataques en tiempo real.
Poco después de que el atacante principal comenzara a vaciar el protocolo, un investigador de seguridad independiente—comúnmente conocido como un hacker "white hat"—detectó la explotación activa. Al reconocer que todo el protocolo estaba a punto de ser vaciado, el white hat ejecutó rápidamente la misma vulnerabilidad de firma cero para retirar aproximadamente $1 millón en activos.
Esta táctica, conocida como "front-running", es una maniobra defensiva común en la seguridad de Web3. Al retirar los fondos primero, el white hat impidió que el actor malicioso robara esa parte del pool de liquidez.
Tras el retiro exitoso, el hacker ético inició inmediatamente el contacto con el equipo de Bonzo Lend. Tras confirmar su identidad e intenciones, el hacker ético devolvió con seguridad los $1 millón completos a las direcciones de recuperación del protocolo. Si bien el atacante principal aún escapó con la mayor parte de los fondos, esta intervención rápida preservó una parte vital de los activos de la comunidad y demostró la naturaleza única y colaborativa de la seguridad de Web3.
Persiguiendo los millones: Cómo los fondos robados salieron del ecosistema Hedera
Una vez que el hacker logró tomar prestados millones de dólares en USDC y wHBAR contra su garantía falsa, su objetivo principal cambió a escapar del ecosistema Hedera antes de que el protocolo pudiera pausar sus contratos.
El atacante no mantuvo los activos robados en su forma original. Utilizando SaucerSwap, un intercambio descentralizado popular en Hedera, el hacker intercambió rápidamente los tokens prestados por stablecoins y activos nativos de alta liquidez para evitar mecanismos de congelación centralizados.
Inmediatamente después de intercambiar los tokens, el atacante utilizó puentes cruzados, redirigiendo específicamente los fondos a través de LayerZero. Al puentear los activos, el hacker transfirió más de $5 millones en fondos robados directamente al mainnet de ethereum.
Una vez que los activos cruzan a una red altamente líquida y masiva como Ethereum, rastrearlos y recuperarlos se vuelve exponencialmente más difícil. Los fondos pueden dividirse entre cientos de direcciones nuevas, depositarse en mezcladores de privacidad descentralizados o intercambiarse por monedas de privacidad no custodiales. Esta ruta de escape rápida y automatizada resalta por qué el monitoreo en tiempo real y las pausas de emergencia inmediatas son las únicas defensas viables contra los exploits cruzados modernos.
Las lecciones difíciles: Cómo los protocolos DeFi pueden protegerse de los desastres de oráculos
La pérdida de 9 millones de dólares es una lección extremadamente costosa, pero proporciona conocimientos invaluables para los desarrolladores de contratos inteligentes que buscan proteger sus aplicaciones contra futuros errores de integración.
Para prevenir vulnerabilidades de firma cero, los desarrolladores deben adoptar prácticas de codificación estrictas y defensivas. Las mejoras estructurales clave incluyen:
-
Verificación explícita de dirección nula: Nunca asuma que una función de verificación de firma tuvo éxito. Cada rutina de validación criptográfica debe verificar explícitamente que la longitud de la firma sea mayor que cero y confirmar que la dirección de salida no se resuelva a un valor nulo (
0x00...00). Si se devuelve un valor nulo, la transacción debe revertirse inmediatamente. -
Arquitecturas redundantes de oráculos: Depender de un solo proveedor de oráculos crea un punto único de fallo. Los protocolos DeFi robustos deben obtener los precios de los activos de múltiples redes de oráculos independientes (como Chainlink, Pyth y Supra simultáneamente). Si un feed se desvía significativamente de la mediana de los demás, el protocolo debe marcar la discrepancia y pausar las operaciones automáticamente.
-
Interruptores de precio en la cadena: Los protocolos de préstamo deben implementar límites de tasa y umbrales de desviación de precio. Incluso si un oracle afirma que el valor de un token ha aumentado un billón de veces en un solo bloque, el interruptor interno del contrato inteligente debe rechazar la actualización como una anomalía, deteniendo cualquier acción de préstamo o liquidación hasta que se realice una verificación administrativa manual.
El futuro de las auditorías de contratos inteligentes: por qué debemos probar los límites
La explotación de Bonzo Lend revela una limitación crítica en las prácticas actuales de auditoría de Web3. Muchas auditorías de seguridad se centran en gran medida en verificar que la lógica de negocio de un contrato funcione bajo condiciones esperadas, a menudo denominadas pruebas de "camino feliz".
Sin embargo, los atacantes del mundo real no siguen el camino ideal. Buscan específicamente condiciones límite, estados no inicializados e entradas inesperadas. La industria de la seguridad debe cambiar hacia pruebas agresivas de casos límite para descubrir fallas ocultas antes de que el código se active en mainnet.
Para lograr esto, los protocolos deben hacer de metodologías avanzadas de prueba, como fuzzing y verificación formal, un estándar obligatorio. El fuzzing implica el uso de herramientas automatizadas para inundar contratos inteligentes con millones de entradas aleatorias, malformadas y vacías, incluyendo cadenas de bytes vacías y firmas nulas. Si el contrato de verificación hubiera sido sometido a un fuzzing riguroso, el contorno de firma cero habría sido detectado al instante.
En última instancia, los proveedores externos de oráculos también deben aceptar estándares de seguridad más elevados. Debido a que estos flujos de datos sirven como base para cientos de millones de dólares en actividad económica, su código de verificación debe tratarse con el mismo nivel de escrutinio que las redes de capa uno que respaldan.
Conclusión: Restaurar la confianza en un ecosistema sin confianza
La explotación de Bonzo Lend es un recordatorio contundente de la naturaleza implacable de los contratos inteligentes. En Web3, el código es ley, y la EVM no se importa por tus intenciones. Una pequeña brecha lógica relacionada con "nada" puede borrar instantáneamente años de desarrollo y millones de dólares en confianza de los usuarios.
Tras el ataque, tanto Bonzo Lend como Supra Oracles trabajaron rápidamente para parchear la vulnerabilidad y asegurar la infraestructura restante. Aunque el incidente fue doloroso, las lecciones aprendidas conducirán inevitablemente a estándares de integración más seguros en todo el ecosistema DeFi. Para desarrolladores e inversores por igual, la conclusión final es sencilla: nunca dé por sentada la seguridad de la integración, pruebe los límites de su código y siempre verifique qué sucede cuando no introduce nada en sus sistemas.
Preguntas frecuentes:
P1: ¿El error de "Firma Cero" significa que la criptografía de la cadena de bloques está rota?
No. Los principios matemáticos detrás de las firmas digitales y la criptografía de clave pública siguen siendo completamente seguros. La explotación fue causada por un error lógico de programación en el contrato inteligente que manejaba la salida de la biblioteca criptográfica. La biblioteca actuó correctamente al devolver un valor nulo cuando se le proporcionó una firma en blanco, pero el contrato interpretó incorrectamente ese valor nulo como una verificación exitosa.
P2: ¿Por qué Bonzo Lend confió automáticamente en un precio tan absurdamente inflado para SAUCE?
Los protocolos de préstamo están diseñados para ser modulares, lo que significa que delegan la tarea compleja de la fijación de precios a redes oraculares dedicadas. Debido a que Bonzo Lend fue construido para aceptar el flujo de precios del oráculo como la verdad absoluta, sin realizar comprobaciones independientes ni límites locales de desviación de precios, aceptó el aumento artificial de precio en un billón de veces y permitió que la transacción de préstamo se realizara.
P3: ¿Qué pueden hacer los usuarios cotidianos de DeFi para protegerse de los ataques relacionados con oráculos?
Si bien los usuarios no pueden controlar el código de un protocolo, sí pueden gestionar su propio riesgo. Para proteger su capital, diversifique sus activos en múltiples plataformas independientes, evite protocolos que dependan de una sola fuente de oracle para activos nicho, y busque plataformas que hayan integrado públicamente sistemas de oracle de múltiples fuentes y interruptores de emergencia sólidos y en cadena.
Descargo de responsabilidad: Este contenido tiene fines informativos únicamente y no constituye asesoramiento de inversión. Las inversiones en criptomonedas conllevan riesgos. Realiza tu propia investigación (DYOR).
Aviso: Esta página fue traducida utilizando tecnología de IA para tu conveniencia. Para obtener la información más precisa, consulta la versión original en inglés.