Mengapa jembatan lintas rantai mengalami begitu banyak kecelakaan tingkat rendah?

kata pengantar

Masalah keamanan lintas-rantai yang sering terjadi baru-baru ini telah menarik perhatian luas dari pasar.Artikel ini berharap untuk memulai dari perspektif desain produk dan memberi tahu pembaca mengapa ada begitu banyak masalah keamanan produk di jalur ini. Harus dinyatakan bahwa masalah yang disebutkan dalam artikel tidak ada di setiap proyek. Sebagian besar masalah telah dirancang dengan strategi penanggulangan yang relevan. Tujuan artikel ini terutama untuk berharap lebih banyak orang dapat memahami trek ini. Kompleksitas .

Logika penulisan artikel ini adalah: pertama jelaskan dengan jelas bagaimana jembatan lintas rantai umum dirancang, perdalam pemahaman pembaca tentang jembatan lintas rantai, dan kemudian rangkum masalah keamanan yang mungkin dihadapi oleh jembatan lintas rantai ini.

1: Solusi lintas rantai yang selalu berubah

Laporan penelitian sebelumnya sebenarnya telah menjelaskan beberapa jenis solusi lintas rantai informasi kepada semua orang, apa pun presentasi akhirnya, dari perspektif desain produk, hanya rantai samping (rantai samping dalam arti luas, dalam teks) Berbicara rollup, itu juga dapat diringkas menjadi tiga mekanisme: rantai samping, kunci waktu hash, dan notaris.

(1) Rantai samping

Di antara ketiga skema tersebut, skema sidechain memiliki keamanan paling tinggi, seperti berbagai rollup dan polkadot parachain. Keamanan dibagi antara rantai utama dan rantai samping.

Namun, skema sidechain umumnya membutuhkan rantai asli dan rantai target menjadi isomorfik, sehingga skenario yang dapat diterapkan jauh lebih sedikit. Ini juga alasan mengapa Vitalik setuju dengan multi-chain, tetapi bukan cross-chain, karena terlalu banyak masalah dengan solusi cross-chain yang tidak dapat berbagi keamanan.

(2) Kunci waktu hash

Solusi ini mengklaim sebagai solusi lintas-rantai heterogen peer-to-peer yang paling terdesentralisasi, tetapi biayanya tinggi dan waktu tunggu pengguna terlalu lama, sehingga tingkat adopsi saat ini tidak tinggi. Dan ketika kita masih membutuhkan pihak ketiga untuk bertindak sebagai simpul perantara untuk pertukaran mata uang, kita juga memerlukan apa yang disebut lapisan konsensus perantara untuk memenuhi persyaratan keamanan dan desentralisasi.

(3) Mekanisme Notaris

Ini saat ini adalah solusi jembatan lintas rantai heterogen yang paling umum digunakan.Sebagian besar produk di pasar pada dasarnya berasal dari yang sama, dan hampir tidak ada perbedaan dari perspektif desain produk. Perbedaan utama mungkin berfokus pada metode dan langkah-langkah verifikasi informasi, algoritme konsensus notaris, algoritme tanda tangan dompet escrow, dll. Tidak banyak perbedaan dalam hal pengalaman pengguna dan keamanan. Oleh karena itu, dari segi keamanan, risiko keamanan yang dihadapi juga memiliki banyak kesamaan.

Artikel ini akan berfokus pada meringkas dan menganalisis beberapa risiko keamanan umum yang dihadapi oleh jembatan lintas rantai dari mekanisme notaris.

Dua: Proses logika produk dari mekanisme notaris

Sebelum memahami berbagai risiko yang dihadapi oleh mekanisme notaris, kita perlu memahami logika desain solusi jenis ini dari sudut pandang produk.

(1) Pengantar singkat

