原文标题：《Eludarea stratului zero: de ce securitatea izolată nu este securitate》

Autor: Krzysztof Urbański, membru al echipei L2BEAT

Compilat de: Babywhale, Foresight News

L2BEAT a investit eforturi considerabile încă de la început pentru a analiza și înțelege riscurile asociate cu protocoalele Layer 2. Acționăm întotdeauna în interesul utilizatorilor și ecosistemului nostru și facem tot posibilul pentru a fi un supraveghetor imparțial și independent, fără a lăsa preferințele noastre personale pentru proiecte sau echipele asociate să influențeze faptele. De aceea, deși respectăm timpul și efortul pe care echipa de proiect le depune în proiect, este posibil să „tragem un semnal de alarmă” sau să ne semnalăm preocupările cu privire la riscurile potențiale ale anumitor protocoale. Discuțiile legate de securitate din timp permite întregului ecosistem să fie mai bine pregătit pentru potențiale riscuri și să reacționeze mai devreme la orice comportament suspect.

Astăzi am dori să discutăm despre modelul de securitate partajat pentru aplicațiile cross-chain. În prezent, există două modele de securitate: securitate partajată și securitate independentă a aplicațiilor. Securitatea partajată este ca toate Rollup-urile. Securitatea aplicațiilor autonome este utilizată în principal de proiectele „omnichain”, care folosesc în principal LayerZero.

Securitate partajată vs. securitate independentă

Securitatea partajată se referă la un anumit token sau aplicație care rulează pe o anumită infrastructură și, în loc să aleagă liber un model de securitate, trebuie să adere la orice cerințe de securitate impuse de infrastructură. De exemplu, Rollup-urile optimiste impun de obicei o fereastră finală de 7 zile — o aplicație care rulează pe astfel de Rollup-uri nu poate pur și simplu să ignore sau să scurteze această perioadă. Deși acest lucru poate părea o piedică, există un motiv pentru asta. Această perioadă oferă utilizatorilor garanții de securitate că, indiferent de politica de securitate internă a aplicației, care trebuie respectată, aplicația poate doar să întărească securitatea Rollup-urilor, nu să o slăbească.

Securitatea independentă înseamnă că fiecare aplicație este responsabilă pentru definirea securității sale și nu este restricționată în niciun fel de infrastructură. Aceasta poate părea o idee bună la început, la urma urmei, dezvoltatorul aplicației știe cel mai bine de ce măsuri de securitate poate avea nevoie aplicația. Dar, în același timp, transferă responsabilitatea evaluării riscurilor asociate cu fiecare politică de securitate a aplicației către utilizatorul final. În plus, dacă dezvoltatorii de aplicații sunt liberi să-și aleagă politicile de securitate, le pot schimba oricând. Prin urmare, nu este suficient să se evalueze riscul o dată pentru fiecare aplicație, acesta ar trebui evaluat de fiecare dată când politicile unei aplicații se modifică.

Probleme

Considerăm că un model de securitate independent în care fiecare aplicație este liberă să-și definească politica de securitate creează probleme serioase de securitate. În primul rând, crește riscul pentru utilizatorii finali, deoarece aceștia trebuie să verifice riscul pentru fiecare aplicație pe care intenționează să o utilizeze.

Securitatea autonomă crește, de asemenea, riscurile pentru aplicațiile care utilizează acest model, de exemplu, adăugând riscuri suplimentare privind modificările politicii de securitate - dacă un atacator ar schimba modelul de securitate al aplicației, ar putea la fel de bine să îl dezactiveze pur și simplu, rămânând astfel fără bani sau riscând să-l Atacă în alte moduri. Nu există straturi suplimentare de securitate în partea de sus a aplicației pentru a preveni atacurile.

În plus, deoarece politicile de securitate se pot schimba în orice moment și din mers, este aproape imposibil să monitorizezi aplicațiile în timp real și să informezi utilizatorii despre riscuri.

Am găsit-o similară cu upgradabilitatea contractelor inteligente, despre care am avertizat pe L2BEAT. Informam utilizatorii despre punțile Rollup și cross-chain care au mecanisme de upgrade în contractele lor inteligente și mecanismele exacte de gestionare a upgradeabilității în fiecare caz. Acest lucru este deja destul de complex, iar utilizarea unui model de securitate separat multiplică numărul, făcând aproape imposibil de urmărit eficient.

