Revest Finance - REKT

Environ 2 millions de dollars volés à Revest Finance.

Une plateforme financière NFT qui "offre une liquidité instantanée pour les actifs bloqués" a été victime d'une attaque par réentrance.

La réaction rapide de l'équipe de Revest leur a permis d'éviter de perdre davantage de fonds, mais ils occupent néanmoins de ce fait une place dans notre classement (n° 67).

Que s'est-il passé ?

Les membres de l'équipe de Revest ont été informés de "l'exploit à 2h24 UTC par l'équipe de développement de BLOCKS DAO".

En sus de BLOCKS DAO, des pertes substantielles ont également été subies par EcoFi et RENA Finance.

En suspendant les transferts de tokens RVST, l'équipe a déjoué la tentative de l'assaillant (70 secondes plus tard) de drainer la pool RVST-ETH sur Uniswap, évitant ainsi des pertes additionnelles de 1,15 millions de dollars.

Le dump des tokens volés par l'assaillant a eu un impact important sur le prix des BLOCKS (initialement en baisse de >95%, et actuellement en baisse de près de 80%) et ECO (en baisse d'environ 98%), mais les tokens RENA, qui demeurent sur l'adresse de l'assaillant, ont été épargnés.

Source : @BlockSecTeam

La root-cause de l'attaque était due à une vulnérabilité de type réentrance dans le contrat de minting ERC1155 (exemple de tx : RENA)

La fonction mintAddressLock, utilisée pour créer de nouveaux Smart Vaults, contient deux paramètres critiques : quantities et depositAmount.

Revest Vault invoque la fonction de mint FNFTHandler, pour mint des quantities de ERC1155(s) avec le fnftId suivant au(x) destinataire(s) qui peuvent plus tard être burn afin de claim la proportion de tokens verrouillés de la position. fnftId incrémente de 1 à chaque fois que la fonction est exécutée.

Des fonds supplémentaires peuvent être déposés dans le FNFT à l'aide de la fonction depositAdditionalToFNFT. Les dépôts doivent être dans la même proportion que celle définie par les quantities, à savoir : quantity==FNFTHandler.getSupply(fnftId).

Si la condition susmentionnée n'est pas remplie, la part de l'utilisateur sera extraite de la position et transférée vers un nouveau FNFT dont le solde est défini par le depositAmount de la position existante plus le montant nouvellement déposé.

Étant donné que le depositAmount de la position existante est utilisé, mais que le fnftId (renseigné via fnftsCreated) n'est pas mis à jour avant la fin de la routine de mint, la réentrance à ce stade permet d'ajouter des fonds supplémentaires à une position existante.

Étape par étape :

1 : L'assaillant utilise la fonction mintAddressLock pour ouvrir une nouvelle position avec fnftId=1027, depositAmount=0, quantities=[2], asset=Rena, et recipients=[malicious contract]. Comme le depositAmount X quantities[0] = 0 X 2 = 0, l'assailant transfère zéro Rena.

2 : L'assaillant utilise à nouveau la fonction mintAddressLock pour ouvrir une nouvelle position avec fnftId=1028, depositAmount=0, quantities=360,000, asset=Rena, et recipients=[malicious contract]. Là encore, l'assaillant transfère zéro Rena et reçoit 360 000 tokens (avec fnftId=1028). Notez que ces 1028 tokens n'ont désormais plus aucune valeur.

3 : À la fin de l'étape 2, pendant la fonction mint du FNFTHandler, l'assaillant réintègre le contrat Revest via l'interface onERC1155Received. La fonction depositAdditionalToFNFT est utilisée avec amount = 1e18, quantities=1, fnftId=1027, ce qui devrait normalement ouvrir la ( nouvelle ) position fnftId=1029. Cependant, en raison du retard dans la mise à jour de fnftId, la position 1028 est écrasée par les données ci-dessus, attribuant une valeur aux 1028 tokens détenus par l'assaillant.

4 : L'assaillant utilise la fonction withdrawFNFT pour retirer les 360 000 X 1e18 Rena tokens après avoir déposé seulement 1 quantity X 1e18 Rena tokens à l'étape 3.

Détail de la perte des tokens (environ 2M$ au total) selon le post-mortem officiel :

• 350k RENA (~125k$, toujours sur l'adresse de l'attaquant)

• 715 MILLIONS BLOCKS (~1, 7M$)

• 7.7M ECO (~100k$)

De plus petites quantités (entre 10 et 12 000 $) de ConstitutionDAO et de LUKSO ont également été volées.

Après avoir échangé la majorité des tokens volés contre des ETH, l'assaillant a déposé les fonds sur Tornado Cash.

Une faille de sécurité n'est jamais une bonne chose pour un protocole DeFi, surtout lorsque son produit est un locker sécurisé auquel on fait confiance pour gérer des tokens d'autres projets.

"Un audit n'est jamais suffisant", souligne Revest, après avoir constaté que la vulnérabilité n'avait pas été détectée dans l'audit du projet (solidity.finance).

La réponse rapide de l'équipe et le post-mortem approfondi sont des signes prometteurs, et bien que Revest ait déclaré qu'ils "ne possèdent pas les fonds nécessaires pour une compensation financière significative", le post mortem souligne le désir de faire correctement les choses à l'avenir.

Pour l'instant, on ne sait pas comment cela va se concrétiser.

REKT sert de plateforme publique pour des auteurs anonymes, nous déclinons toute responsabilité quant aux opinions ou contenus hébergés sur REKT.

faites un don (ETH / ERC20): 0x3C5c2F4bCeC51a36494682f91Dbc6cA7c63B514C

avertissement:

REKT n'est responsable en aucune manière du contenu publié sur notre site Web ou en lien avec nos Services, qu'il soit publié ou occasionné par l'Auteur Anon de notre site Web, ou par REKT. Bien que nous fournissions des règles pour la conduite et les publications de l'Auteur Anon, nous ne contrôlons pas et ne sommes pas responsables de ce que l'Auteur Anon publie, transmet ou partage sur notre site Web ou nos Services, et ne sommes pas responsables de tout contenu offensant, inapproprié, obscène, illégal ou autrement répréhensible que vous pourriez rencontrer sur notre site Web ou nos Services. REKT ne saurait être tenu responsable de la conduite, en ligne ou hors ligne, de tout utilisateur de notre site Web ou de nos services.