Solusi ini sebenarnya sangat sederhana dari perspektif filosofi desain. Saat kita menghadapi kebutuhan aset heterogen lintas rantai, solusi paling intuitif sebenarnya adalah "pemetaan". Pemetaan berarti ketika pengguna A mentransfer ETH dari Ethereum ke Fantom. Kami tidak perlu mentransfer aset secara fisik, atau menerbitkannya kembali di Fantom (tidak bisa). Alih-alih, pertama-tama simpan ETH pengguna A di alamat yang tidak dapat dipindahkan, lalu terbitkan aset yang dipetakan 1:1 yang sesuai di Fantom sesuai dengan jumlah ETH pengguna A yang disimpan di alamat ini. Aset yang dipetakan mewakili hak untuk menggunakan ETH tersebut pada rantai Ethereum asli. Karena jangkar 1:1, pengguna di Fantom juga mengenali nilai aset ini.

Proses lintas rantai yang paling disederhanakan

(2) Kesulitan dalam desain

Akan ada banyak masalah dalam hal ini, masalah terbesar adalah pengelolaan dompet multi-tanda tangan, karena penyeberangan ETH dari Ethereum ke Fantom adalah deposit, dan jika pengguna A ingin menyeberang kembali, itu akan melibatkan masalah penarikan koin.

Desentralisasi dan keamanan deposit dan penarikan telah menjadi kesulitan terbesar.

1: Siapa yang akan mengelola uang?

2: Siapa yang akan memulai?

3: Siapa yang akan memantau transaksi?

4: Bagaimana cara mengonfirmasi bahwa memang ada pengguna yang mentransfer uang?

5: Bagaimana cara memastikan bahwa uang pengguna memang ingin ditarik oleh pengguna sendiri?

6: Bagaimana mencegah serangan replay?

7: Bagaimana cara mengajukan kembali transaksi yang gagal?

8: Bagaimana jika manajer multi-tanda tangan melakukan kejahatan?

9: Apa yang harus saya lakukan jika ada waktu henti?

Saya tidak berani memikirkannya, semakin saya memikirkannya, semakin rumit rasanya. Teknologi jembatan lintas-rantai tidak hanya melibatkan multi-tanda tangan, tetapi juga melibatkan penerbitan aset, pemantauan lintas-rantai, verifikasi asinkron, dan bahkan perlu mengeluarkan lapisan konsensus perantara independen (rantai baru).

Oleh karena itu, untuk lebih menyederhanakan kesulitan yang dipahami pengguna, saya akan membagi seluruh proses rantai silang menjadi dua bagian: setoran dan penarikan. Untuk membantu Anda mempelajari lebih lanjut tentang:

(3) Penyempurnaan proses lebih lanjut

1: Setor koin

Pertama-tama, izinkan saya menyatakan bahwa proses yang digambarkan pada gambar di bawah ini hanyalah rencana desain saya sendiri yang disimpulkan tanpa argumentasi yang cermat. Tujuannya adalah untuk mengeksplorasi kemungkinan masalah keamanan dalam logika desain, dan tidak dapat diadopsi sebagai rencana final. Itu semua omong kosong.

Seperti yang ditunjukkan pada gambar: transaksi deposit dari rantai asli ke rantai target pada prinsipnya akan mencakup langkah-langkah berikut:

(1) Pengguna mengisi ulang ke alamat hosting

(2) Setelah pendengar memantau transaksi, BP (simpul konsensus juga merupakan administrator multi-tanda tangan) memulai transaksi

(3) Kontrak memverifikasi kebenaran tanda tangan BP

(4) Apakah ada mekanisme toleransi kesalahan node

(5) Jika tidak ada panggilan balik, jika ada, isi ulang alamat rantai target sesuai dengan hubungan alamat yang dipetakan

(6) BP mengonfirmasi transaksi isi ulang

(7) Transfer token pemetaan ke alamat pengguna di rantai target setelah melewati Byzantium

Perlu dicatat bahwa proses ini ditujukan untuk membahas rantai silang heterogen umum, jadi dibandingkan dengan anyswap dan solusi lainnya, ini menambahkan langkah yang memungkinkan pengguna untuk mengikat hubungan alamat pada lapisan konsensus perantara. Hal ini terutama disebabkan oleh perbedaan cara melampirkan informasi ke transaksi rantai heterogen yang berbeda.Untuk menghadapinya secara seragam, lebih baik biarkan pengguna mengikat hubungan pemetaan terlebih dahulu.

