Sigurnosna razmatranja nadjačavaju sva druga razmatranja u softveru općenito i posebno u blockchainu. Ako sigurnost zakaže, ništa drugo nije važno. Blockchain dokazuje da decentralizirane, nepovjerljive transakcije rade, ali svejedno ostaju mnoge sigurnosne ranjivosti blockchaina.

Sigurnosna iskorištavanja postoje na razini dizajna i arhitekture, u fazi kodiranja i u operativnoj fazi. I u slučaju da ste se pitali, da, blockchain se može hakirati.

Blokchain sigurnosne ranjivosti – odavde do vječnosti

Dijamanti su zauvijek, a pametni ugovori žive dokle god se koristi blockchain na kojem su raspoređeni. Slijedom toga, sve programske pogreške i sigurnosne ranjivosti blockchaina također žive dok god ugovor traje.

Tipično, svaki blockchain nudi vlastiti programski jezik za provedbu pametnih ugovora. Pogledajmo izbliza.

Jezici pametnog ugovora

Blockchain okruženja uključuju vlastite jezike za razvoj pametnih ugovora.

Platforma Ethereum, na primjer, uključuje jezik Solidity za pisanje pametnih ugovora. Stvoritelji su Solidity stvorili kao cjelovit Turingov jezik.

Kompletan Turingov jezik u osnovi omogućuje programeru da implementira sve što je osnovni sustav sposoban. Posljedično, to programerima daje mogućnosti poput implementacije petlji u kod, što potencijalno može uzrokovati sigurnosne ranjivosti blockchaina.

Turingova cjelovitost

Turingovi cjeloviti jezici sadrže složenost po prirodi, a složenost poziva na programske pogreške i ranjivosti.

Bitcoin mreža također ima programski jezik koji naziva Script. Skripta namjerno nije Turingova cjelovita da bi poboljšala sigurnost.

Što je manje mogućnosti koje se daju programeru, to je manja vjerojatnost da će sigurnosne ranjivosti blockchaina ući u sustav.

Kako bi minimizirali rizik od puštanja neispravnog koda u divljinu, programeri moraju razumjeti uobičajene zamke i uzorke koji su svojstveni programiranju pametnih ugovora. (Anti-obrasci predstavljaju lošu praksu programiranja).

DAO Hack: Problem ponovnog pojavljivanja

slika sigurnosnih ranjivosti blockchaina

DAO Hack

Problem povratka vjerojatno se nalazi na najvišem mjestu među blockchain sigurnosnim ranjivostima programerima kodiranim u pametne ugovore. Ponovno pristupanje iscrpljuje račun kroz višestruke troškove za istu transakciju. Slučaj upotrebe obrade povrata novca prikladan je za ovo iskorištavanje, ali ovaj nedostatak utječe na bilo koju vrstu transakcije ako se ne riješi u fazi dizajniranja i kodiranja.

U jednom od najzloglasnijih napada kriptovaluta do danas, hakeri DAO-a iskoristili su ponovno ulazak. Niti jedan organizacijski čelnik nije diktirao kako voditi DAO (ili Decentraliziranu autonomnu organizaciju), a DAO je predložio da korisnici osnaže mogućnost glasanja na projektima u koje treba ulagati.

Prvih mjesec dana prikupila je više od 150 milijuna američkih dolara. 17. lipnja 2016. godine, hakeri su isušili 50 milijuna dolara iz organizacije kroz nedostatak ponovnog ulaska. Tvrda vilica s Ethereum Classic (ETC) na Ethereum (ETH) rezultirala je pokušajem rješavanja problema koje je ovaj hak stvorio.

Anti-obrazac ranjiv na ponovno ulazak

Ranjiva povratna logika za kod izgleda ovako:

funkcija za obradu uplate () {

(1) provjeriti valjanost transakcije, primatelja i stanja računa;

(2) obraditi transakciju;

(3) ažurirati stanje sustava kako bi pokazalo da je transakcija obrađena;

}

Na prvi pogled logika izgleda ispravno i cjelovito, ali nedostatak je u redoslijedu koraka 2 prije koraka 3.

Dok se prvi poziv funkcije nastavlja s obradom koraka 2, u nju može ući drugi poziv za istu transakciju. Budući da podaci o stanju ostaju u početnom stanju i još nisu obrađeni u koraku 3, drugi poziv provjerava se kao valjana transakcija za obradu.

Slijedom toga, sustav po drugi put troši valutu za istu obvezu. Hakeri hrle s višestrukim transakcijama na funkciju prije nego što se država pravilno postavi.

Lijek za ponovno ulazak

Ova promjena algoritma ispravlja gornji problem:

funkcija za obradu uplate () {

(1) provjeriti valjanost transakcije, primatelja i stanja računa;

(2) ažurirati stanje sustava kako bi pokazalo da je transakcija obrađena;

(3) obraditi transakciju;

}

Kôd mora uzimati u obzir sve potrebne obrade iznimki, a mora računati i sve logičke ovisnosti.

Prelijevanje

Prelijevanje je još jedna uobičajena sigurnosna greška koju programeri moraju biti svjesni.

Neki programski jezici pružaju snažno tipkanje, a drugi slabo tipkanje. Snažno otkucani jezici odbijaju programerima dodijeliti niz podataka numeričkoj varijabli, na primjer, a slabo otkucani jezici dopuštaju takve radnje.

