Het volledige verhaal achter de Poly-network hack

Het verhaal achter de grootste cryptohack ooit..

Op 10 augustus 2021 werd Poly Network gehacked met een potentieel verlies van meer dan 600 miljoen dollar. De hack vond plaats op meerdere blockchains, waaronder ‎‎Ethereum,‎‎ ‎‎Binance Smart Chain ‎‎en ‎‎Polygon‎‎. Dit is de grootste cryptohack tot nu toe.‎
(Mt.GOX was groter , maar zat anders in elkaar..)

Wie zijn zij ?

‎Poly Network is een Blockchain-interoperabiliteits-project waarmee mensen transacties over blockchains kunnen verzenden. Een van hun belangrijkste use-case- is een cross-blockchain brug waarmee je assets van de ene blockchain naar de andere kunt verplaatsen door tokens op de ene blockchain te vergrendelen en ze op een andere te ontgrendelen. De aanvaller slaagde erin tokens op verschillende blockchains te ontgrendelen zonder de bijbehorende bedragen op andere blockchains te vergrendelen.‎

Wat iedereen wil weten , hoe lukte dit ?

‎Poly Network-project is een flexibel project en maakt algemene berichtpassing via blockchains mogelijk. Het maakt gebruik van vertrouwde entiteiten genaamd "keepers" om cross-blockchain transacties te vergemakkelijken. De gebruiker doet de transactie oorspronkelijk op een bron-blockchain en wordt herhaald op de doel-blockchain via Poly Network. De keepers ondertekenen blokken van de bron-blockchain die de oorspronkelijke transactie bevat. De gebruiker dient dit ondertekende blok vervolgens in bij een smart-contract‎‎ (EthCrossChainManager)‎‎ op de doel-blockchain die de geldigheid van de handtekening controleert. Als de handtekeningen geldig zijn, voert het contract een vergelijkbare transactie uit op de doel-blockchain.‎

‎Dit kan elke transactie zijn. Er wordt niet gefilterd op transacties. Aangezien deze transactie wordt uitgevoerd door EthCrossChainManager op de doel-blockchain in plaats van de gebruiker, kunnen de gebruikers zich voordoen als EthCrossChainManager en bijna elke transactie uitvoeren. Dit ontwerp maakt het noodzakelijk om ervoor te zorgen dat de EthCrossChainManager geen speciale machtigingen heeft die de gebruikers kunnen misbruiken door zich voor te doen als de EthCrossChainManager.

Maar het smart-contract heeft echter de toestemming om de keepers die zijn opgeslagen in het ‎‎EthCrossChainData-contract‎‎ te wijzigen. Hierdoor kon de aanvaller de oorspronkelijke keepers ruilen voor een kwaadaardige keeper die door de aanvaller wordt bestuurd.‎

‎Zodra de keeper in de controle van de aanvaller was, kon de aanvaller willekeurige cross-chain transacties uitvoeren op de doel-blockchains, zelfs als een dergelijke transactie niet plaatsvond op de bron-blockchain. De aanvaller deed dat door valse blokken van de bron-blockchain te ondertekenen die willekeurige transacties naar keuze van de aanvaller bevatten. Deze blokken waren geen geldige blokken van de bron-blockchains. Aangezien EthCrossChainManager er echter alleen voor zorgt dat het blok wordt ondertekend door de keepers in plaats van het volledige blok te verifiëren, accepteerde het ze als geldige blokken en voerde het de willekeurige cross-chain transacties uit die door de aanvaller waren ingevoegd.‎

‎De aanvaller creëerde valse transacties waarmee ze tokens op de doel-blockchain konden ontgrendelen zonder ze op de bron-blockchain te vergrendelen.

Het LockProxy-contract beheert het vergrendelen en ontgrendelen van tokens. Het ontgrendelt tokens op de doel-blockchain wanneer deze wordt aangeroepen door de EthCrossChainManager van de bron-blockchain via een cross-blockchain-oproep. Het EthCrossChainManager-contract maakt een dergelijke aanroep alleen als de gebruiker zijn tokens op de bron blockchain vergrendelt. De aanvaller omzeilde het slot door een nep-oproep van EthCrossChainManager naar de LockProxy te maken met behulp van de kwaadaardige keeper. Het LockProxy-contract voor de doelketen accepteerde de cross-chain call en ontgrendelde de tokens. LockProxy ging ervan uit dat de gebruiker de overeenkomstige hoeveelheid tokens al heeft vergrendeld op de bron blockchain.‎

‎Nu heeft de bron-blockchain tokens die zouden moeten worden vergrendeld, maar die daadwerkelijk zijn ontgrendeld. Deze tokens worden niet langer gedekt door onderpand.

De aanvaller is er in feite in geslaagd om tokens over twee netwerken te dupliceren. De originele, waardevolle tokens bevinden zich op de doel-blockchain, onder de controle van de aanvaller. Andere gebruikers blijven achter met niet-gecodaliseerde, dubbele tokens op bron-blockchains

Als gevolg hiervan zijn mensen die deze tokens in welke vorm dan ook hebben (vasthouden in hun portemonnee, liquiditeit verstrekken, enz.) degenen die een verlies hebben geleden. De prijs van deze overbrugde tokens (pTokens als pEth) zal naar verwachting sterk dalen. Het is het beste om te wachten en deze situatie te laten spelen, omdat de aanvaller het geld kan terugbetalen, in welk geval pTokens terug moet gaan naar peg.‎

‎De hoofdoorzaak van deze exploit is dat het EthCrossChainManager-contract de Keepers mag wijzigen. Er wordt verwacht dat het hele protocol wordt gecompromitteerd als de keepers worden gecompromitteerd. In dit geval slaagde de aanvaller erin om direct te veranderen wie de keepers zijn in plaats van de bestaande keepers in gevaar te brengen.

