Tento článek je příspěvek od komunity. Autorem je Minzhi He, auditor společnosti CertiK.
Názory vyjádřené v tomto článku jsou názory přispěvatele/autora a nemusí nutně odrážet názory Binance Academy.
souhrn
Blockchainové mosty jsou důležité pro dosažení interoperability v oblasti blockchainu. Proto je zabezpečení mostu velmi důležité. Některé běžné bezpečnostní slabiny mostů zahrnují slabé on-chain a off-chain ověřování, nesprávné zacházení s nativními tokeny a nesprávnou konfiguraci. Pro zajištění rozumné logiky ověření se doporučuje testovat most proti všem možným útočným vektorům.
Úvod
Bridge blockchain je protokol, který spojuje dva blockchainy a umožňuje mezi nimi interakci. Pokud vlastníte bitcoiny, ale chcete se podílet na aktivitách DeFi v síti Ethereum, blockchainové mosty vám to umožňují, aniž byste bitcoiny prodávali.
Blockchainové mosty jsou zásadní pro dosažení interoperability v oblasti blockchainu. Tento most funguje pomocí různých on-chain a off-chain validací, takže má různé bezpečnostní chyby.
Proč je zabezpečení mostu důležité?
Mosty obvykle ukládají tokeny, které chtějí uživatelé přenést z jednoho řetězce do druhého. Mosty jsou často implementovány jako inteligentní smlouvy a ukládají velké množství tokenů, jak se hromadí přenosy napříč řetězci, což z nich dělá lákavé cíle pro hackery.
Navíc blockchainové mosty mají velkou útočnou mezeru, protože zahrnují mnoho komponent. Zločinci jsou proto vysoce motivováni k tomu, aby se zaměřili na aplikace napříč řetězci, aby odčerpali velké množství finančních prostředků.
Bridge útoky způsobily ztráty ve výši více než 1,3 miliardy USD v roce 2022, což je podle odhadů CertiK 36 % celkových ztrát za daný rok.
Běžné bezpečnostní zranitelnosti mostů
Pro zlepšení zabezpečení mostů je důležité porozumět běžným bezpečnostním zranitelnostem mostů a testovacích mostů před spuštěním. Tyto zranitelnosti lze kategorizovat do čtyř oblastí.
Slabá validace v řetězci
U jednoduchých mostů, zejména těch navržených pro konkrétní DApps, je ověření v řetězci minimální. Most se spoléhá na centralizovaný backend pro provádění základních operací, jako je ražba, vypalování a přenos tokenů, zatímco veškeré ověřování probíhá mimo řetězec.
Naproti tomu jiné typy mostů používají inteligentní smlouvy k ověřování zpráv a provádění ověřování v řetězci. V této situaci, když uživatel vloží prostředky do řetězce, inteligentní smlouva vygeneruje podepsanou zprávu a vrátí podpis v transakci. Tento podpis slouží jako doklad o vkladu a slouží k ověření požadavků uživatelů na jiných řetězcích. Tento proces by měl zabránit různým bezpečnostním útokům, včetně útoků opakovaného přehrávání a falešných záznamů o vkladech.
Pokud však během procesu ověřování v řetězci existuje chyba zabezpečení, útočník by mohl způsobit vážné poškození. Pokud například most používá strom Merkle k ověření záznamů transakcí, útočník by mohl vytvořit falešné důkazy. To znamená, že mohou obejít ověření ověření a razit nové tokeny na svůj účet, pokud je proces ověřování zranitelný.
Některé mosty implementují koncept „zabaleného tokenu“. Když například uživatel převede DAI z Etherea do BNB Chain, jeho DAI se převezme ze smlouvy Ethereum a ekvivalentní množství zabaleného DAI se vydá do BNB Chain.
Pokud však tyto transakce nejsou řádně ověřeny, může útočník pomocí manipulace s jeho funkčností implementovat škodlivou smlouvu na směrování zabalených tokenů z mostu na nesprávnou adresu.
Útočník také vyžaduje, aby oběť souhlasila s překlenovací smlouvou, aby mohla převést tokeny pomocí funkce „transferFrom“ k odčerpání aktiv z překlenovací smlouvy.
Bohužel se to zhoršuje, protože většina mostů vyžaduje neomezené schválení tokenu od uživatelů DApp. Jedná se o běžnou praxi, která snižuje poplatky za plyn, ale přináší další riziko tím, že umožňuje chytrým smlouvám přístup k tokenům z neomezeného počtu uživatelských peněženek. Útočníci mohou využít nedostatek ověření a nadměrného schvalování k přenosu tokenů od jiných uživatelů k sobě.
Slabá mimořetězová validace
V některých přemosťovacích systémech hrají off-chain backend servery důležitou roli při ověřování platnosti zpráv odeslaných z blockchainu. V tomto případě se zaměřujeme na ověřování vkladových transakcí.
Způsob, jakým blockchain bridge funguje s off-chain validací, je následující:
Uživatelé interagují s DApp a vkládají tokeny do inteligentních smluv ve zdrojovém řetězci.
Poté DApp odešle hash transakce vkladu na backendový server prostřednictvím rozhraní API.
Hodnoty hash transakcí vyžadují určité ověření serverem. Pokud je to považováno za platné, podepisující zprávu podepíše a poté odešle podpis zpět do uživatelského rozhraní prostřednictvím rozhraní API.
Po obdržení podpisu jej DApp ověří a poté umožní uživateli stáhnout tokeny z cílového řetězce.
Backendový server musí zajistit, že zpracovaná vkladová transakce skutečně proběhla a nebyla zfalšována. Tento back-end server určuje, zda uživatelé mohou stáhnout tokeny v cílovém řetězci, což z něj činí vysoce hodnotný cíl pro útočníky.
Backendový server musí ověřit strukturu události vyplývající z transakce a také adresu smlouvy, která událost vygenerovala. Pokud je adresa smlouvy ignorována, může útočník implementovat zákeřnou smlouvu k předstírání události vkladu pomocí stejné struktury jako legitimní událost vkladu.
Pokud neověří adresu, která událost vygenerovala, může backend server předpokládat, že tato smlouva je platná, a zprávu podepíše. Poté může útočník poslat transakční hash do backendu, čímž obejde ověření a umožní mu stáhnout tokeny z cílového řetězce.
Nesprávné zacházení s nativními tokeny
Bridge využívá různé přístupy ke zpracování nativních tokenů a pomocných tokenů. Například v síti Ethereum je nativním tokenem ETH a většina pomocných tokenů se řídí standardem ERC-20.
Když uživatel zamýšlí převést své ETH do jiného řetězce, musí je nejprve vložit do překlenovací smlouvy. Aby toho uživatelé dosáhli, jednoduše připojí ETH k transakci a množství ETH pak lze získat přečtením pole „msg.value“ transakce.
Vkládání ERC-20 tokenů je velmi odlišné od vkládání ETH. Aby uživatelé mohli vložit tokeny ERC-20, musí nejprve umožnit překlenovací smlouvě používat jejich tokeny. Jakmile souhlasí a vloží tokeny do smlouvy o přemostění, smlouva buď spálí tokeny uživatele pomocí funkce „burnFrom()“, nebo převede tokeny uživatele do smlouvy pomocí funkce „transferFrom()“.
Jedním z přístupů k jejich odlišení je použití příkazů if-else v rámci stejné funkce. Dalším přístupem je vytvoření dvou samostatných funkcí pro zpracování každého scénáře. Pokus o vklad ETH pomocí funkce vkladu ERC-20 může vést ke ztrátě finančních prostředků.
Při zpracování požadavku na vklad ERC-20 uživatelé obvykle poskytují adresu tokenu jako vstup do funkce vkladu. Tato akce představuje značné riziko, protože během transakcí může docházet k nedůvěryhodným externím hovorům. Běžnou praxí minimalizace rizika je implementace whitelistu, který obsahuje pouze tokeny podporované mostem. Jako argumenty mohou být předány pouze adresy ze seznamu povolených. Tím se zabrání externím voláním, protože projektový tým již filtruje adresy tokenů.
Problémy však také nastávají, když most zpracovává cross-chain přenosy nativních tokenů, protože nativní tokeny nemají adresy. Adresa nula (0x000...0) představuje původní token. To může být problematické, protože předání prázdné adresy funkci může obejít ověření whitelistu, i když je implementováno nesprávně.
Když překlenovací smlouva zavolá „transferFrom“ k převedení uživatelských aktiv do smlouvy, externí volání adresy nula vrátí hodnotu false, protože na adrese nula není implementována žádná funkce „transferFrom“. K transakcím však stále může dojít, pokud kontrakt nedokáže správně zpracovat výslednou hodnotu. To vytváří příležitost pro útočníky provádět transakce bez převodu tokenů do smlouvy.
Chyba konfigurace
Ve většině blockchainových mostů je privilegovaná pozice zodpovědná za whitelisting nebo blacklisting tokenů a adres, přiřazení nebo změnu signatářů a další důležité konfigurace. Zajištění přesnosti všech konfigurací je zásadní, protože i zdánlivě triviální chyby mohou způsobit velké ztráty.
Ve skutečnosti se v jednom incidentu útočníkovi podařilo obejít ověření záznamu o přenosu kvůli chybě konfigurace. Projektový tým implementoval upgrade protokolu několik dní před hackem, který zahrnoval změnu proměnné. Proměnná se používá k reprezentaci výchozí hodnoty důvěryhodných zpráv. Tato změna způsobí, že všechny zprávy budou automaticky považovány za ověřené, což útočníkům umožní posílat zprávy podle libosti a obejít proces ověření.
Jak zlepšit zabezpečení mostu
Čtyři běžné zranitelnosti mostů popsané výše demonstrují výzvy při zajišťování bezpečnosti v propojeném blockchainovém ekosystému. Existují významné úvahy týkající se řešení každé z těchto zranitelností. Neexistuje jediný návod, který by se vztahoval na všechno.
Je například obtížné poskytnout obecné pokyny k zajištění bezchybného procesu ověřování, protože každý most má jedinečné požadavky na ověření. Nejúčinnějším přístupem, jak zabránit ověřovacímu bypassu, je důkladně otestovat most proti všem možným útočným vektorům a zajistit, aby ověřovací logika dávala smysl.
Stručně řečeno, je důležité provádět přísné testování potenciálních útoků a věnovat zvláštní pozornost běžným bezpečnostním zranitelnostem v mostech.
Zavírání
Mosty se zkříženými řetězy byly pro svou vysokou hodnotu dlouho cílem útočníků. Stavitelé mohou posílit zabezpečení mostů provedením důkladného testování před implementací a prováděním auditů třetích stran, aby snížili riziko nákladných hacků, které mosty sužovaly v posledních několika letech. Mosty jsou nezbytné ve světě s mnoha řetězci, ale bezpečnost musí být primárním zájmem při navrhování a budování efektivní infrastruktury Web3.
Další čtení
Co je Bridge Blockchain?
Co je meziřetězová interoperabilita?
Tři oblíbené krypto mosty a jak fungují
Co jsou to zabalené tokeny?
Zřeknutí se odpovědnosti a varování před rizikem: Tento obsah je vám prezentován „tak, jak je“, pouze pro obecné informace a vzdělávací účely bez zastoupení nebo záruky jakéhokoli druhu. Tento obsah by neměl být vykládán jako finanční, právní nebo jiné odborné poradenství ani není určen k doporučení nákupu jakéhokoli konkrétního produktu nebo služby. Měli byste vyhledat radu od příslušných profesionálních poradců. Pokud je článek příspěvkem přispěvatele třetí strany, vezměte prosím na vědomí, že vyjádřené názory jsou názory přispěvatele třetí strany a nemusí nutně odrážet názory Binance Academy. Pro další podrobnosti si prosím přečtěte naše úplné prohlášení o vyloučení odpovědnosti zde. Ceny digitálních aktiv mohou být kolísavé. Hodnota vaší investice může klesat nebo stoupat. Investovaná částka se vám nemusí vrátit. Jste plně odpovědní za svá investiční rozhodnutí. Binance Academy nenese odpovědnost za žádné ztráty, které můžete utrpět. Tento materiál by neměl být považován za finanční, právní nebo jiné odborné poradenství. Pro více informací si přečtěte naše Podmínky použití a Upozornění na rizika.