Acesta este motivul pentru care considerăm un model de securitate independent ca fiind un risc de securitate în sine și presupunem că fiecare aplicație care va folosi acest model în mod implicit ar trebui să fie considerată riscantă până când se dovedește contrariul.

Demonstrați că există vulnerabilități de securitate

Am decis să ne testăm ipoteza pe mainnet. Cadrul LayerZero a fost ales pentru experimentare deoarece este una dintre cele mai populare soluții autonome concentrate pe securitate. Am implementat un token omnichain securizat și ulterior am actualizat configurația de securitate pentru a permite retragerile rău intenționate ale simbolului. Codul pentru token se bazează pe exemplele oferite de LayerZero și este foarte similar sau identic cu multe alte token-uri și aplicații omnicain implementate în viața reală.

Dar înainte de a intra în detalii, să aruncăm o scurtă privire la cum arată modelul de securitate LayerZero.

După cum subliniază LayerZero în cartea sa albă, „comunicarea inter-lanț fără încredere” se bazează pe doi actori independenți (oracole și relee) care acționează împreună pentru a asigura securitatea protocolului.

LayerZero afirmă pe site-ul său web că conceptul său de bază este „aplicațiile utilizator care rulează ULN (UltraLightNode), terminale configurabile în lanț”. Componenta on-chain a LayerZero se bazează pe două componente externe off-chain pentru a transmite mesaje între lanțuri - oracole și relee.

Ori de câte ori orice mesaj M este trimis din lanțul A în lanțul B, au loc următoarele două operații:

  • În primul rând, oracolul așteaptă până când tranzacția care trimite mesajul M pe lanțul A este finalizată și apoi scrie informații relevante pe lanțul B, cum ar fi valoarea hash a antetului bloc al lanțului A care conține mesajul M (valoarea exactă între diferite lanțuri/oracole Formatul poate varia).

  • Releul trimite apoi o „dovadă” (cum ar fi Merkle Proof) la lanțul B, demonstrând că antetul blocului stocat conține mesajul M.

LayerZero presupune că releele și oracolele sunt participanți independenți și onești. Cu toate acestea, LayerZero a mai precizat în cartea albă că, dacă această ipoteză nu este îndeplinită, de exemplu, releul și oracolul se complică, rezultând că „atât antetul blocului furnizat de oracol, cât și dovada tranzacției furnizate de releu sunt invalide, dar încă se potrivește.”

LayerZero susține că „designul LayerZero elimină posibilitatea de coluziune”. Dar, de fapt, această afirmație este incorectă (demonstrăm acest lucru în experimentele prezentate mai jos), deoarece fiecare aplicație utilizator își poate defini propriile relee și oracole. LayerZero nu garantează prin proiect că aceste componente sunt independente și nu pot colabora, mai degrabă, este la latitudinea aplicației utilizator să ofere aceste garanții. LayerZero nu are niciun mecanism pentru a opri aplicațiile dacă aleg să le spargă.

În plus, în mod implicit, toate aplicațiile utilizatorului pot schimba releele și oracolele în orice moment, redefinind complet ipotezele de securitate. Prin urmare, verificarea securității unei anumite aplicații o singură dată nu este suficientă, deoarece se poate schimba în orice moment după verificare, așa cum vom arăta în experimentele noastre.

design experimental

Pentru experimentele noastre, am decis să creăm un simbol omnichain simplu, CarpetMoon, care rulează atât pe Ethereum, cât și pe Optimism și care utilizează LayerZero pentru a comunica între cele două lanțuri.

Tokenul nostru folosește inițial modelul de securitate implicit furnizat de LayerZero, făcându-l identic cu aplicațiile LayerZero mari (poate nu toate) implementate în prezent. Prin urmare, este în general la fel de sigur ca orice altă monedă care utilizează LayerZero.

În primul rând, implementăm contractul nostru token pe Ethereum și Optimism:

https://ethtx.info/mainnet/0xf4d1cdabb6927c363bb30e7e65febad8b9c0f6f76f1984cd74c7f364e3ab7ca9/

https://optimistic.etherscan.io/tx/0xf41389d71fa3942de5225efb067072728c6c6de56c241574187781db7c73d221

Apoi am configurat rutarea astfel încât LayerZero să știe ce contract corespunde căruia pe ambele lanțuri.

