Revisión del ataque de gobernanza de X100 y Arkadiko: ¿Por qué fallaron el bloqueo y el largo período de votación?

La gobernanza de los proyectos de criptomonedas necesita mecanismos de amortiguación.

Escrito por: Liam Akiba Wright

Traducido por: Chopper, Foresight News

Recientemente, dos ataques de gobernanza revelaron el mismo defecto de diseño. Los atacantes tomaron el control de dos asientos de gobernanza del proyecto X100 del ecosistema de Ethereum, aprobando una transferencia de tesorería a través de una transacción en cadena el 24 de octubre, al mismo tiempo que completaron el reembolso de un préstamo relámpago.

El protocolo de préstamos Arkadiko permite a los usuarios hipotecar activos de la tesorería para obtener préstamos. Una votación de gobernanza de 5 días del proyecto se cerró anticipadamente, y los atacantes compraron tokens justo antes de que finalizara la votación para participar. Una vez que la propuesta maliciosa fue aprobada, no hubo período de enfriamiento, y el contrato tomó el control de los activos de la tesorería.

Estos dos eventos expusieron el mismo problema: hay una brecha de diseño entre el bloqueo de fondos, la obtención de derechos de voto y la ejecución de propuestas. El token X100 tiene un período de bloqueo de un año, lo que aumenta el costo de hacer el mal, pero no retrasa el tiempo de efectividad de los derechos de voto; el ciclo de votación de Arkadiko es largo, lo que da tiempo para que el mercado observe, pero no impide que los fondos entren de manera repentina cerca del final. Ambos diseños no dejaron un período de amortiguación después de la aprobación de la propuesta para que la comunidad pudiera reaccionar ante los riesgos.

Los tokens de X100 están bloqueados, pero obtienen inmediatamente derechos de gobernanza

El contrato Freezer de X100 custodia los tokens X congelados, y la proporción de participación determina el ranking de los candidatos al consejo de gobernanza. El período de bloqueo se divide en 1, 3 y 5 años, pero el contrato no exige un tiempo mínimo de tenencia de participación. En el ataque del 24 de octubre, dos contratos auxiliares apostaron 19000.000001 tokens X cada uno, eligiendo un bloqueo de un año. Registraron su identidad, entraron en el ranking del consejo de gobernanza y emitieron dos votos clave, permitiendo la ejecución de la propuesta número 7. Todo el proceso se completó en una sola transacción.

Este mecanismo de gobernanza no tiene un período de espera obligatorio: durante la fase abierta de la propuesta, la mayoría de los asientos del consejo de gobernanza pueden autorizar la ejecución directamente. Los atacantes controlaban 2 de los 3 asientos y ya tenían derechos de ejecución inmediatos. Después de que la propuesta fue aprobada, 400,000 tokens X de la tesorería fueron transferidos a un nuevo fondo creado por los atacantes, y el contrato Freezer solo recibió 35.675313 USDT. Luego, los atacantes retiraron tokens del fondo, vendieron X para obtener fondos y pagaron el préstamo relámpago.

Los tokens apostados permanecieron bloqueados durante todo el proceso; los atacantes no necesitaban desbloquear su participación, solo robar activos de la tesorería y usar los fondos obtenidos de la venta de tokens para completar el reembolso. Después de que la transacción de ataque completó el reembolso del capital + intereses, aproximadamente 4.75 millones de USDT fluyeron hacia la dirección de recepción final. Philippark, un contribuyente de ChainBounty, rastreó estos fondos, que aún no incluyen los tokens X no vendidos y su valor fluctuante, solo contabilizando las transferencias rastreables.

El contrato Freezer tiene una restricción: después de que se complete la ejecución de la transacción, el saldo de X dentro del contrato debe cubrir todo el capital apostado bloqueado por los usuarios. Esta regla solo protege el capital apostado de los usuarios, no puede proteger la liquidez del fondo externo ni sostener el precio del token en el mercado secundario.

Arkadiko: fondos que entran al final de la votación pueden participar en la votación

La propuesta número 12 de Arkadiko fue presentada a las 20:35 UTC del 17 de octubre y ejecutada a las 16:04 UTC del 22 de octubre. Este contrato de gobernanza establece una ventana de votación de 720 bloques de Bitcoin, lo que equivale a 5 días.

