Ez a cikk egy közösségi beadvány. A szerzője Minzhi He, a CertiK auditora.
A jelen cikkben kifejtett nézetek a beküldő/szerző nézetei, és nem feltétlenül tükrözik a Binance Academy álláspontját.
TL;DR
A blokklánchidak kritikus szerepet játszanak a blokklánctéren belüli átjárhatóság elérésében. Ezért a blokklánchidak (bridge-ek) biztonsága kiemelten fontos. A hidak gyakori biztonsági problémái közé sorolható a gyenge on-chain és off-chain validálás, a natív tokenek helytelen kezelése és rossz beállításai. Javasolt a hidak tesztelése az összes lehetséges támadási vektorral szemben, hogy biztosított legyen a megbízható jóváhagyási/hitelesítési logika.
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.
További olvasnivaló
Mi az a keresztláncú interoperabilitás?
Három népszerű kriptohíd és működésük
Mik azok a becsomagolt (wrapped) tokenek?
Felelősségi nyilatkozat és kockázati figyelmeztetés: A jelen bejegyzés tartalmát annak mindenkori formájában bocsátjuk rendelkezésre általános tájékoztatási és oktatási céllal, és semmilyen felelősséget vagy szavatosságot nem vállalunk az alkalmazásával kapcsolatban. Az itt leírtak nem tekintendők pénzügyi, jogi vagy egyéb szakmai tanácsadásnak, sem egy konkrét termék vagy szolgáltatás megvásárlására tett javaslatnak. Javasoljuk, hogy megfelelő szaktanácsadóktól kérjen tanácsot. Mivel a jelen cikket külső szerző írta, felhívjuk figyelmét, hogy az itt kifejtett nézőpontok a harmadik fél szerző álláspontját részletezik, és nem feltétlenül tükrözik a Binance Academy véleményét. Kérjük, hogy idekattintva olvassa el részletes felelősségi nyilatkozatunkat. A digitális eszközök ára erősen ingadozhat. A befektetés értéke csökkenhet vagy nőhet, és az is előfordulhat, hogy Ön nem kapja vissza a befektetett összeget. A befektetési döntéseiért egyedül Ön felel, és a Binance Academy nem vállal felelősséget az esetlegesen felmerülő veszteségekért. Az itt leírtak nem minősülnek pénzügyi, hogy vagy egyéb szakmai tanácsnak. További információért tekintse meg Felhasználási feltételeinket és a Kockázati figyelmeztetést.