Menghindari Lapisan Nol

Sejak awal L2BEAT, kami berupaya keras untuk menganalisis dan memahami risiko yang terkait dengan protokol L2. Kami melakukan yang terbaik untuk menjadi pengawas independen yang tidak memihak, bertindak demi kepentingan terbaik pengguna dan ekosistem. Kami tidak membiarkan preferensi pribadi kami untuk proyek atau tim yang terlibat menghalangi. Itulah mengapa kami perlu mengaktifkan peringatan merah atau menunjukkan kekhawatiran kami dalam berbagai protokol, meskipun kami menghargai waktu dan kerja yang diberikan oleh tim tertentu ke dalam proyek mereka. Memiliki diskusi terkait keamanan sejak awal memungkinkan seluruh ekosistem untuk mempersiapkan diri dengan lebih baik terhadap potensi risiko dan bereaksi lebih awal terhadap perilaku yang mencurigakan.

Hari ini kami ingin membuka debat tentang model keamanan bersama dari aplikasi lintas rantai. Saat ini, ada dua pendekatan: keamanan bersama vs. keamanan per aplikasi. Yang pertama, keamanan bersama, digunakan, misalnya, oleh semua rollup. Yang kedua, keamanan per aplikasi, digunakan oleh proyek “omnichain”. Contoh utama dari proyek semacam itu adalah LayerZero.

Keamanan bersama vs. Keamanan terisolasi

Dengan keamanan bersama, maksud kami adalah bahwa token atau aplikasi tertentu yang berjalan pada infrastruktur tertentu tidak bebas memilih model keamanannya. Sebaliknya, mereka harus mematuhi persyaratan keamanan apa pun yang diberlakukan oleh infrastruktur. Misalnya, rollup optimis biasanya memberlakukan jendela finalitas 7 hari — aplikasi yang berjalan pada rollup semacam itu tidak dapat mengabaikan atau mempersingkat periode ini begitu saja. Ini mungkin tampak seperti hambatan, tetapi hambatan itu ada karena suatu alasan. Hal ini memungkinkan untuk memberikan jaminan keamanan kepada pengguna yang dapat mereka perkirakan dipegang oleh aplikasi apa pun yang mereka gunakan pada rollup itu, apa pun kebijakan keamanan internal aplikasi tersebut. Aplikasi mungkin hanya memperkuat kebijakan pembatalan, bukan melemahkannya.

Dengan keamanan terisolasi, maksud kami adalah bahwa setiap aplikasi bertanggung jawab untuk menentukan keamanannya, tidak dibatasi oleh infrastruktur dengan cara apa pun. Pada awalnya, ini mungkin tampak seperti ide yang bagus. Lagi pula, pengembang aplikasi paling tahu langkah-langkah keamanan apa yang mungkin diperlukan aplikasi. Namun pada saat yang sama, ini mengalihkan tanggung jawab untuk menilai risiko yang terkait dengan setiap kebijakan keamanan aplikasi kepada pengguna akhir. Selain itu, jika pengembang aplikasi bebas memilih kebijakan aplikasi mereka, mereka juga dapat memilih untuk mengubahnya kapan pun mereka mau. Jadi tidak cukup hanya menilai risiko satu kali untuk setiap aplikasi, risiko harus dinilai setiap kali kebijakan aplikasi berubah.

Masalah

Menurut kami, model keamanan terisolasi di mana setiap aplikasi dapat dengan bebas menentukan kebijakan keamanannya menimbulkan masalah keamanan yang serius. Pertama-tama, ini meningkatkan risiko bagi pengguna akhir, karena mereka harus memvalidasi risiko secara terpisah dengan setiap aplikasi yang ingin mereka gunakan.

Ini juga meningkatkan risiko aplikasi yang menggunakan model seperti itu. Keamanan yang terisolasi menambah risiko tambahan terkait perubahan kebijakan keamanan — jika penyerang dapat mengubah model keamanan untuk aplikasi, mungkin juga menonaktifkannya, memberikan kemungkinan untuk menguras dana atau menyalahgunakannya dengan cara lain. Tidak ada lapisan keamanan tambahan di atas aplikasi yang akan melindungi dari penyalahgunaan.

Selain itu, dengan kebijakan keamanan yang dapat berubah secara instan kapan saja, praktis tidak mungkin untuk memantau aplikasi setiap hari dan memberi tahu pengguna tentang risikonya.

Kami menemukannya mirip dengan peningkatan kemampuan kontrak pintar. Kami sudah memperingatkannya di L2BEAT . Kami memberi tahu pengguna tentang rollup dan jembatan yang memiliki mekanisme kemampuan untuk ditingkatkan dalam kontrak pintar mereka, serta mekanisme yang tepat yang mengatur kemampuan untuk ditingkatkan dalam setiap kasus. Ini sudah cukup rumit dan dengan model keamanan yang terisolasi, ini berlipat ganda untuk setiap aplikasi, membuatnya hampir tidak mungkin untuk dilacak secara efektif.

