De siste trendene innen hackerangrep og hvordan de skal håndteres

Ettersom DeFi-sektoren fortsetter å tiltrekke seg penger og brukere, fortsetter dårlige aktører fra hele verden å se den som et attraktivt mål som er modent for plukking og dårlig beskyttet.

I løpet av de siste månedene har jeg holdt styr på noen av de mest bemerkelsesverdige utnyttelsene av DeFi-protokoller, og minst syv av dem ser ut til å være et resultat av smarte kontraktsfeil alene.

For eksempel slo og ranet hackere Wormhole og stjal over 300 millioner dollar, Qubit Finance (80 millioner dollar), Meter (4.4 millioner dollar), Deus (3 millioner dollar), TreasureDAO (over 100 NFT-er), og til slutt, Agave og Hundred Finance som sammen , tapte 11 millioner dollar totalt. Alle disse angrepene resulterte i tyveri av ganske betydelige mengder penger, og forårsaket stor skade på prosjektene.

Mange av de målrettede protokollene har sett en devaluering av deres kryptovaluta, mistillit fra brukere, kritikk angående sikkerheten til DeFi og smarte kontrakter, og lignende negative konsekvenser.

Hvilke typer utnyttelser skjedde under angrepene?

Naturligvis er hver av disse sakene unik, og ulike typer utnyttelser ble brukt for å takle hvert enkelt prosjekt, avhengig av deres sårbarheter og feil. Eksempler inkluderer logiske feil, reentrancy-angrep, flashloan-angrep med prismanipulasjoner og mer. Jeg tror at dette er resultatet av at DeFi-protokoller har blitt mer komplekse, og etter hvert som de gjør det, gjør kodens kompleksitet det mer og mer vanskelig å fjerne alle feilene.

Videre la jeg merke til to ting mens jeg analyserte hver av disse hendelsene. Den første er at hackere klarte å komme unna med enorme beløp hver gang - for millioner av dollar i krypto.

Denne "lønningsdagen" gir hackerne insentiv til å bruke all nødvendig tid på å studere protokollene, til og med måneder av gangen, siden de vet at belønningen vil være verdt det. Det betyr at hackerne er motivert til å bruke mye mer tid på å lete etter feil enn revisorene.

Den andre tingen som skilte seg ut er at hackene i noen tilfeller faktisk var ekstremt enkle. Ta Hundred Finance-angrepet som et eksempel. Prosjektet ble truffet ved hjelp av en velkjent feil som vanligvis kan finnes i Compound forks hvis et token legges til protokollen. Alt som hackeren trenger å gjøre er å vente til en av disse tokenene blir lagt til Hundred Finance. Etter det er det bare å følge noen få enkle trinn for å bruke utnyttelsen for å komme til pengene.

Hva kan DeFi-prosjekter gjøre for å beskytte seg selv?

Fremover er det beste disse prosjektene kan gjøre for å beskytte seg mot dårlige aktører å fokusere på revisjonene. Jo mer i dybden, jo bedre, og utført av erfarne fagfolk som vet hva de skal være oppmerksomme på. Men, det er en annen ting prosjektene kan gjøre, selv før de tyr til revisjonene, og det er å sikre at de har en god arkitektur skapt av ansvarlige utviklere.

Dette er spesielt viktig siden de fleste blokkjedeprosjekter er åpen kildekode, noe som betyr at koden deres har en tendens til å bli kopiert og gjenbrukt. Det setter fart under utviklingen, og koden er gratis å ta.

Problemet er hvis det viser seg at det er feil, og det blir kopiert før de originale utviklerne finner ut av sårbarhetene og fikser dem. Selv om de kunngjør og implementerer rettelsen, kan de som kopierte den ikke se nyhetene, og koden deres forblir sårbar.

Hvor mye kan egentlig tilsynene hjelpe?

Smarte kontrakter fungerer som programmer som kjører på blokkjedeteknologi. Som sådan er det mulig at de er feil og at de inneholder insekter. Som jeg nevnte før, jo mer kompleks kontrakten er – jo større er sjansen for at en feil eller to har sluppet gjennom utviklernes kontroller.

Dessverre er det mange situasjoner der det ikke er noen enkel løsning for å rette opp disse feilene, og det er derfor utviklere bør ta seg god tid og sørge for at koden gjøres riktig og at feilene blir oppdaget umiddelbart eller i det minste så tidlig som mulig.

Det er her revisjoner kommer inn, for hvis du tester koden og dokumenterer fremdriften i utviklingen og testene tilstrekkelig, kan du bli kvitt de fleste problemene tidlig.

Selvsagt kan ikke selv revisjoner gi en 100 % garanti for at det ikke vil være noen problemer med koden. Ingen kan. Det er ikke tilfeldig at hackere trenger måneder på å finne ut den minste sårbarheten de kan bruke til sin fordel – du kan ikke lage den perfekte koden og gjøre den nyttig, spesielt ikke når det kommer til ny teknologi.

Tilsyn reduserer antallet problemer, men det virkelige problemet er at mange av prosjektene som blir rammet av hackerne ikke en gang hadde noen revisjoner i det hele tatt.

Så for alle utviklere og prosjekteiere som fortsatt er i utviklingsprosessen er det å huske at sikkerhet ikke kommer fra å bestå en revisjon. Imidlertid begynner det absolutt der. Arbeid med koden din; sørge for at den har en godt utformet arkitektur og at dyktige og flittige utviklere jobber med den.

Sørg for at alt er testet og godt dokumentert, og bruk alle ressursene du har til rådighet. Bug bounties, for eksempel, er en fin måte å få koden din sjekket ut av folk fra hackernes synspunkt, og et nytt perspektiv fra noen som leter etter en vei inn kan være uvurderlig for å sikre prosjektet ditt.