Stel je voor dat iemand de mogelijkheid had om je wachtwoord te wijzigen. Zelfs als ze uw wachtwoord niet kenden, zouden ze het gewoon wijzigen in een wachtwoord dat ze kennen en dat vervolgens gebruiken om in te loggen.‎

Uitgewerkte technische details van de hack /
deze is Engelstalig :

The EthCrossChainManager contract has a function that allows users to execute arbitrary cross chain transactions.verifyHeaderAndExecuteTx
EthCrossChainManager verifies that the block containing this transaction has been signed by more than two thirds of the trusted keepers before executing the transaction.
The keepers are supposed to sign only the blocks that are real and exist on the source blockchain.
Once the user executes a transaction on source blockchain, they can take the real block from the source blockchain, have the keepers sign it and then do a cross-chain transaction on the destination blockchain using the keeper’s signature.
The arbitrary transaction is supposed to call only the functions that take as parameters. The contract tries to ensure this by generating the target function signature using.(bytes,bytes,uint64)abi.encode
Packed(_method, "(bytes,bytes,uint64)")
This is an incorrct security assumption which can be easily bypassed. Function signatures are only 4 byte long in solidity. They are meant to be generated by hashing the function name and parameters together but that is not enforced by the EVM. It is very easy to find collisions. For example, and generate the same function .

The list of trusted keepers is stored in the EthCrossChainData contract and can only be changed by the Owner of the contract by calling .putCurEpochConPubKeyBytes(bytes)
Since EthCrossChainManager allows users to execute arbitrary transactions, it is not supposed to be owner of anything but was made owner of the EthCrossChainData contract. The attacker exploited a combination of this fact and incorrect function signature security assumption to make the EthCrossChainManager call EthCrossChainData’s function and change the keepers to a single keeper that they control.putCurEpochConPubKeyBytes(bytes)
The attacker did this by normally calling a function like on a source blockchain (Ontology Blockchain, Allegedly) that triggers the function signature collission. The transaction most likely reverted because such a function doesn’t exist in the contract. However, even reverted transactions are part of the block.f1121318093(bytes,bytes,uint64)EthCrossChainData
The keepers signed the block containing the attackers transaction because it was a legit transaction (Albeit it probably reverted).
The attacker then used this signature to do a cross-chain transaction on the destination blockchains (Ethereum, Binance Smart Chain, and Polygon). Since these transactions were dispatched via , the check in was fulfilled and the trusted keepers were swapped to a malicious keeper.
EthCrossChainManageronlyOwnerEthCrossChainData
Having control of the Keepers meant that the attacker could trick EthCrossChainManager contract into executing cross-chain transactions that aren’t even real on the source blockchain.
The LockProxy contract has an function that accepts cross-chain calls from the EthCrossChainManager of source blockchains.unlock
The attacker created fake blocks that had transactions from the EthCrossChainManager of soure blockchains, calling the function of LockProxy.unlock
the trusted keepers would not have signed such bogus blocks but since the attacker controls the malicious keeper, they signed the block.
The EthCrossChainManager verified that the block was signed by the keeper and then executed the transaction. This resulted in LockProxy unlocking and sending the tokens to the attacker.
The attacker repeated this with various tokens accross multiple blockchains.
Also worth noting that the EthCrossChainManager contract mandatarily fills the last two params of the arbitrary transaction with and params. This meant that the encoded keepers data was not ideally typed. The EthCrossChainManager contract use a custom decoding and deserializing scheme when extracting the keepers’ addresses from the encoded data. This attack was only made possible due to the lineant decoding and deserialization scheme. If the encoded data was type checked more strictly, the transactions shoudl’ve failed._fromContractAddr_fromChainId
Addendum
The hack started as early as Aug-10-2021 09:33:07 AM +UTC and the drainage continued till at least Aug-10-2021 10:29:21 AM +UTC. If there were stricter monitoring and alerting mechanisms in place, the damage could potentially have been minimized as EthCrossChainManager is a pausible contract.

I originally posted a Twitter thread with my early findings. I alleged that only a single keeper was used, and that keeper got compromised because it was signing invalid blocks. This analysis was based on just one transaction that triggered a cross-chain unlock. I did not look at previous transactions and missed the crucial bit where the attacker swapped the trusted keepers with a malicious keeper.

My original thoughts were that this is a boring, traditional hack. Due to this, I didn’t bother analyzing more transactions. After learning that the attacker switched the keepers rather than compromising the keeper’s keys, it became a fascinating hack to analyze!

Right now, it seems like the attacker is negotiating a partial return of funds to Poly Network by sending messages over the Ethereum network. You can track the conversations via this google sheet created by a community member.

The attacker apparently has linked wallets that were used on centralized exchanges and people are trying to gather real information about the attacker from the exchanges. It is possible that the attacker used stolen accounts but it’s also possible that this direction of investigation will reveal the attacker’s real Identity. Earlier, the attacker posted some troll comments via their Ethereum address and also tipped a different troller. This is a bit unusual behavior since more interactions imply more chances of a slip-up. It is possible that the attacker has already slipped up and is now in damage control mode. It is also possible that they are just trolling. All of this is speculation at this point but quite interesting, nonetheless.

Updates (Laatste update over verloop hack) :

The attacker is now claiming to be a whitehat and is negotiating returning all funds. They have already refunded over $250 million.
The hacker has returned all funds (except for the frozen USDT). They were offered a $500k bug bounty reward which they declined. The hacker can now be labelled as a white hat. Perfect example of a chaotic neutral, I guess.

met dank aan (bron) : mudit.blog

web-site Poly-network : https://www.poly.network/#:~:text=Poly%20Netw