Hvordan skal man bedømme, om et såkaldt "HACK", der skete med et krypto- eller blockchain-projekt, er lovligt, eller om det bare er en mekanisme til at skjule et tæppe?

Genudgivet af Platon

Abonnenter: 0

Det er klart, efter hvad der skete med MtGox eller QuadrigaCX eller lignende sager, hvor grundlæggere hævdede, at de mistede de private nøgler med størstedelen af de digitale aktiver på deres børser, mens de forsvandt eller fundet døde senere, bliver folk i kryptosfæren mere og mere mistænksomme, når de hører om en hacke på et projekt, og den første tanke, der kommer til at tænke på, er, at stifterne stort set har tømt fonden og stukket af med den, det er det, man i daglig tale kalder et RUG.

Sådan har det nok været i mange projekter, men ikke nødvendigvis i dem alle, så i dag kigger vi på en sag, som vi mener er et rigtigt hack på grund af situationens karakter.

Vi synes, det er en interessant case at analysere, fordi den vil hjælpe til bedre at forstå vigtigheden af sikkerhed og revisioner i smart-kontrakt eller blockchain-relaterede projekter generelt.

Vi vil objektivt analysere det drama, der skete med RING Financial-projektet, et token lanceret på BSC (Binance Blockchain).

Inden vi kommer til hacket, vil vi først opsummere projektet og dets situation før det:

RING Financial før hacket

RING financial var et DeFi-projekt med det formål at gøre DeFi mere tilgængelig for DeFi- og kryptofællesskabet. Et ambitiøst projekt, der ønskede at skabe en node-afkast-protokol, der ville blive styret af Node Holders og allokere likviditet til mere end 300 protokoller på én gang. Målet var at få adgang til alle protokollerne gennem én RING Node og gennem RING Dapp.

Disse protokoller blev verificeret af holdet, og derefter ville fællesskabet stemme om dem, hvor de skulle tildeles. Det samme koncept for at stemme, som du ville have i en DAO, hvilket gjorde RING ret attraktiv.

RING Financial forenklede også ret meget af forskningsprocessen og implementeringsprocessen for en enkelt nodeholder. Én Dapp for at få adgang til alle de andre Dapps, så du behøver kun én grænseflade i stedet for 300 forskellige med deres egne adgange og egne noder.

Endelig var RING Financials mål at reducere gebyrerne for implementering på forskellige protokoller, med volumen kommer lavere transaktionsgebyrer for individuelle indehavere, hvilket var et af de vigtigste salgsargumenter for projektet. Et projekt med flair og ambition om at gøre tingene lettere for samfundet og endnu mere mainstream for dem, der ikke kender til Defi.

Men flair og ambition er ikke altid nok, og du har brug for ekspertise og viden, som på nye og umodne markeder er et sjældent fund, og derfor kunne RING Financial ikke helt leve op til sit løfte.

Så hvad skete der egentlig med RING Financial? Og hvorfor blev den hacket? Takket være blockchain har vi alle de retsmedicinske beviser, der er nødvendige for at dykke ned i dette og se, hvor sårbarhederne var og hvorfor RING Financial var ikke en fidus.

RING Financial HACK fandt sted den 5. december 2021 mellem 2:01 og 2:06 UTC.

Ja, alt skete på bogstaveligt talt kun 5 minutter! Takket være blockchain-scanneren for disse detaljer, giver vi dig i øvrigt lige under links til transaktioner relateret til HACK samt adressen på kontrakten for dem, der ønsker at søge mere detaljeret.

Her er oversigten, der forklarer den fejl, som angriberen har udnyttet:

Du skal forstå, at RING Financials smart-kontrakt var sammensat af flere dele, en for tokenet og alle de data, der er relateret til det, og en anden for alt relateret til bogføring af noder og belønninger. Den del af tokenet havde en sikkerhed, så kun administratoren af kontrakten kan ændre de vigtige data i denne, for at vise dig noget kode, her er en overskrift på en funktion af kontrakten, som er beskyttet via attributten "onlyOwner" som foreskriver, at funktionen kun kan udføres af administratoren:

En funktion, der ikke har en eneste ejer attribut (eller tilsvarende attribut for at beskytte funktionens adgang) kan udføres af bogstaveligt talt alle.

Nu, gæt hvad? Funktionerne på Nodes and Rewards-delen havde ikke denne egenskab, som du kan se ved at se på funktionsnavnene nedenfor (den eneste ejer attribut mangler):

Og som du kan forestille dig, udnyttede og svindlede en hacker denne fejl for at få et eksponentielt antal belønninger i RING, og dumpede dem derefter i likviditetspuljen og tømte den næsten voldsomt på få minutter. Dermed begik han sine fiduser.

Nu stiller du sikkert dig selv to spørgsmål:

Hvordan kunne udviklerne efterlade et sådant smuthul?

Efter at have talt med Solidity-udviklere (sprog der bruges til at kode smart-kontrakter på Ethereum), er dette en fejl relateret til rollearven mellem to smart-kontrakter, arv er et begreb om programmeringssprog og for ikke at give dig hovedpine, vil blive i simple ord: Grundlæggende er det meget sandsynligt, at den person, der kodede kontrakten, troede, at funktionerne i Node-delen arvede sikkerhedsrollerne for funktionerne i Token-delen, men det er desværre ikke tilfældet i Solidity, og det er nødvendigt at omdefinere rollerne for hver funktion i hver kontrakt, uanset deres sammenhæng. Så vores konklusion på dette punkt er, at bygherren ikke var ekspert, og at han formentlig har offentliggjort kontrakten UDEN at tage sig tid til at læse den igen, sandsynligvis i en fart.

Hvordan ved du, at det ikke er udvikleren selv, der efterlod denne fejl med vilje, og at det ikke var en fidus?

Meget god indvending, og det er nemt at antage en fidus, når du ikke er sikker på hvordan smarte kontrakter arbejde, men det er faktisk meget nemt at antage udviklerens uskyld, fordi han offentliggjorde og verificerede hele koden for smart-kontrakten offentligt på BSCSCAN.COM (den mest populære scanner af Binance Blockchain), den 19. november 2021, at vil sige mere end to uger før RING Financial HACK fandt sted. Og som forklaret før, var fejlen skrevet med SORT PÅ HVID i kontrakten, og enhver erfaren udvikler ville have bemærket det og reageret, men desværre var den første, der slet ikke havde nåde. Det er derfor indlysende, at bygherren ikke var klar over denne fejl, fordi han ikke ville have taget risikoen for at lade nogen dræbe RING Financial-projektet på noget tidspunkt.

For at vende tilbage til fortsættelsen af RING Financial HACK, indså udvikleren sin bommert og frøs simpelthen kontrakten for at stoppe enhver uddeling af belønninger, så angriberen ikke tømmer poolen fuldstændigt. Han omdisponerede derefter en Node-kontrakt, denne gang med sikkerhedsattributten "onlyOwner". Denne nye Node-kontrakt var i stand til at håndtere den nye belønningsfordeling korrekt, bortset fra at det var for sent, fordi som et resultat af HACK var al tillid til projektet og teamet gået tabt, og salgspresset dræbte og afsluttede tokenet og projektet.

Afslutningsvis valgte vi denne historie, fordi den viser to vigtige ting om smart-kontrakter og kryptoprojekter, kode aldrig en kontrakt i hast og kontakt altid revisionsfirmaerne, for når først hacket sker, er det for sent at redde båden, og RING Financial-projektet er et godt eksempel, de har desuden, ifølge deres kommunikation, kontaktet revisionsfirmaer for denne anden Node-kontrakt og ikke offentliggjort den på BSCSCAN, før de var sikre på dets sikkerhed. Men som sagt før, var det for sent for RING Financial, og skaden var uoprettelig.