Vilka är de vanligaste säkerhetsproblemen för broar?

Den här artikeln kommer från vårt community. Författaren är Minzhi He, en revisor på CerTiK.

Åsikterna i den här artikeln tillhör författaren och återspeglar inte nödvändigtvis Binance Academys åsikter.

TL;DR

Blockkedjebroar är kritiska för att uppnå interoperabilitet i blockkedjevärlden. Därför är brosäkerheten för blockkedjor väldigt viktigt. Några vanliga säkerhetsproblem med broar är bland annat svag validering på kedjan och utanför kedjan, felaktig hantering av inbyggda token och felkonfigurationer. Testa bron mot alla möjliga attackvektorer rekommenderas för att säkerställa god verifieringslogik.

Introduktion 

En blockkedjebro är ett protokoll som förbinder två blockkedjor för att möjliggöra interaktioner mellan dem. Om du äger bitcoin men vill delta i DeFi-aktivitet på Ethereum-nätverket gör en blockkedjebro att du kan göra detta utan att du behöver sälja dina bitcoin. 

Blockkedjebroar är grundläggande för att uppnå interoperabilitet i blockkedjevärlden. De fungerar med hjälp av olika valideringar på och utanför kedjan och har därför olika säkerhetsproblem.

Varför är brosäkerhet kritiskt? 

En bro innehåller vanligtvis den token som en användare vill överföra från en kedja till en annan. Broar distribueras ofta som smarta kontrakt och har en betydande mängd token när överföringarna för tvärkedjor ackumuleras, vilket gör dem till lukrativa mål för hackare. 

Dessutom har blockkedje-broar en stor attackyta eftersom de involverar många komponenter. Med det i åtanke är skadliga aktörer mycket motiverade att rikta in sig på tvärkedjeapplikationer för att tömma stora summor tillgångar. 

Under 2022 ledde bro-attacker till förluster på över 1,3 miljarder USD, vilket svarar för 36 % av årets totala förluster enligt CerTiks uppskattningar. 

Vanliga säkerhetsproblem med broar

För att förbättra broarnas säkerhet är det värdefullt att förstå vanliga säkerhetsproblem för broar och testa broarna före lanseringen. Dessa sårbarheter kan kategoriseras i följande fyra områden. 

Svag validering på kedjan

För enkla broar, särskilt de som är utformade för specifika DApps hålls validering på kedjan till ett minimum. Dessa broar förlitar sig på en centraliserad backend för att utföra grundläggande operationer som myntning, bränning och tokenöverföringar medan alla verifieringar utförs utanför kedjan.

I kontrast använder andra typer av broar smarta kontrakt för att validera meddelanden och utföra verifieringar i kedjan. I detta scenario, när en användare sätter in pengar i en kedja, genererar det smarta kontraktet ett signerat meddelande och returnerar signaturen i transaktionen. Denna signatur fungerar som bevis på insättningen och används för att verifiera användarens uttagsbegäran i den andra kedjan. Denna process bör kunna förhindra olika säkerhetsattacker, inklusive replayattacker och förfalskade insättningsregister. 

Men om det finns en sårbarhet under valideringsprocessen på kedjan kan angriparen orsaka allvarliga skador. Om en bro till exempel använder Merkle-träd för att validera transaktionsposten kan en angripare generera förfalskade bevis. Detta innebär att de kan kringgå bevisvalidering och mynta nya token till sitt konto om valideringsprocessen är sårbar.

Vissa broar implementerar begreppet ”inslagna token”. Till exempel, när en användare överför DAI från Ethereum till BNB Chain, tas deras DAI från Ethereum-kontraktet och motsvarande mängd förpackad DAI utfärdas i BNB-kedjan. 

Om den här transaktionen inte valideras korrekt kan en angripare distribuera ett skadligt kontrakt för att dirigera inslagna token från bron till en felaktig adress genom att manipulera funktionen. 

Angriparna behöver också offer för att godkänna broavtalet för att överföra token med funktionen ”transferFrom” för att tömma tillgångar från brokontraktet. 

