Acest articol este o contribuție a comunității. Autorul este Minzhi He, auditor al CertiK.

Părerile exprimate în acest articol sunt cele ale contribuitorului/autorului și nu reflectă neapărat punctele de vedere ale Academiei Binance.

rezumat

Punțile blockchain sunt fundamentale pentru realizarea interoperabilității în spațiul blockchain. Prin urmare, securitatea tehnologiei cross-chain bridging este crucială. Unele vulnerabilități comune de securitate a podurilor blockchain includ verificarea insuficientă în lanț și în afara lanțului, manipularea necorespunzătoare a token-urilor native și configurarea greșită. Pentru a vă asigura că logica de verificare este bună, se recomandă testarea punții încrucișate împotriva tuturor vectorilor de atac posibili.

Introducere

O punte blockchain este un protocol care conectează două blockchain-uri și le permite să interacționeze. Prin intermediul punții blockchain, dacă utilizatorii doresc să participe la activitățile DeFi din rețeaua Ethereum, trebuie doar să dețină Bitcoin și nu trebuie să-l vândă pentru a-și atinge obiectivele.​

Puntea blockchain este fundația interoperabilității în domeniul blockchain. Ei folosesc diverse verificări în lanț și în afara lanțului pentru a funcționa, astfel încât pot exista și vulnerabilități de securitate diferite.

De ce este critică securitatea punților blockchain?

Punțile blockchain dețin de obicei jetoane pe care utilizatorii doresc să le transfere de la un lanț la altul. Podurile blockchain sunt de obicei implementate sub formă de contracte inteligente Pe măsură ce transferurile în lanțuri încrucișate continuă să se acumuleze, un număr mare de jetoane vor fi deținute pe pod.

În plus, suprafața de atac a podurilor blockchain tinde să fie mare datorită numeroaselor componente implicate. Prin urmare, infractorii au stimulente puternice să vizeze aplicațiile cross-chain pentru a obține sume mari de fonduri.

Potrivit estimărilor CertiK, atacurile de poduri blockchain au cauzat pierderi de peste 1,3 miliarde de dolari în 2022, reprezentând 36% din pierderile totale în acel an.

Vulnerabilitățile de securitate comune încrucișate

Pentru a spori securitatea unui pod blockchain, este important să înțelegeți vulnerabilitățile comune de securitate ale podurilor cross-chain și să testați puntea blockchain înainte de a-l lansa. Aceste vulnerabilități provin în principal din următoarele patru aspecte:

Verificare insuficientă în lanț

Pentru punțile blockchain simple, în special cele concepute pentru un anumit dApp, există de obicei doar un nivel minim de verificare în lanț. Aceste punți se bazează pe un backend centralizat pentru a efectua operațiuni de bază, cum ar fi baterea, arderea și transferurile de jetoane, toate verificările având loc în afara lanțului.

În timp ce alte tipuri de punți folosesc contracte inteligente pentru a valida mesajele și a le verifica în lanț. În acest caz, atunci când un utilizator depune fonduri în lanț, contractul inteligent generează un mesaj semnat și returnează semnătura în tranzacție. Această semnătură va fi folosită ca dovadă a depunerii și utilizată pentru a verifica cererea de retragere a utilizatorului pe un alt lanț. Acest proces ar trebui să prevină diferite atacuri de securitate, inclusiv atacurile de reluare și înregistrările de încărcare falsificate.

Cu toate acestea, dacă există o vulnerabilitate în procesul de verificare în lanț, un atac ar putea provoca daune grave. De exemplu, dacă blockchain-ul folosește arbori Merkle pentru a verifica înregistrările tranzacțiilor, un atacator poate genera dovezi falsificate. Aceasta înseamnă că, dacă procesul de verificare este vulnerabil, un atacator poate ocoli verificarea dovezilor și poate bate noi token-uri în contul său.

Unele punți blockchain implementează conceptul de „jetoane înfășurate”. De exemplu, atunci când un utilizator transferă DAI de la Ethereum la BNB Chain, DAI-ul său este scos din contractul Ethereum și o cantitate egală de DAI împachetat este emisă pe BNB Chain.

Cu toate acestea, dacă această tranzacție nu este validată în mod corespunzător, un atacator poate implementa un contract rău intenționat care manipulează această funcționalitate pentru a direcționa token-urile împachetate de la punte la adresa greșită.​

Atacatorul are nevoie, de asemenea, ca victima să aprobe contractul de pod încrucișat înainte de a utiliza funcția „TransferFrom” pentru a transfera jetoane, luând astfel active din contractul de pod încrucișat.

Dar partea dificilă este că multe poduri cross-chain impun utilizatorilor dApp să aprobe o cantitate nelimitată de jetoane. Această practică este foarte comună, care poate reduce taxele de gaz, dar permite contractelor inteligente să acceseze o cantitate nelimitată de jetoane din portofelul utilizatorului. care va aduce Riscuri Suplimentare. Atacatorii ar exploata aceste subverificări și supraaprobări pentru a transfera jetoane de la alți utilizatori către ei înșiși.

Verificare în afara lanțului insuficientă

În unele sisteme cross-chain bridge, serverele backend off-chain joacă un rol crucial în verificarea legitimității mesajelor trimise din blockchain. În acest caz, trebuie să ne concentrăm pe verificarea tranzacției de reîncărcare.

O punte blockchain cu verificare în afara lanțului funcționează după cum urmează:

1. Utilizatorii interacționează cu dApp și depun jetoane în contracte inteligente din lanțul sursă.

2. Apoi dApp trimite hash-ul tranzacției de depunere către serverul backend prin intermediul API-ului.

3. Hash-ul tranzacției trebuie verificat de mai multe ori de către server. Dacă este considerat legitim, semnatarul semnează un mesaj și trimite semnătura înapoi la interfața cu utilizatorul prin intermediul API-ului.

4. Odată ce semnătura este primită, dApp o verifică și permite utilizatorului să retragă jetoane din lanțul țintă.

Serverul backend trebuie să se asigure că tranzacțiile de reîncărcare pe care le gestionează sunt reale și nu falsificate. Acest server backend determină dacă un utilizator poate retrage jetoane din lanțul țintă, făcându-l prima țintă a atacurilor.

Serverul backend trebuie să verifice structura evenimentului de inițiere a tranzacției și adresa contractului care a inițiat evenimentul. Dacă acesta din urmă este ignorat, atacatorii pot implementa contracte rău intenționate pentru a crea evenimente de reîncărcare cu aceeași structură ca și evenimentele de reîncărcare legitime.

Dacă serverul backend nu verifică care adresă a inițiat evenimentul, va presupune că este o tranzacție validă și va semna mesajul. Un atacator poate trimite apoi hash-ul tranzacției către serverul backend, ocolind verificarea și permițându-i să retragă jetoane din lanțul țintă.

Manevrare incorectă a jetoanelor native

Podurile cu lanțuri încrucișate adoptă o abordare diferită a jetoanelor native și a jetoanelor utilitare. De exemplu, în rețeaua Ethereum, tokenul nativ este ETH, iar majoritatea token-urilor utilitare respectă standardul ERC-20.

Dacă un utilizator intenționează să-și transfere ETH într-un alt lanț, trebuie mai întâi să îl depună în contractul cross-chain bridge. Pentru a face acest lucru, utilizatorul atașează pur și simplu ETH la tranzacție și poate prelua cantitatea de ETH citind câmpul tranzacției „msg.value”.

Depunerea de jetoane ERC-20 este foarte diferită de depunerea ETH. Pentru a depune jetoane ERC-20, utilizatorii trebuie mai întâi să permită contractului de punte cross-chain să-și folosească jetoanele. După ce aprobă și depune token-urile în contractul cross-chain bridge, contractul va folosi funcția „burnFrom()” pentru a distruge jetoanele utilizatorului sau funcția „transferFrom()” pentru a transfera token-urile utilizatorului în contract.

Pentru a distinge ce operație este, puteți utiliza instrucțiuni if-else în aceeași funcție. Sau creați două funcții separate pentru a gestiona fiecare scenariu. Datorită diferitelor metode de procesare, dacă un utilizator încearcă să depună ETH folosind funcția de depunere ERC-20, ETH poate fi pierdut.

Când procesează cererile de depunere ERC-20, utilizatorii furnizează de obicei adresa simbolului ca parametru de intrare în funcția de depunere. Acest lucru prezintă un risc semnificativ, deoarece apelurile externe nesigure pot apărea în timpul tranzacțiilor. Folosirea unei liste albe pentru a include numai jetoane susținute de o punte de lanț încrucișat este o practică comună pentru a minimiza riscul. Doar adresele din lista albă sunt trecute ca parametri. Acest lucru previne apelurile externe, deoarece echipa de proiect a filtrat adresele simbolurilor.

Cu toate acestea, există și o problemă când bridge-ul cross-chain se ocupă de transferul încrucișat al jetoanelor native, deoarece jetoanele native nu au adrese. Tokenurile native pot fi reprezentate printr-o adresă specială, „adresa zero” (0x000... 0). Dar există o problemă cu aceasta, dacă logica de verificare a listei albe nu este implementată corect, transmiterea unei adrese zero către funcție poate ocoli verificarea listei albe.

