Tento článek je příspěvkem komunity. Autorem je Minzhi He, auditor společnosti CertiK.

Názory v tomto článku jsou názory přispěvatele/autora a nemusí nutně odrážet názory Binance Academy.

souhrn

Blockchainové mosty jsou zásadní pro dosažení interoperability v rámci blockchainového prostoru. Vaše bezpečnost je proto nanejvýš důležitá. Některé z nejběžnějších chyb 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 otestovat most proti všem možným útočným vektorům, aby byla zajištěna robustní ověřovací logika.

Úvod

Blockchain bridge je protokol, který spojuje dva blockchainy a umožňuje mezi nimi interakce. Pokud máte bitcoiny, ale chcete se zúčastnit aktivity DeFi v síti Ethereum, blockchain bridge vám to umožní, aniž byste museli prodávat svůj bitcoin.

Blockchainové mosty jsou zásadní pro dosažení interoperability v rámci blockchainového prostoru. Pracují prostřednictvím různých on-chain a off-chain validací, takže představují různé bezpečnostní chyby.

Proč je bezpečnost mostů nezbytná?

Most obvykle podrží token, který chce uživatel přenést z jednoho řetězce do druhého. Mosty, které jsou často implementovány jako inteligentní smlouvy, drží značné množství tokenů, protože se hromadí přenosy napříč řetězci, což z nich dělá lukrativní cíle pro hackery.

Navíc blockchainové mosty mají velkou útočnou plochu, protože obsahují více komponent. S ohledem na to zlomyslní aktéři považují cross-chain aplikace za velmi dobré cíle pro krádeže velkého množství finančních prostředků.

V roce 2022 vygenerovaly útoky na mosty ztráty ve výši více než 1,3 miliardy dolarů, což podle odhadů společnosti CertiK představuje 36 % celkových ztrát za rok.

Běžné chyby zabezpečení mostu

Pro zlepšení zabezpečení mostů je cenné porozumět jejich nejčastějším zranitelnostem a otestovat je před jejich uvolněním. Tyto zranitelnosti lze rozdělit 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 při provádění základních operací, jako je ražba, vypalování a přenos tokenů, spoléhají na centralizovaný backend, 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 těchto případech, když uživatel vloží on-chain, inteligentní smlouva vygeneruje podepsanou zprávu a vrátí podpis v transakci. 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 typům bezpečnostních útoků, včetně replay útoků a falšování záznamů o vkladech.

Pokud však existuje chyba zabezpečení v procesu ověřování na řetězci, útočník může způsobit velké škody. Pokud například most používá strom Merkle k ověření protokolu transakcí, může útočník generovat padělané účtenky. To znamená, že pokud je proces ověřování zranitelný, útočník může obejít ověření účtenky a vyrazit nové tokeny pro váš účet.

Některé mosty implementují koncept „zabalených žetonů“. Například, když uživatel převede DAI z Etherea do BNB Chain, DAI se převezme ze smlouvy Ethereum a ekvivalentní množství zabaleného DAI se vydá na BNB Chain.

Pokud však transakce není správně ověřena, může útočník implementovat škodlivou smlouvu, která nasměruje zabalené tokeny z mostu na nesprávnou adresu.

Útočníci také potřebují, aby oběti schválily smlouvu o přemostění, aby mohly převést tokeny pomocí funkce „transferFrom“ a odčerpat tak aktiva z překlenovací smlouvy.

Bohužel je to ještě horší, protože mnoho mostů požaduje nekonečné schvalování tokenů od uživatelů DApps. Jedná se o běžnou praxi, která snižuje poplatky za plyn, ale vytváří další rizika tím, že chytré smlouvě umožňuje přístup k neomezenému počtu tokenů z peněženky uživatele. Útočníci mohou využívat 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. Tentokrát se zaměříme na ověřování vkladových transakcí.

Blockchain bridge s off-chain validací funguje následovně:

  1. Uživatelé interagují s DApp a vkládají tokeny do inteligentní smlouvy zdrojového řetězce.

  2. DApp poté odešle hash transakce vkladu na backendový server prostřednictvím rozhraní API.

  3. Transakční hash prochází několika ověřeními serverem. 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.

  4. Po obdržení podpisu jej DApp ověří a autorizuje uživatele stáhnout tokeny z cílového řetězce.

Server typu back-end musí zajistit, že transakce vkladu, kterou zpracovává, skutečně proběhla a že nejde o padělek. Tento backend server určuje, zda uživatel může stáhnout tokeny v cílovém řetězci, a je proto velmi vyhledávaným cílem útoku kyberzločinců.

Backendový server musí 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 zákeřnou smlouvu ke zfalšování události vkladu se stejnou strukturou, jako má událost legitimního vkladu.

