Kuidas otsustada, kas krüpto- või plokiahela projektiga juhtunud niinimetatud "HACK" on seaduslik või on see lihtsalt mehhanism vaiba peitmiseks?

Ilmselgelt on pärast MtGoxi või QuadrigaCX-i juhtunut või sarnaseid juhtumeid, kus asutajad väitsid, et nad kaotasid ära privaatvõtmed, millel oli suurem osa nende börside digitaalsetest varadest, kui nad kadusid või leiti hiljem surnuna, on krüptosfääris inimesed üha kahtlustavad, kui kuulevad häkkida projekti ja esimene mõte, mis pähe tuleb, on see, et asutajad on põhimõtteliselt fondi tühjaks teinud ja sellega minema jooksnud, seda nimetatakse tavaliselt RUGiks.

Tõenäoliselt on see nii olnud paljudes projektides, kuid mitte tingimata kõigis, nii et täna käsitleme juhtumit, mis meie arvates on olukorra olemuse tõttu tõeline häkkimine.

Meie arvates on see huvitav juhtum analüüsimiseks, sest see aitab paremini mõista turvalisuse ja auditite tähtsust nutikate lepingute või plokiahelaga seotud projektides üldiselt.

Analüüsime objektiivselt draamat, mis juhtus BSC-l (Binance Blockchain) käivitatud märgiga RING Financial.

Enne häkkimise juurde asumist teeme esmalt kokkuvõtte projektist ja selle olukorrast enne seda:

RING Financial enne häkkimist

RING Financial oli DeFi projekt, mille eesmärk oli muuta DeFi DeFi ja krüptokogukonna jaoks kättesaadavamaks. Ambitsioonikas projekt, mille eesmärk oli luua sõlm, mis annaks protokolli, mida juhiksid sõlmeomanikud ja mis eraldaks likviidsuse korraga rohkem kui 300 protokolli. Eesmärk oli saada juurdepääs kõikidele protokollidele ühe RING Node ja RING Dappi kaudu.

Meeskond kontrollis neid protokolle ja seejärel hääletas kogukond, kuhu need eraldada. Sama hääletamise kontseptsioon nagu DAO puhul, mis muutis RINGi üsna atraktiivseks.

RING Financial lihtsustas ka ühe sõlmehoidja jaoks üsna palju uurimis- ja juurutamisprotsessi. Üks Dapp, et pääseda juurde kõigile teistele Dappidele, nii et vajate 300 erineva oma juurdepääsu ja oma sõlmedega liidese asemel ainult ühte liidest.

Lõpuks oli RING Financiali eesmärk vähendada erinevate protokollide kasutuselevõtu tasusid, kusjuures mahuga kaasnevad madalamad tehingutasud üksikutele omanikele, mis oli projekti üks peamisi müügiargumente. Projekt, millel on elegants ja ambitsioon, et muuta kogukonna jaoks asjad lihtsamaks ja veelgi tavalisemaks nende jaoks, kes Defist ei tea.

Kuid elegantsusest ja ambitsioonikusest ei piisa alati ning vajate asjatundlikkust ja teadmisi, mis uutel ja ebaküpsetel turgudel on haruldane leid ning mistõttu ei suutnud RING Financial oma lubadust täielikult täita.

Mis siis tegelikult RING Financialiga juhtus? Ja miks see häkiti? Tänu plokiahelale on meil kõik kohtuekspertiisi tõendid, mis on vajalikud sellesse süvenemiseks ja haavatavuste leidmiseks ja miks RING Financial ei olnud pettus.

RING Financial HACK toimus 5. detsembril 2021 ajavahemikus 2–01 UTC.

Jah, kõik juhtus sõna otseses mõttes vaid 5 minutiga! Tänu plokiahela skannerile nende üksikasjade eest, muide, pakume teile just allpool HACKiga seotud tehingute linke ja ka lepingu aadressi neile, kes soovivad täpsemalt otsida.

Siin on kokkuvõte, mis selgitab viga, mida ründaja on ära kasutanud:

Peate mõistma, et RING Financiali nutikas leping koosnes mitmest osast, millest üks oli märgi ja kõigi sellega seotud andmete jaoks ning teine ​​​​kõike sõlmede ja preemiate arvestusega seotud osa jaoks. Tokeni osal oli turvalisus, nii et ainult lepingu administraator saab selle olulisi andmeid muuta, et näidata teile mõnda koodi, siin on lepingu funktsiooni päis, mis on kaitstud atribuudi "onlyOwner" kaudu mis näeb ette, et funktsiooni saab teostada ainult administraator:

Funktsioon, millel puudub ainult omanik atribuuti (või samaväärset atribuuti funktsiooni juurdepääsu kaitsmiseks) saab käivitada peaaegu igaüks.

Nüüd arvake ära, mida? Funktsioonidel osal Sõlmed ja preemiad seda atribuuti ei olnud, nagu näete allolevatest funktsioonide nimedest ( ainult omanik atribuut puudub):