Snažno otkucani jezici provode ograničenja dometa. Ako je niz deset elemenata, programeri ne mogu pokušati pristupiti jedanaestom elementu. Slabo upisani jezici dopuštaju takvo ponašanje, ali rezultiraju padovima. Ako je najveća dopuštena vrijednost koju sadrži varijabla 99, a vi joj dodijelite vrijednost 100, gledajte kako pada kad je pokrenete!

Slijedom toga, preljev je zloporaba koju hakeri koriste. Ako haker pametnom ugovoru doda parametar koji je izvan dosega koji kôd može obraditi, dolazi do pada. Takav krah potiče višestruke eksploatacije. Pad bi mogao pokrenuti napad uskraćivanja usluge (DDoS napad), a vitalne informacije o unutrašnjosti sustava ponekad se otkriju u porukama pogreške.

U web aplikacijama hakeri često ispunjavaju memoriju vlastitim zlonamjernim kodom, pa kad se program sruši i pređe na slučajno mjesto u memoriji, zlonamjerni kod se izvršava.

Slabo upisani jezici pružaju snagu i dinamičku fleksibilnost, ali također zahtijevaju strožiji dizajn i testiranje kako bi se ojačali protiv napada.

Hidra s mnogo glava

slika sigurnosnih ranjivosti blockchaina

Mnoštvo sigurnosnih problema muči svijet softvera. Kako se pojavljuje nova tehnologija, pojavljuju se i nove prijetnje. Osim gore spomenutih iskorištavanja, ove značajne nedostatke predstavljaju samo neke od mnogih drugih sigurnosnih ranjivosti blockchaina.

Loša kriptografija stvara mnoge glavobolje. Kriptografija osigurava privatnost, a kad privatnost pukne, sve se prekida. IOTA tim pogriješio je napisavši vlastitu kriptografsku biblioteku ispočetka u početnoj verziji svog proizvoda. Problem svojstven valjku vlastite kriptografije je taj što sav složeni softver sadrži bugove, tako da ćete zajamčeno imati buggy kriptografiju.

Utemeljene kriptografske knjižnice preživljavaju provjeru od strane akademika i s vremenom se pokazuju pouzdanima kroz život u divljini.

U svijetu novčanika generiranje slučajnih brojeva mora biti uistinu slučajno. Pogotovo u prvim danima kriptovaluta, neki novčanici nisu ispunili ovaj zahtjev.

Adrese za kriptovalute zahtijevaju adrese koje moraju biti jedinstvene. Jedinstvenost dolazi od generatora slučajnih brojeva, a generatoru slučajnih brojeva treba sjeme da započne postupak. Ako sjeme ne bude uistinu slučajno, sustav zakaže.

Jedan rezultat loše slučajnosti znači da se ista adresa stvara više puta. Zamislite scenarij u kojem novčanik dodjeljuje adresu X osobi A, a zatim nešto kasnije dodjeljuje adresu X osobi B. Kada uplata ide na adresu X, ide samo jednoj osobi. Koja osoba dobiva novac?

Drugi problem s lošom slučajnošću pojavljuje se kada haker smisli algoritam koji se koristi za stvaranje sjemena. Haker sam obnavlja sjeme i posjeduje sustav.

Put ide zauvijek, a zabava nikad ne završava

Sigurnost je neprestana bitka, čak i ako programeri, arhitekti i testeri uklone sve ranjivosti iz koda, operativne ranjivosti ostaju.

U okruženju Proof of Work, ako loši akteri kontroliraju 51% mreže, integritet se uništava. Teorija igara ublažava ovaj napad. Nova kriptovaluta s malom mrežom izlaže najveći rizik ovom napadu. Ali napad od 51% uništava vrijednost valute, pa napadači samo naštete sebi.

Blockchains žive na Internetu i dijele istu izloženost hakerima kao i Internet. Na primjer, pretpostavimo da novac kupujete na burzi na web mjestu. Prevladavaju injekcijski napadi, skriptiranje na više web lokacija, napadi na krađu identiteta i svi drugi tradicionalni hakovi na web stranicama.

Završne misli

Baš kao što se programeri čuvaju od bugova, programeri moraju u svoj razvoj ugraditi sigurnost. Postoje neki alati koji pomažu programerima u zadatku, ali programeri prvo moraju razumjeti vlastite ranjivosti kako bi se zaštitili od njih.

The Projekt decentralizirane zaštite aplikacija (DASP) teži biti spremištem informacija i resursa o blockchain sigurnosti. Oni se donekle modeliraju na Otvoreni projekt sigurnosti web aplikacija (OWASP). Godišnji OWASP Top 10 definitivno navodi primarne ranjivosti web aplikacija koje trenutno postoje. Top 10 DASP-a nada se da će pružiti ekvivalentan resurs za blockchain.

Nisu svi napadi poznati unaprijed. Eksploatacija nultog dana definira eksploataciju koju hakeri znaju prije nego što bilo tko drugi zna. Dakle, programeri moraju razmišljati poput napadača kada dizajniraju i implementiraju softver. Ako u svom kodu ne pronađete ranjivosti, očekujte da ih pronađe haker koji traži zaradu.