Las reglas requieren que el proponente posea el 0.25% de la cantidad de DIKO (el token de gobernanza de Arkadiko) que cumple con los requisitos, y que la tasa de participación en la votación alcance el 5% para que se considere quórum; la propuesta se aprueba si los votos a favor superan a los en contra. El cálculo de la circulación excluye los DIKO dentro del contrato de distribución inicial. Las reglas del contrato no exigen que los votantes posean tokens antes de que se presente la propuesta. La billetera del atacante compró tokens a las 15:03 UTC del 22 de octubre y completó la votación a las 15:06, invirtiendo aproximadamente 4.573 millones de DIKO.

La trazabilidad en cadena de Bitquery muestra que el 77% de los STX recibidos por la billetera de votación del atacante provino de fondos robados anteriormente de StackSwap. (Nota: StackSwap es un DEX del ecosistema Stacks que sufrió un ataque de gobernanza el 20 de octubre.)

Los atacantes prepararon los fondos a través de múltiples transacciones y en varios días, lo que difiere claramente del modelo de préstamo relámpago de una sola transacción de X100. La clave de este ataque fue que, durante el período de apertura de la votación, los tokens comprados posteriormente podían obtener inmediatamente derechos de voto. Una vez que la votación se cerró, la propuesta entró en vigor directamente, sin período de espera entre la aprobación de la votación y la autorización del contrato.

El contrato de operación de la tesorería de Arkadiko habilitado tiene una vulnerabilidad: las funciones de retiro y acuñación de USDA carecen de verificación de permisos del llamador. La propuesta número 12 registró este contrato malicioso como el contrato de operación de la tesorería, otorgándole permisos de acuñación. Minutos después de que la propuesta entró en vigor, es decir, a las 16:06 UTC, el atacante transfirió sBTC; a las 16:09 transfirió stSTX. Bitquery estima que las pérdidas de Arkadiko en este ataque son de aproximadamente 1.09 millones de dólares: de los cuales 780,000 dólares son stSTX, 135,000 dólares son sBTC, y 173,000 dólares son ingresos de la venta de USDT no respaldados acuñados por el atacante.

El 22 de octubre, Arkadiko declaró en un post de respuesta que había deshabilitado el contrato malicioso y suspendido la gobernanza, el canje de tesorería y la liquidación. La empresa afirmó que los fondos de stSTX y sBTC afectados no podían modificarse, ya que sus colaterales no estaban disponibles. El 27 de octubre, la propuesta 14 "AIP 32.2 -- Restaurar operaciones de tesorería" fue ejecutada, estableciendo los elementos de operación de la tesorería como contratos legítimos de Arkadiko.

Lecciones: la gobernanza necesita mecanismos de amortiguación

Establecer un snapshot de votación y exigir que los tokens deban ser poseídos con anticipación puede evitar que los nuevos tokens comprados obtengan inmediatamente derechos de voto; mientras que un bloqueo de tiempo de ejecución separa "la aprobación de la propuesta" de "la operación de activos" en dos etapas independientes. Si todas las operaciones de propuestas deben pasar por un bloqueo de tiempo, el modo de ataque de "un préstamo, ataque y reembolso en una sola transacción" de X100 no podría llevarse a cabo. Por supuesto, los atacantes que poseen fondos a largo plazo aún pueden esperar hasta que finalice el período de bloqueo para actuar, por lo que también se necesita restringir por separado los permisos operativos del contrato de propuesta.

La documentación de OpenZeppelin define los snapshots de derechos de voto históricos y los bloqueos de tiempo de ejecución de propuestas como dos mecanismos de seguridad de gobernanza independientes. En estos dos casos, la cuestión central es: ¿cuándo obtienen derechos de voto los nuevos fondos comprados, qué operaciones puede ejecutar el contrato una vez que la votación es aprobada y cuánto tiempo se deja a la comunidad para reaccionar antes de que se movilicen los activos?

Los tokens X de X100 no pueden desbloquearse durante el período de bloqueo, incluso si se agrega un bloqueo de tiempo de ejecución, no cambiará la restricción de que las participaciones no pueden ser retiradas anticipadamente.

El contrato de tesorería original v1-3 de Arkadiko tiene un mecanismo de salida: los usuarios normales pueden recuperar sus colaterales después de pagar sus deudas y tarifas estables, cuando la función está habilitada. Este proceso depende de que haya suficientes fondos y que los activos colaterales estén disponibles.

La ventana de votación de 5 días parece haber dado una alerta al mercado, pero la votación decisiva se completó justo antes de la fecha límite, y el contrato malicioso entró en vigor inmediatamente después de que se cerró la votación. Si se piensa que el ciclo de votación es igual a la ventana de detención de pérdidas posterior, se ocultará el verdadero momento en que ocurren los riesgos.

Este contenido se ofrece únicamente con fines informativos generales y no constituye asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, tradear o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.