How To Judge If A So Called “HACK” That Happened To A Crypto Or Blockchain Project Is Legit Or If It’s Just A Mechanism To Hide A RUG?

Újra kiadta Platón

Követő: 0

Nyilvánvaló, hogy az MtGox-szal vagy a QuadrigaCX-szel vagy hasonló esetekkel történtek után, amikor az alapítók azt állították, hogy elvesztették a tőzsdéik digitális eszközeinek többségét tároló magánkulcsokat, miközben eltűntek vagy később holtan találták őket, a kriptográfiai szférában dolgozók egyre gyanakvóbbak, amikor meghallják feltörni egy projektet, és az első gondolat, ami eszembe jut, az az, hogy az alapítók alapvetően kiürítették az alapot, és elszaladtak vele, ezt szokták RUG-nak nevezni.

Valószínűleg ez sok projektnél így volt, de nem feltétlenül mindegyiknél, ezért ma egy olyan esetet vizsgálunk, amelyet a helyzet természetéből adódóan valódi hacknek tartunk.

Úgy gondoljuk, hogy ez egy érdekes eset elemzése, mert segít jobban megérteni a biztonság és az auditok fontosságát az intelligens szerződésekkel vagy általában a blokklánccal kapcsolatos projektekben.

Objektíven elemezzük azt a drámát, amely a BSC-n (Binance Blockchain) indított tokennel, a RING Financial projekttel történt.

Mielőtt rátérnénk a hackre, először összefoglaljuk a projektet és az előtte lévő helyzetet:

RING Pénzügyi a hack előtt

A RING Financial egy DeFi projekt volt, azzal a céllal, hogy a DeFi-t elérhetőbbé tegye a DeFi és a kriptográfiai közösség számára. Egy ambiciózus projekt, amely egy csomópontot létrehozó protokollt akart létrehozni, amelyet a csomóponttulajdonosok irányítanának, és amely egyszerre több mint 300 protokollra osztaná a likviditást. A cél az volt, hogy egy RING Node-on és a RING Dappon keresztül hozzáférjenek az összes protokollhoz.

Ezeket a protokollokat a csapat ellenőrizte, majd a közösség megszavazta, hogy hol kell kiosztani őket. Ugyanaz a szavazás koncepciója, mint egy DAO-ban, ami meglehetősen vonzóvá tette a RING-et.

A RING Financial emellett jelentős mértékben leegyszerűsítette a kutatási és telepítési folyamatot egyetlen csomóponttartó számára. Egy Dapp az összes többi Dapp eléréséhez, így csak egy interfészre lesz szüksége a 300 különböző, saját hozzáféréssel és csomóponttal rendelkező interfész helyett.

Végül a RING Financial célja az volt, hogy csökkentse a különböző protokollokon történő telepítés díjait, a mennyiséggel együtt alacsonyabb tranzakciós díjak is járnak az egyéni tulajdonosok számára, ami a projekt egyik fő értékesítési pontja volt. Egy projekt érzékkel és ambícióval, hogy megkönnyítse a közösség dolgát, és még inkább mainstream azok számára, akik nem ismerik a Defit.

Az érzék és az ambíció azonban nem mindig elég, és szakértelemre és tudásra van szükség, ami az új és éretlen piacokon ritka lelet, és ezért a RING Financial nem tudta teljes mértékben teljesíteni ígéretét.

Tehát mi történt valójában a RING Financial-szel? És miért törték fel? A blokkláncnak köszönhetően rendelkezésünkre áll minden igazságügyi bizonyíték, amely szükséges ahhoz, hogy ebbe beleássunk, és megnézzük, hol voltak a sebezhetőségek és miért A RING Financial nem volt átverés.

A RING Financial HACK 5. december 2021-én 2:01 és 2:06 UTC között történt.

Igen, minden szó szerint mindössze 5 perc alatt történt! A blokklánc szkennernek köszönhetően ezekért a részletekért egyébként közvetlenül a HACK-hez kapcsolódó tranzakciók linkjeit, valamint a szerződés címét adjuk meg azoknak, akik részletesebben szeretnének keresni.

Íme az összefoglaló, amely elmagyarázza a támadó által kihasznált hibát:

Meg kell értenie, hogy a RING Financial intelligens szerződése több részből állt, az egyik a tokenhez és az ahhoz kapcsolódó összes adathoz, egy másik pedig mindenhez, ami a csomópontok és jutalmak elszámolásával kapcsolatos. A token része volt egy biztosíték, hogy ennek a fontos adatait csak a szerződés adminisztrátora tudja módosítani, hogy mutasson néhány kódot, itt van a szerződés funkciójának fejléce, amelyet az “onlyOwner” attribútum véd. amely kimondja, hogy a funkciót csak az adminisztrátor hajthatja végre:

