Ez a tanfolyam csak Pro tagjaink számára elérhető
Bevezetés
A blokklánchíd két blokkláncot összekötő protokoll, amely lehetővé teszi köztük az interakciót. Ha Ön bitcoinnal rendelkezik, de szeretne részt venni az Ethereum hálózaton zajló DeFi-tevékenységben, akkor egy blokklánchíd lehetővé teszi ezt anélkül, hogy el kellene adnia a bitcoinját.
A blokklánchidak alapvető fontosságúak a blokklánc téren belüli átjárhatóság eléréséhez. Különböző on-chain és off-chain validálást használnak a működésükhöz, ezért különböző biztonsági problémákkal, sebezhető pontokkal bírnak.
Miért bír kritikus jelentőséggel a hídbiztonság?
Általában a híd tárolja azt a tokent, amelyet a felhasználó az egyik láncról a másikra szeretne továbbítani. A gyakran okosszerződések formájában megjelenő hidak a keresztláncú továbbítások felhalmozódásával jelentős mennyiségű tokent tárolhatnak, ezért a hekkerek számára jövedelmező célpontot jelentenek.
Emellett a blokklánchidak a sok komponensüknek köszönhetően nagy támadási felületet adnak. Ez pedig jelentős motivációt jelent a rosszindulatú szereplők számára, hogy a keresztláncú alkalmazásokat támadva nagy mennyiségű pénzeszközt szivárogtassanak el a rendszerből.
A hidak elleni támadások a CertiK becslése szerint 2022-ben több mint 1,3 milliárd USD veszteséget okoztak, az éves veszteség 36%-át.
A hidak gyakran előforduló biztonsági problémái, sebezhetőségei
A hidak biztonságának fokozásához érdemes megismerni a hidak gyakori biztonsági problémáit, sebezhető pontjait, továbbá tesztelni a hidakat az elindításuk előtt. Ezeket a sebezhetőségeket a következő négy területhez sorolhatjuk.
Gyenge on-chain validálás
Az egyszerű hidak – különösen a konkrét DAppokhoz tervezett hidak – esetén az on-chain validálást a minimumra szorítják. Ezek a hidak centralizált háttérre építve hajtják végre az alapvető műveleteket – pl. mintelés, égetés és tokenátutalások –, míg a jóváhagyásokat/hitelesítéseket teljes egészében off-chain módon végzik.
Ezzel ellentétben más típusú hidak okosszerződéseket használnak az üzenetek validálásához, és on-chain végzik a jóváhagyást/hitelesítést. Ebben az esetben amikor egy felhasználó pénzeszközöket helyez letétbe az egyik láncon, az okosszerződés egy aláírt üzenetet generál, és az aláírást visszavezeti a tranzakcióba. Ez az aláírás szolgál letéti bizonyítékként, és ezt használja a rendszer a felhasználó kiutalási kérelmének jóváhagyásához a másik láncon. Ez a folyamat hivatott a különböző támadások megelőzésére, ideértve a visszajátszásos (replay) és a hamisított letéti adatok (forged deposit records) típusú támadásokat is.
Ugyanakkor ha az on-chain validálási folyamat során alakul ki sebezhetőség, akkor a támadó jelentős károkat okozhat. Például, ha egy híd a Merkle-fa segítségével validálja a tranzakció-nyilvántartást, akkor a támadó hamis bizonyítékokat generálhat. Ez azt jelenti, hogy ha a validálási folyamat sebezhető, akkor megkerülhetik a bizonyítékvalidálást és új tokeneket mintelhetnek a számlájukra,.
Egyes hidak a „wrapped token.” (becsomagolt token) koncepciót alkalmazzák. Például, amikor egy felhasználó DAI-t küld az Ethereum ról a BNB Chainre, akkor a híd DAI-t vesz ki az Ethereum szerződésből, és azonos mennyiségű wrapped DAI-t bocsát ki a BNB Chain blokkláncon.
Ugyanakkor, ha a tranzakció validálása nem megfelelő, akkor egy támadó egy rosszindulatú szerződéssel manipulálva ezt a funkciót helytelen címre irányíthatja át a becsomagolt tokeneket a hídról.
A pénzeszközök elszivárogtatásához a támadóknak emellett szükségük van arra is, hogy az áldozatok a „transferFrom” függvénnyel jóváhagyják a hídszerződést a tokenek továbbításához.
Sajnos a helyzetet tovább rontja, hogy sok híd végtelen tokenjóváhagyást követel meg a DApp-felhasználóktól. Ez a bevett gyakorlat csökkenti a gas díjakat, de extra kockázatot generálva lehetővé teszi, hogy egy okosszerződés végtelen számú tokenhez hozzáférjen a felhasználó tárcájában. A támadók a validálási rést és a túlzott jóváhagyást kihasználva képesek más felhasználóktól magukhoz továbbítani a tokeneket.
Gyenge off-chain validálás
Néhány hídrendszerben az off-chain háttérkiszolgáló kritikus szerepet tölt be a blokkláncról küldött üzenetek legitimitásának igazolásában. Ebben az esetben a letéti tranzakciók hitelesítésére összpontosítunk.
Egy off-chain validálással működő blokklánchíd az alábbiak szerint működik:
- A felhasználók a DApp felhasználásával tokeneket helyeznek letétbe a forrásláncon létrehozott okosszerződésben.
- A DApp ezután egy API-n keresztül elküldi a letéti tranzakció hash-kódját a háttérkiszolgálónak.
- A tranzakcióhash-t a kiszolgáló többször is validálja. Ha legitimnek találja, akkor egy aláíró aláírja az üzenetet, és az API-n keresztül visszaküldi az aláírást a felhasználói felületre.
- Az aláírás beérkezésekor a DApp hitelesíti azt, és engedélyezi, hogy a felhasználó a rendeltetési blokkláncon lehívja a tokenjeit.
A háttérkiszolgálónak meg kell győződnie arról, hogy az általa feldolgozott letéti tranzakció valóban megtörtént-e, és nem csak hamisítvány. Ez a háttérkiszolgáló határozza meg, hogy a felhasználó lehívhatja-e a tokeneket a rendeltetési blokkláncon, éppen ezért a támadók szemében értékes célpontot képvisel.
A háttérkiszolgálónak validálnia kell a tranzakció által létrehozott esemény struktúráját, valamint az eseményt létrehozó szerződéscímet. Ha ez utóbbit elhanyagolja, akkor a támadó egy rosszindulatú szerződéssel hamisíthat egy letéti eseményt, amelynek struktúrája megegyezik a legitim letéti esemény struktúrájával.
Ha a háttérkiszolgáló nem hitelesíti az eseményt létrehozó címet, akkor ezt érvényes tranzakciónak tekinti és aláírja az üzenetet. A támadó ezután elküldheti a tranzakcióhash-t a háttérkiszolgálónak, megkerülve a hitelesítést, és lehetővé téve, hogy a rendeltetési blokkláncon lehívja a tokeneket.
Natív tokenek helytelen kezelése
A hidak a natív tokenek és a hasznossági tokenek kezelése során eltérő megközelítést alkalmaznak. Például, az Ethereum hálózatán a natív token az ETH, és a legtöbb hasznossági token az ERC-20 szabványt követi.
Ha egy felhasználó ETH-et szeretne egy másik láncra átutalni, akkor először letétbe kell azt helyeznie a híd szerződésében. Ehhez a felhasználónak csak csatolnia kell az ETH-et a tranzakcióhoz, és az ETH-összeg kinyerhető a tranzakció „msg.value” mezőjének leolvasásával.
Az ERC-20 tokenek letétbe helyezése jelentősen eltér az ETH-letét elhelyezésétől. Egy ERC-20 token letétbe helyezéséhez a felhasználónak engedélyeznie kell, hogy a hídszerződés elköltse a tokenjeit. Ennek engedélyezése és a tokenletét hídszerződésben való elhelyezése után a szerződés vagy elégeti a felhasználó tokenjeit a „burnFrom()” függvénnyel, vagy átutalja a felhasználó tokenjeit a szerződésre a „transferFrom()” függvénnyel.
Ennek eldöntésére az egyik megközelítés egy if-else (ha, különben) állítást alkalmaz ugyanazon a függvényen belül. Egy másik megközelítés két külön függvényt hoz létre a két forgatókönyv kezeléséhez. Ha valaki az ERC-20 letétbe helyezési függvénnyel próbál meg ETH-et letétben helyezni, az a pénzeszközök elvesztését eredményezheti.
Az ERC-20 letétbe helyezési kérelmek kezelésekor a felhasználók a letétbe helyezési függvény bemeneti adataként általában megadják a tokencímet. Ez jelentős kockázattal jár, mivel a tranzakció során nem megbízható külső hívások történhetnek. A kizárólag a híd által támogatott tokeneket tartalmazó fehérlista alkalmazása gyakori módszer a kockázat minimalizálására. Csak a fehérlistán szereplő címeket lehet argumentumként alkalmazni. Ez megakadályozza a külső hívásokat, mivel a projektcsapat már megszűrte a tokencímeket.
Mindazonáltal akkor is merülhetnek fel problémák, amikor a hidak natív tokenek keresztláncú utalását kezelik, mivel a natív tokennek nincs címe. A natív tokent nullás címmel (0x000…0) lehet jelölni. Ez problémás lehet, mivel ha nullás címet küldünk a függvénynek, azzal elkerülhető a fehérlistás jóváhagyás, még akkor is, ha egyébként mindent helyesen teszünk.
Amikor a hídszerződés a „transferFrom” segítségével utalja át a felhasználó eszközeit a szerződésre, akkor a nullás címet érintő külső hívás hamis értéket ad vissza, mivel a nullás cím nem tartalmaz „transferFrom” függvényt. Ugyanakkor a tranzakció továbbra is bekövetkezhet, ha a szerződés helytelenül kezeli a visszaadott értéket. Ez lehetőséget ad a támadóknak a tranzakció végrehajtására anélkül, hogy tokent utalnának át a szerződésre.
Hibás beállítások
A legtöbb blokklánchíd esetén egy kiemelt szerepkör felel a tokenek és címek fehér- és feketelistázásáért, az aláírók kijelöléséért vagy módosításáért, továbbá egyéb kritikus beállítások konfigurálásáért. Kulcsfontosságú, hogy az összes konfiguráció pontos legyen, mivel még a látszólag triviális tévedések is jelentős veszteségekhez vezethetnek.
Bizony, volt olyan eset, ahol a támadó egy hibás beállítás miatt sikeresen megkerülte az átutalási adatok hitelesítését. A projektcsapat a hekkertámadás előtt néhány nappal protokollfrissítést hajtott végre, amely során egy változót is módosítottak. A változó képviselte a megbízható üzenet alapértelmezett értékét. A változtatás azt eredményezte, hogy a rendszer minden üzenetet automatikusan hitelesítettnek tekintett, így a támadó tetszőleges üzeneteket elküldve mehetett át a hitelesítési folyamaton.
A hídbiztonság fokozása
A fent leírt négy gyakori hídbiztonsági rés érezteti azokat a kihívásokat, amelyeket egy kapcsolatokkal átszőtt blokklánc-ökoszisztéma védelme jelent. Minden egyes felsorolt sebezhetőség kezelése jelentős megfontolásokat igényel, és nincs olyan forgatókönyv, amely mind a négyet kezelné.
Például a hibamentes jóváhagyási/hitelesítési folyamatot biztosító általános iránymutatás kiadása nagy kihívás, mivel minden híd egyedi jóváhagyási/hitelesítési követelményeket alkalmaz. A jóváhagyás/hitelesítés elkerülését úgy lehet a leghatékonyabban megakadályozni, hogy alapos tesztelésnek vetjük alá a hidat az összes lehetséges támadási vektorral szemben, biztosítva, hogy a jóváhagyási/hitelesítési logika szilárd alapokon áll.
Összefoglalva, alapvető fontosságú a potenciális támadások elleni szigorú tesztelés és különös elővigyázatosság a hidak leggyakoribb biztonsági réseivel kapcsolatban.
Záró gondolatok
A nagy érték miatt a keresztláncú hidak már régóta a támadók célkeresztjében vannak. A fejlesztők az éles üzem előtti alapos teszteléssel és harmadik felek által lefolytatott auditokkal erősíthetik a létrehozott hidak védelmét, csökkentve az elsöprő erejű hekkertámadások kockázatát, amelyek az utóbbi néhány évben a hidakat sújtották. Egy többláncú világban a hidak kritikus jelentőséggel bírnak, de a hatékony Web3 infrastruktúra tervezése és megépítése során a biztonságot kiemelten kell kezelni.
