Trader mister $26M i ezETH-tokens: Media Blames User, Hacker Call Out ERC-20 Flaws

• Mit navn er Dexaran. Jeg er en hacker, jeg har designet og udført et af de største angreb på konsensusniveau i branchen . I 2019 DDOS'ede jeg EOS-netværkets hovednet og frøs det i en måned ved at udnytte en fejl i dets konsensusressourcemodel. EOS var rangeret top7 på det tidspunkt. ( EOSGO rapport , samfundsrapport )

  
  

• Jeg er grundlægger af et af Ethereum Classics kerneudviklingsteams . ( Cointelegraphs artikel )

  
  

• Jeg har designet tillægget til Nakamoto-konsensus , et sæt regler, der løser 51 % angreb , som var industriens plage for krigsfangekæder.

Ulykke

En bruger mistede ezETH-tokens til en værdi af $26.000.000 ved at sende dem til en smart-kontrakt. Der er flere artikler og twitter-tråde, der hævder, at dette var en brugerfejl, for eksempel denne af CoinTelegraph .

Dette er forkert. Lignende brugerfejl ville ikke resultere i tab af Eth, NFT eller ERC-223 token . Overførsler til eksternt ejede adresser og overførsler til smart-kontrakter fungerer forskelligt.

Hvis brugeren ville sende tokens til en forkert adresse (som ikke er en smart-kontrakt) eller adresse, der ikke ejes af nogen - ville det være en brugers fejl.

I dette tilfælde indsatte brugeren dog tokens til en smart-kontrakt. Smart-kontrakter formodes at forhindre disse fejl, og de kan helt sikkert gøre det - for eksempel hvis en bruger ville indbetale Ether (eller enhver anden indfødt valuta), NFT'er (ERC-721) eller ERC-223 -tokens til en smart-kontrakt, som var ikke designet til at modtage dem - så ville tokens ikke gå tabt. Der ville være en transaktionsfejl, og overførslen af tokens ville bare ikke ske.

Fejlhåndtering er et af de mest grundlæggende principper for softwaresikkerhed. At designe software på en sådan måde, at det ikke ville være muligt at håndtere invokationsfejl korrekt, er det samme som at mangle onlyOwner modifier for en styringsfunktion - det ville være et sikkerhedsproblem.

Dette er et problem i ERC-20-standarden - det er designet på en måde, der gør fejlhåndtering umulig. Og dette er et sikkerhedsproblem. ERC-20-standarden er usikker . I 2023 bekræftede skaberen af ERC-20-standarden selv, at dette er et sikkerhedsproblem for standarden .

Jeg har anmeldt det i 2017 her og her . Jeg har også designet ERC-223-standarden til at løse netop dette problem i 2017, her er den originale EIP-223 -tråd, hvor det fremhæves, at denne standard forhindrer et tab af penge.

Det er alt for nemt for sikkerhedsfirmaer og udviklere at bebrejde brugerne for at lave en fejl. Det er dog udviklerens skyld, at de byggede deres applikationer ved hjælp af den usikre standard, som ikke kan håndtere brugernes fejl, som resulterede i en så katastrofal skade.

Historie

Jeg har fremhævet, at dette kan forårsage økonomisk skade for brugerne, mens det rapporteres til Ethereum Foundation. De gjorde ingenting. I 7 år.

• Der gik $16.000 tabt på grund af dette problem i 2017.
• Der gik $2.000.000 tabt i 2018
• $60.000.000 i 2023
• Den 1. november 2024 var der $90.000.000 (eksklusive de 25 mio. tabt i ezETH-kontrakten)
• Nu er der $115.000.000

Mit team udviklede et script, der beregner mængden af tabte tokens:

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

• I 2017 mistede en anden bruger 130K.
• I 2020 mistede en bruger sin livsopsparing.
• I 2023 mistede en bruger $240.000 i en transaktion.
• Så tabte Poloniex-hackeren $2,5 mio.

Jeg har anmodet om at stoppe med at promovere ERC-20-standarden på grund af dette sikkerhedsproblem i 2017, der var intet svar https://github.com/ethereum/ethereum-org/issues/755 .

Jeg har eskaleret dette problem til EthereumCatHerders, de fyre, der administrerer EIP'er i Ethereum.

I 2023 svarede de "vi har intet at gøre med sikkerhedsafsløringer, det har vi ikke en proces for".

Præcisering: EIP'er og ERC'er er forslag, som alle kan indsende til Ethereum. De kan blive standarder eller modifikationer, som udviklere gælder for, hvordan Ethereum fungerer. De er tekstfiler i deres github-repo.

Kontekst: de har ikke en proces til at håndtere sikkerhedsoplysninger i EIP'er 10 år efter lanceringen af Ethereum-projektet.

Jeg foreslog en metode til at ændre, hvordan EIP'er fungerer for at tillade sikkerhedsoplysninger: https://ethereum-magicians.org/t/modification-of-eip-process-to-account-for-security-treatments/16265

Jeg foreslog at tilføje en advarsel om ERC-20 og dokumentere problemet i EIP'erne. Her er deres opkald, hvor de besluttede, at jeg skulle hen og oprette en anden informativ EIP, der ville afsløre en sårbarhed i EIP-20: https://github.com/ethcatherders/EIPIP/issues/257#issuecomment-1693372317

Det gjorde jeg. De afviste min offentliggørelse af EIP efter det.

Jeg kom med forslaget om at genoplive min oprindelige idé, som jeg beskrev på EthereumMagicians forum, som ville tillade sikkerhedsoplysninger i afsnittet "Sikkerhedsovervejelser" af EIP'er i 2024 igen.

Her er min diskussion med EIP-redaktører: https://www.youtube.com/watch?v=PKkJNqcozhw&t=744s

Som resultat fortalte EIP-redaktørerne mig, at de vil stemme om det: https://github.com/ethcatherders/EIPIP/issues/349

Mit forslag blev stemt ud. Der er stadig ingen proces til at håndtere sikkerhedsoplysninger i EIP'er. Problemet med ERC-20 er ikke løst. Det er ikke engang rapporteret eller dokumenteret som et problem, så implementere bliver ved med at reproducere det igen og igen.

Urimelige revisorer

Jeg rapporterede personligt dette problem til OpenZeppelin og anmodede om en rettelse 3 gange.

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

  
  

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

  
  

• Efter at de afviste de to foregående, besluttede jeg at rapportere det på en måde, der kunne demonstrere problemets alvor, så jeg indsendte det til deres bug-bounty, fordi det passer ind i kriterierne for "kritisk sikkerhedssårbarhed" i henhold til deres egne regler https:/ /github.com/OpenZeppelin/openzeppelin-contracts/issues/4474#issuecomment-1646901022

OpenZeppelin afviste det med "offentlig offentliggørelse af unpatched sårbarhed" (hvilket bekræfter, at dette i det mindste er et sikkerhedsproblem).

For et par dage siden på Devcon7 blev der stillet et spørgsmål til den samme fyr fra OpenZeppelin, som lukkede et problem på deres github vedrørende dette problem: https://www.youtube.com/watch?app=desktop&v=DKJYpdXsOwQ&start=406

6 år efter det blev rapporteret, og efter at det forårsagede $115.000.000 tab for deres brugere.

Deres svar er ikke engang sandt. I stedet for at have et åbent problem, lukkede de 3 spørgsmål, som jeg åbnede, og afviste alle anbefalinger, jeg havde fremsat.

Konklusion

1. Ethereum Foundation censurerer ethvert forsøg på at fremhæve problemet, hvilket fik brugere af økosystemet til at miste $115.000.000. Problemet er ikke annonceret, offentliggørelse er ikke håndteret korrekt, implementere bliver ved med at gengive det i nye kontrakter.

   
   

   Jeg tror, de mener, at det ville være for skadeligt for deres omdømme at afsløre det.

2. Revisorer som OpenZeppelin afslører heller ikke spørgsmålet, sandsynligvis fordi de har en interessekonflikt, da de allerede har placeret "Secure"-mærket på hundredvis af ERC-20-kontrakter, som de reviderede.

   
   

3. Udviklere siger "Vi implementerer bare standarden, som den er."

   
   

4. Standarden er styret af EIP-processen, EIP-processen er ikke bygget til at håndtere sikkerhedsoplysninger.

EIP-processen skal ændres. ERC-20-problemet skal oplyses og dokumenteres korrekt. Ideelt set skal en ny standard implementeres. Det er bedre at anvende et sæt "bandaids" på ERC-20 for at afbøde skaden end at gøre ingenting, men det ville ikke løse problemet i sig selv.

Alle, der siger "problemet kan løses på tegnebogsniveau", mangler sikkerhedsekspertise. Der er et princip om secure by design i softwaresikkerhed, hvilket betyder, at du ikke kan bygge et stykke usikker software, fortælle alle, hvordan de skal bruge det, så det ikke påvirker dine brugere, og lade som om, at det ikke vil forårsage skade. Ikke i en finansbranche. Den tilgang kan for eksempel fungere i webdesign, hvor omkostningerne ved en fejl er, at en person ikke er i stand til at indlæse en korrekt skrifttype til deres webside. I den finansielle industri resulterer dette i, at millioner af dollars går tabt.

Det er absolut umuligt at garantere, at alle tegnebogsudviklere i hele fremtiden for den menneskelige civilisation altid vil implementere alle de nødvendige rettelser korrekt.