ប្រវត្តិសាស្ត្រថ្មី។

ពាណិជ្ជករបាត់បង់ 26 លានដុល្លារនៅក្នុង ezETH Tokens: ប្រព័ន្ធផ្សព្វផ្សាយបន្ទោសអ្នកប្រើប្រាស់, Hacker ហៅកំហុស ERC-20

ដោយ Dexaran6m2024/11/19

យូរពេក; អាន

គុណវិបត្តិរបស់ ERC-20 បានធ្វើឱ្យអ្នកប្រើប្រាស់ចំណាយអស់ $115M ដោយសារតែការដោះស្រាយកំហុសមិនល្អ។ Dexaran បង្ហាញពីហានិភ័យ បញ្ហាប្រឈមអ្នកសវនករ និង Ethereum ដើម្បីធ្វើសកម្មភាព និងអ្នកតស៊ូមតិសម្រាប់ ERC-223 ជាដំណោះស្រាយសុវត្ថិភាព។

featured image - ពាណិជ្ជករបាត់បង់ 26 លានដុល្លារនៅក្នុង ezETH Tokens: ប្រព័ន្ធផ្សព្វផ្សាយបន្ទោសអ្នកប្រើប្រាស់, Hacker ហៅកំហុស ERC-20

ខ្ញុំឈ្មោះ Dexaran ។ ខ្ញុំជាអ្នកលួចចូល ខ្ញុំបានរចនា និងប្រតិបត្តិការវាយប្រហារកម្រិតការយល់ស្របដ៏ធំបំផុតមួយនៅក្នុងឧស្សាហកម្មនេះ ។ នៅឆ្នាំ 2019 ខ្ញុំបានភ្ជាប់បណ្តាញមេបណ្តាញ EOS របស់ DDOS ហើយបានបង្កកវារយៈពេលមួយខែដោយទាញយកកំហុសនៅក្នុងគំរូនៃធនធានការយល់ស្របរបស់វា។ EOS ជាប់ចំណាត់ថ្នាក់កំពូល 7 នៅពេលនោះ។ ( របាយការណ៍ EOSGO របាយការណ៍សហគមន៍ )
ខ្ញុំជាស្ថាបនិកមួយនៃក្រុមអភិវឌ្ឍន៍ស្នូល Ethereum Classic ។ ( អត្ថបទរបស់ Cointelegraph )
ខ្ញុំបានរចនា វិសោធនកម្មទៅ Nakamoto consensus ដែលជាសំណុំនៃច្បាប់ដែល ដោះស្រាយការវាយប្រហារ 51% ដែលជាការគំរាមកំហែងនៃឧស្សាហកម្មសម្រាប់ខ្សែសង្វាក់ POW ។

កំណត់សម្គាល់របស់អ្នកនិពន្ធ៖ រឿងនេះតំណាងឱ្យទស្សនៈរបស់អ្នកនិពន្ធរឿង។ អ្នកនិពន្ធមិនមានទំនាក់ទំនងជាមួយបុគ្គលិក HackerNoon ហើយសរសេររឿងនេះដោយខ្លួនឯងទេ។ ក្រុមវិចារណកថារបស់ HackerNoon បានត្រឹមតែផ្ទៀងផ្ទាត់រឿងសម្រាប់ភាពត្រឹមត្រូវតាមវេយ្យាករណ៍ប៉ុណ្ណោះ និងមិនថ្កោលទោស/ថ្កោលទោសការអះអាងណាមួយដែលមាននៅទីនេះទេ។ #DYOR

គ្រោះថ្នាក់

អ្នកប្រើប្រាស់ម្នាក់បានបាត់បង់ 26,000,000 ដុល្លារនៃសញ្ញាសម្ងាត់ ezETH ដោយបញ្ជូនពួកគេទៅកិច្ចសន្យាឆ្លាតវៃ។ មានអត្ថបទជាច្រើននិងបណ្តាញធ្វីតធឺដែលអះអាងថានេះជាកំហុសអ្នកប្រើឧទាហរណ៍នេះដោយ CoinTelegraph ។

