Poly Network - REKT

Nous y voilà, chers lecteurs de rekt : le gros coup.

611 millions de dollars dérobés.

C'est plus que le hack de Mt Gox. Plus que le PIB de plusieurs petits pays. Plus que tout le classement de rekt.news cumulé.

Le plus grand hack de crypto-monnaie, de tous les temps.

Poly Network = rekt.

Mais comment cela a-t-il été possible ?

Source : breadcrumbs.app, slowmist, blocksec

Assaillant ETH : 0xc8a65fadf0e0ddaf421f28feab69bf6e2e589963

Assaillant BSC : 0x0D6e286A7cfD25E0c01fEe9756765D8033B32C71

Nous nous trouvions loin des habituelles histoires d'arbitrage ou de flash loan de smart contracts.

Le hacker a exploité les contrats Proxy Lock de Poly Network sur trois blockchains différentes.

Ethereum : 0x250e76987d838a75310c34bf422ea9f1ac4cc906

BSC : 0x05f0fDD0E49A5225011fff92aD85cC68e1D1F08e

Polygon : 0x28FF66a1B95d7CAcf8eDED2e658f768F44841212

Source : @kelvinfichter

"Poly a un contrat appelé "EthCrossChainManager". C'est un contrat privilégié qui a le droit de déclencher des messages à partir d'une autre chain. C'est quelque chose de banal pour les projets cross-chain.

Ce contrat possède une fonction appelée verifyHeaderAndExecuteTx que n'importe qui peut call pour exécuter une transaction cross-chain.

Elle (1) vérifie que l'en-tête du bloc est correct en vérifiant les signatures (il semble que l'autre chain était une sidechain poa) puis (2) vérifie que la transaction a bien été incluse dans ce bloc avec une preuve Merkle. Le code se trouve ici.

L'une des dernières choses que fait la fonction est de call executeCrossChainTx, qui effectue le call au contrat cible. C'est ici que se situe la faille critique. Si Poly vérifie que la cible est un contrat, il a cependant omis d'empêcher les utilisateurs de call une cible très importante... le contrat EthCrossChainData.

En envoyant ce message à travers la chain, l'utilisateur pouvait duper le EthCrossChainManager et l'amener à call le contrat EthCrossChainData, cela en passant le contrôle onlyOwner. L'utilisateur n'avait plus qu'à créer les bonnes données pour être capable de déclencher la fonction permettant de changer les clés publiques...

Le dernier défi était de trouver comment faire en sorte que le EthCrossChainManager call la bonne fonction. Cela devient alors un peu complexe pour savoir comment Solidity choisit la fonction que vous essayez de call.

Les quatre premiers octets des données d'entrée de la transaction sont appelés "hachage de signature" ou " sighash " en abrégé. Il s'agit d'une courte information qui indique au contrat Solidity ce que vous essayez de faire.

Le hachage d'une fonction est calculé en prenant les quatre premiers octets du hachage de "<nom de la fonction>(<types d'entrée de la fonction>)". Par exemple, le sighash de la fonction de transfert ERC20 est constitué des quatre premiers octets du hash de "transfer(address,uint256)".

Le contrat de Poly était prêt à call n'importe quel contrat. Cependant, il ne faisait que call la fonction du contrat qui correspondait au hachage suivant :

Euh, mais attendez... "_method" était ici une entrée utilisateur. Tout ce que l'assaillant avait à faire pour call la bonne fonction était de trouver une valeur pour "_method" qui, une fois combinée avec ces autres valeurs et hashée, avait les mêmes quatre premiers octets que le sighash de notre fonction cible.

Avec un minimum de persévérance, vous pouvez facilement trouver une entrée qui produit le bon sighash. Vous n'avez pas besoin de trouver une collision de hashage complète : vous n'avez qu'à vérifier les quatre premiers octets. Cette théorie est-elle donc la bonne ?

Eh bien voici le sighash réel de la fonction cible :

http://ethers.utils.id ('putCurEpochConPubKeyBytes(bytes)').slice(0, 10)

‘0x41973cd9'.

Et le "sighash" que l'assaillant a créé...

http://ethers.utils.id ('f1121318093(bytes,bytes,uint64)').slice(0, 10)

‘0x41973cd9'

Fantastique. Pas besoin de compromettre la clé privée ! Il suffit de créer les bonnes données et hop... le contrat se hackera lui-même !

Une des plus importantes leçons de conception à tirer de tout cela est que, si vous avez des contrats de relais cross-chain comme celui-ci, IL EST IMPÉRATIF DE S'ASSURER QU'ILS NE PEUVENT PAS ÊTRE UTILISÉS POUR APPELER DES CONTRATS SPÉCIAUX. Le EthCrossDomainManager n'aurait pas dû détenir le contrat EthCrossDomainData.

Des préoccupations distinctes. Si votre contrat doit absolument avoir des privilèges spéciaux comme celui-ci, assurez-vous que les utilisateurs ne peuvent pas utiliser les messages cross-chain pour CALL ces contrats spéciaux."

Sur la blockchain Ethereum, le hacker a volé :

USDC - 96 389 444

WBTC - 1 032

DAI - 673 227

UNI - 43 023

SHIBA - 259 737 345 149

renBTC - 14.47

USDT - 33 431 197

wETH - 26 109

FEI USD - 616 082

Sur la BSC, le hacker a volé :

BNB - 6 613.44

USDC - 87 603 373

ETH - 299

BTCB - 26 629

BUSD - 1 023

Sur la blockchain Polygon, le hacker a volé :

USDC - 85 089 610

VALEUR TOTALE PERDUE - ~611 000 000 $.

