Kako hakeri napadaju EOS ugovore i načine kako to spriječiti

Nedavno je EOS Bet - kockarski dApp koji koristi EOS tokene, izgubio najmanje 338.000 dolara iz svojih operativnih novčanika hakerima 15. listopada. Ovo nije prvi put da je ovaj dApp hakiran od iste katastrofe koja se dogodila prije 14. rujna. EOS Bet, i drugi EOS koji se temelji na Dappu također trpe isto pitanje.

Pa kako su hakeri napravili napad na EOS Dapps i ukrali žeton? Ovaj članak donijet će vam detaljno objašnjenje ovog problema, kao i zaključiti nekoliko iskustava za programere EOS-a u zaštiti njihovih Dapps-a od hakiranja.

Pregled
1. Metoda primjene () pomoću EOS pametnog ugovora
2. Kako su dva puta hakirali EOSDice
3. Uobičajeni načini za sprečavanje hakiranja

Primjena () metode pomoću pametnog ugovora EOS

Zašto spominjem ovu metodu?

Kao DApp programeru uobičajeni je zadatak provjeriti plaćanje i poslati token od korisnika na ugovor i obrnuto. Da bi radio s ovim unutar EOS ugovora, vlasnik ugovora trebao bi primijeniti metodu primjene () kako bi nadoknadio radnju prijenosa iz token ugovora. Ali EOSIO službeno ne pokriva ovu temu. Zato je većina EOS ugovora bila hakirana s ove funkcije: EOSBet, DEOS, EOS.WIN ... Moram objasniti detaljno o tome i zaključiti s nekim iskustvima hakiranih u EOSbetu kao i drugih DApps-a.

Kako funkcionira primjena ()?

U ugovoru definirajte metodu primjene () kako biste zaključili obavijest o transakciji s eosio.token. Jednom kada netko prenese EOS token na vaš ugovor, on će nadoknaditi ovu transakciju, a zatim izvršiti funkciju mytransfer () s upakiranim podacima. Pogledajte donji dijagram toka ispod:

Primjer za primjenu () metoda

Da bismo razumjeli kako ova funkcija funkcionira, uzmimo jedan primjer: U EOS ugovoru želim prihvatiti EOS plaćanja od korisnika, a zatim im vratiti svoj token s određenim omjerom. Detaljan kod naveden je u nastavku:

Kako su dva puta hakirani EOSDice.

EOSBEet je doživio hakiranje dva puta, a haker je preuzeo više od 100.000 EOS-a. Iako imaju sigurnosne preglede od 2 treće strane nakon prve hakirane. Drugi napad je vrlo pametan i lukav.

Danas ću vam detaljno pokazati kako je haker to učinio korak po korak. Ovdje je EOSBet kôd ugovora.

Molimo uzmite u obzir sljedeće kodne funkcije EOSBet-a prije njegovog hakiranja:

Hack broj 1:

U očekivanom scenariju, ugovor prihvaća samo prijenos s eosio.token ugovora, a zatim ga obrađuje. Ali što će se dogoditi ako funkciju transfer () nazovemo izravno ugovorom?

Apsolutno, ovu radnju bi čvor odbio, jer abi datoteka ne podržava tu funkciju, kao ni parametre podataka. Ali što se događa ako ga nazovemo putem inline funkcije ili promjenom koda čvora izravno prihvaćamo radnju poziva.

Odabrao sam jednostavan način - napišite jednostavan hack ugovor kako biste pozvali linijsku funkciju kao dolje:

Evo rezultata nakon što sam poticao akciju na sklapanje ugovora s lažnim parametrima podataka, tada bi hackcontract pozvao funkciju prijenosa da igra bet.

$ cleos push action hackcontract hack '["hackcontract", "10000000.0000 SYS", "50"]' -p hackcontract
$ cleos dobivaju stol eosbettest12 eosbettest12 activebets {
"redovi": [{
"id": "3931680559943168590",
"bettor": "hackcontract",
"preporuka": "eosbettest12",
"bet_amt": "100000000000",
"roll_under": 50,
"sjeme": "6799ccac87b63a34dcec107a860c2463b84b687ac5a8c88dca6970b58acf6bf1",
"bet_time": "2018-11-28T10: 10: 19"
}]}

Kao što vidite, nalog za klađenje već je na redu.

Rješenje za hack broj 1:

Da biste ispravili ovaj bug, samo dodajte jedan redak ispod koda. To znači da ugovor prihvaća samo funkciju prijenosa poziva iz eosio.token ugovora, drugi slučaj bi bio odbačen. Ili možete dodati ovu check in dispečersku funkciju.

Hak broj 2

Haker je iskoristio pogrešku u funkciji prijenosa otpreme. U ovoj funkciji ugovor dobiva pakirane podatke s eosio.token, ali nikad ne provjeravajte prijenos s / na. U osnovi, haker ima 2 računa A i hakerski ugovor B. A će token poslati B, B nadoknaditi ovu radnju i proslijediti na eosbet račun putem Requ_recipient (). EOSBet bi pogrešno shvatio da je ta radnja eosio.token i da bi je obradio.

Ovdje je detaljan kod:

Nakon transfer tokena u hackcontract, nalog za klađenje je već na redu.

$ cleos prijenos myaccount hackcontract "1234567.0000 SYS" "50" -p moj račun
$ cleos dobivaju stol eosbettest12 eosbettest12 activebets {
"redovi": [{
"id": "2817973050780582232",
"bettor": "moj račun",
"preporuka": "eosbettest12",
"bet_amt": "12345670000",
"roll_under": 50,
"sjeme": "e2a32f55658ebfa76a9d335abe532253326b86910b52e1b8c81f319c3d71ab73",
"bet_time": "2018-11-29T04: 15: 27"
}]}

Rješenje za hack broj 2:

Ne zaboravite provjeriti gdje je prijenos u dispečerskom transferu ().

Uobičajeni načini za sprječavanje hakiranja

Ažurirajte zadnju zakrpu za funkciju "primijeni"

Molimo pogledajte ovdje: https://medium.com/@eoscafeblock/contract-vulnerability-patch-57b948cacc3a

Koristite drugačije dopuštenje u ugovoru s Requ_auth2

Trenutno, DApp-ovi programeri obično koriste metodu Requ_auth () da bi dobili dopuštenje od pošiljatelja akcije. U slučaju da je za radnju potrebna_auth (samo), trebali biste pohraniti privatni ključ vlasnika ugovora na poslužitelj ako to želite učiniti automatski. Ali što ako se haker ukrao ovim privatnim ključem, to je apsolutno katastrofa ...

Da biste riješili taj problem, u ugovoru trebate odvojiti razinu dozvole.

Primjer: Dozvola je aktivna za važne radnje (skup ugovora, token za prijenos ...) i tu radnju treba izvoditi ručno. Kôd dozvole za radnje manje je važan, tako da je vjerojatnije da će se izvršiti automatski, tada možete na poslužitelj spremiti privatni ključ dopuštenog koda. Ako je netko ukrao ovaj ključ, nema se što izgubiti.

Provjerite ima li vaš ugovor zadržani način zamrzavanja ugovora kada primijeti bug

Cybersecurity je zaista velika stvar koju treba podnijeti, posebno za mladu tehnologiju kao blockchain. Iznad je sve moje objašnjenje i prijedlog za trenutačno pitanje hakiranja. Hvala vam na čitanju i sjetite se da uvijek primjećujete vašu Dapp-ovu cyber-sigurnost.

Autor bloga Quoc Le @ Lecle VietNam