នេះមិនត្រឹមត្រូវ។ កំហុសរបស់អ្នកប្រើស្រដៀងគ្នានឹងមិនបណ្តាលឱ្យបាត់បង់និមិត្តសញ្ញា Eth, NFT ឬ ERC-223 ទេ ។ ការផ្ទេរទៅអាសយដ្ឋានដែលគ្រប់គ្រងដោយខាងក្រៅ និងការផ្ទេរទៅកិច្ចសន្យាឆ្លាតវៃដំណើរការខុសគ្នា។

ប្រសិនបើអ្នកប្រើនឹងផ្ញើសញ្ញាសម្ងាត់ទៅអាសយដ្ឋានខុស (ដែលមិនមែនជាកិច្ចសន្យាឆ្លាតវៃ) ឬអាសយដ្ឋានដែលមិនមែនជាកម្មសិទ្ធិរបស់នរណាម្នាក់ — នោះជាកំហុសរបស់អ្នកប្រើប្រាស់។

ទោះយ៉ាងណាក៏ដោយ ក្នុងករណីនេះ អ្នកប្រើប្រាស់បានដាក់ថូខឹនទៅកិច្ចសន្យាឆ្លាតវៃ។ Smart-contracts ត្រូវបានគេសន្មត់ថាដើម្បីការពារកំហុសនេះ ហើយពួកគេប្រាកដជាអាចធ្វើវាបាន - ឧទាហរណ៍ប្រសិនបើអ្នកប្រើនឹងដាក់ប្រាក់ Ether (ឬរូបិយប័ណ្ណដើមផ្សេងទៀត) NFTs (ERC-721) ឬ ERC-223 tokens ទៅ smart-contract ដែល មិនត្រូវបានរចនាឡើងដើម្បីទទួលពួកវា — បន្ទាប់មកសញ្ញាសម្ងាត់នឹងមិនត្រូវបានបាត់បង់។ វានឹងមានកំហុសក្នុងប្រតិបត្តិការ ហើយការផ្ទេរសញ្ញាសម្ងាត់នឹងមិនកើតឡើងទេ។

ការដោះស្រាយកំហុសគឺជាគោលការណ៍ជាមូលដ្ឋានបំផុតមួយនៃសុវត្ថិភាពកម្មវិធី។ ការរចនាកម្មវិធីក្នុងរបៀបដែលវានឹងមិនអាចដោះស្រាយកំហុសការហៅបានត្រឹមត្រូវគឺដូចគ្នានឹងការបាត់តែអ្នកកែប្រែ onlyOwner សម្រាប់មុខងារអភិបាលកិច្ច — ដែលនឹងជាបញ្ហាសុវត្ថិភាព។

នេះគឺជាបញ្ហានៃស្តង់ដារ ERC-20 - វាត្រូវបានរចនាឡើងតាមរបៀបដែលធ្វើឱ្យការដោះស្រាយកំហុសមិនអាចទៅរួច។ ហើយនេះគឺជាបញ្ហាសុវត្ថិភាព។ ស្តង់ដារ ERC-20 មិនមានសុវត្ថិភាព ។ នៅឆ្នាំ 2023 អ្នកបង្កើតស្តង់ដារ ERC-20 ខ្លួនឯងបានបញ្ជាក់ថានេះគឺជាបញ្ហាសុវត្ថិភាពនៃស្តង់ដារ ។

ខ្ញុំបានរាយការណ៍វានៅឆ្នាំ 2017 នៅ ទីនេះ ។ ដូចគ្នានេះផងដែរខ្ញុំបានរចនាស្តង់ដារ ERC-223 ដើម្បីដោះស្រាយបញ្ហាពិតប្រាកដនេះក្នុងឆ្នាំ 2017 នេះគឺជាខ្សែស្រឡាយ EIP-223 ដើម ដែលវាត្រូវបានគូសបញ្ជាក់ថាស្តង់ដារនេះការពារការបាត់បង់ប្រាក់។

វាងាយស្រួលពេកសម្រាប់ក្រុមហ៊ុនសន្តិសុខ និងអ្នកអភិវឌ្ឍន៍ក្នុងការបន្ទោសអ្នកប្រើប្រាស់ថាមានកំហុស។ ទោះជាយ៉ាងណាក៏ដោយ វាជាកំហុសរបស់អ្នកអភិវឌ្ឍន៍ដែលពួកគេបានបង្កើតកម្មវិធីរបស់ពួកគេដោយប្រើស្តង់ដារមិនសុវត្ថិភាព ដែលបរាជ័យក្នុងការដោះស្រាយកំហុសរបស់អ្នកប្រើប្រាស់ ដែលបណ្តាលឱ្យមានការខូចខាតយ៉ាងធ្ងន់ធ្ងរបែបនេះ។

