Superfluid - REKT

8,7 millions de dollars ont été soutirés de Superfluid.

Le protocole de streaming de crypto a été hacké à 06:17 +UTC le 08/02/22.

D'autres projets qui utilisaient ce service pour les rémunérations des contributeurs ou les escrows contrats des investisseurs ont vu le prix de leurs tokens natifs s'effondrer suite au dumping effectué par l'assaillant de ces tokens.

Parmi les protocoles affectés figurent Mai Finance (QI), Stacker Ventures (STACK), Stake DAO (SDT) et Museum of Crypto Art (MOCA).

QI a été le token le plus durement touché, chutant initialement de près de 80 % après le dump. Il a depuis toutefois retrouvé ~62 % de son prix d'avant le hack.

@francescorenzia, de Superfluid, a confié à rekt.news que le hack ne visait que les plus gros portefeuilles de la plateforme. Jusqu'à ce que la vulnérabilité soit corrigée, le hacker a épargné de nombreux ETH, USDC et DAI, probablement parce que l'assaillant en avait "assez".

Comment cela s'est-il produit ?

Adresse de l'assaillant : 0x1574f7f4c9d3aca2ebce918e5d19d18ae853c090

Tx de l'exploit : 0xdee86cae2e1bab16496a49…

Actifs volés :

19.4M QI (valeur pre-hack de $24M) vendus en quatre transactions pour un total de 2.3k WETH (~$6.2M)

24,4 WETH - (~$76k)

563k USDC vendus pour 173 WETH

45k SDT - vendus pour ~17 WETH - (~$54k)

24k STACK - vendus pour ~6.2 WETH - (~$19k)

39k sdam3CRV - échangés contre des am3CRV, puis contre ~44k amDAI

1.5M MOCA - 1M sur 1.5M ont été vendus pour 173 WETH (~$500K)

11k MATIC - pas encore vendu

Total - ~8.7M

Superfluid a patché le bug environ 6 heures après l'attaque, avec l'aide de Mudit Gupta.

Le patch peut être trouvé ici.

Le texte ci-dessous est tiré du post-mortem de Superfluid

Analyse de la vulnérabilité

Superfluid.sol, connu sous le nom du contrat, est le contrat qui permet de composer des accords (agreements) Superfluid (ConstantFlowAgreement, InstantDistributionAgreement) en une seule transaction, et les systèmes composés sont souvent appelés Super Apps.

Toutefois, afin de disposer d'un état fiable et partagé tout au long de la transaction entre les différents agreement calls, un concept appelé "ctx" (un état sérialisé géré par le host contract) est introduit.

Le "ctx" contient tout le contexte qu'une fonction d'accord doit connaître, y compris notamment l'expéditeur "msg.sender" du call initial.

C'est là qu'une vulnérabilité malheureuse a été exploitée.

L'assaillant a été en mesure d'élaborer habilement les calldata de telle sorte que le processus de sérialisation dans le host contract et de désérialisation dans le agreement contract ait pour résultat que le agreement contract opère sur un objet de contexte forgé spécifiquement pour usurper l'identité d'autres comptes.

Ce mécanisme a été utilisé afin de créer des index IDA "au nom" d'autres comptes et de transférer leurs tokens de cette façon.

Le contrat de l'exploiteur :

Le contrat d'exploitation suivant démontre comment la vulnérabilité pourrait être utilisée pour usurper l'identité d'autres comptes afin de couper leurs streams ouverts.

Dans la transaction d'exploitation réelle, l'assaillant a utilisé le contrat IDA pour drainer les fonds d'autres comptes en utilisant la même technique :

Chain de Function Calls

deleteAnyFlowBad

La convention pour callAgreement est d'utiliser le placeholder ctx, afin que le agreement solidity code ultérieur puisse le lire directement comme un argument "ctx".

Pour en savoir plus sur ce concept, voir About-Placeholder-Ctx.

C'est ici que l'assaillant a réussi à injecter un faux "ctx", où un expéditeur arbitraire a pu être défini.

Superfluid.callAgreement

En temps normal, Superfluid.callAgreement crée le ctx et lui attribue un cachet (stocke son hash dans une variable d'état), de sorte qu'il puisse être validé à l'aide de Superfluid.isCtxValid.

AccordConstantFlowV1.createFlow

L'agreement utilise ensuite AgreementLibrary.authorizeTokenAccess pour vérifier que le host contract appelant est autorisé à effectuer des state modifying calls sur le token contract.

AgreementLibrary.authorizeTokenAccess

Une fois que le host appelant est authentifié, l'accord fait transitivement confiance au ctx transmis et le décode (désérialise) en une memory structure.

Mais un faux ctx !

Le problème était que, comme dans la fonction d'exploitation deleteAnyFlowBad, il est possible d'injecter un faux ctx.

Après avoir été fusionné (merged) en un seul objet octet par Superfluid.replacePlaceholderCtx (le Host ne fait aucune supposition sur les data spécifiques à un agreement), le dataWithCtx résultant contient maintenant 2 variantes de ctx, la légitime et celle injectée.

Lorsque le agreement contract décode ces données, le décodeur abi prend la première variante (injectée) et ignore les données restantes qui contiennent le ctx légitime.

Afin de résoudre ce problème, Superfluid a ajouté une étape de vérification dans le contrat d'accord :

ISuperfluid.isCtxValid. Cette étape vérifie le ctx décodé en comparant son cachet, son stamp (hash) stocké dans le host contract.

Cette vérification était déjà en place pour le traitement des données ctx fournies par les callbacks SuperApp, mais elle ne l'était pas pour les données transmises par le host contract de confiance.

Superfluid a contacté l'assaillant on-chain et, selon le post-mortem, une prime de 1M$ est toujours sur la table en échange de la restitution des fonds.

L'équipe déclare également que la plupart des comptes affectés ont déjà été remboursés, alors que les pertes plus importantes de QI et MOCA seront compensées plus progressivement.

Bien qu'il ne s'agisse pas de l'exploit le plus important (celui-ci figure au 42e rang de notre classement) et qu'aucun fonds d'utilisateur n'ait été perdu, il est remarquable par la manière dont il a affecté d'autres protocoles.

La croissance de l'infrastructure des DAO offre davantage de cibles aux assaillants anonymes qui sont si répandus au sein de la DeFi.

Les fonds volés se trouvent toujours dans le portefeuille de l'assaillant.

Le hacker acceptera-t-il la prime, ou laissera-t-il Superfluid rincé et à sec ?

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.