https://ethtx.info/mainnet/0x19d78abb03179969d6404a7bd503148b4ac14d711f503752495339c96a7776e9/

https://optimistic.etherscan.io/tx/0x037b1bad33faa5607bb5835460a1d5caaf3a147dc3a09762ac7703befcdb3c3c

Token-ul a fost implementat și arată exact ca orice alt jeton omnichain care utilizează LayerZero, folosind configurația implicită și nimic neplăcut.

Am furnizat 1 miliard de jetoane CarpetMoon pe Ethereum „utilizatorului nostru de testare” Alice.

https://ethtx.info/mainnet/0x7e2faa8426dacae92830efbf356ca2da760833eca28e652ff9261fc03042b313/

Acum, Alice folosește LayerZero pentru a încrucișa aceste jetoane cu Optimism.

Blocăm jetoanele într-un contract de escrow pe Ethereum:

https://ethtx.info/mainnet/0xe4dc3757b86bfda8e7baddc088fb1a599e083ed77034c29e5dd8bd11f1e17771/。

Mesajul care conține tranzacția este transmis către Optimism prin LayerZero:

https://layerzeroscan.com/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/message/111/address/0x201fe0d843b546f2e24d4c8444403b71c84441818444181844418184441818

Jetoanele cu lanțuri încrucișate sunt bătute pe Optimism, iar Alice deține acum 1 miliard de jetoane MoonCarpet pe Optimism:

https://optimistic.etherscan.io/tx/0x5388ced88cf562acafff82d6798f791b0b38b90ee106df9bf91c0d86306ec302.

Totul funcționează conform așteptărilor, Alice încrucișează jetoanele și vede că există 1 miliard de jetoane MoonCarpet în contractul de escrow pe Ethereum și 1 miliard de jetoane MoonCarpet în contul ei la Optimism. Dar doar pentru a se asigura că totul a fost bine, ea și-a transferat jumătate din jetoanele înapoi la Ethereum.

Începem cu o tranzacție pe Optimism care a ars 500 de milioane de jetoane:

https://optimistic.etherscan.io/tx/0x118a57106488ad0bae1f3b920b1fd98b187752ad966f3a901fc53cff47f2097f.

Informațiile despre tranzacție sunt transmise către Ethereum:

https://layerzeroscan.com/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/message/101/address/0xc6005ccc1de4b300d538903bffc1。nod10d5b78484845b784848484848484848484b748184

După cum era de așteptat, 500 de milioane de jetoane MoonCarpet sunt returnate din contractul de escrow la adresa lui Alice:

https://etherscan.io/tx/0x27702e07a65a9c6a7d1917222799ddb13bb3d05159d33bbeff2ca1ed414f6a18.

Până acum, totul funcționează bine și exact așa cum se presupunea. Alice a verificat că poate încrucișa jetoanele de la Ethereum la Optimism și înapoi, nu are de ce să-și facă griji cu privire la jetoanele ei MoonCarpet.

Dar ipoteticele au propriile lor probleme - de exemplu, echipa din spatele simbolului nostru se confruntă cu probleme, iar tipul rău Bob obține acces la configurația LayerZero a aplicației noastre.

În acest fel, Bob poate schimba oracolele și releele de la componentele implicite la componentele pe care le controlează.

Trebuie remarcat faptul că acesta este un mecanism furnizat pentru fiecare aplicație care utilizează LayerZero și este înrădăcinat în arhitectura LayerZero. Nu este o ușă în spate de niciun fel, ci un mecanism standard.

Deci, Bob schimbă oracolul într-un EOA sub controlul său:

https://ethtx.info/mainnet/0x4dc84726da6ca7d750eef3d33710b5f63bf73cbe03746f88dd8375c3f4672f2f/。

De asemenea, repetorul a fost schimbat:

https://ethtx.info/mainnet/0xc1d7ba5032af2817e95ee943018393622bf54eb87e6ff414136f5f7c48c6d19a/。

Acum se întâmplă ceva ciudat. Deoarece oracolul și ștafeta sunt acum sub controlul deplin al lui Bob, el este capabil să fure jetoanele lui Alice. Chiar dacă nu s-a luat nicio măsură în privința Optimism (jetoanele MoonCarpet erau încă în portofelul lui Alice), Bob a reușit să convingă contractul inteligent MoonCarpet de pe Ethereum (folosind mecanismul LayerZero) că a distrus jetoanele de pe celălalt lanț și a putut să retrageți jetoanele de pe tokenul MoonCarpet de pe Ethereum.