ប្រវត្តិសាស្ត្រ

ខ្ញុំបានគូសបញ្ជាក់ថា វាអាចបង្កការខូចខាតផ្នែកហិរញ្ញវត្ថុដល់អ្នកប្រើប្រាស់ ខណៈពេលដែលរាយការណ៍រឿងនេះទៅមូលនិធិ Ethereum។ ពួកគេមិនបានធ្វើអ្វីសោះ។ រយៈពេល 7 ឆ្នាំ។

មានការខាតបង់ចំនួន 16,000 ដុល្លារដោយសារតែបញ្ហានេះក្នុងឆ្នាំ 2017 ។
ក្នុងឆ្នាំ 2018 មានការខាតបង់ចំនួន 2,000,000 ដុល្លារ
60,000,000 ដុល្លារក្នុងឆ្នាំ 2023
នៅថ្ងៃទី 1 ខែវិច្ឆិកា ឆ្នាំ 2024 មាន $90,000,000 (មិនរាប់បញ្ចូល 25M ដែលបានបាត់បង់នៅក្នុងកិច្ចសន្យា ezETH)
ឥឡូវនេះមាន 115,000,000 ដុល្លារ

ក្រុមរបស់ខ្ញុំបានបង្កើតស្គ្រីបដែលគណនាចំនួនលេខសម្ងាត់ដែលបាត់៖

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

ខ្ញុំបានស្នើសុំឱ្យបញ្ឈប់ការលើកកម្ពស់ស្តង់ដារ ERC-20 ដោយសារតែបញ្ហាសុវត្ថិភាពនេះក្នុងឆ្នាំ 2017 មិនមានការឆ្លើយតប https://github.com/ethereum/ethereum-org/issues/755 ។

ខ្ញុំបានបង្កើនបញ្ហានេះទៅ EthereumCatHerders ដែលជាបុរសទាំងនោះដែលគ្រប់គ្រង EIPs នៅក្នុង Ethereum ។

នៅឆ្នាំ 2023 ពួកគេ បានឆ្លើយថា "យើងមិនមានអ្វីដែលត្រូវធ្វើជាមួយការបង្ហាញសុវត្ថិភាពទេ យើងមិនមានដំណើរការសម្រាប់រឿងនោះទេ"។

ការបញ្ជាក់៖ EIPs និង ERCs គឺជាសំណើដែលនរណាម្នាក់អាចដាក់ជូន Ethereum។ ពួកគេអាចក្លាយជាស្តង់ដារ ឬការកែប្រែដែល devs អនុវត្តចំពោះរបៀបដែល Ethereum ដំណើរការ។ ពួកវាជាឯកសារអត្ថបទនៅក្នុង github repo របស់ពួកគេ។

បរិបទ៖ ពួកគេមិនមានដំណើរការដើម្បីដោះស្រាយជាមួយនឹងការបង្ហាញសុវត្ថិភាពនៅក្នុង EIPs 10 ឆ្នាំបន្ទាប់ពីការចាប់ផ្តើមគម្រោង Ethereum ។

ខ្ញុំកំពុងស្នើវិធីសាស្រ្តដើម្បីកែប្រែរបៀបដែល EIPs ដំណើរការដើម្បីអនុញ្ញាតឱ្យមានការបង្ហាញសុវត្ថិភាព៖ https://ethereum-magicians.org/t/modification-of-eip-process-to-account-for-security-treatments/16265

ខ្ញុំបានស្នើឱ្យបន្ថែមការព្រមាននៅលើ ERC-20 និងកត់ត្រាបញ្ហានៅក្នុង EIPs ។ នេះគឺជាការហៅទូរសព្ទរបស់ពួកគេ ដែលពួកគេបានសម្រេចចិត្តថាខ្ញុំត្រូវតែទៅ និងបង្កើត EIP ផ្តល់ព័ត៌មានមួយផ្សេងទៀតដែលនឹងបង្ហាញភាពងាយរងគ្រោះនៅក្នុង EIP-20៖ https://github.com/ethcatherders/EIPIP/issues/257#issuecomment-1693372317