Itulah mengapa kami menganggap model keamanan terisolasi sebagai risiko keamanan itu sendiri, dan kami mendalilkan untuk memperlakukan setiap aplikasi yang menggunakan model seperti itu sebagai berisiko secara default hingga terbukti sebaliknya.

Rencana

Kami memutuskan untuk menguji asumsi kami di dunia nyata, di mainnet. Kerangka kerja LayerZero dipilih untuk percobaan karena merupakan salah satu solusi paling populer yang menggunakan keamanan terisolasi pada intinya. Kami menerapkan token omnichain yang aman dan kemudian konfigurasi keamanan diperbarui yang memungkinkan penarikan token berbahaya. Kode token didasarkan pada contoh yang diberikan oleh LayerZero dan sangat mirip atau identik dengan banyak token dan aplikasi omnichain lainnya yang digunakan dalam produksi.

Namun sebelum kita menyelami detailnya, mari kita lihat sekilas seperti apa model keamanan LayerZero.

Seperti yang dinyatakan dengan jelas oleh laporan resmi LayerZero, "komunikasi antar-rantai yang tidak dapat dipercaya" bergantung pada dua aktor independen (oracle dan relayer) yang bertindak bersama untuk memastikan keamanan protokol.

Seperti yang dinyatakan LayerZero di situs webnya, konsep intinya adalah bahwa ini adalah "titik akhir rantai aplikasi yang dapat dikonfigurasi pengguna yang menjalankan ULN (UltraLightNode)." Komponen on-chain LayerZero bergantung pada dua pihak eksternal off-chain untuk menyampaikan pesan antar rantai — Oracle dan Relayer.

Setiap kali pesan M dikirim dari rantai A ke rantai B, dua tindakan berikut terjadi:

• pertama, Oracle menunggu hingga transaksi yang mengirim pesan M pada rantai A diselesaikan dan kemudian menulis pada rantai B komitmen untuk bundel pesan, misalnya, hash dari header blok (format yang tepat dapat bervariasi antara rantai/oracle yang berbeda) pada rantai A yang berisi pesan M
• kemudian Relayer mengirim ke rantai B sebuah "bukti" (misalnya Bukti Merkle) bahwa header yang disimpan berisi pesan M

LayerZero mengklaim bahwa "desain LayerZero menghilangkan kemungkinan kolusi". Namun pada kenyataannya, pernyataan tersebut tidak benar (yang kami buktikan dalam eksperimen yang ditampilkan di bawah), karena setiap aplikasi pengguna dapat menentukan Relayer dan Oracle-nya sendiri. LayerZero tidak menjamin dengan desain bahwa komponen tersebut independen dan tidak dapat berkolusi. Terserah aplikasi pengguna untuk memberikan jaminan tersebut. Dan jika aplikasi memilih untuk merusaknya, tidak ada mekanisme LayerZero yang dapat menghentikannya.

Selain itu, secara default semua aplikasi pengguna dapat mengubah Relayer dan Oracle kapan saja, sepenuhnya mendefinisikan ulang asumsi keamanan. Jadi tidak cukup hanya memeriksa keamanan aplikasi yang diberikan satu kali, karena mungkin akan berubah kapan saja setelah pemeriksaan, seperti yang akan kami tunjukkan dalam percobaan kami.

Percobaan

Dalam eksperimen kami, kami memutuskan untuk membuat token omnichain sederhana, CarpetMoon, bekerja baik di Ethereum maupun Optimisme, menggunakan ZeroLayer untuk berkomunikasi di antara kedua rantai.

Token kami awalnya menggunakan model keamanan default yang disediakan oleh LayerZero, sehingga terlihat sama seperti sebagian besar (jika tidak semua) aplikasi LayerZero yang saat ini digunakan. Dengan demikian, umumnya sama amannya dengan token lain yang menggunakan LayerZero.

Pertama, kami menggunakan kontrak token kami di Ethereum dan Optimisme:
https://ethtx.info/mainnet/0xf4d1cdabb6927c363bb30e7e65febad8b9c0f6f76f1984cd74c7f364e3ab7ca9/
https://optimistic.etherscan.io/tx/0xf41389d71fa3942de5225efb067072728c6c6de56c241574187781db7c73d221

