Artikel ini adalah kiriman komunitas. Penulisnya adalah Minzhi He, auditor di CertiK.
Pandangan dalam artikel ini adalah milik kontributor/penulis dan tidak mencerminkan pandangan Binance Academy.
TL;DR
Jembatan Blockchain sangat penting dalam mencapai interoperabilitas di ruang blockchain. Oleh karena itu, keamanan jembatan sangatlah penting. Beberapa kerentanan keamanan jembatan yang umum mencakup validasi on-chain dan off-chain yang lemah, penanganan token asli yang tidak tepat, dan kesalahan konfigurasi. Disarankan untuk menguji jembatan terhadap semua kemungkinan vektor serangan untuk memastikan logika verifikasi yang baik.
Perkenalan
Jembatan 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, jembatan blockchain memungkinkan Anda melakukannya tanpa menjual bitcoin Anda.
Jembatan blockchain sangat penting untuk mencapai interoperabilitas dalam ruang blockchain. Jembatan ini berfungsi menggunakan berbagai validasi on-chain dan off-chain dan karenanya memiliki kerentanan keamanan yang berbeda.
Mengapa Keamanan Jembatan Penting?
Bridge biasanya menyimpan token yang ingin ditransfer pengguna dari satu rantai ke rantai lainnya. Sering digunakan sebagai kontrak pintar, bridge menyimpan sejumlah besar token saat transfer lintas rantai terakumulasi, menjadikannya target yang menguntungkan bagi para peretas.
Selain itu, jembatan blockchain memiliki permukaan serangan yang besar karena melibatkan banyak komponen. Dengan mempertimbangkan hal itu, pelaku kejahatan sangat termotivasi untuk menargetkan aplikasi lintas rantai untuk menguras sejumlah besar dana.
Serangan jembatan menyebabkan kerugian lebih dari 1,3 miliar USD pada tahun 2022, yang mencakup 36% dari total kerugian tahun ini, menurut perkiraan CertiK.
Kerentanan Keamanan Jembatan Umum
Untuk meningkatkan keamanan jembatan, penting untuk memahami kerentanan keamanan jembatan yang umum dan menguji jembatan sebelum peluncuran. Kerentanan ini dapat dikategorikan ke dalam empat area berikut.
Validasi on-chain yang lemah
Untuk jembatan sederhana, terutama yang dirancang untuk DApps tertentu, validasi on-chain dijaga seminimal mungkin. Jembatan ini mengandalkan backend terpusat untuk menjalankan operasi dasar seperti pencetakan, pembakaran, dan transfer token sementara semua verifikasi dilakukan di luar rantai.
Sebaliknya, jenis jembatan lainnya menggunakan kontrak pintar untuk memvalidasi pesan dan melakukan verifikasi di rantai. Dalam skenario ini, saat pengguna menyetor dana ke dalam rantai, kontrak pintar menghasilkan pesan yang ditandatangani dan mengembalikan tanda tangan dalam transaksi. Tanda tangan ini berfungsi sebagai bukti penyetoran dan digunakan untuk memverifikasi permintaan penarikan pengguna di rantai lainnya. Proses ini seharusnya dapat mencegah berbagai serangan keamanan, termasuk serangan replay dan pemalsuan catatan penyetoran.
Namun, jika terdapat kerentanan selama proses validasi on-chain, penyerang dapat menyebabkan kerusakan parah. Misalnya, jika sebuah jembatan menggunakan pohon Merkle untuk memvalidasi catatan transaksi, penyerang dapat membuat bukti palsu. Ini berarti mereka dapat melewati validasi bukti dan mencetak token baru ke akun mereka jika proses validasi rentan.
Jembatan tertentu menerapkan konsep “token terbungkus.” Misalnya, ketika pengguna mentransfer DAI dari Ethereum ke BNB Chain, DAI mereka diambil dari kontrak Ethereum, dan jumlah DAI terbungkus yang setara dikeluarkan pada BNB Chain.
Namun, jika transaksi ini tidak divalidasi dengan benar, penyerang dapat menyebarkan kontrak berbahaya untuk mengarahkan token yang dibungkus dari jembatan ke alamat yang salah dengan memanipulasi fungsi tersebut.
Penyerang juga memerlukan korban untuk menyetujui kontrak jembatan untuk mentransfer token menggunakan fungsi “transferFrom” untuk menguras aset dari kontrak jembatan.
Sayangnya, hal ini diperparah karena banyak jembatan meminta persetujuan token tak terbatas dari pengguna DApp. Ini adalah praktik umum yang menurunkan biaya gas tetapi menimbulkan risiko tambahan dengan memungkinkan kontrak pintar mengakses token dalam jumlah tak terbatas dari dompet pengguna. Penyerang dapat memanfaatkan kurangnya validasi dan persetujuan berlebihan untuk mentransfer token dari pengguna lain ke diri mereka sendiri.
Validasi off-chain yang lemah
Dalam beberapa sistem jembatan, server backend off-chain memainkan peran penting dalam memverifikasi keabsahan pesan yang dikirim dari blockchain. Dalam hal ini, kami berfokus pada verifikasi transaksi deposit.
Jembatan blockchain dengan validasi off-chain bekerja sebagai berikut:
Pengguna berinteraksi dengan DApp untuk menyetorkan token ke dalam kontrak pintar di rantai sumber.
DApp kemudian mengirimkan hash transaksi deposit ke server backend melalui API.
Hash transaksi tunduk pada beberapa validasi oleh server. Jika dianggap sah, penanda tangan menandatangani pesan dan mengirimkan tanda tangan kembali ke antarmuka pengguna melalui API.
Setelah menerima tanda tangan, DApp memverifikasinya dan mengizinkan pengguna untuk menarik token mereka dari rantai sumber.
Server backend harus memastikan bahwa transaksi deposit yang diprosesnya benar-benar terjadi dan tidak dipalsukan. Server backend ini menentukan apakah pengguna dapat menarik token pada rantai target dan, oleh karena itu, merupakan target bernilai tinggi bagi penyerang.
Server backend perlu memvalidasi struktur peristiwa transaksi yang dipancarkan, serta alamat kontrak yang memancarkan peristiwa tersebut. Jika yang terakhir diabaikan, penyerang dapat menyebarkan kontrak jahat untuk memalsukan peristiwa setoran dengan struktur yang sama dengan peristiwa setoran yang sah.
Jika server backend tidak memverifikasi alamat mana yang memancarkan peristiwa tersebut, maka server tersebut akan menganggap ini sebagai transaksi yang valid dan menandatangani pesan tersebut. Penyerang kemudian dapat mengirim hash transaksi ke backend, melewati verifikasi dan memungkinkan mereka untuk menarik token dari rantai target.
Penanganan token asli yang tidak tepat
Bridge menggunakan pendekatan yang berbeda dalam menangani token asli dan token utilitas. Misalnya, pada jaringan Ethereum, token asli adalah ETH dan sebagian besar token utilitas mematuhi standar ERC-20.
Ketika pengguna bermaksud mentransfer ETH mereka ke rantai lain, mereka harus terlebih dahulu menyetorkannya ke dalam kontrak jembatan. Untuk mencapai hal ini, pengguna cukup melampirkan ETH ke transaksi, dan jumlah ETH dapat diambil dengan membaca kolom “msg.value” dari transaksi tersebut.
Penyetoran token ERC-20 berbeda secara signifikan dengan penyetoran ETH. Untuk menyetorkan token ERC-20, pengguna harus terlebih dahulu mengizinkan kontrak jembatan untuk menggunakan token mereka. Setelah mereka menyetujui hal ini dan menyetorkan token ke dalam kontrak jembatan, kontrak akan membakar 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 lain adalah dengan membuat dua fungsi terpisah untuk menangani setiap skenario. Mencoba menyetor ETH menggunakan fungsi setoran ERC-20 dapat mengakibatkan hilangnya dana tersebut.
Saat menangani permintaan deposit ERC-20, pengguna biasanya memberikan alamat token sebagai input ke fungsi deposit. Hal ini menimbulkan risiko yang signifikan karena panggilan eksternal yang tidak tepercaya dapat terjadi selama transaksi. Menerapkan daftar putih yang hanya menyertakan token yang didukung oleh bridge merupakan praktik umum untuk meminimalkan risiko. Hanya alamat yang masuk daftar putih yang diizinkan untuk diteruskan sebagai argumen. Hal ini mencegah panggilan eksternal karena tim proyek telah memfilter alamat token.
Namun, masalah juga dapat muncul saat bridge menangani transfer lintas rantai token asli, karena token asli tidak memiliki alamat. Alamat nol (0x000...0) merupakan representasi dari token asli. Hal ini dapat menjadi masalah karena meneruskan alamat nol ke fungsi dapat melewati verifikasi daftar putih meskipun diterapkan secara tidak benar.
Ketika kontrak jembatan memanggil "transferFrom" untuk mentransfer aset pengguna ke kontrak, panggilan eksternal ke alamat nol mengembalikan false karena tidak ada fungsi "transferFrom" yang diterapkan di alamat nol. Namun, transaksi masih dapat terjadi jika kontrak tidak menangani nilai pengembalian dengan tepat. Hal ini menciptakan peluang bagi penyerang untuk mengeksekusi transaksi tanpa mentransfer token apa pun ke kontrak.
Kesalahan konfigurasi
Di sebagian besar jembatan blockchain, peran istimewa bertanggung jawab untuk memasukkan token dan alamat ke dalam daftar putih atau daftar hitam, menetapkan atau mengubah penanda tangan, dan konfigurasi penting lainnya. Memastikan bahwa semua konfigurasi akurat adalah hal yang penting, karena kelalaian yang tampaknya sepele pun dapat menyebabkan kerugian yang signifikan.
Faktanya, pernah terjadi insiden di mana penyerang berhasil melewati verifikasi catatan transfer karena kesalahan konfigurasi. Tim proyek menerapkan pemutakhiran protokol beberapa hari sebelum peretasan, yang melibatkan perubahan variabel. Variabel tersebut digunakan untuk mewakili nilai default dari pesan tepercaya. Perubahan ini mengakibatkan semua pesan secara otomatis dianggap terbukti, sehingga memungkinkan penyerang untuk mengirimkan pesan sembarangan dan lolos dari proses verifikasi.
Cara Meningkatkan Keamanan Jembatan
Keempat kerentanan jembatan umum yang dijelaskan di atas menunjukkan tantangan dalam memastikan keamanan dalam ekosistem blockchain yang saling terhubung. Ada pertimbangan penting untuk menangani masing-masing kerentanan ini, dan tidak ada satu pun pedoman yang berlaku untuk semuanya.
Misalnya, menyediakan panduan umum untuk memastikan proses verifikasi bebas kesalahan merupakan tantangan karena setiap jembatan memiliki persyaratan verifikasi yang unik. Pendekatan yang paling efektif untuk mencegah verifikasi terlewati adalah dengan menguji jembatan secara menyeluruh terhadap semua vektor serangan yang mungkin terjadi dan memastikan logika verifikasinya kuat.
Singkatnya, sangat penting untuk melakukan pengujian ketat terhadap serangan potensial dan memberikan perhatian khusus pada kerentanan keamanan yang paling umum di jembatan.
Pemikiran Penutup
Karena nilainya yang tinggi, jembatan lintas rantai telah lama menjadi target para penyerang. Para pembangun dapat memperkuat keamanan jembatan mereka dengan melakukan pengujian pra-penerapan menyeluruh dan terlibat dalam audit pihak ketiga, sehingga mengurangi risiko peretasan yang merusak yang telah mengganggu jembatan selama beberapa tahun terakhir. Jembatan sangat penting dalam dunia multi-rantai, tetapi keamanan harus menjadi perhatian utama saat merancang dan membangun infrastruktur Web3 yang efektif.
Bacaan lebih lanjut
Apa itu Jembatan Blockchain?
Apa itu Interoperabilitas Lintas Rantai?
Tiga Jembatan Kripto Populer dan Cara Kerjanya
Apa itu Wrapped Token?
Penafian dan Peringatan Risiko: Konten ini disajikan kepada Anda "apa adanya" hanya untuk informasi umum dan tujuan edukasi, tanpa pernyataan atau jaminan apa pun. Konten ini tidak boleh ditafsirkan sebagai nasihat keuangan, hukum, atau profesional lainnya, dan tidak dimaksudkan untuk merekomendasikan pembelian produk atau layanan tertentu. Anda harus mencari nasihat Anda sendiri dari penasihat profesional yang sesuai. Jika artikel disumbangkan oleh kontributor pihak ketiga, harap dicatat bahwa pandangan yang diungkapkan tersebut adalah milik kontributor pihak ketiga dan tidak mencerminkan pandangan Binance Academy. Harap baca penafian lengkap kami di sini untuk detail lebih lanjut. Harga aset digital bisa berubah-ubah. Nilai investasi Anda dapat turun atau naik, dan Anda mungkin tidak mendapatkan kembali jumlah yang diinvestasikan. Anda bertanggung jawab penuh atas keputusan investasi Anda, dan Binance Academy tidak bertanggung jawab atas kerugian yang mungkin Anda alami. Materi ini tidak boleh ditafsirkan sebagai nasihat keuangan, hukum, atau profesional lainnya. Untuk informasi lebih lanjut, lihat Ketentuan Penggunaan dan Peringatan Risiko kami.