Analisis pro teknologi mengenai insiden serangan Hacker pada Cetus Protocol

Versi umum: Penjelasan "terjemahan" sederhana tentang pro mengenai @CetusProtocol

Analisis kejadian serangan hacker:

Serangan kali ini mengungkapkan masalah klasik overflow integer, yang ditunjukkan oleh pemotongan data selama proses konversi tipe.

Pecahan rincian teknis:

1. Penentuan Kerentanan: Masalah muncul dalam mekanisme konversi tipe pada fungsi get_amount_by_liquidity, di mana konversi paksa dari u256 ke u64 menyebabkan kehilangan data tinggi.

2）Proses serangan:

1. Penyerang mengirimkan parameter jumlah likuiditas yang sangat besar melalui fungsi add_liquidity;

2、Sistem memanggil fungsi get_delta_b untuk menghitung jumlah token B yang diperlukan;

3、Dalam proses perhitungan, dua data tipe u128 yang dikalikan, hasil teorinya seharusnya bertipe u256;

Kekurangan utama: Pada saat mengembalikan fungsi, hasil u256 dipaksa untuk dikonversi menjadi u64, yang mengakibatkan data 128 bit tinggi terpotong.

3）Efek pemanfaatan: Kuota likuiditas yang sebelumnya memerlukan banyak token untuk dicetak, kini hanya membutuhkan sedikit token untuk menyelesaikannya. Penyerang memperoleh bagian likuiditas yang besar dengan biaya yang sangat rendah, kemudian melakukan arbitrase kolam dana dengan menghancurkan sebagian likuiditas.

Analogi sederhana: seperti menggunakan kalkulator yang hanya dapat menampilkan 8 digit untuk menghitung 1 miliar × 1 miliar, hasil yang terdiri dari 20 digit hanya dapat menampilkan 8 digit terakhir, sedangkan 12 digit sebelumnya langsung hilang. Penyerang memanfaatkan kerentanan "kekurangan presisi perhitungan" ini.

Perlu ditegaskan: Kerentanan kali ini tidak ada hubungannya dengan arsitektur keamanan dasar dari @SuiNetwork, dan keamanan bahasa Move "kemuliaan" masih dapat dipercaya untuk sementara. Kenapa?

Bahasa Move memang memiliki keunggulan yang signifikan dalam manajemen sumber daya dan keamanan tipe, yang dapat secara efektif mencegah masalah keamanan dasar seperti pembayaran ganda dan kebocoran sumber daya. Namun, apa yang terjadi dengan protokol Cetus kali ini adalah kesalahan perhitungan matematis di tingkat logika aplikasi, bukan cacat desain dari bahasa Move itu sendiri.

Secara spesifik, meskipun sistem tipe Move ketat, untuk operasi konversi tipe eksplisit, masih perlu bergantung pada penilaian yang benar dari pengembang. Ketika program secara aktif melakukan konversi tipe dari u256 ke u64, compiler tidak dapat menentukan apakah ini dirancang dengan sengaja atau merupakan kesalahan logika.

Selain itu, insiden keamanan kali ini sama sekali tidak terkait dengan mekanisme konsensus Sui, pemrosesan transaksi, manajemen status, dan fungsi inti dasar lainnya. Jaringan Sui hanya setia menjalankan instruksi transaksi yang diajukan oleh protokol Cetus, dan kerentanan berasal dari cacat logika dalam protokol lapisan aplikasi itu sendiri.

Jadi, tidak peduli seberapa canggih bahasa pemrograman, tidak ada yang dapat sepenuhnya mencegah kesalahan logika di lapisan aplikasi. Move dapat mencegah sebagian besar risiko keamanan di lapisan bawah, tetapi tidak dapat menggantikan pengembang dalam memeriksa batas logika bisnis dan melindungi dari overflow dalam perhitungan matematis.

Koreksi:

Saya telah berkomunikasi lebih lanjut dengan pro, sebelumnya analisis teknis mengenai serangan hacker @CetusProtocol memiliki kesalahan dalam detail spesifik, untuk itu saya mengoreksinya.

Sebelumnya telah diidentifikasi dengan tepat bahwa ini adalah jenis kerentanan overflow perhitungan matematis, penyerang melalui konstruk nilai khusus "mengambil risiko kecil untuk mendapatkan keuntungan besar" adalah logika inti yang benar, dan jawaban atas keraguan tentang keamanan bahasa Move yang menjadi perhatian semua orang juga benar.

Hanya saja melihat fenomena kesalahan perhitungan matematika, mengira itu adalah masalah konversi tipe, tetapi sebenarnya adalah masalah pemeriksaan batas fungsi lainnya. Faktanya, bahasa Move memiliki mekanisme pemeriksaan yang ketat untuk konversi tipe dari u256 ke u64 dan sebagainya, konversi eksplisit semacam ini memang akan memiliki pemeriksaan keamanan dalam kondisi normal.

Lokasi kerentanan yang spesifik dan mekanisme implementasi teknis perlu diperbaiki, sebagai berikut.

Masalah yang sebenarnya muncul pada mekanisme pemeriksaan overflow fungsi get\_delta\_a tidak berfungsi:

1）Fungsi: Menghitung jumlah token A yang dibutuhkan saat menambahkan likuiditas yang ditentukan;

2）Kekurangan kunci: pemeriksaan overflow pada fungsi checked\_shlw memiliki kesalahan pengkodean, tidak dapat mencegah nilai likuiditas besar yang tidak valid;

3）Eksploitasi serangan: Hacker membangun nilai likuiditas khusus, melewati pemeriksaan kegagalan, dan akhirnya melalui mekanisme pembulatan ke atas div\_round, membuat jumlah token A yang dibutuhkan menjadi 14).

Efek serangan: gunakan 1 token A untuk mencetak likuiditas besar, kemudian sedot dana dari pool.