Olyan függvény, amely nem rendelkezik csak Tulajdonos attribútum (vagy azzal egyenértékű attribútum a függvény hozzáférését védi) gyakorlatilag bárki végrehajthatja.

Most találd ki? A csomópontok és jutalmak rész függvényei nem rendelkeztek ezzel az attribútummal, amint azt az alábbi függvénynevek alapján láthatja (a csak Tulajdonos attribútum hiányzik):

És ahogy képzelheti, egy hacker kihasználta és átverte ezt a hibát, hogy exponenciálisan sok jutalmat szerezzen a RING-ben, majd a likviditási készletbe dobta, és néhány perc alatt szinte erőszakosan kiürítette. Így követte el csalásait.

Most valószínűleg két kérdést teszel fel magadnak:

Hogyan hagyhattak a fejlesztők ekkora kiskaput?

Miután beszéltünk a Solidity fejlesztőivel (az intelligens szerződések kódolására használt nyelv az Ethereumon), ez a két intelligens szerződés közötti szerepörökléssel kapcsolatos hiba, az öröklődés a programozási nyelv fogalma, és hogy ne okozzunk fejfájást, maradjunk egyszerű szavaknál: Alapvetően nagyon valószínű, hogy a szerződést kódoló személy úgy gondolta, hogy a csomóponti rész funkciói örökölték a Token rész funkcióinak biztonsági szerepét, de ez sajnos nem így van a Solidityben, és újra meg kell határozni az egyes szerződések egyes funkcióinak szerepét, függetlenül azok kapcsolatától. Ebből a szempontból tehát az a következtetésünk, hogy a fejlesztő nem volt szakértő, és valószínűleg úgy tette közzé a szerződést, hogy nem fordított időt az újraolvasásra, valószínűleg sietősen.

Honnan tudod, hogy nem maga a fejlesztő hagyta ezt a hibát szándékosan, és nem átverés volt?

Nagyon jó kifogás, és könnyen feltételezhető egy átverés, ha nem tudja, hogyan intelligens szerződések működik, de valójában nagyon könnyű feltételezni a fejlesztő ártatlanságát, mert 19. november 2021-én közzétette és ellenőrizte az intelligens szerződés teljes kódját a BSCSCAN.COM-on (a Binance Blockchain legnépszerűbb szkennerén). vagyis több mint két héttel a RING Financial HACK megtörténte előtt. És ahogy korábban kifejtettük, a hiba FEKETE-FEHÉRE felirattal szerepelt a szerződésben, és minden tapasztalt fejlesztő észrevette volna és reagált volna, de sajnos az elsőnek egyáltalán nem kegyelmezett. Ezért nyilvánvaló, hogy a fejlesztő nem volt tudatában ennek a hibának, mert nem vállalta volna azt a kockázatot, hogy bármikor hagyja, hogy bárki megölje a RING Financial projektet.

Hogy visszatérjen a RING Financial HACK folytatásához, a fejlesztő rájött baklövésére, és egyszerűen befagyasztotta a szerződést, hogy leállítsa a jutalmak elosztását, hogy a támadó ne ürítse ki teljesen a készletet. Ezután újratelepített egy csomóponti szerződést, ezúttal az „onlyOwner” biztonsági attribútummal. Ez az új Node szerződés megfelelően tudta kezelni az új jutalomelosztást, kivéve, hogy már túl késő volt, mert a HACK eredményeként minden bizalom elveszett a projektben és a csapatban, és az eladási nyomás megölte és véget vetett a tokennek és a projekt.

Befejezésül azért választottuk ezt a történetet, mert két fontos dolgot mutat be az intelligens szerződésekkel és a kriptoprojektekkel kapcsolatban, soha ne kódoljon sietve egy szerződést, és mindig vegye fel a kapcsolatot a könyvvizsgáló cégekkel, mert ha egyszer megtörténik a feltörés, már késő megmenteni a hajót, és Jó példa erre a RING Financial projekt, ráadásul közleményük szerint felvették a kapcsolatot a könyvvizsgáló cégekkel a második Node-szerződés kapcsán, és addig nem tették közzé nyilvánosan a BSCSCAN-on, amíg meg nem bizonyosodtak a biztonságáról. De ahogy korábban is mondtuk, már túl késő volt a RING Financial számára, és a kár visszafordíthatatlan.