Trader förlorar 26 miljoner dollar i ezETH-tokens: Media skyller på användare, hackare kallar ut ERC-20-brister

• Jag heter Dexaran. Jag är en hackare, jag har designat och utfört en av de största attackerna på konsensusnivå i branschen . 2019 DDOS:ade jag EOS-nätverkets huvudnät och frös det i en månad genom att utnyttja en brist i dess konsensusresursmodell. EOS var rankad topp7 vid den tiden. ( EOSGO rapport , community rapport )

  
  

• Jag är grundare av ett av Ethereum Classics kärnutvecklingsteam . ( Cointelegraphs artikel )

  
  

• Jag har utformat tillägget till Nakamoto-konsensus , en uppsättning regler som löser 51 % attacker som var branschens gissel för krigsfångskedjor.

Olycka

En användare förlorade $26 000 000 i ezETH-tokens genom att skicka dem till ett smart-kontrakt. Det finns flera artiklar och twittertrådar som hävdar att detta var ett användarmisstag, till exempel den här av CoinTelegraph .

Detta är felaktigt. Liknande användarmisstag skulle inte resultera i förlust av Eth-, NFT- eller ERC-223-token . Överföringar till externt ägda adresser och överföringar till smarta kontrakt fungerar annorlunda.

Om användaren skulle skicka tokens till en felaktig adress (som inte är ett smart-kontrakt) eller adress som inte ägs av någon - det skulle vara ett användarens misstag.

I det här fallet deponerade dock användaren tokens till ett smart-kontrakt. Smarta kontrakt är tänkta att förhindra dessa misstag, och de kan verkligen göra det - till exempel om en användare skulle sätta in Ether (eller någon annan inhemsk valuta), NFTs (ERC-721) eller ERC-223 -tokens till ett smart-kontrakt som var inte designad för att ta emot dem — då skulle tokens inte gå förlorade. Det skulle uppstå ett transaktionsfel och överföringen av tokens skulle helt enkelt inte ske.

Felhantering är en av de mest grundläggande principerna för mjukvarusäkerhet. Att designa programvara på ett sådant sätt att det inte skulle vara möjligt att korrekt hantera anropsfel är detsamma som att sakna onlyOwner modifierare för en styrningsfunktion – det skulle vara ett säkerhetsproblem.

Detta är ett problem med ERC-20-standarden — den är utformad på ett sätt som gör felhantering omöjlig. Och detta är ett säkerhetsproblem. ERC-20-standarden är osäker . År 2023 bekräftade skaparen av ERC-20-standarden själv att detta är en säkerhetsfråga för standarden .

Jag har redovisat det under 2017 här och här . Jag har också designat ERC-223-standarden för att lösa detta exakta problem under 2017, här är den ursprungliga EIP-223 -tråden där det framhålls att denna standard förhindrar en förlust av pengar.

Det är alldeles för lätt för säkerhetsföretag och utvecklare att skylla på användare för att ha gjort ett misstag. Det är dock utvecklarens fel att de byggde sina applikationer med den osäkra standarden som misslyckas med att hantera användarnas misstag som resulterade i en sådan katastrofal skada.

Historia

Jag har framhållit att detta kan orsaka ekonomisk skada för användarna samtidigt som detta rapporteras till Ethereum Foundation. De gjorde ingenting. I 7 år.

• Det gick förlorade $16 000 på grund av detta problem 2017.
• Det gick förlorade 2 000 000 $ 2018
• 60 000 000 USD 2023
• Den 1 november 2024 fanns det 90 000 000 $ (exklusive de 25 miljonerna förlorade i ezETH-kontraktet)
• Nu finns det 115 000 000 $

Mitt team utvecklade ett skript som beräknar mängden förlorade tokens:

https://dexaran.github.io/erc20-losses

• Under 2017 förlorade en annan användare 130 000.
• År 2020 förlorade en användare sina livsbesparingar.
• 2023 förlorade en användare 240 000 USD i en transaktion.
• Då förlorade Poloniex hacker $2,5 miljoner.

Jag har begärt att sluta marknadsföra ERC-20-standarden på grund av detta säkerhetsproblem 2017, det kom inget svar https://github.com/ethereum/ethereum-org/issues/755 .

Jag har eskalerat den här frågan till EthereumCatHerders, killarna som hanterar EIP:er i Ethereum.

2023 svarade de "vi har ingenting att göra med säkerhetsavslöjande, vi har ingen process för det".

Förtydligande: EIP och ERC är förslag som vem som helst kan skicka till Ethereum. De kan bli standarder eller modifieringar som utvecklare tillämpar på hur Ethereum fungerar. De är textfiler i deras github-repo.