Au moment de la rédaction de cet article, les fonds volés se trouvent dans les portefeuilles suivants :

ETH : 0xC8a65Fadf0e0dDAf421F28FEAb69Bf6E2E589963

BSC : 0x0D6e286A7cfD25E0c01fEe9756765D8033B32C71

Polygon : 0x5dc3603C9D42Ff184153a8a9094a73d461663214

Les intrigues de la DeFi sont rarement simples, et celle-ci ne fait pas exception.

Ce qui est sûr, c'est que même les acteurs anonymes raffolent de l'attention.

Peu de temps après l'exploit, un protagoniste inattendu est apparu, répondant au nom de hanashiro.eth.

hanashiro.eth a d'abord attiré l'attention en envoyant au hacker un conseil sur la façon de manipuler les USDT, ce qui lui a valu de recevoir 13,37 Ether de la part du hacker comme récompense.

À la suite de cela, bien des gens ont envoyé des messages au hacker, mais aucun n'a eu autant de succès que hanashiro.eth.

Avec un niveau de philanthropie spectaculaire et authentiquement cryptographique, hanashiro.eth a fait don de l'argent volé à quelques-unes des organisations fondatrices qui soutiennent notre industrie, comme Infura, Etherscan ou encore rekt.news.

Mais tous les fonds n'étaient pas aussi librement accessibles.

Tether a gelé les 33 millions d'USDT volés sur la blockchain Ethereum.

Leur coin - leur choix... Un fait dont il faut se souvenir si vous utilisez l'USDT.

À ce stade, la situation est devenue critique et tous les regards se sont tournés vers Poly Network, qui a publié une lettre ouverte à l'assaillant pour le supplier de rendre les fonds.

Un simple tweet pour demander à un criminel de rendre 600 millions de dollars... Peut-être Gensler avait-il raison lorsque celui-ci a estimé que nous étions dans la phase "Far West" des crypto-monnaies.

Mettez-vous à la place de l'assaillant à ce stade de l'histoire. Que croyez-vous qu'ils ont ressenti le plus : l'euphorie ou la terreur ?

Voler 600 millions de dollars en restant assis devant son ordinateur doit être une expérience assez surréaliste.

L'expérience consistant à essayer ensuite de blanchir cet argent doit être tout aussi intense.

En dehors de JPEGS, tornado.cash serait évidemment un bon point de départ. Et c'est exactement là que notre hacker s'est rendu.

Il s'est envoyé à lui-même une transaction contenant le message suivant :

Et pourquoi pas Tornado ? Les mineurs vont-ils me stopper ? Instruisez-moi, s'il vous plaît.

Était-ce une opération psychologique ou de la stupidité ? En crypto, on ne sait jamais trop…

Le voilà en cavale avec 600 millions et diffusant des messages à une audience de milliers de personnes.

Le hacker devenait trop confiant.

Quand @WardBradt a tweeté ceci :

L'exploiteur de PolyNetwork a-t-il accidentellement utilisé la mauvaise adresse d'expéditeur pour ce tx 0xb12681d9e ? L'adresse de l'expéditeur est liée à des comptes FTX, Binance, 0kex.

L'attitude de l'assaillant a subitement changé.

Un assaillant qui se sent assez confiant pour tenter une attaque de cette ampleur ne ferait tout de même pas une erreur d'OPSEC aussi élémentaire ? A moins qu'il n'ait utilisé de faux documents pour le KYC...

Quoi qu'il en soit, nous commençons à percevoir des signes de fébrilité de la part de l'assaillant.

Le hacker a commencé à suggérer qu'il pourrait retourner "quelques tokens" voire même les abandonner, en affirmant ne pas être "si intéressé que ça par l'argent".

Puis le hacker a ensuite envisagé l'idée de créer une DAO pour redistribuer les fonds volés.

Finalement, la pression étant devenue trop forte, le hacker a annoncé qu'il était "PRÊT À SE RENDRE".

Dans un geste inattendu et sans précédent, l'assaillant est maintenant en train de rendre les fonds à Poly Network.

Le hacker a annoncé qu'il était "PRÊT À RENDRE LES FONDS" dans une transaction Ethereum envoyée depuis le même porte-monnaie que celui utilisé pour l'attaque.

Avant d'envoyer la première transaction de retour, le hacker a créé un token appelé "The hacker is ready to surrender", puis l'a envoyé à Poly Network qui a annoncé qu'il avait mis en place un multisig contrôlé par des ''adresses Poly connues''.

Un résumé de la communication des hackers avec Poly Network peut être trouvé ici.

À l'heure où nous écrivons ces lignes, le hacker a renvoyé ce qui suit :

Sur la blockchain Ethereum : 2,6 millions de dollars

Sur la BSC : 1,1 million de dollars

Sur la blockchain Polygon : 1 million de dollars

Le hacker va-t-il continuer à rendre les fonds, ou s'agit-il encore d'un coup monté ?

Peut-il vraiment simplement rendre l'argent et être pardonné ?

Poly Network. 611 millions.

Et vous pensiez connaître tous les grands protocoles de la DeFi.

Cette industrie a grandi plus que notre chambre d'écho ne peut le supporter.

Si cette attaque est la première de cette ampleur, elle ne sera pas la dernière que nous verrons dans les années à venir. Et pourtant, et à juste titre, le marché ne semble pas abattu.

Pour le meilleur ou pour le pire, les crypto-monnaies feront la une des journaux, et le monde devra en tirer les conséquences au fur et à mesure que notre secteur deviendra la norme.

Ce n'est qu'une autre étape inévitable du progrès.

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.