Superfluid - REKT

8,7 millones de dólares drenados de Superfluid.

El protocolo para pagos automatizados en cripto fue hackeado a las 06:17 +UTC del 22 de febrero.

Otros proyectos que utilizaban el servicio para pagos a contribuidores o contratos escrow para inversores, sufrieron impactos negativos en los precios, ya que el agresor vendió los tokens nativos de los protocolos.

Los protocolos afectados fueron Mai Finance (QI), Stacker Ventures (STACK), Stake DAO (SDT) y Museum of Crypto Art (MOCA).

QI fue el token más afectado, cayendo inicialmente casi un 80% tras el dump, pero se ha recuperado un ~62% de su precio anterior al ataque.

@francescorenzia, de Superfluid, dijo a rekt.news que el ataque solo se centró en las addresses con los fondos más grandes de la plataforma. Antes de que la vulnerabilidad fuera parcheada, el hacker dejó una suma considerable de ETH, USDC y DAI sin tocar, posiblemente porque el agresor había "tenido suficiente".

¿Cómo ocurrió ?

Dirección del agresor: 0x1574f7f4c9d3aca2ebce918e5d19d18ae853c090

Exploit tx: 0xdee86cae2e1bab16496a49…

Activos robados:

19.4M QI (valor previo al hack $24M) vendidos en cuatro transacciones por un total de 2.3k WETH (~$6.2M)

24.4 WETH - (~$76k)

563k USDC vendidos por 173 WETH

45k SDT - vendidos por ~17 WETH - (~$54k)

24k STACK - vendidos por ~6.2 WETH - (~$19k)

39k sdam3CRV - Swap a am3CRV, luego a ~44k amDAI

1.5M MOCA - 1M de 1.5M vendidos por 173 WETH (~$500K)

11k MATIC - Aún no se ha vendido.

Total - ~$8.7M

~6 horas después del hack, Superfluid arregló el bug con la ayuda de Mudit Gupta.

El parche se puede encontrar aquí.

El texto a continuación se encuentra en el post-mortem de Superfluid.

Explicación de la vulnerabilidad

Superfluid.sol, conocido como contrato host, es el contrato que permite acuerdos, “agreements”, componibles de Superfluid (ConstantFlowAgreement, InstantDistributionAgreement) en una sola transacción, y los sistemas compuestos a menudo se denominan Super Apps.

Sin embargo, para tener un estado confiable y compartido durante toda la transacción entre diferentes calls, se introduce un concepto llamado "ctx" (un estado serializado administrado por el contrato host).

El “ctx” contiene todo el contexto que necesita saber una función agreement, que incluye especialmente quién es el “msg.sender” de la call inicial.

Ahí es donde se explotó la desafortunada vulnerabilidad.

El agresor pudo crear hábilmente los datos de la llamada de modo que el proceso de serialización en el contrato host y la posterior deserialización en el contrato agreement, dieron como resultado que el contrato agreement operara en un objeto de contexto falsificado, específicamente para hacerse pasar por otras cuentas.

Este mecanismo se usó para crear índices IDA "en nombre" de otras cuentas y mover sus tokens de esta manera.

El contrato del exploit:

El siguiente contrato exploit, demuestra cómo se podría usar la vulnerabilidad para hacerse pasar por otras cuentas para cerrar sus flujos abiertos.

En la exploit transaction real , el agresor usó el contrato IDA para extraer fondos de otras cuentas usando la misma técnica:

Secuencia de Function Calls

deleteAnyFlowBad

La convención para callAgreement es usar el placeholder ctx, de modo que el código de solidity agreement posterior pueda leerlo directamente como un agreement "ctx".

Para leer más sobre este concepto, consulte About-Placeholder-Ctx .

Aquí es donde el agresor logró inyectar un "ctx" falso, donde se podría configurar un remitente arbitrario.

Superfluid.callAgreement

En el caso normal, Superfluid.callAgreement crea el ctx y le pone un sello (almacena su hash en una variable de estado), de modo que se puede validar usando Superfluid.isCtxValid.

ConstantFlowAgreementV1.createFlow

Luego, el agreement usa AgreementLibrary.authorizeTokenAccess para verificar que el contrato host que llama, esté autorizado para realizar calls de modificación de estado en el contrato del token.

AgreementLibrary.authorizeTokenAccess

Una vez que se autentica el host que llama, el agreement también confiaría transitivamente en el ctx entregado y lo decodifica (deserializar) en una estructura de memoria.

Pero Fake Ctx!

El problema era que, al igual que en la función de exploit deleteAnyFlowBad , se puede inyectar un ctx falso.

Después de que Superfluid.replacePlaceholderCtx lo fusionara en un objeto de un byte (el Host no hace ninguna suposición sobre los datos específicos del agreement), el dataWithCtx resultante ahora contiene 2 variantes de ctx, la legítima y la inyectada.

Cuando el contrato agreement decodifica estos datos, el decodificador abi toma la primera variante (inyectada) e ignora los datos restantes que contiene el ctx legítimo.

Para solucionar esto, Superfluid agregó un paso de verificación en el contrato agreement:

ISuperfluid.isCtxValid. Esto verifica el ctx decodificado comparando su sello (hash) almacenado en el contrato host.

Esta verificación ya estaba vigente para manejar los datos ctx proporcionados por las devoluciones de llamada SuperApp, pero no estaba vigente para los datos entregados por el contrato host confiable.

Superfluid se acercó al hacker y, según el post-mortem, un bounty de $1 millón de dólares, permanece sobre la mesa, a cambio de la devolución de los fondos.

El equipo también afirma que la mayoría de las cuentas afectadas ya han sido reembolsadas, mientras que las pérdidas más grandes de QI y MOCA se compensarán de manera gradual.

Aunque este no fue el exploit más grande (número 42 en nuestro leaderboard) , y no se perdieron fondos de los usuarios, es notable por la forma en que afectó a otros protocolos.

El área en crecimiento de infraestructura de las DAOs, presenta aún más blancos para los agresores anónimos que son tan frecuentes en DeFi.

Los fondos robados todavía se encuentran en poder del agresor.

¿Tomarán la bounty o dejarán a Superfluid rekt?

REKT sirve como plataforma pública para autores anónimos, nos deslindamos de la responsabilidad por las opiniones y contenidos alojados en REKT.

dona (ETH / ERC20): 0x3C5c2F4bCeC51a36494682f91Dbc6cA7c63B514C

aviso legal:

REKT no es responsable ni culpable de ninguna manera por cualquier Contenido publicado en nuestro Sitio Web o en conexión con nuestros Servicios, sin importar si fueron publicados o causados por Autores ANÓN de nuestro Sitio Web, o por REKT. Aunque determinamos reglas para la conducta y publicaciones de los Autores ANÓN, no controlamos y no somos responsables por cualquier contenido ofensivo, inapropiado, obsceno, ilegal o de cualquier forma objetable, que se pudiera encontrar en nuestro Sitio Web o Servicios. REKT no es responsable por la conducta, en línea o fuera de línea, de cualquier usuario de nuestro Sitio Web o Servicios.