 . 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. (   ,   ) Jag heter Dexaran. Jag är en hackare, jag har designat och utfört en av de största attackerna på konsensusnivå i branschen EOSGO rapport community rapport    . (   ) Jag är grundare av ett av Ethereum Classics kärnutvecklingsteam Cointelegraphs artikel  Jag har utformat   , en uppsättning regler som   som var branschens gissel för krigsfångskedjor. tillägget till Nakamoto-konsensus löser 51 % attacker  Redaktörens anmärkning: Den här berättelsen representerar åsikterna från författaren till berättelsen. Författaren är inte knuten till HackerNoon-personalen och skrev den här historien på egen hand. HackerNoon-redaktionen har endast verifierat berättelsen för grammatisk korrekthet och tolererar/fördömer inte något av påståendena häri. #DYOR   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    . Överföringar till externt ägda adresser och överföringar till smarta kontrakt fungerar annorlunda. Detta är felaktigt. Liknande användarmisstag skulle inte resultera i förlust av Eth-, NFT- eller ERC-223-token  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   -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. ERC-223  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   modifierare för en styrningsfunktion – det skulle vara ett säkerhetsproblem. onlyOwner  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.   . År 2023   . ERC-20-standarden är osäker 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   och   . Jag har också designat ERC-223-standarden för att lösa detta exakta problem under 2017, här är den   -tråden där det framhålls att denna standard förhindrar en förlust av pengar. här här ursprungliga EIP-223     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   de "vi har ingenting att göra med säkerhetsavslöjande, vi har ingen process för det". svarade  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   min avslöjande EIP efter det. avvisade  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  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.  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.  Utvecklare säger "Vi implementerar bara standarden som den är."  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   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. säker genom design  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.

Read My Stories

Det här ljudet är producerat på berättelsens originalspråk!

För länge; Att läsa

Download free Tech Leaders Productivity Report!

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

About Author

KOMMENTARER

HÄNG TAGGAR

DENNA ARTIKEL PRESENTERAS I

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps