DAO Hack- og Blockchain-sikkerhetsproblemer

Sikkerhetshensyn overstyrer alle andre hensyn i programvare generelt og spesielt i blockchain. Hvis sikkerheten mislykkes, betyr ingenting annet noe. Blockchain viser at desentraliserte, pålitelige transaksjoner fungerer, men mange sikkerhetsproblemer i blockchain forblir likevel.

Sikkerhetsutnyttelser eksisterer på design- og arkitektonisk nivå, på kodingsfasen og i den operasjonelle fasen. Og i tilfelle du lurte på, ja, blockchain kan bli hacket.

Sikkerhetsproblemer i Blockchain – herfra til evigheten

Diamanter er for alltid, og smarte kontrakter lever så lenge blockchain de er distribuert på fortsetter å bli brukt. Derfor lever alle feil og sikkerhetsproblemer i blockchain også så lenge kontrakten gjør.

Vanligvis gir hver blockchain sitt eget programmeringsspråk for å implementere smarte kontrakter. La oss se nærmere på det.

Smarte kontraktsspråk

Blockchain-miljøer inkluderer egne språk for utvikling av smarte kontrakter.

Ethereum-plattformen inkluderer for eksempel Soliditetsspråket for å skrive smarte kontrakter. Skaperne designet Solidity for å være et fullstendig Turing-språk.

Et Turing-komplett språk lar i hovedsak programmereren implementere alt det underliggende systemet er i stand til. Derfor gir dette programmerere muligheter som å implementere sløyfer i koden, noe som potensielt kan forårsake sikkerhetsproblemer i blockchain.

Turing fullstendighet

Turing komplette språk inneholder kompleksitet av natur, og kompleksitet innbyr til feil og sårbarheter.

Bitcoin-nettverket har også et programmeringsspråk som det kaller Script. Script er med vilje ikke Turing komplett for å øke sikkerheten.

Jo færre alternativer som blir gitt til en programmerer, desto mindre sannsynlig er det at blockchain-sikkerhetsproblemer kommer inn i systemet.

For å minimere risikoen for å slippe feil kode i naturen, må programmerere forstå vanlige fallgruver og antimønstre som ligger i smart kontraktprogrammering. (Antimønstre representerer dårlig programmeringspraksis).

DAO Hack: The Reentrancy Problem

bilde av sikkerhetsproblemer i blockchain

DAO Hack

Reentrancy-problemet ligger sannsynligvis høyest blant blockchain-sikkerhetssårbarhetsprogrammerere kodet i smarte kontrakter. Reentrancy tapper en konto gjennom flere utgifter for samme transaksjon. Brukstilfellet for behandling av refusjoner egner seg til denne utnyttelsen, men denne feilen påvirker enhver form for transaksjon hvis den ikke adresseres på design- og kodingsstadiet.

I et av de mest beryktede kryptovalutaangrepene til dags dato utnyttet hackere av DAO reentrancy. Ingen organisasjonsleder dikterte hvordan man skulle kjøre DAO (eller desentralisert autonom organisasjon), og DAO foreslo å gi brukerne muligheten til å stemme på prosjekter å investere i.

Det samlet inn over 150 millioner dollar i finansiering den første måneden. 17. juni 2016 tappet hackere 50 millioner dollar fra organisasjonen gjennom gjenopprettelsesfeilen. Den harde gaffelen fra Ethereum Classic (ETC) til Ethereum (ETH) resulterte i et forsøk på å løse problemene dette hacket skapte.

Anti-mønster sårbart for reentrancy

En sårbar reentrant-logikk for kode ser slik ut:

funksjon for å behandle en betaling () {

(1) sjekk gyldigheten av transaksjonen, mottakeren og kontosaldoen;

(2) behandle transaksjonen;

(3) oppdatere tilstanden til systemet for å vise at transaksjonen er behandlet;

}

Ved første øyekast ser logikken riktig og fullstendig ut, men feilen ligger i rekkefølgen av å gjøre trinn 2 før trinn 3.

Mens den første samtalen til funksjonen fortsetter behandlingen av trinn 2, kan en annen samtale for den samme transaksjonen komme inn i funksjonen. Siden tilstandsinformasjon forblir i sin opprinnelige tilstand og ennå ikke er behandlet i trinn 3, sjekker den andre samtalen ut som en gyldig transaksjon å behandle.

Følgelig bruker systemet valuta for samme forpliktelse en gang til. Hackere skynder flere transaksjoner til funksjonen før staten blir satt riktig.

Cure for Reentrancy

Denne endringen av algoritmen retter opp problemet ovenfor:

funksjon for å behandle en betaling () {

(1) sjekk gyldigheten av transaksjonen, mottakeren og kontosaldoen;

(2) oppdatere tilstanden til systemet for å vise at transaksjonen er behandlet;

(3) behandle transaksjonen;

}

Koden må ta hensyn til all nødvendig unntaksbehandling, og den må også ta hensyn til alle logiske avhengigheter.

Flyte

Overflow er en annen vanlig sikkerhetsfeil som programmerere må være klar over.

Noen programmeringsspråk gir sterk skriving, og andre gir svak skriving. Sterkt typte språk nekter for eksempel programmerere å tilordne strengdata til en numerisk variabel, og svakt skrevne språk tillater slike handlinger.

Sterkt skrevne språk håndhever rekkeviddebegrensninger. Hvis en matrise består av ti elementer, kan ikke programmerere prøve å få tilgang til det ellevte elementet. Svakt skrevne språk tillater slik oppførsel, men krasjer resulterer. Hvis den maksimalt tillatte verdien en variabel har, er 99, og du tildeler den verdien 100, se den krasje når du kjører den!

Følgelig er overløp en utnyttelse som hackere bruker. Hvis en hacker mater en parameter til en smart kontrakt som er utenfor området koden kan behandle, resulterer det i et krasj. Et slikt krasj driver flere utnyttelser. Krasjet kan utløse et denial of service-angrep (DDoS-angrep), og viktig informasjon om det indre av systemet avslører noen ganger seg selv i feilmeldinger..

I webapplikasjoner fyller hackere ofte minne med sin egen ondsinnede kode, så når programmet krasjer og går til et tilfeldig sted i minnet, kjøres den ondsinnede koden.

Svakt skrevne språk gir kraft og dynamisk fleksibilitet, men de krever også strengere design og testing for å bli herdet mot angrep.

Den mangehodede hydraen

bilde av sikkerhetsproblemer i blockchain

En rekke sikkerhetsproblemer plager programvareverdenen. Når ny teknologi dukker opp, dukker det opp nye trusler. Foruten utnyttelsene nevnt ovenfor, representerer disse bemerkelsesverdige feilene bare noen få av de mange andre sikkerhetsproblemene i blockchain.

Dårlig kryptografi skaper mange hodepine. Kryptografi sørger for personvern, og når personvernet bryter, bryter alt. IOTA-teamet gjorde feilen ved å skrive sitt eget kryptografiske bibliotek fra bunnen av i den første versjonen av produktet. Problemet med å rulle din egen kryptografi er at all kompleks programvare inneholder bugs, så du er garantert å ha buggy-kryptografi.

Etablerte kryptografiske biblioteker overlever undersøkelser av akademikere og viser seg pålitelige over tid gjennom livet i naturen.

I lommebokens verden må generering av tilfeldig tall være virkelig tilfeldig. Spesielt i de første dagene av kryptokurrency sviktet noen lommebøker dette kravet.

Kryptovaluta-adresser krever adresser som må være unike. Unikt kommer fra en tilfeldig tallgenerator, og tilfeldig tallgenerator trenger et frø for å starte prosessen. Hvis frøet ikke er virkelig tilfeldig, mislykkes systemet.

Ett resultat av dårlig tilfeldighet betyr at samme adresse blir opprettet flere ganger. Tenk deg scenariet der en lommebok tildeler adresse X til person A, og deretter en gang senere tildeler adresse X til person B. Når en betaling går til adresse X, går den bare til en person. Hvilken person får pengene?

Et annet problem med dårlig tilfeldighet oppstår når en hacker finner ut algoritmen som brukes til å lage frøet. Hackeren regenererer frøet for seg selv og eier systemet.

Veien fortsetter for alltid og festen slutter aldri

Sikkerhet er en uendelig kamp, ​​og selv om programmerere, arkitekter og testere fjerner alle sårbarheter fra koden, forblir operasjonelle sårbarheter.

I et bevis på arbeidsmiljø, hvis dårlige aktører kontrollerer 51% av nettverket, blir integriteten ødelagt. Spillteori gir lindring for dette angrepet. En ny kryptovaluta med et lite nettverk utsetter mest risiko for dette angrepet. Men et 51% angrep ødelegger verdien av valutaen, så angripere bare skader seg selv.

Blockchains lever på internett og deler den samme eksponeringen for hackere som internett. Anta for eksempel at du kjøper mynter fra en børs på et nettsted. Injiseringsangrep, skript på tvers av nettsteder, phishing-angrep og alle de andre tradisjonelle nettstedhackene er fremherskende.

Siste tanker

Akkurat som programmerere beskytter mot feil, må programmerere faktorere sikkerhet i utviklingen. Noen verktøy finnes for å hjelpe programmerere i oppgaven, men programmerere må først forstå sine egne sårbarheter for å beskytte dem.

De Desentralisert applikasjonssikkerhetsprosjekt (DASP) ønsker å være et lager av informasjon og ressurser om blockchain-sikkerhet. De modellerer seg noe på Åpne sikkerhetsprosjekt for webapplikasjon (OWASP). Den årlige OWASP Top 10 lister definitivt de viktigste sårbarhetene for nettapplikasjoner. DASP Top 10 håper å gi den tilsvarende ressursen for blockchain.

Ikke alle angrep er kjent på forhånd. En null-dagers utnyttelse definerer en utnyttelse hackere vet om før noen andre gjør det. Så programmerere må tenke som angripere når de designer og implementerer programvare. Hvis du ikke finner sårbarhetene i koden din, kan du forvente at en hacker som ser etter fortjeneste, finner dem.

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
map