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

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

Pe scurt

Punțile blockchain reprezintă fundamentul realizării interoperabilității în sectorul blockchain. Prin urmare, asigurarea podurilor este foarte importantă. Unele vulnerabilități obișnuite de securitate a podurilor includ autentificarea slabă în lanț și în afara lanțului, manipularea necorespunzătoare a token-urilor native și configurările greșite. Puntea trebuie testată pentru a se asigura că poate rezista tuturor vectorilor de atac și pentru a asigura o logică de verificare adecvată.

Introduce

O punte blockchain este un protocol care conectează două blockchain-uri pentru a permite interacțiunea între ele. Dacă dețineți bitcoin, dar doriți să participați la activitatea DeFi în rețeaua Ethereum, puntea blockchain vă va permite să faceți acest lucru fără a vă vinde bitcoin.

Punțile blockchain sunt fundamentale pentru realizarea interoperabilității în sectorul blockchain. Aceștia funcționează folosind diferite autentificări în lanț și în afara lanțului și, prin urmare, au vulnerabilități de securitate diferite.

De ce este importantă securitatea podului?

Podurile dețin de obicei jetoane pe care utilizatorii doresc să le transfere de la un lanț la altul. Adesea implementate ca contracte inteligente, podurile dețin o cantitate semnificativă de jetoane pe măsură ce transferurile încrucișate se acumulează, făcându-le ținte profitabile pentru hackeri.

În plus, punțile blockchain au o suprafață mare de atac, deoarece implică multe componente. Având în vedere această natură, actorii rău intenționați sunt foarte motivați să vizeze aplicațiile încrucișate pentru a retrage sume mari de fonduri.

Atacurile pod conduc la pierderi de peste 1,3 miliarde de dolari în 2022, reprezentând 36% din pierderile totale pentru anul, potrivit estimărilor CertiK.

Vulnerabilități comune de legătură

Pentru a îmbunătăți securitatea podurilor, este valoros să înțelegeți vulnerabilitățile comune ale podurilor și să testați podurile înainte de a le lansa. Aceste vulnerabilități pot fi clasificate în patru tipuri, după cum urmează.

Autentificare slabă în lanț

Pentru podurile simple, în special cele concepute pentru anumite DApps, validarea în lanț este adesea minimă. Aceste punți se bazează pe un backend centralizat pentru a efectua operațiuni de bază, cum ar fi baterea, arderea și transferul de jetoane, în timp ce toate verificările sunt efectuate în afara lanțului.

În schimb, alte tipuri de punți folosesc contracte inteligente pentru a valida mesajele și pentru a efectua verificarea în lanț. În acest caz, atunci când un utilizator depune bani într-un lanț, contractul inteligent generează un mesaj semnat și returnează semnătura în tranzacție. Această semnătură servește ca dovadă a depunerii, utilizată pentru a verifica cererea de retragere a unui utilizator pe alt lanț. Acest proces va putea preveni diferite atacuri de securitate, inclusiv atacuri de reluare și înregistrări false ale depozitelor.

Cu toate acestea, dacă există vulnerabilități în procesul de autentificare în lanț, un atacator poate provoca daune grave. De exemplu, dacă o punte folosește un arbore Merkle pentru a autentifica înregistrările tranzacțiilor, un atacator ar putea crea dovezi falsificate. Acest lucru înseamnă că pot ocoli autentificarea cu dovadă și pot introduce noi token-uri în conturile lor dacă procesul de autentificare este vulnerabil.

Unele poduri 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 preluat din contractul Ethereum și o cantitate echivalentă de DAI împachetat este eliberată pe BNB Chain.

Cu toate acestea, dacă această tranzacție nu este autentificată corespunzător, un atacator poate implementa un contract rău intenționat pentru a direcționa jetoanele împachetate de la punte la o adresă incorectă prin manipularea funcționalității.

Atacatorii trebuie, de asemenea, ca victima să aprobe contractul bridge pentru a transfera jetoanele folosind funcția „transferFrom” pentru a retrage activele din contractul bridge.

