Prekybininkas praranda 26 mln. USD ezETH žetonų: žiniasklaida kaltina vartotoją, įsilaužėlis praneša apie ERC-20 trūkumus

• Mano vardas Deksaranas. Esu įsilaužėlis, sukūriau ir įvykdžiau vieną didžiausių konsensuso lygio atakų pramonėje . 2019 m. DDOS įdiegiau EOS tinklo pagrindinį tinklą ir užšaldžiau jį mėnesiui, pasinaudojęs jo konsensuso išteklių modelio trūkumu. Tuo metu EOS užėmė 7 vietą. ( EOSGO ataskaita , bendruomenės ataskaita )

  
  

• Esu vienos iš pagrindinių Ethereum Classic kūrimo komandų įkūrėjas . ( Cointelegraph straipsnis )

  
  

• Sukūriau Nakamoto konsensuso pataisą – taisyklių rinkinį, kuris išsprendžia 51 % atakų , kurios buvo belaisvių grandinių pramonės rykštė.

Nelaimingas atsitikimas

Vartotojas prarado 26 000 000 USD vertės ezETH žetonus, nusiųsdamas juos pagal išmaniąją sutartį. Yra keli straipsniai ir „Twitter“ gijos, kuriose teigiama, kad tai buvo vartotojo klaida, pavyzdžiui, tai padarė „CoinTelegraph“ .

Tai neteisinga. Dėl panašios vartotojo klaidos Eth, NFT ar ERC-223 prieigos raktas nebus prarastas . Pervedimai į išoriškai priklausančius adresus ir pervedimai į išmaniąsias sutartis veikia skirtingai.

Jei vartotojas siųstų žetonus netinkamu adresu (tai nėra išmanioji sutartis) arba niekam nepriklausančiu adresu – tai būtų vartotojo klaida.

Tačiau šiuo atveju vartotojas įnešė žetonus į išmaniąją sutartį. Išmaniosios sutartys turėtų užkirsti kelią šioms klaidoms, ir jos tikrai gali tai padaryti – pavyzdžiui, jei vartotojas įneštų eterį (arba bet kurią kitą vietinę valiutą), NFT (ERC-721) arba ERC-223 žetonus į išmaniąją sutartį, kuri nebuvo skirtas jiems gauti - tada žetonai nebūtų prarasti. Įvyktų operacijos klaida ir žetonų perdavimas tiesiog neįvyktų.

Klaidų apdorojimas yra vienas iš pagrindinių programinės įrangos saugumo principų. Sukurti programinę įrangą taip, kad nebūtų įmanoma tinkamai tvarkyti iškvietimo klaidų, yra tas pats, kas valdymo funkcijai trūksta onlyOwner modifikatoriaus – tai būtų saugumo problema.

Tai ERC-20 standarto problema – jis sukurtas taip, kad klaidų apdorojimas būtų neįmanomas. Ir tai yra saugumo problema. ERC-20 standartas yra nesaugus . 2023 m. pats ERC-20 standarto kūrėjas patvirtino, kad tai yra standarto saugumo problema .

Apie tai pranešiau čia ir čia 2017 m. Be to, sukūriau ERC-223 standartą, kad išspręsčiau šią tikslią problemą 2017 m., čia yra originali EIP-223 gija, kurioje pabrėžiama, kad šis standartas apsaugo nuo pinigų praradimo.

Apsaugos įmonėms ir kūrėjams per lengva kaltinti vartotojus padarius klaidą. Tačiau tai kūrėjo kaltė, kad jie sukūrė savo programas naudodami nesaugų standartą, kuris nesugeba susidoroti su vartotojų klaidomis, dėl kurių buvo padaryta tokia pražūtinga žala.

Istorija

Pabrėžiau, kad tai gali sukelti finansinės žalos vartotojams, o apie tai pranešiau Ethereum fondui. Jie nieko nedarė. Jau 7 metus.

• Dėl šios problemos 2017 m. buvo prarasta 16 000 USD.
• 2018 m. buvo prarasta 2 000 000 USD
• 60 000 000 USD 2023 m
• 2024 m. lapkričio 1 d. buvo 90 000 000 USD (neįskaitant 25 mln., prarastų pagal ezETH sutartį)
• Dabar yra 115 000 000 USD

Mano komanda sukūrė scenarijų, kuris apskaičiuoja prarastų žetonų kiekį:

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

• 2017 m. kitas vartotojas prarado 130 tūkst.
• 2020 m. vartotojas prarado savo santaupas.
• 2023 m. vartotojas per vieną operaciją prarado 240 000 USD.
• Tada Poloniex įsilaužėlis prarado 2,5 mln.

Pateikiau užklausą nebereklamuoti ERC-20 standarto dėl šios saugos problemos 2017 m., nebuvo jokio atsakymo https://github.com/ethereum/ethereum-org/issues/755 .

Iškėliau šią problemą EthereumCatHerders, tiems vaikinams, kurie tvarko EIP Ethereum.

2023 m. jie atsakė : „Mes neturime nieko bendra su saugumo atskleidimu, mes neturime tam proceso“.

Paaiškinimas: EIP ir ERC yra pasiūlymai, kuriuos kiekvienas gali pateikti Ethereum. Jie gali tapti standartais arba modifikacijomis, kurias kūrėjai taiko Ethereum veikimui. Jie yra tekstiniai failai jų github repo.

