 . 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. (   ,   ) Mit navn er Dexaran. Jeg er en hacker, jeg har designet og udført et af de største angreb på konsensusniveau i branchen EOSGO rapport samfundsrapport    . (   ) Jeg er grundlægger af et af Ethereum Classics kerneudviklingsteams Cointelegraphs artikel  Jeg har designet   , et sæt regler, der   , som var industriens plage for krigsfangekæder. tillægget til Nakamoto-konsensus løser 51 % angreb  Redaktørens note: Denne historie repræsenterer historiens forfatters synspunkter. Forfatteren er ikke tilknyttet HackerNoon-personalet og skrev denne historie på egen hånd. HackerNoon-redaktionen har kun bekræftet historien for grammatisk nøjagtighed og tolererer/fordømmer ikke nogen af påstandene heri. #DYOR   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    . Overførsler til eksternt ejede adresser og overførsler til smart-kontrakter fungerer forskelligt. Dette er forkert. Lignende brugerfejl ville ikke resultere i tab af Eth, NFT eller ERC-223 token  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   -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. ERC-223  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   modifier for en styringsfunktion - det ville være et sikkerhedsproblem. onlyOwner  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.   . I 2023   . ERC-20-standarden er usikker bekræftede skaberen af ERC-20-standarden selv, at dette er et sikkerhedsproblem for standarden  Jeg har anmeldt det i 2017   og   . Jeg har også designet ERC-223-standarden til at løse netop dette problem i 2017, her er den   -tråd, hvor det fremhæves, at denne standard forhindrer et tab af penge. her her originale EIP-223     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   de "vi har intet at gøre med sikkerhedsafsløringer, det har vi ikke en proces for". svarede  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   min offentliggørelse af EIP efter det. afviste  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  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.  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.  Udviklere siger "Vi implementerer bare standarden, som den er."  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   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. secure by design  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.

Read My Stories

Denne lyd er produceret på historiens originalsprog!

For langt; At læse

Download free Tech Leaders Productivity Report!

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

About Author

KOMMENTARER

HÆNG TAGS

DENNE ARTIKEL BLEV PRÆsenterET I

Related Stories

Meet IONOS: HackerNoon Company of the Week

Meet Tailscale: HackerNoon Company of the Week

Yale Media Relations for Entrepreneurs with Journalist Walter Thompson & HackerNoon CEO David Smooke

Meet MinIO: The HackerNoon Company of the Week

Meet IONOS: HackerNoon Company of the Week

Meet Tailscale: HackerNoon Company of the Week

Yale Media Relations for Entrepreneurs with Journalist Walter Thompson & HackerNoon CEO David Smooke

Meet MinIO: The HackerNoon Company of the Week

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps