Analisis Kasus Serangan Reentrancy pada OrionProtocol
Pada tanggal 2 Februari 2023, OrionProtocol di Ethereum dan Binance Smart Chain mengalami serangan reentrancy akibat celah kontrak, dengan total kerugian sekitar 2,9 juta USD, termasuk 2.844.766 USDT di Ethereum dan 191.606 BUSD di BSC.
Analisis Proses Serangan
Penyerang pertama-tama menerapkan kontrak Token khusus dan melakukan operasi transfer dan otorisasi untuk mempersiapkan serangan selanjutnya. Kemudian, penyerang melakukan pinjaman melalui metode swap di suatu DEX dan memanggil metode ExchangeWithAtomic.swapThroughOrionPool untuk pertukaran token. Jalur pertukaran diatur sebagai USDC → Token Penyerang → USDT.
Selama proses eksekusi metode ExchangeWithAtomic.swapThroughOrionPool, adanya fungsi callback dalam kontrak token pelaku penyerangan menyebabkan metode ExchangeWithAtomic.depositAsset dipanggil lagi selama proses Token.Transfer, sehingga memungkinkan terjadinya serangan reentrancy. Hal ini mengakibatkan jumlah setoran terakumulasi berkali-kali, dan akhirnya pelaku penyerangan mendapatkan keuntungan berlebih melalui operasi penarikan.
Arus Dana
Modal awal penyerang berasal dari dompet panas suatu platform perdagangan. Dari 1.651 ETH yang diperoleh dari serangan, 657,5 ETH masih tersimpan di alamat dompet penyerang, sementara sisanya telah dipindahkan melalui layanan pencampuran.
Analisis Kerentanan
Kerentanan inti terletak pada fungsi doSwapThroughOrionPool dan _doSwapTokens. Masalah kunci adalah bahwa kontrak memperbarui variabel curBalance hanya setelah melakukan transfer token, yang menciptakan kondisi untuk serangan reentrancy. Penyerang menambahkan logika callback dalam fungsi transfer Token kustom, sehingga memanggil lagi fungsi depositAsset selama proses transfer, yang mengakibatkan curBalance diperbarui secara salah.
Reproduksi Kerentanan
Peneliti memberikan sebagian kode POC yang mensimulasikan proses serangan. Hasil pengujian menunjukkan bahwa penyerang berhasil memanfaatkan kerentanan untuk mendapatkan USDT tambahan.
Saran Keamanan
Pengembangan kontrak harus mengikuti pola "Pemeriksaan - Efek - Interaksi" (Checks-Effects-Interactions) dengan ketat, yaitu melakukan pemeriksaan status terlebih dahulu, kemudian memperbarui status kontrak, dan terakhir berinteraksi dengan kontrak eksternal.
Saat mengimplementasikan fungsi pertukaran token, perlu mempertimbangkan risiko keamanan yang mungkin ditimbulkan oleh berbagai Token dan jalur pertukaran.
Untuk fungsi kunci yang melibatkan operasi keuangan, harus diterapkan kunci reentrancy atau menggunakan pustaka keamanan seperti ReentrancyGuard dari OpenZeppelin.
Secara berkala melakukan audit kode dan evaluasi keamanan, untuk mendeteksi dan memperbaiki potensi kerentanan dengan cepat.
Pertimbangkan untuk memperkenalkan mekanisme seperti batasan jumlah transaksi atau penguncian waktu untuk mengurangi kerugian yang mungkin ditimbulkan oleh serangan tunggal.
Dengan mengambil langkah-langkah ini, tim proyek dapat secara efektif meningkatkan keamanan kontrak pintar dan mengurangi risiko terkena serangan serupa.
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
7 Suka
Hadiah
7
4
Bagikan
Komentar
0/400
ZkProofPudding
· 3menit yang lalu
Reentrasi datang lagi hehe~
Lihat AsliBalas0
ContractFreelancer
· 07-29 23:53
Ini serangan reentrancy lagi, sangat menjengkelkan.
OrionProtocol mengalami serangan reentrancy dengan kerugian sebesar 2,9 juta dolar AS. Analisis saran keamanan.
Analisis Kasus Serangan Reentrancy pada OrionProtocol
Pada tanggal 2 Februari 2023, OrionProtocol di Ethereum dan Binance Smart Chain mengalami serangan reentrancy akibat celah kontrak, dengan total kerugian sekitar 2,9 juta USD, termasuk 2.844.766 USDT di Ethereum dan 191.606 BUSD di BSC.
Analisis Proses Serangan
Penyerang pertama-tama menerapkan kontrak Token khusus dan melakukan operasi transfer dan otorisasi untuk mempersiapkan serangan selanjutnya. Kemudian, penyerang melakukan pinjaman melalui metode swap di suatu DEX dan memanggil metode ExchangeWithAtomic.swapThroughOrionPool untuk pertukaran token. Jalur pertukaran diatur sebagai USDC → Token Penyerang → USDT.
Selama proses eksekusi metode ExchangeWithAtomic.swapThroughOrionPool, adanya fungsi callback dalam kontrak token pelaku penyerangan menyebabkan metode ExchangeWithAtomic.depositAsset dipanggil lagi selama proses Token.Transfer, sehingga memungkinkan terjadinya serangan reentrancy. Hal ini mengakibatkan jumlah setoran terakumulasi berkali-kali, dan akhirnya pelaku penyerangan mendapatkan keuntungan berlebih melalui operasi penarikan.
Arus Dana
Modal awal penyerang berasal dari dompet panas suatu platform perdagangan. Dari 1.651 ETH yang diperoleh dari serangan, 657,5 ETH masih tersimpan di alamat dompet penyerang, sementara sisanya telah dipindahkan melalui layanan pencampuran.
Analisis Kerentanan
Kerentanan inti terletak pada fungsi doSwapThroughOrionPool dan _doSwapTokens. Masalah kunci adalah bahwa kontrak memperbarui variabel curBalance hanya setelah melakukan transfer token, yang menciptakan kondisi untuk serangan reentrancy. Penyerang menambahkan logika callback dalam fungsi transfer Token kustom, sehingga memanggil lagi fungsi depositAsset selama proses transfer, yang mengakibatkan curBalance diperbarui secara salah.
Reproduksi Kerentanan
Peneliti memberikan sebagian kode POC yang mensimulasikan proses serangan. Hasil pengujian menunjukkan bahwa penyerang berhasil memanfaatkan kerentanan untuk mendapatkan USDT tambahan.
Saran Keamanan
Pengembangan kontrak harus mengikuti pola "Pemeriksaan - Efek - Interaksi" (Checks-Effects-Interactions) dengan ketat, yaitu melakukan pemeriksaan status terlebih dahulu, kemudian memperbarui status kontrak, dan terakhir berinteraksi dengan kontrak eksternal.
Saat mengimplementasikan fungsi pertukaran token, perlu mempertimbangkan risiko keamanan yang mungkin ditimbulkan oleh berbagai Token dan jalur pertukaran.
Untuk fungsi kunci yang melibatkan operasi keuangan, harus diterapkan kunci reentrancy atau menggunakan pustaka keamanan seperti ReentrancyGuard dari OpenZeppelin.
Secara berkala melakukan audit kode dan evaluasi keamanan, untuk mendeteksi dan memperbaiki potensi kerentanan dengan cepat.
Pertimbangkan untuk memperkenalkan mekanisme seperti batasan jumlah transaksi atau penguncian waktu untuk mengurangi kerugian yang mungkin ditimbulkan oleh serangan tunggal.
Dengan mengambil langkah-langkah ini, tim proyek dapat secara efektif meningkatkan keamanan kontrak pintar dan mengurangi risiko terkena serangan serupa.