Când contractul cross-chain bridge apelează „TransferFrom” pentru a transfera activele utilizatorului către contract, apelul extern la adresa zero va returna fals deoarece funcția „transferFrom” nu este implementată în adresa zero. Cu toate acestea, dacă contractul nu gestionează corect valoarea returnată, tranzacția poate continua să aibă loc. Acest lucru creează o oportunitate pentru un atacator de a executa o tranzacție fără a transfera niciun simbol în contract.

Eroare de configurare

În majoritatea punților blockchain, există un rol privilegiat responsabil pentru listarea albă sau lista neagră a jetoanelor și adreselor, atribuirea sau schimbarea semnatarilor și alte configurații cheie. Este esențial să ne asigurăm că toate configurațiile sunt corecte, deoarece neglijerile aparent banale pot duce la pagube semnificative.

De fapt, au existat incidente în care atacatorii au ocolit cu succes verificarea înregistrărilor de transfer din cauza unei configurări greșite. Echipa de proiect a implementat o actualizare a protocolului cu câteva zile înainte de hack, în care a fost schimbată o anumită variabilă. Această variabilă este valoarea implicită folosită pentru a reprezenta mesajele de încredere. Această modificare face ca toate mesajele să fie considerate automat autentificate, permițând astfel unui atacator să trimită un mesaj aleator și să treacă validarea.

Cum să îmbunătățiți securitatea podurilor cu lanțuri transversale

Cele patru vulnerabilități comune ale podurilor cross-chain descrise mai sus demonstrează că provocările cu care se confruntă securitatea într-un ecosistem blockchain conectat nu pot fi subestimate. Pentru a face față acestor vulnerabilități, trebuie să luăm în considerare „în funcție de condițiile locale” Nicio metodă nu poate fi un panaceu pentru a face față tuturor vulnerabilităților.

De exemplu, deoarece fiecare punte cu lanț încrucișat are cerințe unice de verificare, ar fi dificil să se asigure că procesul de verificare este lipsit de erori prin simpla furnizare de linii directoare generale. Cea mai eficientă modalitate de a preveni ocolirea verificării este de a testa cu atenție puntea încrucișată împotriva tuturor vectorilor de atac posibili și de a vă asigura că logica de verificare este rezonabilă.

Una peste alta, trebuie efectuate teste riguroase împotriva potențialelor atacuri, acordându-se o atenție deosebită celor mai comune vulnerabilități de securitate din podurile cross-chain.

Concluzie

Datorită volumului imens de fonduri, podurile încrucișate au fost mult timp vizate de atacatori. Constructorii pot întări securitatea podurilor încrucișate prin efectuarea de teste prealabile cuprinzătoare și încorporând audituri terțe, reducând astfel riscul de hack-uri catastrofale care au apărut peste podurile încrucișate în ultimii ani. Punțile încrucișate sunt cruciale într-o lume cu mai multe lanțuri, dar securitatea trebuie să fie o considerație principală atunci când se proiectează și se construiește o infrastructură Web3 eficientă.

Lectură în continuare

Ce este un pod blockchain?

Ce este interoperabilitatea cross-chain?

Trei poduri populare de criptomonede și cum funcționează

Ce este un jeton împachetat?

Exonerare de răspundere și avertisment privind riscurile: conținutul acestui articol este real și este doar pentru informații generale și în scopuri educaționale și nu constituie nicio reprezentare sau garanție. Acest articol nu trebuie interpretat ca un sfat financiar, juridic sau de alt tip profesional și nu este o recomandare de a cumpăra un anumit produs sau serviciu. Ar trebui să solicitați propriul sfat de la consilierii profesioniști corespunzători. Dacă acest articol a fost furnizat de un colaborator terț, vă rugăm să rețineți că opiniile exprimate în acest articol aparțin contributorului terț și nu reflectă neapărat punctele de vedere ale Academiei Binance. Pentru mai multe informații, vă rugăm să faceți clic aici pentru a citi clauza noastră completă de declinare a răspunderii. Prețurile activelor digitale pot fluctua. Valoarea investiției dumneavoastră poate scădea sau crește și este posibil să nu vă recuperați capitalul investit. Sunteți singurul responsabil pentru propriile decizii de investiții, iar Academia Binance nu este responsabilă pentru pierderile pe care le puteți suferi. Acest articol nu constituie sfaturi financiare, juridice sau de alt tip profesional. Pentru mai multe informații, consultați Termenii de utilizare și Avertismentul privind riscurile.