În primul rând, actualizează hash-ul de bloc al lui Ethereum folosind un oracol pe care îl controlează:

https://ethtx.info/0xde2edee2cc7f070120e96c9df90d86696970befcfc221e18c6ac4168bb5b1d92/。

Acum poate retrage jetoanele rămase din contractul de escrow:

https://ethtx.info/0xda695f374b375d5372efeca37aae4c5a17f114d5a76db1e86edebb0924bcdcc7/。

Rezultate experimentale

Alice nici măcar nu știe de ce și când a apărut eroarea. Dintr-o dată, jetonul ei MoonCarpet pe Optimism nu a mai fost susținut de jetonuri pe Ethereum.

Contractul inteligent nu poate fi actualizat și funcționează conform așteptărilor. Singura activitate suspectă este modificarea oracolului și a releului, dar acesta este un mecanism obișnuit încorporat în LayerZero, așa că Alice nici măcar nu știe dacă această schimbare este intenționată. Chiar dacă Alice află de schimbare, este prea târziu - atacatorul poate scurge fondurile înainte de a putea reacționa.

LayerZero nu poate face nimic - toate acestea sunt implementări eficiente ale mecanismelor lor, asupra cărora nu au niciun control. În teorie, aplicațiile în sine s-ar putea împiedica să schimbe oracolele și releele, dar din cunoștințele noastre, nicio aplicație implementată nu a făcut acest lucru.

Am făcut acest experiment pentru a testa dacă a observat cineva, dar așa cum ne așteptam, nimeni nu a făcut-o. Este aproape imposibil să monitorizați eficient toate aplicațiile create cu LayerZero pentru a verifica dacă politicile lor de securitate s-au schimbat și pentru a alerta utilizatorii atunci când se întâmplă acest lucru.

Chiar dacă cineva poate descoperi la timp că oracolele și releele s-au schimbat și au creat un risc de securitate, va fi prea târziu. Deoarece noile oracole și relee sunt acum libere să aleagă ce mesaje să livreze sau pur și simplu să dezactiveze comunicarea între lanțuri, în general, utilizatorii nu pot face multe în acest sens. Experimentele noastre arată clar că, chiar dacă Alice observă schimbarea configurației aplicației, nu poate face mare lucru cu jetoanele ei încrucișate - noile oracole și relee nu mai sunt acceptate în mesajul original al lanțului de comunicații, așa că mesajul nu va fi returnat la Ethereum. .

în concluzie

După cum putem vedea, deși jetonul nostru a fost construit cu LayerZero și și-a folosit mecanica conform intenționării, am reușit să furăm fonduri din escrow-ul jetonului. Desigur, aceasta este vina aplicației (în cazul nostru, jetonul CarpetMoon) și nu LayerZero în sine, dar demonstrează că LayerZero în sine nu oferă nicio garanție de securitate.

Când LayerZero își descrie modelul de securitate în ceea ce privește oracolele și releele, ei presupun că proprietarul aplicației (sau oricine are cheia privată) nu va face nimic nerezonabil. Dar într-un mediu advers, această presupunere este incorectă. În plus, solicită utilizatorilor să aibă încredere în dezvoltatorul aplicației ca terță parte de încredere.

Deci, în practică, nu se poate face nicio presupunere cu privire la securitatea aplicațiilor construite cu LayerZero - fiecare aplicație ar trebui considerată riscantă până când se dovedește contrariul.

De fapt, toată povestea a început cu un PR pe care am plănuit să includem toate jetoanele omnichain pe site-ul L2BEAT - ne-a fost greu să ne dăm seama cum să le evaluăm riscul. Când am analizat riscurile, ne-a venit ideea de experimentare.

Dacă L2BEAT ar fi lansat, consecința ar fi că ar trebui să plasăm alerte pe fiecare aplicație construită cu LayerZero pentru a avertiza despre posibilele riscuri de securitate. Dar am vrut să avem o discuție mai largă despre modelele de securitate, deoarece credem că securitatea de sine stătătoare este un model care ar trebui evitat, mai ales în domeniul nostru.

Credem că, pe măsură ce modelele de securitate independente precum LayerZero devin tot mai populare, tot mai multe proiecte vor abuza de ele, provocând daune masive și crescând incertitudinea în întreaga industrie.