Analisis Serangan Reentrancy Pinjaman Flash pada Proyek Jarvis Network

Data menunjukkan bahwa pada 15 Januari 2023 pukul 17:43:37 UTC, proyek Jarvis_Network diserang, mengakibatkan kerugian sebanyak 663,101 MATIC.

Analisis tumpukan panggilan transaksi menemukan bahwa ada logika reentrancy selama proses penghapusan likuiditas. Panggilan fungsi yang sama pada kontrak yang sama sebelum dan sesudah reentrancy, dengan parameter yang sama, tetapi nilai kembalian yang sangat berbeda:

• Sebelum masuk kembali: 1,002,157,321,772,769,944
• Setelah masuk kembali: 10,091,002,696,492,234,934

Reentrancy terjadi di dalam fungsi remove_liquidity. Fungsi ini akan mengembalikan token yang ditambahkan pengguna saat menghapus likuiditas. Karena Polygon dan EVM adalah rantai yang isomorfik, transfer MATIC ke kontrak akan memicu reentrancy kontrak.

Analisis mendalam menunjukkan bahwa masalah terletak pada implementasi fungsi getUnderlyingPrice. Fungsi ini melibatkan serangkaian perhitungan internal dan pemanggilan eksternal, di mana kuncinya adalah nilai yang dikembalikan oleh fungsi get_virtual_price.

Nilai kembalian fungsi get_virtual_price dipengaruhi oleh variabel self.D. Dalam fungsi remove_liquidity, pembaruan self.D terjadi setelah transfer token. Penyerang mentransfer MATIC ke kontrak penyerang saat menghapus likuiditas, dan saat memanggil fallback, harga token terlebih dahulu diperiksa. Karena self.D belum diperbarui, hal ini menyebabkan kesalahan dalam mendapatkan harga.

alur fungsi remove_liquidity:

1. Menghancurkan LP pengguna
2. Mengirimkan dana staking pengguna
3. Perbarui self.D

Penyerang melakukan reentrancy pada langkah 2, memanfaatkan nilai self.D yang belum diperbarui untuk meminjam, mendapatkan dana 10 kali lipat dari harga normal.

Meskipun fungsi remove_liquidity menggunakan @nonreentrant('lock') untuk mencegah reentrancy, penyerang berhasil melewati mekanisme perlindungan ini melalui reentrancy antar kontrak.

Serangan ini mengungkapkan beberapa masalah kunci:

1. Logika modifikasi variabel setelah pemanggilan eksternal, menyebabkan anomali dalam pengambilan harga.
2. Reentrasi antar kontrak membuat kunci reentrasi tidak berlaku
3. Tidak mengikuti pola "Pemeriksaan-Dampak-Interaksi" (Checks-Effects-Interactions)

Untuk meningkatkan keamanan, pihak proyek harus:

• Melakukan audit keamanan yang ketat
• Tempatkan modifikasi variabel sebelum panggilan eksternal.
• Menggunakan beberapa sumber data untuk mendapatkan harga
• Mengikuti standar pengkodean "evaluasi terlebih dahulu, kemudian tulis ke variabel, lalu lakukan panggilan eksternal"

Dengan langkah-langkah ini, keamanan dan stabilitas proyek dapat ditingkatkan secara signifikan, serta dapat mencegah serangan serupa dengan efektif.