Pokud backendový server neověří, která adresa událost vydala, mohl by to považovat za platnou transakci a zprávu podepsat. Útočník by pak mohl poslat transakční hash do backendu, obejít ověření a zvládnout odstranit 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.

Pokud se uživatel pokusí převést své ETH do jiného řetězce, musí je nejprve vložit do překlenovací smlouvy. Aby toho uživatel dosáhl, 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í ERC-20 tokenů je velmi odlišné od vkládání ETH. Pro vložení tokenu ERC-20 musí uživatel nejprve umožnit překlenovací smlouvě utratit své tokeny. Po schválení a uložení tokenů do překlenovací smlouvy smlouva spálí tokeny uživatele pomocí funkce "burnFrom()" nebo převede token uživatele do smlouvy pomocí funkce "transferFrom()".

Jedním ze způsobů, jak to odlišit, je použití podmíněného příkazu v rámci samotné funkce. Dalším způsobem je vytvořit dvě samostatné funkce pro zpracování každého scénáře. Pokus o vklad ETH pomocí funkce vkladu pro ERC-20 může vést ke ztrátě finančních 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 dojít k nespolehlivému externímu volání. Běžnou praxí minimalizace tohoto rizika je implementace whitelistu, který obsahuje pouze tokeny podporované mostem. Jako argument lze předat pouze adresy ze seznamu povolených. Tím se zabrání externím voláním, protože projektový tým již prozradil adresu tokenu.

Problémy však mohou nastat, když mosty zpracovávají přenos nativních tokenů napříč řetězcem, protože nativní token nemá adresu. Nulová adresa (0x000...0) představuje nativní token. To může být problematické, protože předání adresy nule funkci může obejít kontrolu whitelistu, i když je implementováno správně.

Když překlenovací smlouva zavolá "transferFrom" k převedení majetku uživatele do smlouvy, externí volání adresy nula vrátí hodnotu false, protože na adrese nula není implementována žádná funkce "transferFrom". K transakci však přesto může dojít, pokud smlouva s vrácenou hodnotou správně nezachází. 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ů má privilegovanou roli osoba odpovědná za whitelisting nebo blacklisting tokenů a adres, přiřazení nebo změnu signatářů a dalších kritických konfigurací. Zajištění přesnosti všech nastavení 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í protokolu přenosu kvůli nesprávné konfiguraci. Projektový tým implementoval aktualizaci protokolu několik dní před hackem a tato aktualizace zahrnovala změnu proměnné. Proměnná byla použita k reprezentaci výchozí hodnoty důvěryhodné zprávy. Tato změna způsobila, že všechny zprávy byly automaticky klasifikovány jako testované, což útočníkovi umožnilo odeslat libovolnou zprávu a projít procesem ověření.

Jak zlepšit bezpečnost mostů

Čtyři nejběžnější zranitelnosti mostů, které byly dosud vysvětleny, ukazují výzvy při zajišťování bezpečnosti v propojeném blockchainovém ekosystému. Při řešení každé z těchto zranitelností jsou důležité úvahy a neexistuje žádné snadné řešení, které by fungovalo pro všechny z nich.

Například poskytnutí obecných pokynů k zajištění bezchybného procesu ověřování je obtíž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 potenciálním vektorům útoku a zajistit, aby byla ověřovací logika robustní.

Stručně řečeno, je nezbytné důsledně testovat potenciální útoky a věnovat zvláštní pozornost nejčastějším bezpečnostním zranitelnostem mostů.

Závěry

Mosty s křížovým řetězem byly pro svou vysokou hodnotu dlouho terčem útoků. Vývojáři mohou posílit zabezpečení svých mostů prováděním rozsáhlého testování před nasazením a zapojením se do auditů třetích stran, čímž se sníží riziko opakování ničivých hacků, které mosty v posledních letech sužovaly. Mosty jsou pro svět více řetězců zásadní, ale při navrhování a budování efektivní infrastruktury Web3 musí být prioritou bezpečnost.

Další čtení

Co je blockchainový most?

Co je interoperabilita mezi řetězci?

Tři populární krypto mosty a jak fungují

Co jsou to zabalené tokeny?

Právní upozornění a varování před riziky: Tento obsah je prezentován „tak, jak je“ pouze pro obecné informace a vzdělávací účely, bez zastoupení nebo záruky jakéhokoli druhu. 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 individuální radu od vhodných profesionálních poradců. Vzhledem k tomu, že do tohoto článku přispěla třetí strana, 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 více informací si přečtěte naše úplné právní upozornění zde. Ceny digitálních aktiv mohou být kolísavé. Hodnota investice může klesat i stoupat a investovaná částka se vám nemusí vrátit. Pouze vy jste zodpovědní za svá investiční rozhodnutí. Binance Academy nezodpovídá za žádné 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.