Saltar al contenido
Financial Context Wiki

Ataque de gobernanza

Un ataque de gobernanza obtiene suficiente poder de voto o ejecución para aprobar cambios perjudiciales mediante la vía de gobernanza autorizada.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

Un ataque de gobernanza obtiene suficiente poder de voto, propuesta, cancelación o ejecución para hacer que un protocolo realice una acción perjudicial por su vía de gobernanza autorizada. Las llamadas pueden superar todas las comprobaciones de los contratos inteligentes. El fallo consiste en que el sistema permite adquirir el control de forma demasiado barata, rápida o poco responsable frente al valor sometido a ese control.

El poder de voto puede proceder de tokens propios, votos delegados, tokens prestados, votantes sobornados, claves comprometidas o funciones privilegiadas del gobernador y del bloqueo temporal. Los puntos de control históricos pueden impedir que un mismo saldo vote de nuevo después de una transferencia y frustrar el préstamo posterior a la instantánea. No impiden los votos obtenidos antes de ella, la delegación concentrada, un cuórum débil ni el compromiso del ejecutor.

No toda propuesta impopular es un ataque: la gobernanza existe para cambiar reglas. La cuestión de seguridad es si un actor obtuvo un control desproporcionado o temporal, ocultó o falseó el efecto ejecutable, o rebasó un límite de autoridad declarado públicamente. Deben revisarse las llamadas reales, la vía más barata hacia el poder decisivo, el tiempo de respuesta y el valor o control máximo alcanzable tras la ejecución.

Cómo funciona

  1. Trace la autoridad desde el activo de voto, pasando por delegaciones y puntos de control, hasta el gobernador, el bloqueo temporal, el administrador del proxy, la tesorería, las funciones de emergencia y los contratos de destino. La interfaz de gobernanza no es el grafo de permisos.
  2. Fije la cadena, direcciones, versiones de implementación, modo del reloj, instantánea, umbral de propuesta, cálculo del cuórum, regla de recuento, demora y periodo de votación, demora de cola, vencimiento, derechos de cancelación y funciones de ejecución.
  3. Reconstruya el poder de voto en la instantánea exacta con lecturas históricas como getPastVotes. Agrupe las direcciones controladas o coordinadas por un mismo actor y separe el saldo de tokens del peso de voto delegado.
  4. Decodifique cada acción: targets, values, calldatas y descriptionHash. Resuelva proxies y selectores, examine llamadas agrupadas y compare la carga ejecutable con la descripción legible.
  5. Reproduzca en una bifurcación la creación, votación, puesta en cola y ejecución. Compare antes y después saldos, propiedad, funciones, autorizaciones, implementaciones, ajustes de oráculos, parámetros de garantía y cualquier función recién accesible.
  6. Calcule la vía de control más barata entre compras al contado, mercados de préstamo, liquidez flash, préstamos extrabursátiles, delegación, incentivos al voto, coberturas con derivados, compromiso de claves y captura de funciones privilegiadas. Incluya comisiones, deslizamiento, garantía, pérdidas al deshacer y tiempo de inmovilización del capital.
  7. Pruebe la respuesta. Confirme quién puede cancelar o pausar, qué pruebas necesita, si cabe dentro de la demora, dónde obtienen los usuarios los avisos oficiales y cómo se reanuda la gobernanza sin dejar una clave de emergencia ilimitada.

Un gobernador de tokens típico pasa por propuesta, demora, instantánea, votación, aprobación o rechazo, cola, bloqueo temporal y ejecución. Las reglas exactas dependen de la implementación. Con puntos de control del tipo ERC-5805 puede consultarse el peso delegado en un momento pasado; el reloj puede usar bloques o marcas de tiempo. Hay que emplear el reloj y la configuración desplegados, no suponer que la duración mostrada o el saldo de tokens son autoritativos.

Un bloqueo temporal crea un plazo mínimo de aviso, pero no juzga la intención ni vuelve segura una carga. Sus funciones de proponente, ejecutor, cancelador y administrador también son críticas. Si un administrador externo puede eludir la demora, el bloqueo no es la autoridad final. Si nadie puede cancelar una acción maliciosa en cola, detectarla no impide su ejecución.