Din păcate, acest lucru se înrăutățește deoarece multe poduri necesită aprobare nelimitată de token din partea utilizatorilor DApp. Aceasta este o metodă populară care reduce taxele de gaz, dar creează un risc suplimentar, permițând contractului inteligent să acceseze un număr nelimitat de jetoane din portofelul utilizatorului. Atacatorii pot exploata lipsa de autentificare și aprobările excesive pentru a transfera token-uri de la alți utilizatori către ei.

Autentificare slabă în afara lanțului

În unele sisteme bridge, serverele backend off-chain joacă un rol important în verificarea legitimității mesajelor trimise din blockchain. În acest caz, ne concentrăm pe verificarea tranzacțiilor de depozit.

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

1. Utilizatorii interacționează cu DApp pentru a depune jetoane într-un contract inteligent pe lanțul sursă.

2. Acest DApp trimite apoi șirul hash al tranzacției de depozit către serverul backend prin API.

3. Șirul hash al tranzacției este supus unei anumite validări de server. Dacă este considerat legitim, semnatarul semnează un mesaj și trimite semnătura înapoi la interfața cu utilizatorul prin intermediul API-ului.

4. La primirea unei semnături, DApp o va verifica și va permite utilizatorilor să-și retragă jetoanele din lanțul țintă.

Serverul backend trebuie să se asigure că tranzacția de depozit pe care o procesează a avut loc efectiv și nu a fost modificată. Acest server backend determină dacă utilizatorii pot retrage jetoane din lanțul țintă și, prin urmare, este o țintă de mare valoare pentru atacatori.

Serverul backend trebuie să valideze structura evenimentului emis al tranzacției, precum și adresa contractului care a emis evenimentul. Dacă acesta din urmă este ignorat, un atacator poate implementa un contract rău intenționat pentru a falsifica un eveniment de depunere cu aceeași structură ca un eveniment de depunere legitim.

Dacă serverul backend nu verifică care adresă a emis evenimentul, consideră că aceasta este o tranzacție validă și semnează mesajul. Atacatorul poate trimite apoi hash-ul tranzacției către backend, ocolind verificarea și permițându-i să retragă jetoane din lanțul țintă.

Manipularea necorespunzătoare a jetoanelor native

Podurile au abordări diferite pentru a gestiona jetoanele native și jetoanele utilitare. De exemplu, în rețeaua Ethereum, jetoanele native sunt ETH și majoritatea jetoanelor utilitare respectă standardul ERC-20.

Atunci când utilizatorii intenționează să își transfere ETH într-un alt lanț, trebuie mai întâi să îl depună în contractul bridge. Pentru a realiza acest lucru, utilizatorii trebuie pur și simplu să atașeze ETH la tranzacție, iar suma de ETH poate fi obținută citind câmpul „msg.value” al tranzacției.

Trimiterea de jetoane ERC-20 este semnificativ diferită de trimiterea ETH. Pentru a depune un token ERC-20, utilizatorii trebuie mai întâi să autorizeze contractul de bridge să-și cheltuiască jetoanele. Odată ce au aprobat acest lucru și au depus jetoanele în contractul de legătură, contractul fie va arde jetoanele utilizatorului folosind funcția „burnFrom()”, fie va transfera jetoanele utilizatorului în contract folosind funcția „transferFrom((”)). .

O abordare pentru a diferenția acest lucru este utilizarea unei declarații if-else în cadrul aceleiași funcții. O altă abordare este de a crea două funcții separate pentru a gestiona fiecare situație. Încercarea de a depune ETH folosind funcția de depunere ERC-20 poate duce la pierderea acestor fonduri.

Atunci când procesează cererile de depunere ERC-20, utilizatorii furnizează, de obicei, adrese de simbol ca intrare în funcția de depunere. Acest lucru prezintă un risc semnificativ, deoarece apelurile externe nesigure pot avea loc în timpul tranzacției. Implementarea unei liste albe care include doar jetoane suportate de bridge este o modalitate populară de a reduce riscul. Numai adresele din lista albă pot fi transmise ca argumente. Acest lucru previne apelurile externe deoarece echipa de proiect a filtrat adresele de simboluri.

Cu toate acestea, pot apărea probleme și atunci când punțile gestionează transferurile în lanț încrucișat de jetoane native, deoarece jetoanele native nu au o adresă. Adresa numărul 0 (0x000...0) reprezintă simbolul original. Acest lucru poate fi problematic deoarece transmiterea adresei 0 unei funcții poate ocoli verificarea listei albe chiar dacă este implementată incorect.

