El exploit de Vesting V2 de UNCX ha expuesto una falla en la contabilidad de participaciones que permitió a los atacantes inflar sus reclamaciones sobre tokens agrupados, explicó el jefe de seguridad de Immunefi tras los informes de aproximadamente 1,5 millones de dólares drenados en cuatro cadenas.
Resumen
- Las funciones de retiro y cancelación dejaron la contabilidad de participaciones desequilibrada, según Magalhães.
- Las pérdidas reportadas alcanzaron aproximadamente 1,5 millones de dólares en cuatro redes, con billeteras imitadoras y bots involucrados.
- Magalhães aconsejó contactar en privado a los equipos afectados antes de emitir advertencias públicas de retiro cuando sea posible.
- Los proveedores y los proyectos afectados comparten la responsabilidad de trabajar hacia el reembolso, dijo.
Gonçalo Magalhães, jefe de seguridad de Immunefi, dijo a crypto.news que el contrato no logró mantener sus contadores de participaciones consistentes cuando los usuarios retiraban tokens adquiridos y cancelaban posiciones.
Los retiros de UNCX dejaron un recuento de participaciones obsoleto
Según el relato de Magalhães, la debilidad comenzó con la función de liberación del contrato, que permite a un beneficiario retirar tokens que se han vuelto disponibles bajo un calendario de adquisición.
Después de un retiro, la función no restó las participaciones liberadas del contador de la posición, dijo. Cuando la función de cancelación leyó posteriormente ese valor sin cambios, restó nuevamente la porción no adquirida, distorsionando la contabilidad del grupo.
Según el jefe de seguridad, la combinación infló el valor asignado a las participaciones restantes. Un atacante podría entonces usar una posición dejada en el grupo para retirar más tokens de los que debería haber recibido.
Al describir un ataque, Magalhães dijo que el explotador abrió tres posiciones de adquisición y sacrificó dos a través de las funciones de retiro y cancelación. La posición restante se volvió elegible para un retiro que conllevaba lo que describió como una "ganancia masiva".
Identificó la falla central como la ausencia de una regla contable consistente en todas las funciones del contrato.
"En última instancia, el contrato inteligente no logró asegurar que ninguna función pudiera romper la invariante en torno al contador global de participaciones".
Su explicación sitúa la debilidad en cómo las funciones actualizaban y reutilizaban los saldos de participaciones. La salvaguarda que identificó fue una regla que aseguraba que cada operación preservara la precisión del recuento total de participaciones.
The Crypto Times informó el 15 de octubre que Blockaid había estimado pérdidas de aproximadamente 1,49 millones de dólares en Ethereum, BNB Chain, Base y Robinhood Chain. Su relato atribuyó 11 transacciones de drenaje a actividad que involucraba al atacante original, billeteras imitadoras y bots de valor máximo extraíble, o MEV.
La intervención privada precede a las advertencias públicas
Cuando se le preguntó cómo deberían responder las firmas de seguridad cuando un exploit sigue activo, Magalhães dijo que la respuesta disponible depende del protocolo y de las personas que pueden intervenir.
"Una vez que se agotan todas las opciones, poco se puede hacer aparte de pedir públicamente a los usuarios que retiren sus fondos de inmediato".
Magalhães no presentó un único calendario de divulgación adecuado para cada incidente. Su respuesta describió en cambio una secuencia de posibles intervenciones, comenzando con las personas que podrían ser capaces de detener el ataque o eliminar los depósitos expuestos.
Un relato del 6 de octubre de una bóveda Base no identificada describió un obstáculo separado para la intervención privada. En ese caso, Magalhães dijo que un investigador enfrentó incertidumbre legal porque los operadores de la bóveda no estaban identificados y no había un canal de divulgación claro. El informe del incidente situó el robo en aproximadamente 6 millones de dólares.
Los historiales de billeteras ayudan a los investigadores a separar a los participantes
Para los investigadores que examinan UNCX, Magalhães dijo que los historiales de transacciones proporcionan un punto de partida para distinguir al explotador original de otros participantes.
La persona que desplegó el ataque por primera vez generalmente aparece entre los primeros en moverse, dijo. Los usuarios establecidos tienen registros de interacciones anteriores con el protocolo, mientras que las carteras de trading automatizado pueden mostrar un historial consistente con la actividad de bots.
Los investigadores pueden comparar transacciones posteriores con la secuencia utilizada por el atacante original, según Magalhães. Un cliente anterior aún podría haber copiado el exploit, por lo que una relación existente con el protocolo no resuelve la cuestión.
"En última instancia, la línea se vuelve difusa y difícil de trazar."
Un incidente separado del 15 de septiembre que involucró 2.900 rsETH en Ethereum ilustra por qué los investigadores examinan el orden de las transacciones. Los investigadores de seguridad dijeron que el bot Yoink se ejecutó antes que el presunto atacante en el mismo bloque, mientras que la transacción del exploit original falló. El bot recibió activos valorados en aproximadamente 7,8 millones de dólares en ese momento.
Sobre las negociaciones de recuperación, el CEO de Immunefi, Mitchell Amador, tomó en cuenta una cuestión diferente de autorización en comentarios sobre Liquid Network publicados el 21 de septiembre. Dijo que los investigadores deberían utilizar canales de divulgación privados y términos de recompensa acordados en lugar de tomar los activos del usuario y establecer una recompensa después.
Los proveedores y los proyectos deberían trabajar hacia el reembolso
Cuando se le preguntó sobre proyectos cuyos tokens estaban en infraestructura de vesting compartida, Magalhães dijo que los equipos deberían tener su propio personal de seguridad examinar cualquier proveedor que adopten.
La reputación de un proveedor forma parte de esa evaluación, dijo, pero su recomendación situaba la revisión técnica en el equipo que elige la infraestructura.
Sobre la responsabilidad después de un exploit, Magalhães dijo que tanto el proveedor responsable del bug como los proyectos que lo seleccionaron deberían trabajar para resarcir a los usuarios.
"La responsabilidad de trabajar para resarcir a los usuarios recae tanto en el proveedor con el bug como en los proyectos que confiaron en dicho proveedor."
Sus comentarios describieron la responsabilidad de buscar el reembolso, sin establecer una fórmula de compensación ni asignar un porcentaje de las pérdidas a ninguna de las partes.
Para los auditores, Magalhães distinguió una vulnerabilidad pasada por alto de una garantía de que el código revisado no puede fallar. Dijo que un servicio de auditoría no promete "código a prueba de fallos".
The Crypto Times informó que la respuesta de UNCX incluyó tarifas más altas destinadas a disuadir una mayor explotación y la coordinación con los equipos afectados, las fuerzas del orden y SEAL 911. Según ese relato del 15 de octubre, UNCX dijo que sus bloqueadores de liquidez y contratos de vesting heredados no se vieron afectados y planeaba publicar hallazgos técnicos y un plan de recuperación propuesto.
