Revest Finance - REKT

~$2M robados de Revest Finance.

Una plataforma de NFTs financieros que "ofrece liquidez instantánea para activos bloqueados", fue víctima de un ataque de reentrancy.

Una rápida reacción del equipo de Revest evitó que perdieran más fondos, y aún así, ahora ocupan un lugar en el leaderboard (#67).

¿Cómo pasó?

El equipo de Revest fue informado del “exploit a las 2:24 UTC por el equipo de desarrollo de BLOCKS DAO”.

Además de BLOCKS DAO, EcoFi y RENA Finance también sufrieron pérdidas sustanciales.

Al detener las transacciones de tokens RVST, el equipo detuvo el intento del atacante (70 segundos después) de drenar el pool RVST-ETH en Uniswap, evitando otros $1,15M en pérdidas.

El dump por parte del atacante de los tokens robados tuvo un gran impacto en el precio de BLOCKS (inicialmente cayó un >95%, actualmente está por debajo del ~80%) y ECO (que cayó un ~98%), sin embargo, los tokens RENA permanecen intactos en la dirección de los atacantes.

Créditos: @BlockSecTeam

La causa raíz del ataque se debió a una vulnerabilidad de reentrancy en el contrato mint ERC1155 (ejemplo tx: RENA)

La función mintAddressLock, utilizada para crear nuevos Smart Vaults, contiene dos parámetros críticos: quantities y depositAmount.

Revest Vault invoca la función mint de FNFTHandler, para acuñar una cantidad de tokens ERC1155 que se establece mediante el parámetro quantities. El ID del token de ese conjunto se define mediante fnftId, que se incrementa en 1 cada vez que se ejecuta la función. Los tokens ERC1155 pueden ser quemados para reclamar la proporción de tokens ERC-20 bloqueado en la posición.

Se pueden depositar fondos adicionales en la FNFT utilizando la función depositAdditionalToFNFT, los depósitos deben estar en la misma proporción definida por quantities, específicamente: quantities==FNFTHandler.getSupply(fnftId).

Si no se cumple con la afirmación anterior, la parte del usuario se extraerá de la posición y se transferirá a una nueva FNFT con un balance definido por el depositAmount de la posición existente más el monto recién depositado.

Dado que se usa depositAmount de la posición existente, pero fnftId (informado a través de fnftsCreated) no se actualiza hasta el final de la rutina de acuñación, el reentrancy en este punto permite que se agreguen fondos adicionales a una posición existente.

Paso a Paso:

1: El atacante usa la función mintAddressLock para abrir una nueva posición con fnftId=1027, depositAmount=0, quantities=[2] , asset=Rena y recipients=[malicious contract]. Dado que depositAmount X quantities[0] = 0 X 2 = 0, el atacante transfiere cero Rena.

2: El atacante usa la función mintAddressLock nuevamente para abrir una nueva posición con fnftId=1028, depositAmount=0, quantities=360,000, asset=Rena y recipients=[malicious contract]. Nuevamente, el atacante transfiere cero Rena y recibe 360 000 tokens (con fnftId=1028). Tenga en cuenta que estos tokens 1028 no tienen ahora ningún valor.

3: Al final del Paso 2, durante la función mint de FNFTHandler, el atacante aplica reentrancy al contrato Revest a través de la interfaz onERC1155Received. La función depositAdditionalToFNFT se usa con amount = 1e18 , quantities=1, fnftId=1027, que normalmente abriría la posición fnftId=1029 (nueva). Sin embargo, debido al retraso en actualizar fnftId , la posición 1028 se sobrescribe con los datos anteriores, asignando valor a los tokens 1028 que ya posee el atacante.

4: El atacante usa la función withdrawFNFT para retirar los tokens Rena de 360,000 X 1e18 después de haber depositado solo 1 quantity X 1e18 de tokens Rena en el Paso 3.

Pérdidas de tokens (aproximadamente $2M en total) según el informe oficial post-mortem:

350k RENA (~$125k, todavía en la dirección del atacante)

715M BLOCKS (~$1.7M)

7.7M ECO (~$100k)

También se robaron cantidades más pequeñas ($10 - $12K) de ConstitutionDAO y LUKSO.

Después de cambiar la mayoría de los tokens robados por ETH, el atacante depositó los fondos en Tornado Cash.

Un fallo de seguridad nunca es un buen aspecto para un protocolo DeFi, especialmente cuando su producto es un locker en el que se pueden confiar los tokens de otros proyectos.

“Una auditoría nunca es suficiente”, dice Revest, ya que la vulnerabilidad no fue detectada en la auditoría del proyecto (solidity.finance).

La rápida respuesta del equipo y el minucioso post-mortem son signos prometedores, y aunque Revest ha declarado que "no poseemos los fondos necesarios para una recompensa financiera significativa", el informe de la autopsia enfatiza el deseo de hacer las cosas bien en el futuro.

Por el momento, no está claro cómo sucederá eso.

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.