Tyvärr förvärras detta eftersom många broar begär oändligt tokengodkännande från dApp-användare. Detta är en vanlig praxis som sänker gasavgifter, men skapar ytterligare risker genom att låta ett smart kontrakt få tillgång till ett obegränsat antal token från användarens plånbok. Angripare kan utnyttja bristen på validering och överdrivet godkännande för att överföra token från andra användare till sig själva.

Svag validering utanför kedjan

I vissa brosystem spelar backend-servern utanför kedjan en avgörande roll för att verifiera legitimiteten för meddelanden som skickas från blockkedjan. I det här fallet fokuserar vi på verifiering av insättningstransaktioner. 

En blockkedje-bro med validering utanför kedjan fungerar enligt följande: 

1. Användare interagerar med dApp för att sätta in token i det smarta kontraktet i källkedjan.

2. DApp skickar sedan insättningstransaktionens hash till backend-servern via ett API.

3. Transaktionshash är föremål för flera valideringar av servern. Om det anses legitimt signerar en undertecknare ett meddelande och skickar signaturen tillbaka till användargränssnittet via API:et.

4. Vid mottagandet av signaturen verifierar DApp den och tillåter användaren att dra tillbaka sina token från målkedjan.

Backend-servern måste se till att insättningstransaktionen den behandlar faktiskt har inträffat och inte har förfalskats. Denna backend-server avgör om en användare kan ta ut token i målkedjan och är därför ett högt värderat mål för angripare.

Backend-servern måste validera strukturen för transaktionens utsända händelse, liksom kontraktsadressen som avgav händelsen. Om den senare försummas kan en angripare distribuera ett skadligt kontrakt för att skapa en insättningshändelse med samma struktur som en legitim insättningshändelse. 

Om backend-servern inte verifierar vilken adress som avgav händelsen anser den att detta är en giltig transaktion och underteckna meddelandet. Angriparen kunde sedan skicka transaktionshash till backend, kringgå verifiering och låta dem dra tillbaka token från målkedjan.

Felaktig hantering av inbyggda token

Broar tar olika tillvägagångssätt för att hantera inbyggda token och nyttokrypto. Den inbyggda token på Etherum-nätverket är till exempel ETH och de flesta nyttokrypto följer ERC-20-standarden. 

När en användare avser att överföra sin ETH till en annan kedja måste de först sätta in det i brokontraktet. För att uppnå detta fäster användaren helt enkelt ETH till transaktionen och mängden ETH kan hämtas genom att läsa ”msg.value” -fältet av transaktionen.

Insättning av ERC-20-token skiljer sig avsevärt från att sätta in ETH. För att sätta in en ERC-20-token måste användaren först tillåta brokontraktet att spendera hens token. Efter att de har godkänt detta och satt in token i brokontraktet kommer kontraktet antingen att bränna användarens token med hjälp av" burnFrom()"-funktionen eller överföra användarens token till kontraktet med funktionen "TransferFrom()". 

Ett tillvägagångssätt för att skilja detta är att använda ett if-sats-uttalande inom samma funktion. Ett annat tillvägagångssätt är att skapa två separata funktioner för att hantera alla scenarier. Att försöka sätta in ETH med ERC-20-insättningsfunktionen kan leda till förlust av dessa tillgångar.

Vid hantering av ERC-20 insättningsförfrågningar anger användare vanligtvis tokenadressen som inmatning till insättningsfunktionen. Detta innebär en betydande risk eftersom opålitliga externa samtal kan inträffa under transaktionen. Att implementera en vitlista som endast innehåller token som stöds av bron är en vanlig praxis för att minimera risken. Endast vitlistade adresser får skickas som argument. Detta förhindrar externa samtal eftersom projektgruppen redan har filtrerat tokenadressen.

Problem kan dock också uppstå när broar hanterar överföring av inbyggd token på tvärkedja, eftersom inbyggda token inte har någon adress. En nolladress (0x000... 0) är representativ för denna inbyggda token. Detta kan vara problematiskt eftersom överföring av nolladressen till funktionen kan kringgå vitlistverifieringen även om den implementeras felaktigt. 