ខ្ញុំបានធ្វើវា។ ពួកគេ បានច្រានចោល ការបង្ហាញរបស់ខ្ញុំ EIP បន្ទាប់ពីនោះ។

ខ្ញុំបានស្នើឡើងនូវសំណើរដើម្បីស្តារឡើងវិញនូវគំនិតដំបូងរបស់ខ្ញុំដែលខ្ញុំបានពិពណ៌នានៅលើវេទិកា EthereumMagicians ដែលនឹងអនុញ្ញាតឱ្យមានការបង្ហាញសុវត្ថិភាពនៅក្នុងផ្នែក "ការពិចារណាសុវត្ថិភាព" នៃ EIPs នៅឆ្នាំ 2024 ម្តងទៀត។

នេះជាការពិភាក្សារបស់ខ្ញុំជាមួយអ្នកកែសម្រួល EIP៖ https://www.youtube.com/watch?v=PKkJNqcozhw&t=744s

ជាលទ្ធផលអ្នកកែសម្រួល EIP បានប្រាប់ខ្ញុំថាពួកគេនឹងបោះឆ្នោតលើវា៖ https://github.com/ethcatherders/EIPIP/issues/349

សំណើរបស់ខ្ញុំត្រូវបានបោះឆ្នោតចេញ។ នៅតែមិនមានដំណើរការដើម្បីដោះស្រាយជាមួយនឹងការបង្ហាញសុវត្ថិភាពនៅក្នុង EIPs ទេ។ បញ្ហានៃ ERC-20 មិនត្រូវបានជួសជុលទេ។ វាមិនត្រូវបានរាយការណ៍ ឬចងក្រងជាឯកសារជាបញ្ហាទេ ដូច្នេះអ្នកអនុវត្តបន្តផលិតវាម្តងហើយម្តងទៀត។

សវនករអយុត្តិធម៌

ខ្ញុំផ្ទាល់បានរាយការណ៍បញ្ហានេះទៅ OpenZeppelin ដោយស្នើសុំការជួសជុល 3 ដង។

នៅឆ្នាំ 2018 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/729
នៅឆ្នាំ 2023 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4451
បន្ទាប់ពីពួកគេបានបដិសេធពីរលើកមុន ខ្ញុំបានសម្រេចចិត្តរាយការណ៍វាតាមរបៀបដែលបង្ហាញពីភាពធ្ងន់ធ្ងរនៃបញ្ហា ដូច្នេះខ្ញុំបានបញ្ជូនវាទៅ bug bounty របស់ពួកគេ ព្រោះវាសមនឹងលក្ខណៈវិនិច្ឆ័យ "ភាពងាយរងគ្រោះសុវត្ថិភាពសំខាន់" យោងទៅតាមច្បាប់របស់ពួកគេផ្ទាល់ https:/ /github.com/OpenZeppelin/openzeppelin-contracts/issues/4474#issuecomment-1646901022

OpenZeppelin បានច្រានចោលវាជាមួយនឹង "ការបង្ហាញជាសាធារណៈអំពីភាពងាយរងគ្រោះដែលមិនបានជួសជុល" (ដែលបញ្ជាក់ថានេះគឺជាបញ្ហាសុវត្ថិភាពយ៉ាងហោចណាស់)។

ប៉ុន្មានថ្ងៃមុននៅ Devcon7 សំណួរមួយត្រូវបានសួរទៅកាន់បុរសដដែលនោះពី OpenZeppelin ដែលបានបិទបញ្ហានៅលើ github របស់ពួកគេទាក់ទងនឹងបញ្ហានោះ៖ https://www.youtube.com/watch?app=desktop&v=DKJYpdXsOwQ&start=406

6 ឆ្នាំបន្ទាប់ពីវាត្រូវបានគេរាយការណ៍ហើយបន្ទាប់ពីវាបានបណ្តាលឱ្យបាត់បង់ $ 115,000,000 ដល់អ្នកប្រើប្រាស់របស់ពួកគេ។

ការឆ្លើយតបរបស់ពួកគេមិនពិតទេ។ ជំនួសឱ្យបញ្ហាបើកចំហ ពួកគេបានបិទបញ្ហាចំនួន 3 ដែលខ្ញុំបានបើក ហើយបដិសេធរាល់អនុសាសន៍ដែលខ្ញុំបានធ្វើ។

