Hvad er almindelige sikkerhedssårbarheder i broer?
Hjem
Artikler
Hvad er almindelige sikkerhedssårbarheder i broer?

Hvad er almindelige sikkerhedssårbarheder i broer?

Avanceret
Offentliggjort Mar 22, 2023Opdateret Jun 15, 2023
9m

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:¬†

  1. Brugerne interagerer med DApp'en for at indsætte tokens på en smart contract på kildekæden.

  2. DApp'en indsender derefter indsættelsestransaktionens hash til backend-serveren via en API.

  3. 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.

  4. 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 en blockchain-bro?

Hvad er interoperabilitet cross-chain?

Tre populære kryptobroer, og hvordan de fungerer

Hvad er indpakkede tokens?

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.