Jika Anda berurusan dengan transaksi pada rantai EVM, Anda tidak memerlukan langkah ini, cukup lampirkan alamat rantai target saat memulai transaksi.

Kembali ke topik: Dari proses di atas, kita dapat melihat bahwa mulai dari langkah kedua, kita akan menemui berbagai masalah verifikasi logika dan memproses masalah dalam situasi yang berbeda.

Logika verifikasi utama meliputi:

(1) Setelah mendengarkan transaksi, verifikasi transaksi yang memulai pemetaan aset dan transfer ke rantai target pengguna A

(2) Inisiasi transaksi rantai target dan verifikasi hasil transaksi

Tentu saja, selain logika verifikasi yang ditarik dalam proses saya, itu juga harus mencakup verifikasi masalah isi ulang mata uang palsu, serta masalah pemrosesan khusus yang perlu dilakukan saat memanggil token yang berbeda. Untuk lebih meringkas potensi bahaya keamanan yang mungkin timbul di masa mendatang, mari terus pahami proses penarikan koin.

2: Tarik koin

Proses yang ditunjukkan oleh penarikan koin adalah logika pertukaran aset rantai target kembali ke aset rantai asli Penting untuk dicatat bahwa banyak token saat ini memiliki beberapa versi rantai, yang berarti bahwa banyak token berada di banyak rantai Token asli sendiri. Oleh karena itu, beberapa proyek jembatan sering kali menyiapkan kumpulan aset. Dalam hal kumpulan dana yang cukup, pengguna tidak akan merasakan keberadaan aset yang dipetakan seperti DAI apa pun, tetapi langsung menggantinya dengan token versi rantai target, tetapi ini tidak memengaruhi logika keseluruhan. Jadi, analisisnya berlanjut:

Seperti yang ditunjukkan pada gambar: aliran transaksi dari rantai target ke rantai asli adalah sebagai berikut:

(1) Pengguna memulai transaksi (mentransfer jumlah yang sama dari aset yang dipetakan ke dompet escrow pada rantai target)

(2) Verifikasi identitas BP, dan BP memulai permintaan penarikan

(3) Konfirmasi otoritas penarikan dan tanda tangan

(4) Selesaikan permintaan untuk menarik koin pada rantai asli setelah melewati Byzantium, dan transfer uang dari dompet penyimpanan rantai asli ke pengguna A

(5) Jika ada kesalahan verifikasi node atau downtime di tengah, perlu di-rollback dan diinisiasi ulang

Seperti dapat dilihat dari proses di atas, logika verifikasi utama yang terlibat di sini adalah:

(1) Verifikasi kewenangan inisiasi dan tanda tangan

(2) Mekanisme toleransi kesalahan setelah masalah terjadi

(4) Risiko keamanan

1: Masalah keamanan dalam logika desain

Setelah pemahaman yang lebih hati-hati tentang desain jembatan lintas rantai, kita dapat menemukan bahwa ada banyak tantangan dalam logika desain jembatan lintas rantai.Untuk meringkas, ada tiga masalah utama (kasus pencurian yang relevan ditandai di akhir pertanyaan)

(1) Setoran

a) Ada celah dalam otoritas kontrak pengisian koin, yang mengarah pada transfer langsung dari uang yang dibebankan. Ini adalah pertanyaan bodoh yang akan dihadapi hampir semua proyek kontrak,

b) Masalah isi ulang mata uang palsu, beberapa proyek belum memverifikasi keaslian Token lintas rantai, menghasilkan fakeTOKEN -> realTOKEN (anyswap), sejujurnya, ini agak bodoh.

c) Masalah top-up mata uang palsu, aset asli seperti ETH berbeda dari kontrak ERC20, dan banyak serangan disebabkan oleh penanganan ETH yang tidak tepat, mengakibatkan fakeETH -> realETH, itulah sebabnya aset yang dibungkus seperti WETH populer . (rantai rantai)

