Cómo un error de diseño en una multifirma bastó para perder USD 27 millones en ETH

El evento fue reportado públicamente por PeckShieldAlert, firma especializada en análisis forense on-chain y alertas de seguridad en DeFi. Según su informe, el atacante no solo drenó los fondos, sino que además mantiene control operativo sobre la multifirma y sobre una posición apalancada en AAVE, mientras parte de los fondos en ether (ETH) fueron lavados vía Tornado Cash.

El caso analizado no es excepcional por su monto, sino por lo que revela sobre cómo se están utilizando las multifirmas en la práctica. Durante años, la multifirma (multisig) fue presentada como el “siguiente nivel” de seguridad: más firmantes, más protección. No obstante, la experiencia demuestra que la seguridad no nace del número de firmas, sino del diseño del esquema de custodia.

No todas las multifirmas ofrecen el mismo nivel de bloqueo. Un esquema 1-de-2 y/o 1-de-3 tiene un único punto de falla: basta con comprometer una sola clave para mover los fondos. En ese caso, la multifirma aporta redundancia operativa, pero no protección real contra el robo. En cambio, una multifirma 2-de-3 introduce dependencia entre firmantes, que requiere comprometer al menos dos entornos distintos. Esa diferencia no es cuantitativa, es estructural. En custodia, el umbral define la exposición.

En este incidente, el compromiso de una clave privada fue suficiente para que el atacante drenara fondos, lavara parte de ellos mediante un mixer y, de forma aún más crítica, mantuviera control operativo sobre la propia multifirma. Esa multifirma no sólo custodiaba activos, sino que tomó control de una posición apalancada en un protocolo DeFi. El resultado fue un evento de control persistente, no un ataque puntual.

¿Por qué sucede esto?

Porque muchas multifirmas están pensadas bajo supuestos débiles: que todos los firmantes estarán siempre disponibles, que sus llaves no serán comprometidas, que el entorno operativo es confiable. Cuando uno de esos supuestos falla, la multifirma deja de ser una barrera, para ser una palanca.

Entre los errores más comunes se destacan:

• Umbrales mal definidos, donde una clave y/o más claves combinadas con automatismos puede estar vulnerable.
  
  
• Ausencia de separación de funciones, usando las mismas claves para custodia, operación diaria y/o control de contratos.
  
  
• Falta de bloqueos temporales, que impidan movimientos inmediatos, para tener un tiempo de reacción.
  
  
• Dependencia de infraestructuras calientes, como servidores, navegadores y/o entornos cloud, que exponen la superficie de ataque.
  
  
• Complejidad sin planificación, donde se suman capas técnicas sin una auditoría conceptual del diseño.
  
  

Desde una perspectiva experto en custodia, el problema no es la multifirma, sino el enfoque con el que se la diseña. Una buena multifirma no busca únicamente impedir el robo externo, sino controlar fallas internas, errores humanos, coacción, ausencias y/o escenarios extremos.

¿Qué se podría haber hecho mejor?

Primero, separar roles de contextos. Una multifirma destinada a custodia pasiva no debería ser la misma que interactúa con protocolos DeFi. En otro orden, incorporar timelocks, que sumen fricción deliberada en los movimientos sensibles. Tercero, diversificar entornos de firma, evitando que varias claves compartan el mismo vector de ataque. Cuarto, definir rutas de escape, que permitan bloquear y/o derivar fondos ante un evento fuera de lo normal.

En Bitcoin, estas prácticas están mucho más controladas. El modelo UTXO, la posibilidad de definir cómo, cuándo se usa, con timelocks y multifirmas a nivel de consenso hacen que el impacto de un compromiso sea más acotado. En cambio, en muchos esquemas DeFi, una multifirma actúa como una llave maestra sobre sistemas complejos y dinámicos.

La lección no es abandonar la multifirma, sino entenderla. Una multifirma bien diseñada es una herramienta soberana; una mal diseñada es una ilusión de custodia.

Este caso no demuestra que la multifirma sea vulnerable. Demuestra que la custodia requiere diseño, no atajos. Sumar firmas sin pensar escenarios de falla puede crear una falsa sensación de protección.

La verdadera custodia nace cuando se asume que las claves pueden fallar, las personas pueden equivocarse y los sistemas pueden ser atacados. En ese contexto, una buena multifirma no elimina el riesgo: lo gestiona. Y en custodia, esa diferencia lo es todo.