När brokontraktet använder ”TransferFrom” för att överföra användartillgångar till kontraktet, returnerar det externa samtalet till nolladressen falskt eftersom det inte finns någon ”TransferFrom” -funktion implementerad i nolladressen. Transaktionen kan dock fortfarande inträffa om kontraktet inte hanterar returvärdet på lämpligt sätt. Detta skapar en möjlighet för angripare att utföra transaktionen utan att överföra några token till kontraktet.

Felkonfigurering

I de flesta blockkedje-broar ansvarar en privilegierad roll för vitlistning eller svartlistning av token och adresser, tilldelning eller ändring av signerare och andra kritiska konfigurationer. Att se till att alla konfigurationer är korrekta är avgörande, eftersom även till synes triviala övervakningar kan leda till betydande förluster.

Faktum är att det har förekommit en incident där angriparen framgångsrikt kringgick verifieringen av en överföring på grund av en felkonfiguration. Projektgruppen genomförde en protokolluppgradering några dagar före hackningen, där bland annat en variabel ändrades. Variabeln användes för att representera standardvärdet för det betrodda meddelandet. Denna förändring resulterade i att alla meddelanden automatiskt ansågs ha bevisats, vilket gjorde det möjligt för en angripare att skicka ett godtyckligt meddelande och bli godkänd i verifieringsprocessen.

Förbättra brosäkerhet

De fyra vanliga brosårbarheterna som förklaras ovan visar utmaningarna för att säkerställa säkerhet i ett sammankopplat blockkedje-ekosystem. Det finns viktiga överväganden för att hantera var och en av dessa sårbarheter och inga instruktioner kan tillämpas på alla. 

Till exempel är det utmanande att tillhandahålla allmänna riktlinjer för att säkerställa en felfri verifieringsprocess eftersom varje bro har unika verifieringskrav. Det mest effektiva sättet att förhindra kringgående av verifiering är att noggrant testa bron mot alla möjliga attackvektorer och se till att verifieringslogiken är sund. 

Sammanfattningsvis är det viktigt att utföra rigorösa tester mot potentiella attacker och ägna särskild uppmärksamhet åt de vanligaste säkerhetsproblemen i broar.  

Sammanfattningsvis 

På grund av dess höga värde har tvärkedjebroar länge varit ett mål för angripare. Byggare kan stärka sina broars säkerhet genom att genomföra grundliga tester före distribution och delta i tredjepartsrevisioner, vilket minskar risken för de förödande hackarna som har plågat broar under de senaste åren. Broar måste finnas i en värld med flera kedjor, men säkerhet måste vara en primär prioritering vid utformandet och byggandet av en effektiv Web3-infrastruktur.

Mer information

Vad är en blockkedjebro?

Vad är tvärkedjeinteroperabilitet?

Tre populära kryptobroar – så här fungerar de

Vad är inslagna token?

Ansvarsfriskrivning och riskvarning: detta innehåll presenteras för dig ”i befintligt skick” och endast för allmän information och utbildningsändamål, utan representation eller garanti av något slag. Det ska inte tolkas som ekonomisk, juridisk eller annan professionell rådgivning. Det är inte heller avsett att rekommendera köp av någon specifik produkt eller tjänst. Du bör söka efter din egen rådgivning från lämpliga professionella rådgivare. I de fall då artikeln har skrivits av en tredje part, tillhör åsikterna som uttrycks denna tredje part och återspeglar inte nödvändigtvis Binance Academys åsikter. Läs vår fullständiga ansvarsfriskrivning här för mer information. Priserna på digitala tillgångar kan vara volatila. Värdet på din investering kan gå ner eller upp och du kanske inte får tillbaka det investerade beloppet. Du är själv ansvarig för dina investeringsbeslut och Binance Academy ansvarar inte för eventuella förluster som du kan ådra dig. Detta material ska inte tolkas som ekonomisk, juridisk eller annan professionell rådgivning. Se våra användarvillkor och riskvarning för mer information.