Tento článek je příspěvek komunity. Autorem je Minzhi He, auditor společnosti CertiK.
Pohledy v tomto článku pocházejí od přispěvatele/autora a nemusí nutně odrážet pohledy Binance Academy.
TL;DR
Blockchainové mosty jsou rozhodující pro dosažení interoperability v blockchainovém prostoru. Proto je zabezpečení mostů prvořadé. Některé běžné chyby zabezpečení mostu zahrnují slabé ověřování v řetězci a mimo něj, nesprávné zacházení s nativními tokeny a nesprávné konfigurace. Doporučuje se testovat most proti všem možným útočným vektorům, aby byla zajištěna správná logika ověření.
Úvod
Blockchain bridge je protokol spojující dva blockchainy a umožňuje mezi nimi interakce. Pokud vlastníte bitcoin, ale chcete se podílet na aktivitě DeFi v síti Ethereum, blockchainový most vám to umožní, aniž byste svůj bitcoin prodali.
Blockchainové mosty jsou zásadní pro dosažení interoperability v rámci blockchainového prostoru. Fungují pomocí různých on-chain a off-chain validací, a proto mají různé bezpečnostní zranitelnosti.
Proč je zabezpečení mostu kritické?
Most obvykle obsahuje token, který chce uživatel přenést z jednoho řetězce do druhého. Mosty, které se často nasazují jako inteligentní smlouvy, drží značné množství tokenů, protože se hromadí převody napříč řetězci, což z nich dělá lukrativní cíle pro hackery.
Kromě toho mají blockchainové mosty velkou útočnou plochu, protože zahrnují mnoho komponent. S ohledem na to jsou zákeřní aktéři vysoce motivováni k tomu, aby se zaměřili na aplikace napříč řetězci, aby odčerpali velké částky finančních prostředků.
Mostní útoky vedly v roce 2022 ke ztrátám přes 1,3 miliardy USD, což podle odhadů společnosti CertiK představuje 36 % celkových ročních ztrát.
Běžné chyby zabezpečení mostu
Pro zvýšení bezpečnosti mostů je cenné porozumět běžným bezpečnostním zranitelnostem mostů a otestovat je před spuštěním. Tyto chyby zabezpečení lze kategorizovat do následujících čtyř oblastí.
Slabá validace v řetězci
U jednoduchých mostů, zejména těch navržených pro konkrétní DApps, je ověřování v řetězci omezeno na minimum. Tyto mosty se spoléhají na centralizovaný backend k provádění základních operací, jako je ražba, vypalování a přenosy tokenů, zatímco všechna ověřování se provádějí 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 tomto scénáři, 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í žádosti uživatele o výběr na druhém řetězci. Tento proces by měl být schopen zabránit různým bezpečnostním útokům, včetně útoků opakovaného přehrávání a padělaných záznamů o vkladech.
Pokud se však během procesu ověřování v řetězci vyskytne chyba zabezpečení, může útočník způsobit vážné poškození. Pokud například most používá strom Merkle k ověření záznamu transakce, útočník může generovat padělané důkazy. To znamená, že mohou obejít ověření ověření a razit nové tokeny na svůj účet, pokud je proces ověření zranitelný.
Některé mosty implementují koncept „zabalených žetonů“. Když například uživatel převede DAI z Etherea do řetězce BNB, jeho DAI se převezme ze smlouvy Ethereum a na řetězec BNB se vydá ekvivalentní množství zabaleného DAI.
Pokud však tato transakce není řádně ověřena, útočník by mohl manipulací s funkcí nasadit škodlivý kontrakt, který by směroval zabalené tokeny z mostu na nesprávnou adresu.
Útočníci také potřebují, aby oběti schválily smlouvu o přemostění k převodu tokenů pomocí funkce „transferFrom“ k odčerpání aktiv z překlenovací smlouvy.
Bohužel je to ještě horší, protože mnoho mostů vyžaduje od uživatelů DApp nekonečné schválení tokenu. Jedná se o běžnou praxi, která snižuje poplatky za plyn, ale vytváří další rizika tím, že umožňuje inteligentní smlouvě přístup k neomezenému počtu tokenů z peněženky uživatele. Útočníci jsou schopni 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 hraje off-chain backend server zásadní roli při ověřování legitimity zpráv odeslaných z blockchainu. V tomto případě se zaměřujeme na ověřování vkladových transakcí.
Blockchain bridge s off-chain validací funguje následovně:
Uživatelé interagují s DApp a vkládají tokeny do inteligentní smlouvy ve zdrojovém řetězci.
DApp poté odešle hash vkladové transakce na backendový server prostřednictvím rozhraní API.
Transakční hash podléhá několika ověřením ze strany serveru. Pokud je to považováno za legitimní, podepisující podepíše zprávu a odešle podpis zpět do uživatelského rozhraní prostřednictvím rozhraní API.
Po obdržení podpisu jej DApp ověří a umožní uživateli stáhnout své tokeny ze zdrojového řetězce.
Server typu back-end musí zajistit, že transakce vkladu, kterou zpracovává, skutečně proběhla a nebyla zfalšována. Tento back-end server určuje, zda uživatel může stáhnout tokeny v cílovém řetězci, a je proto pro útočníky vysoce hodnotným cílem.
Backendový server potřebuje ověřit strukturu události emitované transakce a také adresu smlouvy, která událost vyslala. Pokud je druhá možnost zanedbána, útočník by mohl nasadit škodlivou smlouvu k vytvoření události vkladu se stejnou strukturou jako legitimní událost vkladu.
Pokud backend server neověří, která adresa událost vyslala, bude to považovat za platnou transakci a zprávu podepíše. Útočník by pak mohl poslat transakční hash do backendu, obejít ověření a umožnit mu stáhnout tokeny z cílového řetězce.
Nesprávné zacházení s nativními tokeny
Bridges používají 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ů dodržuje standard 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 bylo dosaženo, uživatel jednoduše připojí ETH k transakci a množství ETH lze získat přečtením pole „msg.value“ transakce.
Vkládání tokenů ERC-20 se výrazně liší od vkládání ETH. Pro vložení tokenu ERC-20 musí uživatel nejprve umožnit překlenovací smlouvě utratit své tokeny. Poté, co to schválí a vloží tokeny do překlenovací smlouvy, smlouva buď spálí tokeny uživatele pomocí funkce „burnFrom()“, nebo převede token uživatele do smlouvy pomocí funkce „transferFrom()“.
Jedním z přístupů, jak to odlišit, je použití příkazu 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ě těchto prostředků.
Při zpracování požadavků na vklad ERC-20 uživatelé obvykle poskytují adresu tokenu jako vstup do funkce vkladu. To představuje značné riziko, protože během transakce může docházet k nedůvěryhodným externím hovorům. Implementace whitelistu, který obsahuje pouze tokeny podporované mostem, je běžnou praxí pro minimalizaci rizika. 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ž filtroval adresu tokenu.
Problémy však mohou také nastat, když mosty zpracovávají přenos mezi řetězci nativního tokenu, protože nativní token nemá adresu. Nulová adresa (0x000...0) je představitelem nativního tokenu. To může být problematické, protože předání nulové 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í na nulovou adresu vrátí false, protože v nulové adrese není implementována žádná funkce „transferFrom“. K transakci však přesto může dojít, pokud smlouva nezpracovává vrácenou hodnotu odpovídajícím způsobem. To vytváří příležitost pro útočníky provést transakci bez převodu jakýchkoli tokenů do smlouvy.
Špatné konfigurace
Ve většině blockchainových mostů je privilegovaná role zodpovědná za whitelisting nebo blacklisting tokenů a adres, přiřazení nebo změnu signatářů a další kritické konfigurace. Zajištění přesnosti všech konfigurací je zásadní, protože i zdánlivě triviální přehlédnutí může vést ke značným ztrátám.
Ve skutečnosti došlo k incidentu, kdy útočník úspěšně obešel ověření záznamu o přenosu kvůli špatné konfiguraci. Projektový tým implementoval upgrade protokolu několik dní před hackem, který zahrnoval změnu proměnné. Proměnná byla použita k reprezentaci výchozí hodnoty důvěryhodné zprávy. Tato změna vedla k tomu, že všechny zprávy byly automaticky považovány za prokázané, což útočníkovi umožnilo odeslat libovolnou zprávu a projít procesem ověření.
Jak zlepšit zabezpečení mostu
Čtyři běžné zranitelnosti mostů vysvětlené výše demonstrují výzvy k zajištění bezpečnosti v propojeném blockchainovém ekosystému. Pro zvládnutí každé z těchto zranitelností jsou důležité úvahy a žádná samostatná příručka se nevztahuje na všechny z nich.
Například poskytnutí obecných pokynů pro zajištění bezchybného procesu ověřování je náročné, protože každý most má jedinečné požadavky na ověření. Nejúčinnějším způsobem, 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 byla ověřovací logika správná.
Abychom to shrnuli, je nezbytné provádět přísné testování proti potenciálním útokům a věnovat zvláštní pozornost nejčastějším bezpečnostním zranitelnostem v mostech.
Závěrečné myšlenky
Mosty se zkříženými řetězy byly pro svou vysokou hodnotu dlouho cílem útočníků. Stavitelé mohou posílit zabezpečení svých mostů provedením důkladného testování před nasazením a zapojením se do auditů třetích stran, čímž se sníží riziko ničivých hacků, které mosty sužovaly v posledních několika letech. Mosty jsou kritické 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 Blockchain Bridge?
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 riziky: Tento obsah je vám prezentován „tak, jak je“, pouze pro obecné informace a vzdělávací účely, bez jakéhokoli zastoupení nebo záruky. Nemělo by být vykládáno jako finanční, právní nebo jiné odborné poradenství, ani není určeno k doporučení nákupu jakéhokoli konkrétního produktu nebo služby. Měli byste vyhledat vlastní radu od příslušných profesionálních poradců. V případě, že článek přispěl přispěvatelem třetí strany, vezměte prosím na vědomí, že vyjádřené názory patří přispěvateli 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 a investovaná částka se vám nemusí vrátit. Jste výhradně odpovědní za svá investiční rozhodnutí a Binance Academy nenese odpovědnost za jakékoli ztráty, které vám mohou vzniknout. Tento materiál by neměl být vykládán jako finanční, právní nebo jiné odborné poradenství. Další informace naleznete v našich podmínkách použití a varování před riziky.