Artikel ini merupakan kiriman dari komunitas. Penulisnya adalah Minzhi He, seorang auditor di CertiK.
Pandangan dalam artikel ini berasal dari kontributor/penulis dan tidak mencerminkan pandangan Binance Academy.
Ringkasan
Bridge blockchain penting dalam mencapai interoperabilitas di bidang blockchain. Oleh karena itu, keamanan bridge sangatlah penting. Beberapa kerentanan keamanan umum dari bridge meliputi validasi on-chain dan off-chain yang lemah, penanganan token asli yang tidak benar, serta kesalahan konfigurasi. Pengujian bridge terhadap semua kemungkinan vektor serangan disarankan untuk memastikan logika verifikasi yang masuk akal.
Pendahuluan
Bridge blockchain adalah protokol yang menghubungkan dua blockchain untuk memungkinkan interaksi di antara keduanya. Jika Anda memiliki bitcoin tetapi ingin berpartisipasi dalam aktivitas DeFi di jaringan Ethereum, bridge blockchain memungkinkan Anda untuk melakukannya tanpa menjual bitcoin.
Bridge blockchain sangat penting untuk mencapai interoperabilitas dalam bidang blockchain. Bridge ini berfungsi menggunakan berbagai validasi on-chain dan off-chain, sehingga memiliki berbagai kerentanan keamanan.
Mengapa Keamanan Bridge Penting?
Bridge biasanya menyimpan token yang ingin ditransfer oleh pengguna dari satu chain ke chain lain. Bridge sering kali diterapkan sebagai smart contract dan menyimpan sejumlah besar token seiring transfer cross-chain terakumulasi, sehingga menjadi sasaran yang menggiurkan bagi peretas.
Selain itu, bridge blockchain memiliki celah serangan yang besar karena melibatkan banyak komponen. Oleh karena itu, pelaku kejahatan sangat termotivasi untuk menargetkan aplikasi cross-chain guna menguras sejumlah besar dana.
Serangan bridge telah menyebabkan kerugian sebesar lebih dari 1,3 miliar USD pada tahun 2022 yang merupakan 36% dari total kerugian tahun tersebut berdasarkan perkiraan CertiK.
Kerentanan Keamanan Umum dari Bridge
Untuk meningkatkan keamanan bridge, penting untuk memahami kerentanan keamanan umum dari bridge dan menguji bridge sebelum diluncurkan. Kerentanan ini dapat dikategorikan ke dalam empat area.
Validasi on-chain yang lemah
Untuk bridge sederhana, khususnya yang dirancang untuk DApp tertentu, validasi on-chain minim. Bridge tersebut mengandalkan backend tersentralisasi untuk mengeksekusi operasi dasar seperti pencetakan, burning, dan transfer token sementara semua verifikasi dilakukan secara off-chain.
Sebaliknya, bridge jenis lain menggunakan smart contract untuk memvalidasi pesan dan melakukan verifikasi secara on-chain. Dalam situasi ini, saat pengguna menyetor dana ke dalam sebuah chain, smart contract akan menghasilkan pesan bertanda tangan dan mengembalikan tanda tangan tersebut di dalam transaksi. Tanda tangan ini berfungsi sebagai bukti penyetoran dan digunakan untuk memverifikasi permintaan pengguna pada chain lain. Proses ini seharusnya dapat mencegah berbagai serangan keamanan, termasuk serangan replay dan catatan setoran palsu.
Namun, jika terdapat kerentanan selama proses validasi on-chain, penyerang bisa menyebabkan kerusakan yang parah. Misalnya, jika sebuah bridge menggunakan Merkle tree untuk memvalidasi catatan transaksi, penyerang dapat menghasilkan bukti palsu. Artinya, mereka dapat memintas validasi bukti dan mencetak token baru ke akun mereka jika proses validasi rentan.
Beberapa bridge mengimplementasikan konsep “wrapped token”. Misalnya, ketika pengguna mentransfer DAI dari Ethereum ke BNB Chain, DAI miliknya diambil dari kontrak Ethereum, lalu wrapped DAI dalam jumlah setara akan diterbitkan pada BNB Chain.
Namun, jika transaksi ini tidak divalidasi dengan benar, penyerang dapat menerapkan kontrak berbahaya untuk merutekan wrapped token dari bridge ke alamat yang salah dengan memanipulasi fungsinya.
Penyerang juga memerlukan korban menyetujui kontrak bridge untuk mentransfer token menggunakan fungsi “transferFrom” guna menguras aset dari kontrak bridge.
Sayangnya, hal ini menjadi makin buruk karena kebanyakan bridge meminta persetujuan token tak terbatas dari pengguna DApp. Ini merupakan praktik umum yang menurunkan biaya gas, tetapi menimbulkan risiko tambahan dengan mengizinkan smart contract mengakses token dari dompet pengguna dalam jumlah tak terbatas. Penyerang dapat memanfaatkan kurangnya validasi dan persetujuan yang berlebih untuk mentransfer token dari pengguna lain ke diri mereka sendiri.
Validasi off-chain yang lemah
Dalam beberapa sistem bridge, server backend off-chain berperan penting dalam memverifikasi kesahan pesan yang dikirim dari blockchain. Dalam hal ini, kita berfokus pada verifikasi transaksi penyetoran.
Cara kerja sebuah bridge blockchain dengan validasi off-chain adalah sebagai berikut:
Pengguna berinteraksi dengan DApp untuk menyetor token ke dalam smart contract pada chain sumber.
Kemudian, DApp mengirim hash transaksi penyetoran ke server backend melalui API.
Hash transaksi memerlukan beberapa validasi oleh server. Jika dianggap sah, penanda tangan akan menandatangani pesan, lalu mengirim kembali tanda tangan tersebut ke antarmuka pengguna melalui API.
Setelah menerima tanda tangan, DApp memverifikasinya, lalu mengizinkan pengguna untuk menarik token dari chain target.
Server backend harus memastikan bahwa transaksi penyetoran yang diproses benar-benar terjadi dan tidak dipalsukan. Server backend ini menentukan apakah pengguna dapat menarik token pada chain target, sehingga menjadi sasaran yang bernilai tinggi bagi para penyerang.
Server backend harus memvalidasi struktur peristiwa yang dihasilkan dari transaksi serta alamat kontrak yang menghasilkan peristiwa tersebut. Jika alamat kontrak diabaikan, maka penyerang dapat menerapkan kontrak berbahaya untuk memalsukan peristiwa penyetoran menggunakan struktur yang sama dengan peristiwa penyetoran yang sah.
Jika tidak memverifikasi alamat yang menghasilkan peristiwa tersebut, server backend dapat menganggap kontrak ini valid, lalu menandatangani pesan. Kemudian, penyerang dapat mengirim hash transaksi ke backend sehingga memintas verifikasi dan memungkinkan mereka untuk menarik token dari chain target.
Penanganan token asli yang tidak benar
Bridge mengambil berbagai pendekatan terhadap penanganan token asli dan token utilitas. Misalnya, di jaringan Ethereum, token aslinya adalah ETH dan sebagian besar token utilitas mengikuti standar ERC-20.
Ketika seorang pengguna berniat untuk mentransfer ETH miliknya ke chain lain, dia harus menyetornya ke dalam kontrak bridge terlebih dahulu. Untuk mencapainya, pengguna cukup melampirkan ETH ke transaksi, lalu jumlah ETH dapat diambil dengan membaca bidang “msg.value” dari transaksi.
Penyetoran token ERC-20 sangat berbeda dari penyetoran ETH. Untuk menyetor token ERC-20, pengguna harus mengizinkan kontrak bridge untuk menggunakan tokennya terlebih dahulu. Setelah dia menyetujuinya dan menyetorkan token ke dalam kontrak bridge, kontrak akan melakukan burning terhadap token pengguna menggunakan fungsi "burnFrom()" atau mentransfer token pengguna ke kontrak menggunakan fungsi "transferFrom()".
Salah satu pendekatan untuk membedakannya adalah dengan menggunakan pernyataan if-else dalam fungsi yang sama. Pendekatan lainnya adalah dengan membuat dua fungsi terpisah untuk menangani masing-masing skenario. Percobaan untuk menyetor ETH menggunakan fungsi penyetoran ERC-20 dapat menyebabkan hilangnya dana.
Saat menangani permintaan penyetoran ERC-20, pengguna biasanya memberikan alamat token sebagai input ke fungsi penyetoran. Tindakan ini menimbulkan risiko yang signifikan, karena panggilan eksternal yang tidak tepercaya dapat terjadi selama transaksi. Menerapkan whitelist yang hanya menyertakan token yang didukung oleh bridge adalah praktik umum untuk meminimalkan risiko. Hanya alamat yang masuk whitelist yang diizinkan untuk diteruskan sebagai argumen. Hal ini mencegah panggilan eksternal, karena tim proyek sudah memfilter alamat token.
Namun, masalah juga muncul ketika bridge menangani transfer cross-chain token asli, karena token asli tidak memiliki alamat. Alamat nol (0x000...0) mewakili token asli. Hal ini dapat menjadi masalah, karena meneruskan alamat nol ke fungsi dapat memintas verifikasi whitelist meskipun diimplementasikan dengan tidak benar.
Ketika kontrak bridge memanggil “transferFrom” untuk mentransfer aset pengguna ke kontrak, panggilan eksternal ke alamat nol menghasilkan false karena tidak ada fungsi “transferFrom” yang diimplementasikan dalam alamat nol. Namun, transaksi masih dapat terjadi jika kontrak tidak dapat menangani nilai hasilnya dengan benar. Hal ini menciptakan peluang bagi penyerang untuk mengeksekusi transaksi tanpa mentransfer token ke kontrak.
Kesalahan konfigurasi
Dalam sebagian besar bridge blockchain, sebuah posisi istimewa bertanggung jawab dalam memasukkan token dan alamat ke whitelist atau blacklist, menetapkan atau mengubah penanda tangan, dan konfigurasi penting lainnya. Memastikan bahwa semua konfigurasi akurat sangatlah penting, karena kesalahan yang tampak sepele pun dapat menyebabkan kerugian yang besar.
Bahkan, dalam suatu insiden, penyerang berhasil memintas verifikasi catatan transfer karena sebuah kesalahan konfigurasi. Tim proyek tersebut mengimplementasikan peningkatan protokol beberapa hari sebelum peretasan yang mencakup perubahan sebuah variabel. Variabel tersebut digunakan untuk mewakili nilai default dari pesan yang tepercaya. Perubahan ini menyebabkan semua pesan dianggap terbukti secara otomatis, sehingga memungkinkan penyerang untuk mengirim pesan sesuka hati dan lolos proses verifikasi.
Cara Meningkatkan Keamanan Bridge
Empat kerentanan umum dari bridge yang dijelaskan di atas menunjukkan tantangan dalam memastikan keamanan di sebuah ekosistem blockchain yang saling terhubung. Ada pertimbangan signifikan terkait penanganan setiap kerentanan tersebut. Tidak ada pedoman tunggal yang berlaku untuk semuanya.
Misalnya, memberikan pedoman umum untuk memastikan proses verifikasi bebas kesalahan adalah hal yang sulit dilakukan, karena setiap bridge memiliki persyaratan verifikasi yang unik. Pendekatan yang paling efektif untuk mencegah pemintasan verifikasi adalah menguji bridge secara menyeluruh terhadap semua kemungkinan vektor serangan dan memastikan bahwa logika verifikasinya masuk akal.
Ringkasnya, penting untuk melakukan pengujian yang ketat terhadap potensi serangan dan memberikan perhatian khusus terhadap kerentanan keamanan umum dalam bridge.
Penutup
Karena bernilai tinggi, cross-chain bridge telah lama menjadi target penyerang. Pembangun dapat memperkuat keamanan bridge dengan melakukan pengujian yang menyeluruh sebelum penerapan dan melakukan audit pihak ketiga untuk mengurangi risiko peretasan merugikan yang telah menjangkiti bridge selama beberapa tahun terakhir. Bridge sangat penting dalam dunia multi-chain, tetapi keamanan harus menjadi perhatian utama saat merancang dan membangun infrastruktur Web3 yang efektif.
Bacaan Lebih Lanjut
Apa Itu Interoperabilitas Cross-Chain?
Tiga Bridge Kripto Populer dan Cara Kerjanya
Penafian dan Peringatan Risiko: Konten ini disajikan kepada Anda dengan dasar “sebagaimana adanya” untuk informasi umum dan tujuan pendidikan saja tanpa pernyataan atau jaminan dalam bentuk apa pun. Konten ini tidak boleh dianggap sebagai nasihat keuangan, hukum, atau profesional lainnya ataupun dimaksudkan untuk menyarankan pembelian produk atau jasa tertentu. Anda sebaiknya mencari nasihat dari penasihat profesional yang sesuai. Jika artikel merupakan kontribusi dari kontributor pihak ketiga, harap diperhatikan bahwa pandangan yang dinyatakan berasal dari kontributor pihak ketiga dan tidak mencerminkan pandangan Binance Academy. Silakan baca penafian lengkap kami di sini untuk detail lebih lanjut. Harga aset digital dapat menjadi volatil. Nilai investasi Anda mungkin turun atau naik. Anda mungkin tidak mendapatkan kembali jumlah yang sudah diinvestasikan. Anda bertanggung jawab sepenuhnya terhadap keputusan investasi Anda. Binance Academy tidak bertanggung jawab terhadap kerugian yang mungkin Anda alami. Materi ini tidak boleh dianggap sebagai nasihat keuangan, hukum, atau profesional lainnya. Untuk informasi selengkapnya, baca Ketentuan Penggunaan dan Peringatan Risiko kami.