Hoe te beoordelen of een zogenaamde "HACK" die is gebeurd met een Crypto- of Blockchain-project legitiem is of dat het slechts een mechanisme is om een ​​RUG te verbergen?

Hoe te beoordelen of een zogenaamde "HACK" die is gebeurd met een Crypto- of Blockchain-project legitiem is of dat het slechts een mechanisme is om een ​​RUG te verbergen?

Tijdstempel: 31 maart 2023 5:23 uur
Oplichterij

Het is duidelijk dat, na wat er gebeurde met MtGox of QuadrigaCX of soortgelijke gevallen waarin oprichters beweerden dat ze de privésleutels verloren hadden die het grootste deel van de digitale activa van hun uitwisselingen bevatten terwijl ze verdwenen of later dood werden gevonden, mensen in de cryptosfeer steeds achterdochtiger worden als ze horen over een hack op een project, en de eerste gedachte die in je opkomt is dat de oprichters het fonds in feite hebben leeggemaakt en ermee aan de haal zijn gegaan, dat is wat gewoonlijk een RUG wordt genoemd.

Dit is waarschijnlijk in veel projecten het geval geweest, maar niet noodzakelijkerwijs in alle, dus vandaag kijken we naar een geval waarvan we denken dat het een echte hack is vanwege de aard van de situatie.

We denken dat het een interessante case is om te analyseren, omdat het zal helpen om het belang van beveiliging en audits in smart-contract- of blockchain-gerelateerde projecten in het algemeen beter te begrijpen.

We zullen objectief het drama analyseren dat is gebeurd met het RING Financial-project, een token gelanceerd op de BSC (Binance Blockchain).

Voordat we naar de hack gaan, zullen we eerst het project en de situatie ervoor samenvatten:

RING Financieel voor de hack

RING financial was een DeFi-project met als doel de DeFi toegankelijker te maken voor de DeFi- en cryptogemeenschap. Een ambitieus project dat een node-opbrengstprotocol wilde creëren dat zou worden beheerd door Node-houders en liquiditeit zou toewijzen aan meer dan 300 protocollen tegelijk. Het doel was om toegang te krijgen tot alle protocollen via één RING Node en via de RING Dapp.

Deze protocollen werden geverifieerd door het team en vervolgens stemde de gemeenschap erover waar ze moesten worden toegewezen. Hetzelfde concept van stemmen als in een DAO, wat RING behoorlijk aantrekkelijk maakte.

RING Financial vereenvoudigde ook een groot deel van het onderzoeksproces en het implementatieproces voor één enkele Node Holder. Eén Dapp om toegang te krijgen tot alle andere Dapps, dus je hebt maar één interface nodig in plaats van 300 verschillende met hun eigen toegangen en eigen knooppunten.

Ten slotte was het doel van RING Financial om de kosten voor implementatie op verschillende protocollen te verlagen, waarbij volume gepaard gaat met lagere transactiekosten voor individuele houders, wat een van de belangrijkste verkoopargumenten van het project was. Een project met flair en ambitie om dingen gemakkelijker te maken voor de gemeenschap en nog meer mainstream voor degenen die Defi niet kennen.

Maar flair en ambitie zijn niet altijd genoeg en je hebt expertise en kennis nodig die in nieuwe en onvolwassen markten zeldzaam is en daarom kon RING Financial zijn belofte niet helemaal waarmaken.

Dus wat is er echt gebeurd met RING Financial? En waarom is het gehackt? Dankzij de blockchain hebben we al het forensisch bewijs dat nodig is om ons hierin te verdiepen en te zien waar de kwetsbaarheden waren en waarom RING Financial was geen oplichterij.

De RING Financial HACK vond plaats op 5 december 2021 tussen 2:01 uur en 2:06 uur UTC.

Ja, alles gebeurde letterlijk in slechts 5 minuten! Dankzij de blockchain-scanner voor deze details bieden we u trouwens net onder de links van de transacties met betrekking tot de HACK, evenals het adres van het contract voor degenen die meer in detail willen zoeken.

Hier is de samenvatting waarin de fout wordt uitgelegd die de aanvaller heeft uitgebuit:

U moet begrijpen dat het slimme contract van RING Financial uit verschillende delen bestond, een voor het token en alle gegevens die daarmee verband houden en een ander voor alles wat te maken heeft met de boekhouding van knooppunten en beloningen. Het deel van het token had een beveiliging zodat alleen de beheerder van het contract de belangrijke gegevens van dit token kan wijzigen, om u wat code te laten zien, hier is een header van een functie van het contract die wordt beschermd via het kenmerk 'onlyOwner' die bepaalt dat de functie alleen door de beheerder kan worden uitgevoerd:

Een functie die geen alleenEigenaar attribuut (of equivalent attribuut om de toegang van de functie te beschermen) kan door letterlijk iedereen worden uitgevoerd.

