Sigurnosne prijetnje programskog jezika Solidity

The fact that we could even recover data from a formatted Hard Drive is kind of amazing. You choose (or not) to delete data, but it is still there, even if it is not that easy to read.

The purpose of this paper is to understand how data recovery works. To do so, we explain the steps and some technics. We will go through how a sinister leading to a try for data recovery can occur. Then, we will see a method that could have been used by computer forensics experts in order to find traces. To finish, we will mention methods to definitely erase data from Hard Drives to avoid leaving traces.

The reasons for those sinisters are numerous, but human mistakes are majorly involved. Peter Gutmann proposed through his papers an explanation of how this data could still be read on Hard Drives at that time, but also some advices to securely erase data.

This paper is some kind of a warning to all those selling Hard Drives via eBay that once contained personal data.

Keywords: recovery; data; traces

Uredi

Uredi

Solidity je objektno orijentirani programski jezik namijenjen za pisanje pametnih ugovora. Najpoznatiji je po činjenici da je upravo on primarni jezik na jednoj od najpoznatijih blockchain platforma - na Ethereumu, ali koristi se i na raznim drugim blockchain platformama. Prvi put se pojavio u kolovozu 2014. godine.

Pametni ugovori su javni i nepromjenjivi računalni programi koji su pohranjeni na blockchainu. Mogu se javno i pouzdano izvršavati koristeći blockchain. Da bi se program uopće mogao pohranjivati i izvršavati na blockchainu u obliku pametnog ugovora, mora se pridržavati pravila i poštivati ograničenja tehnologije blockchain. Svrha Solidity-ja je da omogući programerima lako i intuitivno pisanje pametnih ugovora dok Solidity interno rješava dio ograničenja i pravila zadanih blockchainom.

Najpopularnije primjene pametnih ugovora programiranih u Solidity-ju su implementacije glasovanja, grupnog financiranja (crowdfunding), aukcija i novčanika s više potpisa (multi-signature wallets).

Iako je široko raširen, Solidity je još uvijek u ranoj razvojnoj fazi (trenutna najnovija verzija je 0.6.X), a to ukazuje na puno prostora za sigurnosne prijetnje. Ovaj će seminar razmotriti nekoliko zanimljiviih otkrivenih sigurnosnih propusta te službena ili potencijalna rješenja za sprječavanje istih.

Za razumijevanje ovog napada, potrebno se upoznati s pojmom fallback funkcije. Fallback funkcija je funkcija koja se izvršava kada neki ugovor primi ethere bez ikakvih drugih podataka povezanih s tom transakcijom. Također, izvršavaju se kad identifikator funkcije ne odgovara niti jednoj funkciji dostupnoj u pametnom ugovoru ili kada nikakvi podatci nisu dani pri pozivu funkcije. Fallback funkcije nemaju ime, ne mogu primati argumente, ne mogu vraćati ništa te u jednom ugovoru postoji najviše jedna fallback funkcija.

Ovaj je napad omogućen kada pametni ugovor šalje ethere na nepoznatu adresu pozivom odgovarajuće funkcije nepoznate adrese / primatelja. Napadač pažljivom konstrukcijom svog ugovora na toj nepoznatoj adresi može umetnuti zlonamjerni kod koji će se pokretati pri slanju sredstava na tu nepoznatu adresu. Točnije, u ovom napadu, taj će zlonamjerni kod ponovno pozvati funkciju napadnutog ugovora prije nego što se prošla iteracija ugovora izvršila do kraja te na taj način iskoristiti ranjivi ugovor.

Pogledajmo primjer.

U ovom primjeru EtherStore je napadnuti ugovor, a Attack je ugovor napadač.Originalna željena funkcionalnost ugovora EtherStore je da pohranjuje riječnik stanja računa svojih klijenata. Neki klijent može pohraniti određenu količinu valute (wei-ja) koji će se dodati na njegovo stanje računa, te može podizati wei-je sa svog računa. Naravno, u metodi za podizanje novaca, pametni ugovor EtherStore provjerava je li iznos koji se pokušava podići manji od stanja računa klijenta (naravno, nije moguće podići više sredstava nego što postoji na računu) te postoji ograničenje da svaki klijent može podići sredstva maksimalno jednom u tjedan dana. Ova su ograničenja vidljiva u linijama 14 i 16 pametnog ugovora EtherStore. U liniji 17, EtherStore šalje sredstva klijentu te u linijama 18 i 19 osvježava stanje računa i vremensku oznaku zadnjeg podizanja novca.

Pogledajmo sada napadača. Napadač prvo pohranjuje određena sredstva (1 wei) na svoj račun u EtherStore, a zatim pokreće funkciju za podizanje tih sredstava - također 1 wei. Zahtjev za podizanje sredstava uspješno prolazi sve provjere te se u liniji 17 ugovora EtherStore sredstva (1 wei) šalju napadaču. Upravo ovdje događa se sigurnosni propust. Linija 17 zapravo pokreće fallback funkciju ugovora Attack, a u fallback funkciji nalazi se zloćudni kod. Taj kod ponovno poziva funkciju EtherStore-a za podizanje sredstava (ponovno jednog wei-a). Problem je u činjenici što su sredstva prethodnog poziva već na računu napadača, a novi poziv funkcije withrawFunds kreće se izvršavati prije nego što je prethodni poziv stigao osvježiti potrebne varijable stanja na računu i vremenske oznake podizanja novca. Tu zapravo ulazimo u petlju koja, wei po wei, potpuno prazni ukupan račun ugovora EtherStore, uz uspješne provjere svih varijabli u svakom pozivu.

Ovo je jedan od većih i važnijih sigurnosnih prijetnji koje treba imati na umu pri dizajniranju pametnih ugovora. Ovakvo neželjeno ponašanje može se spriječiti na više načina. Jedno od rješenja je korištenje funkcije transfer() pri slanju sredstava vanjskim ugovorima. Funkcija transfer sa svojim pozivom šalje dovoljno gas-a (platne jedinice za izvršavanje funkcija) da bi se sredstva poslala, ali nedovoljno da bi vanjski ugovor izveo operaciju poput zvanja nekog drugog ugovora - to automatski sprječava ponovno pozivanje napadnutog ugovora. Još jedno rješenje je koristiti “checks-effects-interactions” slijed događaja pri dizajniranju funkcija pametnih ugovora. Ova metoda predlaže da se u svakoj funkciji prvo naprave provjere i zadovolje uvjeti da bi se funkcionalnost ugovora izvršila, zatim da se osvježe sve varijable (kao da je akcija već izvršena), a tek se na kraju akcija stvarno izvrši. Na taj način spriječili smo ovakav napad jer već u drugom pozivu ugovora, uvjeti neće biti zadovoljeni.

Propust ugovora EtherStore događa se upravo u liniji 17, liniji koja šalje sredstva klijentu. Napadač u

Uredi

Uredi

Uredi

Uredi

Uredi

Uredi

Uredi

Uredi

Uredi

Uredi