Dan kami menyiapkan perutean sehingga LayerZero mengetahui kontrak mana yang sesuai dengan kontrak mana di kedua rantai:
https://ethtx.info/mainnet/0x19d78abb03179969d6404a7bd503148b4ac14d711f503752495339c96a7776e9/
https://optimistic.etherscan.io/tx/0x037b1bad33faa5607bb5835460a1d5caaf3a147dc3a09762ac7703befcdb3c3c

Jadi token sudah diatur, terlihat persis seperti semua token omnichain lainnya yang menggunakan LayerZero, dengan konfigurasi default, tidak ada yang mencurigakan.

Kami menyediakan pengguna uji kami, sebut saja dia Alice, dengan token uji, jadi Alice memiliki 1B token CarpetMoon di Ethereum:
https://ethtx.info/mainnet/0x7e2faa8426dacae92830efbf356ca2da760833eca28e652ff9261fc03042b313/

Sekarang Alice menjembatani token tersebut ke Optimisme menggunakan LayerZero.

Kami mengunci token di escrow di Ethereum:
https://ethtx.info/mainnet/0xe4dc3757b86bfda8e7baddc088fb1a599e083ed77034c29e5dd8bd11f1e17771/

Pesan dengan transaksi sedang dikirim ke Optimisme melalui LayerZero:
https://layerzeroscan.com/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/message/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/nonce/1

Dan token yang dijembatani sedang dicetak di Optimisme, Alice sekarang memiliki 1B token MoonCarpet di Optimisme:
https://optimistic.etherscan.io/tx/0x5388ced88cf562acafff82d6798f791b0b38b90ee106df9bf91c0d86306ec302

Oke, jadi semuanya berjalan seperti yang diharapkan, Alice menjembatani tokennya dan melihat ada 1B token MoonCarpet di escrow di Ethereum dan 1B token MoonCarpet di akunnya di Optimism. Tetapi untuk memastikan semuanya berfungsi dengan benar, dia mentransfer kembali setengah dari token (500 juta MoonCarpet) kembali ke Ethereum.

Jadi kita mulai dengan transaksi membakar 500 juta token di Optimism:
https://optimistic.etherscan.io/tx/0x118a57106488ad0bae1f3b920b1fd98b187752ad966f3a901fc53cff47f2097f

Informasi tentang transaksi itu diteruskan ke Ethereum:
https://layerzeroscan.com/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/message/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/nonce/1

Dan, seperti yang diharapkan, 500 juta token MoonCarpet dikirimkan kembali ke alamat Alice dari escrow:
https://etherscan.io/tx/0x27702e07a65a9c6a7d1917222799ddb13bb3d05159d33bbeff2ca1ed414f6a18

Sampai sekarang, semuanya bekerja dengan baik, persis seperti yang diasumsikan. Alice telah memeriksa bahwa dia dapat mentransfer token dari Ethereum ke Optimisme dan kembali lagi, dia tidak memiliki alasan untuk takut dengan token MoonCarpet miliknya.

Tapi katakanlah ada yang tidak beres — misalnya, tim di belakang token kita disusupi, dan aktor jahat Bob mendapatkan akses ke konfigurasi LayerZero untuk aplikasi kita.

Dengan akses tersebut, Bob dapat mengubah Oracle dan Relayer dari default menjadi yang berada di bawah kendalinya.

Harap diingat bahwa ini adalah mekanisme yang disediakan untuk setiap aplikasi menggunakan LayerZero, tertanam dalam arsitektur LayerZero, ini bukan jenis pintu belakang apa pun melainkan mekanisme standar.

Jadi Bob mengubah Oracle menjadi EOA di bawah kendalinya:
https://ethtx.info/mainnet/0x4dc84726da6ca7d750eef3d33710b5f63bf73cbe03746f88dd8375c3f4672f2f/

Dan melakukan hal yang sama dengan Relayer:
https://ethtx.info/mainnet/0xc1d7ba5032af2817e95ee943018393622bf54eb87e6ff414136f5f7c48c6d19a/

Dan sekarang hal-hal aneh terjadi. Dengan Oracle dan Relayer sekarang berada di bawah kendali penuh Bob, dia dapat mencuri token Alice. Meskipun tidak ada tindakan yang terjadi pada Optimisme (token MoonCarpet masih ada di dompet Alice di sana) Bob dapat meyakinkan kontrak pintar MoonCarpet di Ethereum (menggunakan mekanisme LayerZero) bahwa dia membakar token di rantai lain dan dia dapat menarik token MoonCarpet di Ethereum.

Pertama, dia memperbarui blockhash di Ethereum menggunakan Oracle nakal:
https://ethtx.info/0xde2edee2cc7f070120e96c9df90d86696970befcfc221e18c6ac4168bb5b1d92/

Dan sekarang dia dapat menarik token yang tersisa dari escrow:
https://ethtx.info/0xda695f374b375d5372efeca37aae4c5a17f114d5a76db1e86edebb0924bcdcc7/