d) Meskipun Token yang berbeda adalah semua standar ERC20, metode implementasi spesifiknya berbeda, atau ada logika tambahan (rebase, fallback, dll.), pengembang tidak melakukan penelitian dengan baik saat beradaptasi, seperti (WETH, PERI , OMT , WBNB, MATIC, AVAX), dll. akan memanggil fungsi fallback kustom pengirim untuk melakukan operasi tambahan setelah transfer selesai, yang meningkatkan kompleksitas penilaian jembatan lintas rantai (anyswap 2022.1.18)

(2) Transfer pesan lintas rantai

Setelah deposit a-chain selesai dan sebelum aset b-chain tiba di akun, jembatan lintas rantai ditangani seperti sistem blockchain independen, yang memerlukan mekanisme konsensus, umumnya menggunakan dpos, dan semua yang berikut diasumsikan gunakan Masalah dpos untuk dipertimbangkan, tetapi saya menduga bahwa semua node termasuk dalam sisi proyek, dan ada risiko sentralisasi di tempat pertama.

a) Untuk memantau pesan setoran koin, siapa yang pertama kali memulai proposal pemrosesan lintas rantai, secara acak? Atau bergantian? Atau sesuai dengan urutan blok yang dihasilkan oleh lapisan konsensus menengah?

b) Bagaimana beberapa notaris memverifikasi kebenaran setoran?Jika sumber data semuanya dari penyedia data seperti infura, infura adalah satu titik risiko.Hal yang paling aman adalah mempertahankan node mereka sendiri, yang menghabiskan banyak biaya.

c) Cara mengonfirmasi bahwa pemrosesan lintas rantai telah selesai (b telah diunggah ke akun), dan ada beberapa situasi di mana pemrosesan tidak selesai:

i. Jembatan rantai silang tidak memulai pemrosesan

ii. Jembatan lintas rantai memulai pemrosesan, tetapi verifikasi & konsensus gagal

iii. Verifikasi jembatan cross-chain dilewati, tetapi tidak ada transaksi yang dimulai pada b-chain

iv.b Ada transaksi di rantai, tetapi gagal (dana tidak mencukupi atau keadaan lain)

(3) Masalah verifikasi multi-tanda tangan

Area yang paling terpukul dengan masalah yang sering terjadi, kebanyakan adalah masalah logika kode

a) 3/5 tanda tangan, saya secara acak membuat tanda tangan yang tidak ada dalam daftar multi-tanda tangan, itu juga +1 (chainswap).

b) Masalah sentralisasi, nominal multi-sig, sebenarnya berada di tangan pihak proyek, yang menimbulkan risiko sentralisasi yang sangat besar.

c) Metode verifikasi tanda tangan, mode pengembangan pada rantai yang berbeda berbeda, yang pasti akan menyebabkan pengembang ketinggalan saat merapat, contoh lubang cacing: fungsi tanda tangan verifikasi pada solana adalah fungsi dalam kontrak sistem, dan kontrak sistem harus dipanggil secara normal , alamat kontrak sistem harus dikodekan dalam kode. Di sini mereka meneruskan alamat kontrak sistem sebagai parameter. Ketika peretas menarik mata uang, dia memberikan alamat kontrak sistem palsu, yang melewati verifikasi tanda tangan dan menarik mata uang lancar. .

(4) Pengembalian dana

a) Seperti yang dibahas dalam (2)-c, ada banyak kemungkinan untuk status cross-chain. Dalam hal apa pun, pengguna perlu menyediakan metode pengembalian dana. Misalnya, ketika anyswap menyetorkan koin, pertama-tama ia akan mengirim pengguna anyToken , lalu kirim anyToken ke pengguna di rantai target, lalu bakar anyToken dari rantai sumber.Tujuan dari ini adalah bahwa di mana pun masalahnya, pengguna dapat mewakili aset mereka sendiri dengan memegang anyToken. Ada 3 rantai (sumber, target, jembatan lintas rantai) dan 4 aset (Token asli/anyToken pada rantai sumber dan rantai target) dalam proses ini, yang sangat rentan terhadap masalah logika kode.

