Setelah membaca laporan "ulasan" keamanan dari serangan hacker @CetusProtocol, Anda akan menemukan fenomena yang "menarik": detail teknis diungkapkan dengan cukup transparan, respons darurat juga bisa disebut tingkat buku teks, tetapi pada pertanyaan paling penting yaitu "mengapa bisa diretas," tampaknya menghindari inti masalah.
Laporan menjelaskan secara rinci tentang fungsi checked\_shlw dari pustaka integer-mate yang memeriksa kesalahan (seharusnya ≤2^192, sebenarnya ≤2^256) dan mengklasifikasikan ini sebagai "kesalahpahaman semantik". Meskipun pernyataan ini secara teknis benar, ini secara cerdik mengalihkan fokus pada tanggung jawab eksternal, seolah-olah Cetus juga merupakan korban yang tidak bersalah dari cacat teknis ini.
Masalahnya adalah, mengapa integer-mate adalah sebuah perpustakaan matematika yang sumber terbuka dan banyak digunakan, tetapi justru terjadi kesalahan konyol di tempat Anda di mana 1 token bisa mendapatkan bagian likuiditas bernilai tinggi?
Analisis jalur serangan hacker menunjukkan bahwa untuk melakukan serangan yang sempurna, hacker harus memenuhi empat kondisi sekaligus: pemeriksaan overflow yang salah, operasi pergeseran yang besar, aturan pembulatan ke atas, dan kurangnya verifikasi rasionalitas 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 seharusnya direnungkan oleh Cetus adalah sebagai berikut:
1）Mengapa menggunakan pustaka eksternal umum tanpa melakukan pengujian keamanan yang memadai? Meskipun pustaka integer-mate memiliki karakteristik seperti sumber terbuka, populer, dan banyak digunakan, Cetus menggunakannya untuk mengelola aset senilai ratusan juta dolar tanpa memahami dengan baik batasan keamanan pustaka ini, apakah ada solusi cadangan yang tepat jika fungsi pustaka tidak berfungsi, dan sebagainya. Jelas, Cetus kurang memiliki kesadaran dasar tentang perlindungan keamanan rantai pasokan;
Mengapa input angka astronomi diizinkan tanpa batasan? Meskipun protokol DeFi seharusnya mencari desentralisasi, semakin terbuka suatu sistem keuangan yang matang, semakin dibutuhkan batasan yang jelas.
Ketika sistem memungkinkan input angka astronomis yang dirancang dengan cermat oleh penyerang, tim jelas tidak mempertimbangkan apakah permintaan likuiditas seperti itu masuk akal? Bahkan untuk dana lindung nilai terbesar di dunia, tidak mungkin membutuhkan bagian likuiditas yang begitu berlebihan. Jelas, tim Cetus kekurangan bakat manajemen risiko yang memiliki intuisi keuangan;
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"; sementara pengguna hanya tahu uang mereka hilang!
Anda lihat, ini pada dasarnya mengungkapkan kelemahan sistemik keamanan di industri DeFi: tim dengan latar belakang teknis murni sangat kekurangan "indera risiko keuangan" dasar.
Namun, dari laporan Cetus ini, jelas bahwa tim tidak melakukan refleksi dengan baik.
Dibandingkan dengan kekurangan teknis yang murni terkait dengan serangan peretasan kali ini, saya merasa bahwa sejak Cetus, semua tim DeFi harus mengubah batasan pemikiran teknis murni, dan benar-benar mengembangkan kesadaran risiko keamanan dari "insinyur keuangan".
Misalnya: Menghadirkan ahli manajemen risiko keuangan untuk melengkapi kekurangan pengetahuan dalam tim teknologi; melakukan mekanisme audit dan pemeriksaan yang melibatkan banyak pihak, tidak hanya melihat audit kode, tetapi audit model ekonomi yang diperlukan juga harus dilengkapi; mengembangkan "indera keuangan", mensimulasikan berbagai skenario serangan dan langkah-langkah respons yang sesuai, serta tetap peka terhadap operasi yang abnormal, dan lain-lain.
Ini mengingatkan saya pada pengalaman kerja sebelumnya di perusahaan keamanan, termasuk konsensus yang ada saat berkomunikasi dengan para tokoh keamanan industri seperti @evilcos, @chiachih_wu, @yajinzhou, dan @mikelee205:
Seiring dengan matangnya 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 tidak memiliki Bug, tetapi bagaimana dapat mencapai "batas logis" memerlukan tim proyek untuk memiliki pemahaman yang lebih dalam tentang esensi bisnis dan kemampuan untuk mengontrol batasan. (Penyebab mendasar dari banyak "kejadian saling menyalahkan" setelah audit keamanan yang masih diserang hacker adalah hal ini.)
Masa depan DeFi adalah milik tim yang memiliki keterampilan teknis yang kuat dalam kode, sekaligus pemahaman mendalam tentang logika bisnis!
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Masalah keamanan Cetus mengingatkan: Apa yang harus diperhatikan oleh tim DeFi?
Penulis: Haotian
Setelah membaca laporan "ulasan" keamanan dari serangan hacker @CetusProtocol, Anda akan menemukan fenomena yang "menarik": detail teknis diungkapkan dengan cukup transparan, respons darurat juga bisa disebut tingkat buku teks, tetapi pada pertanyaan paling penting yaitu "mengapa bisa diretas," tampaknya menghindari inti masalah.
Laporan menjelaskan secara rinci tentang fungsi
checked\_shlwdari pustakainteger-mateyang memeriksa kesalahan (seharusnya ≤2^192, sebenarnya ≤2^256) dan mengklasifikasikan ini sebagai "kesalahpahaman semantik". Meskipun pernyataan ini secara teknis benar, ini secara cerdik mengalihkan fokus pada tanggung jawab eksternal, seolah-olah Cetus juga merupakan korban yang tidak bersalah dari cacat teknis ini.Masalahnya adalah, mengapa
integer-mateadalah sebuah perpustakaan matematika yang sumber terbuka dan banyak digunakan, tetapi justru terjadi kesalahan konyol di tempat Anda di mana 1 token bisa mendapatkan bagian likuiditas bernilai tinggi?Analisis jalur serangan hacker menunjukkan bahwa untuk melakukan serangan yang sempurna, hacker harus memenuhi empat kondisi sekaligus: pemeriksaan overflow yang salah, operasi pergeseran yang besar, aturan pembulatan ke atas, dan kurangnya verifikasi rasionalitas 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 seharusnya direnungkan oleh Cetus adalah sebagai berikut:
1）Mengapa menggunakan pustaka eksternal umum tanpa melakukan pengujian keamanan yang memadai? Meskipun pustaka
integer-matememiliki karakteristik seperti sumber terbuka, populer, dan banyak digunakan, Cetus menggunakannya untuk mengelola aset senilai ratusan juta dolar tanpa memahami dengan baik batasan keamanan pustaka ini, apakah ada solusi cadangan yang tepat jika fungsi pustaka tidak berfungsi, dan sebagainya. Jelas, Cetus kurang memiliki kesadaran dasar tentang perlindungan keamanan rantai pasokan;Ketika sistem memungkinkan input angka astronomis yang dirancang dengan cermat oleh penyerang, tim jelas tidak mempertimbangkan apakah permintaan likuiditas seperti itu masuk akal? Bahkan untuk dana lindung nilai terbesar di dunia, tidak mungkin membutuhkan bagian likuiditas yang begitu berlebihan. Jelas, tim Cetus kekurangan bakat manajemen risiko yang memiliki intuisi keuangan;
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!
Anda lihat, ini pada dasarnya mengungkapkan kelemahan sistemik keamanan di industri DeFi: tim dengan latar belakang teknis murni sangat kekurangan "indera risiko keuangan" dasar.
Namun, dari laporan Cetus ini, jelas bahwa tim tidak melakukan refleksi dengan baik.
Dibandingkan dengan kekurangan teknis yang murni terkait dengan serangan peretasan kali ini, saya merasa bahwa sejak Cetus, semua tim DeFi harus mengubah batasan pemikiran teknis murni, dan benar-benar mengembangkan kesadaran risiko keamanan dari "insinyur keuangan".
Misalnya: Menghadirkan ahli manajemen risiko keuangan untuk melengkapi kekurangan pengetahuan dalam tim teknologi; melakukan mekanisme audit dan pemeriksaan yang melibatkan banyak pihak, tidak hanya melihat audit kode, tetapi audit model ekonomi yang diperlukan juga harus dilengkapi; mengembangkan "indera keuangan", mensimulasikan berbagai skenario serangan dan langkah-langkah respons yang sesuai, serta tetap peka terhadap operasi yang abnormal, dan lain-lain.
Ini mengingatkan saya pada pengalaman kerja sebelumnya di perusahaan keamanan, termasuk konsensus yang ada saat berkomunikasi dengan para tokoh keamanan industri seperti @evilcos, @chiachih_wu, @yajinzhou, dan @mikelee205:
Seiring dengan matangnya 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 tidak memiliki Bug, tetapi bagaimana dapat mencapai "batas logis" memerlukan tim proyek untuk memiliki pemahaman yang lebih dalam tentang esensi bisnis dan kemampuan untuk mengontrol batasan. (Penyebab mendasar dari banyak "kejadian saling menyalahkan" setelah audit keamanan yang masih diserang hacker adalah hal ini.)
Masa depan DeFi adalah milik tim yang memiliki keterampilan teknis yang kuat dalam kode, sekaligus pemahaman mendalam tentang logika bisnis!