Hasilnya

Alice bahkan tidak akan tahu mengapa dan kapan sesuatu yang salah terjadi. Tiba-tiba token MoonCarpet miliknya di Optimism tidak lagi didukung oleh token di Ethereum.

Kontrak pintar tidak dapat ditingkatkan dan bertindak sebagaimana dimaksud. Satu-satunya aktivitas yang mencurigakan adalah perubahan Oracle dan Relayer, tetapi ini adalah mekanisme reguler yang ada di dalam LayerZero, jadi Alice bahkan tidak dapat mengetahui apakah perubahan ini disengaja atau tidak. Dan bahkan jika Alice mengetahui tentang perubahan itu, itu sudah terlambat — penyerang dapat menghabiskan dana bahkan sebelum dia dapat bereaksi.

Dan LayerZero juga tidak dapat membantu di sini — ini semua adalah eksekusi sah dari mekanisme mereka, yang tidak dapat mereka kendalikan lagi. Secara teoritis, aplikasi itu sendiri dapat memblokir dirinya sendiri dari mengubah Oracle dan Relayer, tetapi sejauh yang kami tahu tidak ada aplikasi yang sudah diterapkan yang melakukannya.

Kami telah melakukan eksperimen ini untuk memeriksa apakah ada yang menyadarinya, tetapi seperti yang kami duga, tidak ada yang menyadarinya. Hampir tidak mungkin untuk secara efektif memantau semua aplikasi yang dibuat dengan LayerZero untuk memeriksa apakah kebijakan keamanan mereka belum berubah dan memperingatkan pengguna jika itu terjadi.

Bahkan jika seseorang dapat mengetahui bahwa Oracle dan Relayer telah berubah dengan cara yang menimbulkan risiko keamanan, ketika itu terjadi sudah terlambat. Karena Oracle dan Relayer baru sekarang dapat dengan bebas memilih untuk menyensor atau hanya menonaktifkan komunikasi antar rantai, pengguna biasanya tidak dapat berbuat apa-apa. Hal ini ditunjukkan dengan jelas dalam eksperimen kami, karena meskipun Alice mengetahui perubahan dalam konfigurasi aplikasi, dia tidak dapat berbuat banyak dengan token penghubungnya — Oracle dan Relayer baru tidak lagi mendengarkan rantai asli sehingga mereka tidak menyampaikan pesan kembali ke Ethereum.

Kesimpulan dan CTA

Seperti yang dapat kita lihat di atas, meskipun token kami dibuat menggunakan LayerZero dan menggunakan mekanismenya sebagaimana dimaksud, kami dapat mencuri dana dari escrow token. Tentu saja, itu adalah kesalahan aplikasi (token KarpetMoon dalam kasus kami) dan bukan LayerZero itu sendiri, tetapi itu membuktikan bahwa LayerZero dengan sendirinya tidak memberikan jaminan keamanan apa pun .

Ketika LayerZero menjelaskan model keamanan mereka terkait Oracle dan Relayer, mereka berasumsi bahwa pemilik aplikasi (atau seseorang yang memiliki kunci pribadinya) tidak akan melakukan sesuatu yang tidak rasional. Tapi anggapan itu tidak benar dalam lingkungan yang bermusuhan. Selain itu, pengguna harus mempercayai pemilik aplikasi sebagai pihak ketiga yang tepercaya.

Dalam praktiknya, sebagai akibatnya, seseorang tidak dapat membuat asumsi apa pun tentang keamanan aplikasi yang dibangun menggunakan LayerZero — setiap aplikasi harus dianggap berisiko hingga terbukti sebaliknya.

Sebenarnya, keseluruhan cerita dimulai untuk kami dengan PR yang kami rencanakan untuk memasukkan semua token omnichain di situs L2BEAT — kami mengalami kesulitan untuk mengetahui cara menilai risikonya. Saat menganalisis vektor risiko, kami mendapatkan ide untuk eksperimen kami.

Untuk L2BEAT, konsekuensinya adalah kami harus memberi peringatan di atas setiap aplikasi yang dibangun menggunakan LayerZero, memperingatkan tentang kemungkinan risiko keamanan. Namun kami ingin membuka diskusi yang lebih luas tentang model keamanan, karena kami percaya bahwa keamanan yang terisolasi adalah anti-pola yang harus dihindari, terutama di ruang kami.

Kami yakin bahwa karena model keamanan yang terisolasi seperti di LayerZero menjadi semakin populer, akan semakin banyak proyek yang menyalahgunakannya, menyebabkan banyak kerusakan dan meningkatkan ketidakpastian tentang keseluruhan industri.