Dengan lebih dari $200 juta yang dicuri, apa implikasi dari insiden keamanan Cetus?

Setelah membaca laporan "rekap" keamanan serangan hacker dari @CetusProtocol, Anda akan menemukan fenomena yang "menarik": rincian teknis diungkapkan dengan cukup transparan, respons darurat juga bisa dibilang tingkat buku teks, tetapi dalam pertanyaan mendasar "mengapa bisa diretas" ini, tampaknya menghindar dari inti permasalahan:

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

Masalahnya adalah, mengingat integer-mate adalah pustaka matematika sumber terbuka yang banyak digunakan, mengapa justru terjadi kesalahan konyol di mana hanya dengan 1 token bisa mendapatkan bagian likuiditas yang sangat mahal?

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

Cetus "lalai" dalam setiap kondisi "pemicu", seperti: menerima angka astronomi seperti input pengguna 2^200, menggunakan perhitungan perpindahan besar yang sangat berbahaya, sepenuhnya mempercayai mekanisme pemeriksaan perpustakaan eksternal, dan yang paling fatal - ketika sistem menghitung hasil yang tidak masuk akal dari "1 token untuk pangsa harga setinggi langit", itu langsung dieksekusi tanpa pemeriksaan akal sehat ekonomi.

Jadi, poin yang benar-benar harus dipikirkan oleh Cetus adalah sebagai berikut:

1）Mengapa menggunakan pustaka eksternal umum tidak melakukan pengujian keamanan dengan baik? Meskipun pustaka integer-mate memiliki karakteristik seperti sumber terbuka, populer, dan banyak digunakan, Cetus menggunakan pustaka ini untuk mengelola aset senilai ratusan juta dolar tetapi tidak sepenuhnya memahami batasan keamanan pustaka ini, dan apakah ada solusi cadangan yang sesuai jika pustaka gagal berfungsi, dan seterusnya. Jelas bahwa Cetus kurang memiliki kesadaran dasar tentang perlindungan keamanan rantai pasokan;

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

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

3. Mengapa setelah beberapa putaran audit keamanan masalah tetap tidak terdeteksi sebelumnya? Pernyataan ini tanpa sengaja mengungkapkan kesalahan pemahaman yang fatal: pihak proyek mengalihdayakan tanggung jawab keamanan kepada perusahaan keamanan, menganggap audit sebagai medali bebas tanggung jawab. Namun kenyataannya sangat keras: insinyur audit keamanan ahli dalam menemukan Bug kode, siapa yang akan berpikir untuk menguji sistem dan menghitung rasio pertukaran yang mungkin tidak sesuai dengan kenyataan seperti dongeng?

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"; sementara pengguna hanya tahu uang mereka hilang!

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

Dan dari laporan Cetus ini, tim jelas-jelas tidak melakukan refleksi dengan baik.

Dibandingkan dengan kekurangan teknis yang hanya ditujukan pada serangan hacker kali ini, saya rasa mulai dari Cetus, semua tim DeFi harus mengubah batasan pemikiran teknis murni, dan benar-benar mengembangkan kesadaran risiko keamanan "insinyur keuangan".

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

Ini mengingatkan saya pada pengalaman kerja sebelumnya di perusahaan keamanan, termasuk kesepakatan yang ada di antara para tokoh besar di industri keamanan seperti @evilcos, @chiachih_wu, @yajinzhou, @mikelee205 :

Seiring dengan kematangan industri, masalah Bug teknis di tingkat kode akan semakin berkurang, sementara "kesadaran Bug" 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 "logika memiliki batas" membutuhkan tim proyek untuk memiliki pemahaman yang lebih dalam tentang esensi bisnis dan kemampuan pengendalian batas. (Sebelumnya banyak insiden "membebaskan diri dari tanggung jawab" setelah audit keamanan masih mengalami serangan Hacker, yang merupakan penyebab utama di balik ini.)

Masa depan DeFi adalah milik tim yang memiliki keterampilan kode yang kuat dan pemahaman yang mendalam tentang logika bisnis!