Često pregledavam izvorni kod raznih blockchain projekata u kontekstu plaćenih revizija ali i kao hobi, i redovito nalazim velike sigurnosne propuste. U ovom ću članku opisati jednu ranjivost Lisk blockchaina na koju je njihov tim konačno odlučio upozoriti svoje korisnike, pa otkrivanje ove greške ne bi trebalo imati velike posljedice.

Ukratko: moguće je otuđiti neke Lisk račune i ukrasti sve njihove LSK tokene nakon samo 264 evaluacija funkcije za generiranje adresa (kombinacija SHA–256, SHA–512 i skalarnog množenja preko Ed25519 krivulje).

Što je Lisk?

Lisk je još jedna među mnogim platformama za izgradnju decentraliziranih aplikacija. Da pojednostavimo, Lisk je kao Ethereum samo što se u Lisku umjesto Vyperom ili Soliditijem pametni ugovori pišu JavaScriptom, dok je consenzus koji se koristi Proof of Stake umjesto Proof of Work. Preciznije, koristi se delegated proof of stake u kojem je podskup čvorova te mreže odabran od zajednice da budu validatori transakcija. Zbog ograničenog broja tih validatora (101) transakcije su veoma brze, a Lisk ostaje donekle decentraliziran.

U momentu pisanja ove analize, vrijednost Liska bila je tolika da je bio na 19. mjestu Coinmarketcap-a s ukupnom tržišnom vrijednosti od 3.4 milijarde dolara. Danas je to više nego 10 puta manje.

Prvi Problem: Kratke Adrese

Kao na svakoj platformi za kriptovalute, vlasnici novčića identificiraju se putem adresa. U Lisku su te adrese 64-bitne brojke, poput 3040783849904107057L. Dok je kod Bitcoina adresa samo hash nečijeg javnog ključa, adresa u Lisku se deterministički računa iz lozinke, istovremeno kreirajući par privatnog i javnog ključa tog korisnika. Detaljnije, to funkcionira ovako:

  1. Kada se funkciji dade lozinka, iz nje se generira 256-bitno sjeme: seed = SHA-256(passphrase).
  2. Iz tog se sjemena računa Ed25519 par ključeva koji uključuje računanje SHA–512(seed) i nakon toga skalarno množenje.
  3. Izračuna se SHA–256 hash javnog ključa i definira se adresa iz zadnjih 8 bajtova 32-bajtnog hasha.

Ako ste tehnički vješti u ovome, već primjećujete problem: moguće je naći pred-sliku bilo koje adrese u otprilike 264 evaluacija gornjeg ciklusa koraka.

Drugi Problem: Nepovezane adrese i ključevi

Kratke adrese u principu ne bi trebale biti problem: ako adresa već postoji i povezana je s nekim parom ključeva, ne biste smjeli biti u mogućnosti ukrasti račun nalaženjem još jedne kombinacije lozinke i ključa koji izvode tu istu adresu.

To je drugi problem. Adresa nije povezana s nekim parom ključeva do kad ne pošalje barem jednu transakciju nekom drugom računu, ili samom sebi. To znači da ako neki Lisk račun samo prima sredstva, a nikad ih ne šalje, taj račun može biti ukraden nalaženjem pred-slike te adrese. Jednom kada napadač ima pred-sliku, može je preuzeti od originalnog vlasnika tako da sa svojom novom kombinacijom lozinke i para ključeva pošalje transakciju, i time veže adresu na svoje podatke, zaključajući je za sve druge.

Ne znam koliko je računa ranjivo na ovaj način, no lako ih je naći: ako samo pregledate popis najbogatijih Lisk računa, vidjeti ćete ih više s višemilijunskim iznosima a da nemaju javni ključ asociran s tom adresom (N/A).

Napad i zaštita od napada

Izvršenje tih 264 operacija nije trenutačno; zbog funkcije generiranja ključeva, tih 264 operacija je znatno sporije od, recimo, 264 običnih evaluacija SHA–256 hash-a. No izvršenje ovog napada u roku od mjesec dana koštati će vas ispod $48 milijuna dolara.

Naravno, u stvarnom pokušaju paralelizirati ćete posao na N jezgri i ciljati ćete na jednu od M adresa, pa će time očekivano vrijeme izvršenja pasti na 263/NM operacija. Sa samo 64 meta i 256 jezgri, radi se o 249 ciklusa.

Lisk sada upozorava: “bitno je poslati točan javni ključ u Lisk mrežu, što možete učiniti slanjem i samo jedne transakcije s vašeg Lisk računa”.

Ne znam je li ova ranjivost upotrebljena za koji napad, no ovo ponovno pokazuje da je blockchain sigurnost kritično neistraženo područje s mnogo neprovjerenih arhitektura i izvornog koda, prepuno novih tipova grešaka koje samo čekaju da ih se otkrije.

PoC||GTFO

Uvjerio sam se da je napad uistinu moguć pronalaskom kolizije (dvije lozinke i dva para ključeva ukazuju na istu adresu), kreiranjem računa koristeći prvu lozinku, primanjem sredstava na taj račun, i krađom tog računa drugom kombinacijom lozinke i para ključeva. Simulirao sam i dobivanje pred-slike kako bih procjenio trošak takvog napada na mom računalu. Ukoliko sami želite isprobati navedeno, kod koji slijedi mogao bi biti od koristi (zajedno s optimiziranom implementacijom Ed25519 aritmetike):

To Nije Sve: Tajni Ključevi Nisu Tajni

Postoji još jedna ranjivost u Lisk ekosustavu. Ako pogledate njihovu API dokumentaciju primijetiti ćete da klijenti moraju poslati tajnu vrijednost – lozinku – da otvore račun ili pošalju transakciju. Drugim riječima, Lisku je promakla cijela poanta public-key kriptografije: držanje tajne polovice para “javni-tajni ključ” – tajnim. Uz to, postoji i otvorena krajnja točka u protokolu (/api/accounts/open) koja dozvoljava računanje javnog ključa iz poslanog privatnog. Toliko o povjerenju u sustav i decentralizaciji.

2 COMMENTS

  1. This is covered by sending at least one transaction after creating a wallet.
    This is old.

    • As this does not happen automatically, and some accounts in that list are still unsecured, it is by no means a solved problem.

LEAVE A REPLY

Please enter your comment!
Please enter your name here