Sammanhang: de har ingen process för att hantera säkerhetsavslöjande i EIPs 10 år efter lanseringen av Ethereum-projektet.

Jag föreslog en metod för att ändra hur EIP:er fungerar för att möjliggöra säkerhetsavslöjande: https://ethereum-magicians.org/t/modification-of-eip-process-to-account-for-security-treatments/16265

Jag föreslog att lägga till en varning om ERC-20 och dokumentera frågan i EIP:erna. Här är deras samtal, där de bestämde att jag måste gå och skapa en annan informations-EIP som skulle avslöja en sårbarhet i EIP-20: https://github.com/ethcatherders/EIPIP/issues/257#issuecomment-1693372317

Jag gjorde det. De avvisade min avslöjande EIP efter det.

Jag kom med förslaget att återuppliva min ursprungliga idé som jag beskrev på EthereumMagicians forum som skulle tillåta säkerhetsavslöjande i avsnittet "Säkerhetsöverväganden" i EIP:er 2024 igen.

Här är min diskussion med EIP-redaktörer: https://www.youtube.com/watch?v=PKkJNqcozhw&t=744s

Som ett resultat sa EIP-redaktörerna till mig att de kommer att rösta om det: https://github.com/ethcatherders/EIPIP/issues/349

Mitt förslag röstades bort. Det finns fortfarande ingen process för att hantera säkerhetsavslöjande i EIP. Problemet med ERC-20 är inte löst. Det är inte ens rapporterat eller dokumenterat som ett problem så implementerare fortsätter att reproducera det om och om igen.

Orättvisa revisorer

Jag rapporterade personligen det här problemet till OpenZeppelin och begärde en fix 3 gånger.

• Under 2018 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/729

  
  

• År 2023 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4451

  
  

• Efter att de avvisat de två föregående, bestämde jag mig för att rapportera det på ett sätt som skulle visa hur allvarligt problemet är, så jag skickade in det till deras buggpris eftersom det passar in i kriterierna för "kritisk säkerhetssårbarhet" enligt deras egna regler https:/ /github.com/OpenZeppelin/openzeppelin-contracts/issues/4474#issuecomment-1646901022

OpenZeppelin avvisade det med "offentliggörande av oparpad sårbarhet" (vilket bekräftar att detta åtminstone är ett säkerhetsproblem).

För några dagar sedan på Devcon7 ställdes en fråga till samma kille från OpenZeppelin som stängde ett problem på sin github angående det problemet: https://www.youtube.com/watch?app=desktop&v=DKJYpdXsOwQ&start=406

6 år efter att det rapporterades och efter att det orsakade $115 000 000 förlust för deras användare.

Deras svar är inte ens sant. Istället för att ha ett öppet problem stängde de 3 nummer som jag öppnade och avvisade alla rekommendationer som jag gjorde.

Slutsats

1. Ethereum Foundation censurerar alla försök att belysa problemet, vilket fick användare av ekosystemet att förlora $115 000 000. Problemet tillkännages inte, avslöjandet hanteras inte korrekt, implementörer fortsätter att återge det i nya kontrakt.

   
   

   Jag tror att de anser att det skulle vara för skadligt för deras rykte att avslöja det.

2. Revisorer som OpenZeppelin avslöjar inte problemet lika bra, förmodligen för att de har en intressekonflikt eftersom de redan placerat "Secure"-etiketten på hundratals ERC-20-kontrakt som de granskat.

   
   

3. Utvecklare säger "Vi implementerar bara standarden som den är."

   
   

4. Standarden styrs av EIP-processen, EIP-processen är inte byggd för att hantera säkerhetsavslöjande.

EIP-processen måste ändras. ERC-20-problemet måste avslöjas och dokumenteras korrekt. Helst måste en ny standard implementeras. Att använda en uppsättning "bandaids" på ERC-20 för att mildra skadan är bättre än att inte göra någonting, men det skulle inte lösa problemet i sig.

Alla som säger "problemet kan lösas på plånboksnivå" saknar säkerhetsexpertis. Det finns en princip om säker genom design inom mjukvarusäkerhet som innebär att du inte kan bygga en osäker programvara, berätta för alla hur man använder den så att den inte skulle påverka dina användare och låtsas att den inte kommer att orsaka skada. Inte i en finansbransch. Det tillvägagångssättet kan fungera i webbdesign, till exempel, där kostnaden för ett fel är att någon inte kan ladda ett korrekt typsnitt för sin webbsida. I finansbranschen leder detta till att miljontals dollar går förlorade.

Det är absolut omöjligt att garantera att alla plånboksutvecklare i hela den mänskliga civilisationens framtid alltid korrekt skulle implementera alla nödvändiga korrigeringar.