Analisis Serangan Reentrancy Pinjaman Flash pada Proyek Jarvis Network
Pada 15 Januari 2023, proyek Jarvis_Network diserang, kehilangan 663.101 MATIC. Melalui analisis tumpukan panggilan dari transaksi serangan, ditemukan adanya logika reentrancy. Dalam proses reentrancy, panggilan fungsi yang sama pada kontrak yang sama, dengan parameter yang sama, tetapi nilai kembali yang sangat berbeda.
Reentrancy terjadi di dalam fungsi remove_liquidity. Fungsi ini akan mengembalikan token yang ditambahkan pengguna saat menghapus likuiditas. Karena Polygon bersifat EVM-kompatibel, transfer MATIC ke kontrak akan memicu reentrancy.
Analisis mendalam menunjukkan bahwa masalah terletak pada implementasi fungsi getUnderlyingPrice. Fungsi ini melibatkan beberapa panggilan kontrak, yang pada akhirnya mempengaruhi nilai kembali dari fungsi get_virtual_price. Nilai kembali dari fungsi get_virtual_price dipengaruhi oleh variabel self.D, dan pembaruan self.D dilakukan setelah transfer.
Penyerang mengalihkan MATIC ke kontrak serangan saat menghapus likuiditas, kemudian memanggil fungsi fallback untuk memeriksa harga. Karena pembaruan self.D terjadi setelah transfer, ini menyebabkan kesalahan dalam mendapatkan harga sebelumnya. Proses metode penghapusan likuiditas adalah: 1) menghancurkan LP pengguna; 2) mengirimkan dana staking pengguna; 3) memperbarui self.D.
self.D digunakan untuk perhitungan harga, dan juga akan diperbarui saat menambahkan likuiditas. Dana likuiditas penyerang cukup besar, dalam kondisi normal nilai self.D akan jauh lebih kecil. Namun, penyerang melakukan reentrancy di langkah 2 dan meminjam dengan harga 10 kali lebih tinggi dari harga asli. Ini karena nilai self.D meningkat saat menambahkan likuiditas, sementara saat menghapus likuiditas tidak diperbarui tepat waktu.
Meskipun metode remove_liquidity menggunakan @nonreentrant('lock') untuk mencegah reentrancy, penyerang dapat melakukan reentrancy ke kontrak lain untuk meminjam dana, sehingga mengakibatkan kunci reentrancy menjadi tidak efektif.
Penyebab utama serangan kali ini adalah logika modifikasi variabel setelah pemanggilan eksternal, yang menyebabkan anomali dalam pengambilan harga. Reentrancy antar kontrak membuat kunci reentrancy tidak berlaku. Disarankan agar pihak proyek melakukan audit keamanan yang ketat, meletakkan modifikasi variabel sebelum pemanggilan eksternal, dan menggunakan metode pengambilan harga dengan banyak sumber data. Mengikuti "periksa dahulu, kemudian tulis variabel, baru lakukan pemanggilan eksternal" sebagai standar pengkodean (Checks-Effects-Interactions) dapat meningkatkan keamanan dan stabilitas proyek.
Lihat Asli
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.
9 Suka
Hadiah
9
6
Bagikan
Komentar
0/400
All-InQueen
· 08-05 00:42
Blockchain kembali mengalami ledakan, sudah parah.
Lihat AsliBalas0
HalfBuddhaMoney
· 08-02 05:37
Tidak mungkin mendapatkan sebanyak ini...
Lihat AsliBalas0
ZeroRushCaptain
· 08-02 05:37
又双叒叕阵亡一个，seluruh tabungan全打水漂了 亏钱Sam Altman冲啊！
Lihat AsliBalas0
ForkLibertarian
· 08-02 05:29
Kecepatan tangan begitu lambat, Cut Loss dan Rug Pull sudah terlambat.
Lihat AsliBalas0
StakeTillRetire
· 08-02 05:24
Satu lagi kasus reentrancy yang tragis, saya sudah tidak bisa berbuat apa-apa.
Lihat AsliBalas0
SighingCashier
· 08-02 05:13
Kamu sudah terlalu jauh, ini adalah kerentanan reentrancy lagi.
Jarvis Network mengalami serangan reentrancy Pinjaman Flash dengan kerugian 663,101 MATIC
Analisis Serangan Reentrancy Pinjaman Flash pada Proyek Jarvis Network
Pada 15 Januari 2023, proyek Jarvis_Network diserang, kehilangan 663.101 MATIC. Melalui analisis tumpukan panggilan dari transaksi serangan, ditemukan adanya logika reentrancy. Dalam proses reentrancy, panggilan fungsi yang sama pada kontrak yang sama, dengan parameter yang sama, tetapi nilai kembali yang sangat berbeda.
Reentrancy terjadi di dalam fungsi remove_liquidity. Fungsi ini akan mengembalikan token yang ditambahkan pengguna saat menghapus likuiditas. Karena Polygon bersifat EVM-kompatibel, transfer MATIC ke kontrak akan memicu reentrancy.
Analisis mendalam menunjukkan bahwa masalah terletak pada implementasi fungsi getUnderlyingPrice. Fungsi ini melibatkan beberapa panggilan kontrak, yang pada akhirnya mempengaruhi nilai kembali dari fungsi get_virtual_price. Nilai kembali dari fungsi get_virtual_price dipengaruhi oleh variabel self.D, dan pembaruan self.D dilakukan setelah transfer.
Penyerang mengalihkan MATIC ke kontrak serangan saat menghapus likuiditas, kemudian memanggil fungsi fallback untuk memeriksa harga. Karena pembaruan self.D terjadi setelah transfer, ini menyebabkan kesalahan dalam mendapatkan harga sebelumnya. Proses metode penghapusan likuiditas adalah: 1) menghancurkan LP pengguna; 2) mengirimkan dana staking pengguna; 3) memperbarui self.D.
self.D digunakan untuk perhitungan harga, dan juga akan diperbarui saat menambahkan likuiditas. Dana likuiditas penyerang cukup besar, dalam kondisi normal nilai self.D akan jauh lebih kecil. Namun, penyerang melakukan reentrancy di langkah 2 dan meminjam dengan harga 10 kali lebih tinggi dari harga asli. Ini karena nilai self.D meningkat saat menambahkan likuiditas, sementara saat menghapus likuiditas tidak diperbarui tepat waktu.
Meskipun metode remove_liquidity menggunakan @nonreentrant('lock') untuk mencegah reentrancy, penyerang dapat melakukan reentrancy ke kontrak lain untuk meminjam dana, sehingga mengakibatkan kunci reentrancy menjadi tidak efektif.
Penyebab utama serangan kali ini adalah logika modifikasi variabel setelah pemanggilan eksternal, yang menyebabkan anomali dalam pengambilan harga. Reentrancy antar kontrak membuat kunci reentrancy tidak berlaku. Disarankan agar pihak proyek melakukan audit keamanan yang ketat, meletakkan modifikasi variabel sebelum pemanggilan eksternal, dan menggunakan metode pengambilan harga dengan banyak sumber data. Mengikuti "periksa dahulu, kemudian tulis variabel, baru lakukan pemanggilan eksternal" sebagai standar pengkodean (Checks-Effects-Interactions) dapat meningkatkan keamanan dan stabilitas proyek.