Ejemplos resueltos

  • Captura con baja participación. Un protocolo tiene 100 million tokens totales y 40 million en circulación. Una propuesta necesita 2 million votos participantes, más votos a favor que en contra y un bloqueo de 6-hour. Un actor compra 1.2 million votos y recibe 1 million delegados. Hay 0.8 million votos en contra, por lo que sus 2.2 million votos favorables aprueban una llamada capaz de transferir 15 million USDC de la tesorería. Controla 2.2 / 100 = 2.2% del suministro total y 2.2 / 40 = 5.5% del circulante, pero 2.2 / 3.0 = 73.3% de los votos emitidos. Los parámetros decisivos son participación, delegación, cuórum, autoridad de la carga y demora, no el eslogan 51%.
  • Límite de la instantánea. Si el peso se lee del saldo actual y la ejecución es inmediata, una transacción puede pedir tokens, votar, ejecutar y devolverlos. Leer el peso histórico inmutable de un momento anterior al voto bloquea esa vía en una sola transacción. Aún admite capital prestado o delegado antes de la instantánea, por lo que la demora de propuesta y la ventana observable de adquisición siguen siendo defensas.
  • Beanstalk el 17 de abril de 2022. Beanstalk Farms informó de que un atacante empleó un préstamo flash para explotar la gobernanza del protocolo y sustrajo aproximadamente $77 million en activos de usuarios distintos de Beanstalk. El caso muestra que la liquidez flash financia el ataque, mientras que la debilidad decisiva es permitir que un poder económico temporal alcance permisos de ejecución valiosos.

Riesgos y controles

  • Poder efectivo concentrado. Mida delegados y entidades coordinadas, no solo direcciones. Publique la cuota de los principales delegados, la distribución de participación y la dependencia de fundaciones, custodios, creadores de mercado y representantes.
  • Reglas débiles de propuesta y cuórum. Compare los umbrales con el poder activo, la oferta prestable y la exposición de tesorería. Separe los requisitos de parámetros rutinarios y cambios o transferencias de gran impacto.
  • Instantáneas inseguras. Use puntos históricos inmutables y un reloj común al token y al gobernador. Deje demora suficiente antes de la instantánea para observar acumulaciones o delegaciones anómalas.
  • Voto tardío o sorpresivo. Considere una ampliación mínima cuando el cuórum llegue cerca del cierre y vigile grandes cambios de delegación durante todo el ciclo.
  • Cargas opacas. Publique llamadas decodificadas y simulaciones independientes. Separe acciones arriesgadas sin relación para que una inocua no oculte un cambio de administrador o una transferencia.
  • Demora de ejecución insuficiente. Ajuste el bloqueo al impacto y publique las operaciones en cola. La demora debe permitir revisión, alertas, cancelación o pausa y una salida creíble para el usuario.
  • Funciones de emergencia excesivas. Limite a los guardianes por función, valor, duración y norma de revisión. Revele miembros, umbrales, rotación, pruebas exigidas y procesos de destitución y reanudación.
  • Vías de actualización no revisadas. Siga administradores de proxy, balizas, inicializadores, despliegues metamórficos y contratos actualizables después de recibir autoridad.
  • Riesgo de ejecución entre cadenas. Autentique gobernador y mensaje de origen, impida repeticiones, limite funciones de destino, añada demora local a llamadas críticas y defina el comportamiento ante fallo o suspensión del puente.
  • Supervisión insuficiente. Alerte sobre creación de propuestas, concentración de votos, cambios de cuórum, cola y cancelación, cambios de estado decodificados, actualizaciones, concesiones de funciones, autorizaciones y salidas de tesorería.
  • Respuesta a incidentes fallida. Ensaye propuestas maliciosas, pérdida de firmantes, compromiso del frontend, caída del puente y pausas erróneas. Registre quién decide, comunica, firma, verifica y restablece con seguridad.
  • Valor en riesgo ilimitado. Limite transferencias individuales y acumuladas, alcance de actualización, acuñación, cambios de garantía y autorizaciones. Una votación aprobada no debe otorgar automáticamente autoridad ilimitada.

El resultado debe ser un registro de control reproducible: cada acción privilegiada, su controlador, votos o claves necesarios, primera hora de ejecución, vía de cancelación, fuente de supervisión y valor máximo alcanzable. Recálculelo tras actualizaciones, distribuciones de tokens, cambios de delegación, migraciones de puentes o variaciones importantes de liquidez y participación.

Errores frecuentes

  • «El atacante necesita el 51% del suministro total». La mayoría de sistemas depende de votos delegados o participantes, cuórum y regla de aprobación. El control decisivo puede costar mucho menos que la mitad del suministro.
  • «Las instantáneas eliminan los ataques de gobernanza». Impiden ciertos reusos de voto o préstamos de última hora, no préstamos previos, compras, concentración de delegación, sobornos ni claves privilegiadas comprometidas.
  • «Una votación aprobada en cadena demuestra legitimidad». Solo demuestra que se cumplieron las condiciones del código. No prueba que descripción y carga coincidan ni que el resultado sea seguro, justo o acorde con compromisos públicos.
  • «Un bloqueo más largo siempre es más seguro». Solo sirve si permite supervisar, analizar, cancelar o pausar, comunicar y salir. Una demora excesiva también puede perjudicar el mantenimiento urgente.
  • «Añadir un consejo de seguridad resuelve el riesgo». Puede acelerar la respuesta, pero crea otra vía de control. Su autoridad, responsabilidad, destitución y fallos deben entrar en el mismo modelo de amenazas.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...