Cetus masalah keamanan mengingatkan: Apa yang harus diperhatikan oleh tim Keuangan Desentralisasi?

Tim dengan latar belakang teknis murni sangat kekurangan "indera penciuman risiko keuangan" dasar.

Ditulis oleh: Haotian

Setelah membaca laporan keamanan "rekap" tentang serangan peretasan @CetusProtocol, Anda akan menemukan fenomena yang "menarik": detail teknis diungkapkan dengan cukup transparan, respons darurat juga bisa disebut sebagai tingkat buku teks, tetapi pada pertanyaan paling penting "mengapa ini bisa diretas", tampaknya kurang mendalam.

Laporan menjelaskan dengan banyak ruang fungsi checked\_shlw dari pustaka integer-mate yang memeriksa kesalahan (seharusnya ≤2^192, sebenarnya ≤2^256), dan menilai ini sebagai "kesalahpahaman semantik". Meskipun narasi ini secara teknis sah, itu secara cerdik mengalihkan fokus ke tanggung jawab eksternal, seolah-olah Cetus juga merupakan korban tak bersalah dari cacat teknis ini.

Masalahnya adalah, mengapa integer-mate yang merupakan pustaka matematika sumber terbuka dan banyak digunakan, justru mengalami kesalahan konyol di mana hanya dengan 1 token Anda dapat memperoleh bagian likuiditas yang sangat tinggi?

Analisis jalur serangan hacker menunjukkan bahwa untuk melakukan serangan yang sempurna, hacker harus memenuhi empat syarat secara bersamaan: pemeriksaan overflow yang salah, operasi pergeseran besar, aturan pembulatan ke atas, dan kurangnya verifikasi kelayakan ekonomi.

Cetus benar-benar "lalai" pada setiap kondisi "pemicu", misalnya: menerima input pengguna 2^200 yang merupakan angka astronomis, menggunakan operasi pergeseran yang sangat berbahaya, sepenuhnya mempercayai mekanisme pemeriksaan dari pustaka eksternal, yang paling fatal adalah—ketika sistem menghitung hasil konyol "1 token ditukar dengan bagian harga selangit" ini, ternyata tidak ada pemeriksaan pengetahuan ekonomi yang dilakukan dan langsung dieksekusi.

Jadi, poin yang sebenarnya harus direfleksikan oleh Cetus adalah sebagai berikut:

1）Mengapa menggunakan pustaka eksternal umum tidak dilakukan pengujian keamanan dengan baik? Meskipun pustaka integer-mate memiliki sifat sumber terbuka, populer, dan banyak digunakan, Cetus menggunakannya untuk mengelola aset senilai ratusan juta dolar namun tidak sepenuhnya memahami di mana batasan keamanan pustaka ini, apakah ada solusi cadangan yang tepat jika pustaka tersebut gagal berfungsi, dan lain-lain. Jelas, Cetus kurang memiliki kesadaran dasar tentang perlindungan keamanan rantai pasokan;

2. Mengapa angka astronomis diizinkan tanpa batas? Meskipun protokol DeFi harus mencari desentralisasi, semakin terbuka suatu sistem keuangan yang matang, semakin dibutuhkan batasan yang jelas.

Ketika sistem mengizinkan input angka astronomis yang dirancang dengan cermat oleh penyerang, tim jelas tidak memikirkan apakah permintaan likuiditas seperti itu masuk akal? Bahkan hedge fund terbesar di dunia pun tidak mungkin membutuhkan bagian likuiditas yang begitu berlebihan. Jelas, tim Cetus kekurangan profesional manajemen risiko yang memiliki intuisi keuangan;

3. Mengapa masih belum ada masalah yang ditemukan sebelumnya setelah beberapa putaran audit keamanan? Kalimat ini secara tidak sengaja mengungkap kesalahpahaman kognitif yang fatal: tim proyek mengalihdayakan tanggung jawab keamanan kepada perusahaan keamanan, dan menganggap audit sebagai medali emas untuk pengecualian. Tetapi kenyataannya keras: insinyur audit keamanan pandai menemukan bug kode, dan siapa yang mengira bahwa mungkin salah untuk menguji sistem untuk menghitung rasio pertukaran yang fantastis?

Verifikasi yang melintasi batasan matematika, kriptografi, dan ekonomi ini adalah titik buta terbesar dalam keamanan DeFi modern. Perusahaan audit akan mengatakan "Ini adalah cacat desain model ekonomi, bukan masalah logika kode"; pihak proyek mengeluh "Audit tidak menemukan masalah"; dan pengguna hanya tahu bahwa uang mereka hilang!

Lihat, ini pada akhirnya mengungkapkan kelemahan sistemik dalam industri DeFi: tim dengan latar belakang teknis murni sangat kekurangan "indera risiko keuangan" yang dasar.

Namun, dari laporan Cetus ini, tim jelas belum melakukan refleksi yang tepat.

Dibandingkan dengan kekurangan teknis yang murni terkait dengan serangan peretasan kali ini, saya merasa bahwa sejak Cetus, semua tim DeFi harus mengubah keterbatasan pemikiran teknis murni dan benar-benar membangun kesadaran risiko keamanan "insinyur keuangan".

Misalnya: Mengundang ahli manajemen risiko keuangan untuk melengkapi kekurangan pengetahuan tim teknis; melakukan mekanisme audit yang melibatkan banyak pihak, tidak hanya melihat audit kode, tetapi juga audit model ekonomi yang diperlukan harus dilengkapi; mengembangkan "indera keuangan", mensimulasikan berbagai skenario serangan dan tindakan respons yang sesuai, serta tetap sensitif terhadap operasi yang tidak biasa.

Ini mengingatkan saya pada pengalaman kerja sebelumnya di perusahaan keamanan, termasuk konsensus semacam ini yang juga diungkapkan oleh para ahli keamanan industri @evilcos, @chiachih_wu, @yajinzhou, @mikelee205.

Seiring dengan kematangan industri yang semakin meningkat, masalah Bug teknis di tingkat kode akan semakin berkurang, sementara "Bug kesadaran" dalam logika bisnis yang tidak jelas batasnya dan tanggung jawab yang kabur akan menjadi tantangan terbesar.

Perusahaan audit hanya dapat memastikan bahwa kode bebas dari bug, tetapi bagaimana cara mencapai "batas logis" memerlukan pemahaman yang lebih mendalam dari tim proyek tentang esensi bisnis dan kemampuan untuk mengendalikan batasan tersebut. (Sebab utama dari banyak insiden "menyalahkan orang lain" setelah audit keamanan yang tetap diserang hacker terletak di sini)

Masa depan DeFi adalah milik tim yang memiliki keterampilan teknis pemrograman yang kuat, sekaligus pemahaman yang mendalam tentang logika bisnis!