Denne artikel er et bidrag fra fællesskabet. Forfatteren er Minzhi He, revisor hos CertiK.
Synspunkterne i denne artikel tilhører bidragsyderen/forfatteren og afspejler ikke nødvendigvis Binance Academys synspunkter.
TL;DR
Blockchain-broer er afgørende for at opnå interoperabilitet i blockchain-området. Derfor er brosikkerhed af afgørende betydning. Nogle almindelige sikkerhedshuller i broer omfatter svag validering på og off-chain, ukorrekt håndtering af integrerede tokens og fejlkonfigurationer. Det anbefales at teste broen mod alle mulige angrebsvektorer for at sikre en sund verifikationslogik.
Introduktion
En blockchain-bro er en protokol, der forbinder to blockchains for at muliggøre interaktioner mellem dem. Hvis du ejer bitcoin, men ønsker at deltage i DeFi-aktiviteter på Ethereum-netværket, giver en blockchain-bro dig mulighed for at gøre det uden at sælge din bitcoin.
Blockchain-broer er grundlæggende for at opnå interoperabilitet inden for blockchain-rummet. De fungerer ved hjælp af forskellige valideringer på og off-chain og har derfor forskellige sikkerhedssårbarheder.
Hvorfor er brosikkerhed altafgørende?
En bro indeholder normalt det token, som en bruger ønsker at overføre fra én kæde til en anden. Broer er ofte implementeret som smart contracts og indeholder en betydelig mængde tokens, da overførslerne cross-chain akkumuleres, hvilket gør dem til lukrative mål for hackere.
Desuden har blockchain-broer en stor angrebsflade, da de involverer mange komponenter. Med dette i tankerne er ondsindede aktører meget motiverede til at målrette applikationer cross-chain for at få store summer af midlerne.
Broangreb førte til tab på over 1,3 milliarder USD i 2022, hvilket ifølge CertiK's estimater tegner sig for 36 % af årets samlede tab.
Almindelige sikkerhedssårbarheder i broer
For at forbedre broers sikkerhed er det værdifuldt at forstå almindelige sikkerhedshuller i broer og teste broerne for dem, før de lanceres. Disse sårbarheder kan inddeles i følgende fire områder.
Svag validering på kæden
For simple broer, især dem, der er designet til specifikke DApps, er valideringen på kæden begrænset til et minimum. Disse broer er afhængige af en centraliseret backend til at udføre grundlæggende operationer såsom prægning, brænding og tokenoverførsler, mens alle verifikationer udføres off-chain.
I modsætning hertil bruger andre typer broer smart contracts til at validere meddelelser og udføre verifikationer på kæden. I dette scenarie genererer en smart contract en signeret meddelelse og returnerer signaturen i transaktionen, når en bruger indsætter midler på en kæde. Denne signatur tjener som bevis for indsættelsen og bruges til at verificere brugerens anmodning om hævning på den anden kæde. Denne proces skal kunne forhindre forskellige sikkerhedsangreb, herunder replay-angreb og forfalskede indsættelsesregistre.
Men hvis der er en sårbarhed i forbindelse med valideringen på kæden, kan en angriber forårsage alvorlig skade. Hvis en bro f.eks. bruger Merkle-træet til at validere transaktionsregistreringen, kan en angriber generere forfalskede beviser. Det betyder, at denne kan omgå bevisvalideringen og præge nye tokens til sin konto, hvis valideringsprocessen er sårbar.
Visse broer implementerer konceptet "wrapped tokens" (indpakkede tokens). Når en bruger f.eks. overfører DAI fra Ethereum til BNB-kæden, bliver dennes DAI taget fra Ethereum-kontrakten, og et tilsvarende beløb af indpakket DAI udstedes på BNB-kæden.
Men hvis denne transaktion ikke er valideret korrekt, kan en angriber anvende en ondsindet kontrakt til at videresende de indpakkede tokens fra broen til en forkert adresse ved at manipulere funktionen.
Angriberne har også brug for, at ofrene skal godkende brokontrakten for at overføre tokens ved hjælp af funktionen "transferFrom" for at dræne aktiver fra brokontrakten.
Desværre forværres dette, fordi mange broer anmoder om uendelig token-godkendelse fra DApp-brugere. Dette er en almindelig praksis, der sænker gasgebyrerne, men skaber yderligere risici ved at give en smart contract adgang til et ubegrænset antal tokens fra brugerens wallet. Angribere kan udnytte den manglende validering og overdrevne godkendelse til at overføre tokens fra andre brugere til dem selv.
Svag validering off-chain
I nogle brosystemer spiller backend-serveren off-chain en afgørende rolle i forbindelse med verificering af legitimiteten af meddelelser, der sendes fra blockchainen. I dette tilfælde fokuserer vi på verificeringen af indsættelsestransaktioner.
En blockchain-bro med validering off-chain fungerer på følgende måde:
Brugerne interagerer med DApp'en for at indsætte tokens på en smart contract på kildekæden.
DApp'en indsender derefter indsættelsestransaktionens hash til backend-serveren via en API.
Transaktionens hash er genstand for flere valideringer af serveren. Hvis en underskriver anses for at være legitim, underskriver denne en meddelelse og sender signaturen tilbage til brugergrænsefladen via API'en.
Når signaturen modtages, verificerer DApp'en den og tillader brugeren at hæve sine tokens fra målkæden.
Backend-serveren skal sikre, at den indsættelsestransaktion, som den behandler, rent faktisk har fundet sted og ikke er forfalsket. Denne backend-server bestemmer, om en bruger kan hæve tokens på målkæden, og er derfor et værdifuldt mål for angribere.
Backend-serveren skal validere strukturen af transaktionens udsendte hændelse samt den kontraktadresse, der udsendte hændelsen. Hvis sidstnævnte ikke tages i betragtning, kan en angriber anvende en ondsindet kontrakt til at forfalske en indsættelseshændelse med samme struktur som en legitim indsættelseshændelse.
Hvis backend-serveren ikke kan verificere, hvilken adresse der har udsendt hændelsen, vil den betragte dette som en gyldig transaktion og underskrive meddelelsen. Angriberen kan derefter sende transaktionens hash til backend-serveren og dermed omgå verifikationen, så denne kan hæve tokens fra målkæden.
Ukorrekt håndtering af integrerede tokens
Broer anvender forskellige tilgange til håndtering af integrerede tokens og utility-tokens. På Ethereum-netværket er det integrerede token f.eks. ETH, og de fleste utility-tokens følger ERC-20-standarden.
Når en bruger har til hensigt at overføre sit ETH til en anden kæde, skal denne først indsætte det på brokontrakten. For at opnå dette skal brugeren blot knytte ETH'et til transaktionen, og ETH-beløbet kan hentes ved at aflæse feltet "msg.value" for transaktionen.
Indsættelse af ERC-20-tokens adskiller sig væsentligt fra indsættelse af ETH. For at indsætte et ERC-20-token skal brugeren først give brokontrakten tilladelse til at bruge sine tokens. Når de har godkendt dette og indsat tokens i brokontrakten, vil kontrakten enten brænde brugerens tokens ved hjælp af funktionen "burnFrom()" eller overføre brugerens tokens til kontrakten ved hjælp af funktionen "transferFrom()".
En metode til at differentiere dette er at bruge en if-else-erklæring inden for den samme funktion. En anden metode er at oprette to separate funktioner til at håndtere hvert scenarie. Forsøg på at indsætte ETH ved hjælp af ERC-20-indsættelsesfunktionen kan resultere i tab af disse midler.
Ved håndtering af ERC-20-indsættelsesanmodninger angiver brugerne normalt token-adressen som input til indsættelsesfunktionen. Dette udgør en betydelig risiko, da der kan forekomme eksterne opkald, som der ikke er tillid til, under transaktionen. Implementering af en positivliste, der kun omfatter de tokens, der understøttes af broen, er en almindelig praksis for at minimere risikoen. Kun adresser på positivlisten må overføres som argumenter. Dette forhindrer eksterne opkald, da projektgruppen allerede har filtreret token-adressen.
Der kan dog også opstå problemer, når broer håndterer overførsel af det integrerede token cross-chain, da det integrerede token ikke har en adresse. En nul-adresse (0x000 ...0) er repræsentativ for det integrerede token. Dette kan være problematisk, eftersom det at give nul-adressen til funktionen kan omgå verificeringen af positivlisten, selv om den er implementeret forkert.
Når brokontrakten kalder "transferFrom" for at overføre brugeraktiver til kontrakten, returneres det eksterne kald til nul-adressen falsk, da der ikke er nogen "transferFrom"-funktion implementeret i nul-adressen. Transaktionen kan dog stadig finde sted, hvis kontrakten ikke håndterer returværdien korrekt. Dette giver angribere mulighed for at udføre transaktionen uden at overføre nogen tokens til kontrakten.
Fejlkonfiguration
I de fleste blockchain-broer er en privilegeret rolle ansvarlig for at føje tokens og adresser til henholdsvis positivliste og negativliste, tildele eller ændre underskrivere samt andre vigtige konfigurationer. Det er afgørende at sikre, at alle konfigurationer er nøjagtige, da selv tilsyneladende ubetydelige fejl kan føre til betydelige tab.
Der har faktisk været en hændelse, hvor det lykkedes angriberen at omgå verifikationen af overførselsposter på grund af en fejlkonfiguration. Projektteamet implementerede en protokolopgradering et par dage før hacket, hvilket indebar en ændring af en variabel. Variablen blev brugt til at repræsentere standardværdien for den betroede meddelelse. Denne ændring resulterede i, at alle meddelelser automatisk blev anset for at være beviste, hvilket gjorde det muligt for en angriber at indsende en vilkårlig meddelelse og passere verifikationsprocessen.
Sådan forbedrer du brosikkerheden
De fire almindelige brosårbarheder, der er forklaret ovenfor, viser de udfordringer, der er forbundet med at sikre sikkerheden i et sammenkoblet blockchain-økosystem. Der er vigtige overvejelser i forbindelse med håndteringen af hver af disse sårbarheder, og der findes ikke en enkelt fremgangsmåde, der gælder for dem alle.
Det er f.eks. en udfordring at give generelle retningslinjer for at sikre en fejlfri verifikationsproces, da hver bro har unikke verifikationskrav. Den mest effektive metode til at forhindre omgåelse af verifikation er at teste broen grundigt mod alle mulige angrebsvektorer og sikre, at verifikationslogikken er sund.
Sammenfattende er det vigtigt at udføre strenge test mod potentielle angreb og være særlig opmærksom på de mest almindelige sikkerhedssårbarheder i broer.
Sammenfatning
På grund af deres høje værdi har broer cross-chain længe været et mål for angribere. Byggerne kan styrke sikkerheden på deres broer ved at foretage grundige test før implementering og få foretaget revisioner fra tredjepart, hvilket reducerer risikoen for de ødelæggende hackerangreb, som broer har været udsat for i de seneste år. Broer er afgørende i en verden med flere kæder, men sikkerhed skal være en vigtig prioritet, når man designer og opbygger en effektiv Web3-infrastruktur.
Yderligere læsning
Hvad er interoperabilitet cross-chain?
Tre populære kryptobroer, og hvordan de fungerer
Ansvarsfraskrivelse og risikoadvarsel: Dette indhold præsenteres for dig "som det er" til generel information og uddannelsesmæssige formål uden erklæring eller garanti af nogen art. Det skal ikke opfattes som økonomisk, juridisk eller anden professionel rådgivning, og det er heller ikke hensigten at anbefale køb af et bestemt produkt eller en bestemt tjeneste. Du bør selv søge råd fra relevante, professionelle rådgivere. Hvis denne artikel er et bidrag fra en tredjepart, bør du bemærke, at dennes synspunkter udtrykkeligt tilhører denne tredjepartsbidragsyder og ikke nødvendigvis afspejler Binance Academys synspunkter. Læs vores fulde ansvarsfraskrivelse her for yderligere oplysninger. Priserne på digitale aktiver kan være volatile. Værdien af din investering kan gå op eller ned, og du får muligvis ikke det investerede beløb tilbage. Du er eneansvarlig for dine investeringsbeslutninger, og Binance Academy er ikke ansvarlig for eventuelle tab, du måtte lide. Dette materiale bør ikke anses for værende økonomisk, juridisk eller anden rådgivning. For yderligere oplysninger kan du læse vores vilkår for anvendelse og risikoadvarsel.