សេចក្តីសន្និដ្ឋាន

មូលនិធិ Ethereum កំពុងត្រួតពិនិត្យរាល់ការប៉ុនប៉ងដើម្បីរំលេចបញ្ហា ដែលបណ្តាលឱ្យអ្នកប្រើប្រាស់ប្រព័ន្ធអេកូបាត់បង់ $115,000,000។ បញ្ហាមិនត្រូវបានប្រកាសទេ ការបង្ហាញមិនត្រូវបានដោះស្រាយត្រឹមត្រូវទេ អ្នកអនុវត្តបន្តផលិតវាឡើងវិញក្នុងកិច្ចសន្យាថ្មី។

ខ្ញុំគិតថា គេចាត់ទុកថា វានឹងខូចកេរ្តិ៍ឈ្មោះគេពេកក្នុងការលាតត្រដាង។

សវនករដូចជា OpenZeppelin ក៏មិនបង្ហាញអំពីបញ្ហានេះដែរ ប្រហែលជាដោយសារតែពួកគេមានទំនាស់ផលប្រយោជន៍ ដូចដែលពួកគេបានដាក់ស្លាក "Secure" រួចហើយនៅលើកិច្ចសន្យា ERC-20 រាប់រយដែលពួកគេបានធ្វើសវនកម្ម។
Devs កំពុងនិយាយថា "យើងកំពុងអនុវត្តស្តង់ដារដូចដែលវាគឺ" ។
ស្តង់ដារត្រូវបានគ្រប់គ្រងដោយដំណើរការ EIP ដំណើរការ EIP មិនត្រូវបានបង្កើតឡើងសម្រាប់ដោះស្រាយជាមួយនឹងការបង្ហាញសុវត្ថិភាពនោះទេ។

ដំណើរការ EIP ត្រូវតែផ្លាស់ប្តូរ។ បញ្ហា ERC-20 ត្រូវតែបង្ហាញ និងចងក្រងឯកសារឱ្យបានត្រឹមត្រូវ។ តាមឧត្ដមគតិស្តង់ដារថ្មីត្រូវតែត្រូវបានអនុវត្ត។ ការអនុវត្តសំណុំនៃ "bandaids" នៅលើ ERC-20 ដើម្បីកាត់បន្ថយការខូចខាតគឺប្រសើរជាងមិនធ្វើអ្វីទាំងអស់ ប៉ុន្តែវាមិនអាចដោះស្រាយបញ្ហាបានទេ។

មនុស្សគ្រប់គ្នាដែលនិយាយថា "បញ្ហាអាចត្រូវបានដោះស្រាយនៅលើកម្រិតកាបូប" ខ្វះជំនាញសុវត្ថិភាព។ មានគោលការណ៍ សុវត្ថិភាពដោយការរចនា នៅក្នុងសុវត្ថិភាពកម្មវិធី ដែលមានន័យថា អ្នកមិនអាចបង្កើតកម្មវិធីដែលមិនមានសុវត្ថិភាព ប្រាប់អ្នកគ្រប់គ្នាពីរបៀបប្រើវា ដើម្បីកុំឱ្យប៉ះពាល់ដល់អ្នកប្រើប្រាស់របស់អ្នក ហើយធ្វើពុតថាវានឹងមិនបង្កការខូចខាត។ មិននៅក្នុងឧស្សាហកម្មហិរញ្ញវត្ថុទេ។ វិធីសាស្រ្តនោះអាចដំណើរការក្នុងការរចនាគេហទំព័រ ជាឧទាហរណ៍ ដែលតម្លៃនៃកំហុសគឺនរណាម្នាក់មិនអាចផ្ទុកពុម្ពអក្សរត្រឹមត្រូវសម្រាប់គេហទំព័ររបស់ពួកគេ។ ក្នុងឧស្សាហកម្មហិរញ្ញវត្ថុ នេះជាលទ្ធផលខាតបង់រាប់លានដុល្លារ។

វាមិនអាចទៅរួចទេក្នុងការធានាថាអ្នកអភិវឌ្ឍន៍កាបូបទាំងអស់នាពេលអនាគតទាំងមូលនៃអរិយធម៌របស់មនុស្សនឹងតែងតែអនុវត្តការកែតម្រូវចាំបាច់ទាំងអស់។