Când contractul bridge apelează „transferFrom” pentru a transfera activele utilizatorului către contract, apelul extern la adresa zero returnează fals deoarece nu există nicio funcție „transferFrom” implementată în adresa zero. Cu toate acestea, tranzacția poate avea loc dacă contractul nu gestionează în mod corespunzător valoarea returnată. Acest lucru creează o oportunitate pentru atacatori de a face tranzacții fără a transfera niciun simbol în contract.

Configurație greșită

În majoritatea punților blockchain, un rol privilegiat este responsabil pentru listarea albă sau lista neagră a jetoanelor și adreselor, atribuirea sau schimbarea semnatarilor și alte configurații importante. Asigurarea faptului că toate configurațiile sunt corecte este crucială, deoarece chiar și erorile aparent mici pot duce la pierderi semnificative.

De fapt, a existat o problemă în care un atacator a ocolit cu succes verificarea înregistrării transferului din cauza unei configurări greșite. Echipa de proiect a efectuat o actualizare a protocolului cu câteva zile înainte de hack, care a implicat schimbarea unei variabile. Variabilă utilizată pentru a reprezenta valoarea implicită a unui mesaj de încredere. Această modificare are ca rezultat ca toate mesajele să fie considerate automat dovedite, permițând astfel unui atacator să trimită un mesaj arbitrar și să ocolească procesul de verificare.

Cum să îmbunătățiți securitatea podului

Cele patru vulnerabilități comune explicate mai sus demonstrează provocările de asigurare a securității într-un ecosistem blockchain interconectat. Există considerații importante pentru abordarea fiecăreia dintre aceste vulnerabilități și niciun manual nu se aplică tuturor acestora.

De exemplu, furnizarea de linii directoare generale pentru a asigura un proces de verificare fără erori este o provocare, deoarece fiecare punte are propriile cerințe de verificare. Cea mai eficientă abordare pentru a preveni ocolirea verificării este de a testa în detaliu puntea împotriva tuturor vectorilor de atac posibili și de a asigura o logică de verificare adecvată.

Pe scurt, este esențial să se efectueze teste riguroase împotriva potențialelor atacuri și să se acorde o atenție deosebită celor mai comune vulnerabilități de securitate pentru poduri.

rezumat

Datorită valorii lor ridicate, punțile cu lanțuri încrucișate au fost mult timp o țintă pentru atacatori. Dezvoltatorii pot crește securitatea punților lor efectuând teste amănunțite înainte de implementare și folosind terțe părți pentru a participa la audit, pentru a reduce riscul de atacuri devastatoare - care au afectat podurile în ultimii ani. Podurile sunt componente foarte importante într-o lume cu mai multe lanțuri, dar securitatea trebuie să fie o preocupare de top pentru a proiecta și a construi o infrastructură Web3 eficientă.

Citeşte mai mult:

Ce este un pod Blockchain?

Ce este interoperabilitatea Cross-Chain?

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

Ce sunt jetoanele împachetate?

Exonerare de responsabilitate și avertisment de risc: acest conținut vă este prezentat „ca atare” numai pentru informații generale și în scopuri educaționale, fără reprezentare sau garanție de niciun fel. Nu ar trebui să fie interpretat ca un sfat financiar, juridic sau de altă natură profesională și nici nu este intenționat ca 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. În cazurile în care articolele sunt contribuite de colaboratori terți, vă rugăm să rețineți că opiniile exprimate aparțin contribuitorului terț și nu reflectă neapărat punctele de vedere ale Academiei Binance. Vă rugăm să citiți declinul nostru complet aici pentru mai multe detalii. Prețurile activelor digitale pot fluctua. Valoarea investiției dvs. poate scădea și crește și este posibil să nu vă recuperați suma investită. Sunteți singurul responsabil pentru deciziile dvs. de investiții, iar Academia Binance nu este responsabilă pentru pierderile pe care le puteți suferi. Acest material nu trebuie interpretat ca un sfat financiar, juridic sau de alt tip profesional. Pentru mai multe informații, consultați Termenii de utilizare și Avertismentul privind riscurile.