Nu, raad eens? De functies op het onderdeel Nodes en Rewards hadden dit attribuut niet, zoals u kunt zien door naar de functienamen hieronder te kijken (de alleenEigenaar attribuut ontbreekt):

En zoals je je kunt voorstellen, heeft een hacker deze fout uitgebuit en opgelicht om een ​​exponentieel aantal beloningen in RING te krijgen, en deze vervolgens in de liquiditeitspool gedumpt en deze in een paar minuten bijna met geweld leeggemaakt. Zo pleegde hij zijn oplichting.

Nu stel je jezelf waarschijnlijk twee vragen:

Hoe konden de ontwikkelaars zo'n maas in de wet laten?

Na een gesprek met Solidity-ontwikkelaars (taal die wordt gebruikt om smart-contracten op Ethereum te coderen), is dit een fout die verband houdt met de rolovererving tussen twee smart-contracten. Overerving is een notie van programmeertaal en om u geen hoofdpijn te bezorgen, we zal in eenvoudige bewoordingen blijven: In principe is het zeer waarschijnlijk dat de persoon die het contract heeft gecodeerd dacht dat de functies van het Node-gedeelte de beveiligingsrollen van de functies van het Token-gedeelte erfden, maar dit is helaas niet het geval in Solidity, en het is noodzakelijk om de rollen van elke functie van elk contract opnieuw te definiëren, ongeacht hun link. Onze conclusie op dit punt is dus dat de ontwikkelaar geen expert was en dat hij waarschijnlijk het contract heeft gepubliceerd ZONDER de tijd te nemen om het opnieuw te lezen, waarschijnlijk in haast.

Hoe weet je dat het niet de ontwikkelaar zelf is die deze fout met opzet heeft achtergelaten en dat het geen oplichterij was?

Zeer goed bezwaar en het is gemakkelijk om oplichterij aan te nemen als u niet zeker weet hoe slimme contracten werk, maar het is eigenlijk heel gemakkelijk om de onschuld van de ontwikkelaar aan te nemen, omdat hij op 19 november 2021 de volledige code van het slimme contract heeft gepubliceerd en geverifieerd op BSCSCAN.COM (de meest populaire scanner van de Binance Blockchain), dat dat wil zeggen, meer dan twee weken voordat de RING Financial HACK plaatsvond. En zoals eerder uitgelegd, was de fout geschreven in ZWART OP WIT in het contract, en elke ervaren ontwikkelaar zou het hebben opgemerkt en gereageerd, maar helaas had de eerste geen genade. Het is daarom duidelijk dat de ontwikkelaar niet op de hoogte was van deze fout, omdat hij op geen enkel moment het risico zou hebben genomen om iemand het RING Financial-project te laten doden.

Om terug te komen op de voortzetting van de RING Financial HACK: de ontwikkelaar besefte zijn blunder en bevroor simpelweg het contract om elke distributie van beloningen te stoppen, zodat de aanvaller de pool niet volledig leegmaakt. Vervolgens implementeerde hij een Node-contract opnieuw, dit keer met het beveiligingsattribuut "onlyOwner". Dit nieuwe Node-contract kon de nieuwe beloningsdistributie correct afhandelen, behalve dat het te laat was, omdat als gevolg van de HACK alle vertrouwen in het project en het team verloren was gegaan, en de verkoopdruk de token en het project.

Tot slot hebben we dit verhaal gekozen omdat het twee belangrijke dingen laat zien over slimme contracten en cryptoprojecten, codeer nooit een contract overhaast en neem altijd contact op met de accountantskantoren, want als de hack eenmaal plaatsvindt, is het te laat om de boot te redden, en RING Financial project is een goed voorbeeld, ze hebben bovendien, volgens hun communicatie, contact opgenomen met accountantskantoren voor dit tweede Node-contract en hebben het niet openbaar op BSCSCAN geplaatst totdat ze zeker waren van de veiligheid ervan. Maar zoals gezegd, voor RING Financial was het te laat en was de schade onomkeerbaar.

Hier zijn alle links van de scanner en de contractadressen:

portemonnee voert transactie uit voor hack exploit: 0xfe58c9e2ecb95757be6f4bca33162cfa346cc34f

 Ring smart-contract address: 0x521ef54063148e5f15f18b9631426175cee23de2

Ring reward pool address: 0xa46cc87eca075c5ae387b86867aa3ee4cb397372

 transactie hack exploit:

 TRX 1

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

TRX 2

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

TRX 3

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

Hoe beoordeel je of een zogenaamde “HACK” die met een Crypto- of Blockchain-project is gebeurd, legitiem is of dat het slechts een mechanisme is om een ​​RUG te verbergen? PlatoBlockchain-gegevensintelligentie. Verticaal zoeken. Ai.

Tijdstempel:

Meer van Fintech Nieuws