Ja nagu võite ette kujutada, kasutas häkker seda viga ära ja pettis, et saada RINGis eksponentsiaalselt palju preemiaid, ning viskas need seejärel likviidsusbasseini ja tühjendas selle mõne minutiga peaaegu vägivaldselt. Seega pani ta oma petuskeemid toime.

Tõenäoliselt esitate nüüd endale kaks küsimust:

Kuidas said arendajad sellise lünga jätta?

Pärast rääkimist Solidity arendajatega (keel, mida kasutatakse nutikate lepingute kodeerimiseks Ethereumis) on see viga, mis on seotud rollide pärimisega kahe nutika lepingu vahel, pärimine on programmeerimiskeele mõiste ja et mitte teile peavalu tekitada, Jään lihtsateks sõnadeks: Põhimõtteliselt on väga tõenäoline, et lepingu kodeerija arvas, et sõlme osa funktsioonid on pärinud Tokeni osa funktsioonide turvarollid, kuid Solidity puhul see kahjuks nii ei ole ja on vaja uuesti määratleda iga lepingu funktsiooni rollid, olenemata nende seostest. Seega on meie järeldus selles küsimuses, et arendaja ei olnud ekspert ja tõenäoliselt avaldas ta lepingu ILMA aega selle uuesti lugemiseks võtta, tõenäoliselt kiirustades.

Kuidas sa tead, et arendaja ise ei ole selle vea tahtlikult jätnud ja see polnud pettus?

Väga hea vastuväide ja on lihtne eeldada pettust, kui te pole kindel, kuidas seda teha arukad lepingud tööd, kuid arendaja süütust on tegelikult väga lihtne eeldada, sest ta avaldas ja kinnitas kogu nutika lepingu koodi avalikult saidil BSCSCAN.COM (Binance Blockchaini populaarseim skanner) 19. novembril 2021, et see tähendab, et rohkem kui kaks nädalat enne RING Financial HACKi juhtumist. Ja nagu eelnevalt selgitatud, oli viga MUST VALGELE kirjas lepingus ja iga kogenud arendaja oleks seda märganud ja reageerinud, kuid kahjuks esimene, kes ei halastanud. Seetõttu on ilmne, et arendaja ei olnud sellest veast teadlik, sest ta poleks võtnud riski, et laseb kellelgi RING Financial projekti igal ajal tappa.

RING Financial HACKi jätkamise juurde naasmiseks sai arendaja aru oma veast ja lihtsalt külmutas leping, et peatada igasugune preemiate jagamine, et ründaja basseini täielikult ei tühjendaks. Seejärel paigutas ta ümber sõlme lepingu, seekord turvaatribuudiga "onlyOwner". See uus Node'i leping sai uue preemiajaotusega õigesti hakkama, välja arvatud see, et oli liiga hilja, sest HACK-i tulemusena oli projekti ja meeskonna vastu kadunud kogu usaldus ning müügisurve tappis ja lõpetas märgi ja projekti.

Kokkuvõtteks valisime selle loo, kuna see näitab kahte olulist asja nutikate lepingute ja krüptoprojektide kohta, ärge kunagi kodeerige lepingut kiirustades ja võtke alati ühendust audiitorfirmadega, sest kui häkkimine juhtub, on juba hilja paati päästa ja RING Financial projekt on hea näide, lisaks on nad oma suhtluse kohaselt võtnud selle teise Node lepingu osas ühendust audiitorfirmadega ega postitanud seda avalikult BSCSCAN-i enne, kui olid selle turvalisuses kindlad. Kuid nagu varem öeldud, oli RING Financiali jaoks liiga hilja ja kahju oli pöördumatu.

Siin on kõik skanneri lingid ja lepingu aadressid:

rahakott teostab tehingut häkkimise ärakasutamiseks: 0xfe58c9e2ecb95757be6f4bca33162cfa346cc34f

 Ring smart-contract address: 0x521ef54063148e5f15f18b9631426175cee23de2

Ring reward pool address: 0xa46cc87eca075c5ae387b86867aa3ee4cb397372

 tehingu häkkimise ärakasutamine:

 TRX 1

    link: https://bscscan.com/tx/0x596d38494ea5ae640b2a556a7029692928f15713d22b5948477c4eb4a92cf68e

TRX 2

    link: https://bscscan.com/tx/0xfc890c855709bb6aeb5177ee31e08751561344402a88af13e7dfd02b9a2f6003

TRX 3

    link: https://bscscan.com/tx/0x35c2f1ed9c5ce13a714af6c0dcbbce8fe720f7d6212232b6dd3657d8799a10f1

• SEO-põhise sisu ja PR-levi. Võimenduge juba täna.
• Platoblockchain. Web3 metaversiooni intelligentsus. Täiustatud teadmised. Juurdepääs siia.
• Allikas: https://www.fintechnews.org/how-to-judge-if-a-so-called-hack-that-happened-to-a-crypto-or-blockchain-project-is-legit-or-if-its-just-a-mechanism-to-hide-a-rug/