b) Kerentanan Thorchain terungkap pada 23 Juli 2021. Peretas menggunakan masalah logika kode untuk membuat isi ulang palsu dalam jumlah besar. Jembatan lintas rantai tidak dapat menanganinya, sehingga masuk ke logika pengembalian dana, menyebabkan peretas mendapatkan keuntungan besar pengembalian dana.

2: Risiko keamanan lainnya

Namun masalah yang dapat ditunjukkan melalui proses logika hanyalah masalah logika bisnis, tidak semuanya.

Dari sudut pandang keamanan, kita juga harus mempertimbangkan tiga risiko lainnya:

(1) Risiko sistemik

Misalnya, deposit rantai asli berhasil di awal, lalu dibatalkan. Ini adalah masalah besar. V Tuhan telah membahas bahwa aset ditransfer dari Solana ke Ethereum. Setelah lintas rantai selesai, Solana memutar kembali , dan aset pengguna akan berlipat ganda.solusi.

Tetapi lapisan 2, seperti rollup, yang berbagi keamanan dengan Ethereum, tidak memiliki masalah ini.

(2) Risiko front-end

a) URL palsu, seperti oxdao.fi 0xdao.fi oxdai.fi dll.

b) Serangan Xss, yaitu serangan skrip lintas situs , adalah serangan injeksi kode, seperti www. Perhatikan untuk mencegah xss, kode ini akan dieksekusi pada halaman, menyebabkan pengguna mengotorisasi tanda tangan transfer peretas transaksi, jadi jangan membuka tautan dari sumber yang tidak dikenal.

c) Serangan layanan lintas situs Cors Di bawah kebijakan asal-usul yang ketat, browser hanya diizinkan untuk memuat konten dari situs ini, yaitu, semua konten yang ditampilkan di situs www.xxxx.finance dan antarmuka yang dipanggil harus berasal dari xxxx Keuangan nama domain, tetapi sebagian besar proyek saat ini memungkinkan panggilan lintas situs, yaitu front-end xxxx dapat memanggil antarmuka quickswap, dan sebaliknya, yang membawa kemudahan untuk pengembangan, tetapi juga membawa risiko:

Jika saya mengunjungi xxxx.finance, menyimpan beberapa data sensitif di cache browser, lalu saya mengunjungi situs web berbahaya, jika kebijakan asal yang sama dari xxxx tidak dibatasi, situs web jahat ini dapat dengan bebas memperoleh data yang disimpan di cache xxxx .

(3) Risiko fungsi tambahan

Beberapa proyek jembatan lintas rantai tidak hanya menyediakan aset lintas rantai, tetapi juga menyediakan panggilan kontrak lintas rantai, yang membawa kerumitan tambahan.

Penyerang memulai panggilan ke kontrak x pada rantai b pada rantai, dan jembatan lintas rantai memanggilnya secara langsung terlepas dari kontrak x Tanpa diduga, kontrak x adalah kontrak multi-tanda dari jembatan lintas rantai pada rantai b. Ini untuk mengubah akun multi-tanda tangan ke alamat penyerang sendiri. Setelah eksekusi berhasil, peretas dapat dengan bebas mengontrol dana jembatan lintas rantai di b-chain (jaringan poli).

Tiga: Kesimpulan

1: Tujuan dari laporan ini adalah untuk membantu pengguna memiliki pemahaman yang lebih jelas tentang risiko keamanan jembatan lintas-rantai, dan ini bukan rendering berbahaya tentang bagaimana jembatan lintas-rantai yang rentan diserang.

2: Solusi jembatan lintas rantai dari mekanisme notaris adalah solusi dengan pengalaman terbaik, cakupan aplikasi terluas dan biaya terendah setidaknya untuk saat ini. Dan produk apa pun akan melalui proses dari bekas luka hingga matang, dan serangan terhadap produk blockchain seringkali merupakan "masalah logis". Pertanyaan-pertanyaan ini pasti akan menjadi lebih baik dengan waktu dan pengalaman.