Kontekstas: jie neturi proceso, kaip tvarkyti informaciją apie saugumą EIP, praėjus 10 metų nuo Ethereum projekto pradžios.

Aš pasiūliau metodą, kaip pakeisti EIP veikimą, kad būtų galima atskleisti saugumą: https://ethereum-magicians.org/t/modification-of-eip-process-to-account-for-security-treatments/16265

Pasiūliau įtraukti įspėjimą dėl ERC-20 ir dokumentuoti problemą EIP. Štai jų skambutis, kuriame jie nusprendė, kad turiu eiti ir sukurti kitą informacinį EIP, kuris atskleistų EIP-20 pažeidžiamumą: https://github.com/ethcatherders/EIPIP/issues/257#issuecomment-1693372317

Aš tai padariau. Po to jie atmetė mano atskleidimo EIP.

Pateikiau pasiūlymą atgaivinti savo pirminę idėją, kurią aprašiau EthereumMagicians forume, kuri leistų 2024 m. dar kartą atskleisti informaciją apie saugumą EIP skiltyje „Saugumo klausimai“.

Štai mano diskusija su EIP redaktoriais: https://www.youtube.com/watch?v=PKkJNqcozhw&t=744s

Kaip rezultatas, EIP redaktoriai man pasakė, kad jie ketina balsuoti dėl to: https://github.com/ethcatherders/EIPIP/issues/349

Mano pasiūlymas buvo atmestas. Vis dar nėra proceso, kaip tvarkyti informaciją apie saugumą EIP. ERC-20 problema neišspręsta. Apie tai net nepranešama ar dokumentuojama kaip apie problemą, todėl įgyvendintojai ją kartoja vėl ir vėl.

Nesąžiningi auditoriai

Aš asmeniškai pranešiau apie šią problemą „OpenZeppelin“ ir 3 kartus prašiau pataisyti.

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

  
  

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

  
  

• Po to, kai jie atmetė ankstesnius du, nusprendžiau apie tai pranešti tokiu būdu, kuris parodytų problemos rimtumą, todėl pateikiau ją jų klaidų kompensacijai, nes ji atitinka „kritinio saugumo pažeidžiamumo“ kriterijus pagal jų pačių taisykles https:/ /github.com/OpenZeppelin/openzeppelin-contracts/issues/4474#issuecomment-1646901022

„OpenZeppelin“ jį atmetė „viešai atskleisdamas nepataisytą pažeidžiamumą“ (tai patvirtina, kad tai bent jau saugumo problema).

Prieš kelias dienas Devcon7 buvo užduotas klausimas tam pačiam vaikinui iš OpenZeppelin, kuris uždarė savo github problemą dėl šios problemos: https://www.youtube.com/watch?app=desktop&v=DKJYpdXsOwQ&start=406

Praėjus 6 metams po to, kai apie tai buvo pranešta, ir po to, kai dėl to naudotojai patyrė 115 000 000 USD nuostolių.

Jų atsakymas net neteisingas. Užuot turėję neišspręstą problemą, jie uždarė 3 problemas, kurias atidariau, ir atmetė visas mano pateiktas rekomendacijas.

Išvada

1. Ethereum fondas cenzūruoja bet kokius bandymus pabrėžti problemą, dėl kurios ekosistemos vartotojai prarado 115 000 000 USD. Problema neskelbiama, atskleidimas netinkamai tvarkomas, įgyvendintojai ją vis atkartoja naujose sutartyse.

   
   

   Manau, kad jie mano, kad jų reputacijai būtų per daug žalinga tai atskleisti.

2. Auditoriai, tokie kaip „OpenZeppelin“, taip pat neatskleidžia problemos, tikriausiai dėl to, kad jie susiduria su interesų konfliktu, nes šimtams ERC-20 sutarčių, kurias jie auditavo, jau pridėjo „Saugus“ etiketę.

   
   

3. Kūrėjai sako: „Mes tiesiog įgyvendiname standartą tokį, koks jis yra“.

   
   

4. Standartą reglamentuoja EIP procesas, EIP procesas nėra skirtas saugos atskleidimui.

EIP procesas turi būti pakeistas. ERC-20 problema turi būti atskleista ir tinkamai dokumentuota. Idealiu atveju turi būti įdiegtas naujas standartas. Taikyti „tvarsčių“ rinkinį ERC-20, siekiant sumažinti žalą, yra geriau nei nieko nedaryti, tačiau tai neišspręstų problemos per se.

Visiems, kurie sako, kad „problema gali būti išspręsta piniginės lygiu“, trūksta saugumo žinių. Programinės įrangos saugume galioja „saugaus projektavimo“ principas, o tai reiškia, kad negalite sukurti nesaugios programinės įrangos, pasakyti visiems, kaip ją naudoti, kad ji nepakenktų jūsų vartotojams, ir apsimesti, kad ji nepadarys žalos. Ne finansų pramonėje. Toks požiūris gali būti naudingas, pavyzdžiui, kuriant žiniatinklio svetainę, kai gedimo kaina yra tai, kad kažkas negali įkelti tinkamo šrifto savo tinklalapiui. Finansų sektoriuje dėl to prarandami milijonai dolerių.

Visiškai neįmanoma garantuoti, kad visi piniginių kūrėjai visoje žmonijos civilizacijos ateityje visada tinkamai įgyvendins visus reikalingus pataisymus.