Refleksi dan Pelajaran dari Insiden Serangan Hacker pada Protokol Cetus
Sebuah protokol baru-baru ini merilis laporan keamanan "replay" tentang serangan Hacker. Laporan tersebut mengungkapkan detail teknis dan respons darurat dengan cukup transparan, bisa dibilang setara dengan buku teks. Namun, ketika menjawab pertanyaan inti "mengapa bisa diserang", laporan tersebut tampak menghindari inti permasalahan.
Laporan tersebut menjelaskan secara panjang lebar tentang kesalahan pemeriksaan fungsi checked_shlw dalam pustaka integer-mate (seharusnya ≤2^192, tetapi sebenarnya ≤2^256), dan mengkualifikasikannya sebagai "kesalahpahaman semantik". Meskipun narasi ini secara teknis tidak dapat diperdebatkan, namun dengan cerdik mengalihkan fokus ke tanggung jawab eksternal, seolah-olah protokol itu sendiri juga merupakan korban yang tidak bersalah dari cacat teknis ini.
Namun, yang patut dipikirkan adalah: mengingat integer-mate adalah pustaka matematika sumber terbuka yang banyak digunakan, mengapa kesalahan yang begitu konyol muncul dalam protokol ini, sehingga hanya dengan 1 token dapat memperoleh bagian likuiditas yang sangat besar?
Menganalisis jalur serangan Hacker dapat menemukan bahwa untuk berhasil melaksanakan serangan, empat kondisi harus dipenuhi secara bersamaan: pemeriksaan overflow yang salah, operasi pergeseran besar yang ekstrem, aturan pembulatan ke atas, dan kurangnya verifikasi kelayakan ekonomi. Yang mengejutkan, protokol mengalami 'kelalaian' pada setiap kondisi 'pemicu': menerima input pengguna seperti 2^200 yang merupakan angka astronomis, menggunakan operasi pergeseran besar yang sangat berbahaya, dan sepenuhnya mempercayai mekanisme pemeriksaan dari pustaka eksternal. Yang paling fatal adalah, ketika sistem menghitung hasil '1 token ditukar dengan porsi yang sangat mahal' yang jelas tidak masuk akal, tidak ada pemeriksaan kelayakan ekonomi yang dilakukan sebelum langsung dieksekusi.
Oleh karena itu, pertanyaan yang benar-benar perlu direnungkan tentang protokol ini mencakup:
Mengapa tidak dilakukan pengujian keamanan yang memadai saat menggunakan pustaka eksternal umum? Meskipun pustaka integer-mate memiliki karakteristik sumber terbuka, populer, dan banyak digunakan, saat mengelola aset senilai ratusan juta dolar, jelas bahwa protokol tidak memiliki pemahaman mendalam tentang batas keamanan pustaka tersebut, serta rencana cadangan jika fungsi pustaka gagal. Ini mengungkapkan kurangnya kesadaran protokol terhadap keamanan rantai pasokan.
Mengapa mengizinkan input angka astronomis tanpa menetapkan batasan yang wajar? Meskipun protokol keuangan terdesentralisasi mengejar keterbukaan, semakin terbuka suatu sistem keuangan yang matang, semakin diperlukan batasan yang jelas. Mengizinkan input nilai yang begitu berlebihan menunjukkan bahwa tim kekurangan talenta manajemen risiko yang memiliki intuisi keuangan.
Mengapa setelah beberapa putaran audit keamanan masalah masih belum dapat terdeteksi sebelumnya? Ini mencerminkan kesalahan pemahaman yang fatal: pihak proyek sepenuhnya mengalihkan tanggung jawab keamanan kepada perusahaan keamanan, menganggap audit sebagai medali pembebasan tanggung jawab. Namun, insinyur audit keamanan umumnya lebih ahli dalam menemukan celah kode, dan jarang mempertimbangkan masalah yang mungkin ada ketika sistem pengujian menghitung rasio pertukaran yang sangat tidak masuk akal.
Verifikasi yang melintasi batasan matematika, kriptografi, dan ekonomi ini adalah titik buta terbesar di bidang keamanan keuangan terdesentralisasi modern. Perusahaan audit mungkin menganggap ini sebagai cacat desain model ekonomi, bukan masalah logika kode; pihak proyek mungkin mengeluh bahwa audit tidak menemukan masalah; dan pada akhirnya, yang dirugikan adalah aset pengguna.
Kejadian ini mengungkapkan kekurangan keamanan sistemik dalam industri keuangan terdesentralisasi: tim dengan latar belakang teknis murni sering kali kurang memiliki "indera penciuman risiko keuangan" yang dasar.
Dari laporan protokol tersebut, tim tampaknya tidak sepenuhnya menyadari hal ini. Alih-alih hanya fokus pada kelemahan teknis dari serangan Hacker kali ini, semua tim keuangan terdesentralisasi harus melampaui batasan pemikiran teknis murni dan benar-benar mengembangkan kesadaran risiko keamanan "insinyur keuangan".
Langkah-langkah spesifik dapat mencakup: mengundang ahli manajemen risiko keuangan untuk menutupi kekurangan pengetahuan tim teknis; membangun mekanisme audit dan pemeriksaan multi-pihak, tidak hanya fokus pada audit kode, tetapi juga memperhatikan audit model ekonomi; mengembangkan "indera keuangan", mensimulasikan berbagai skenario serangan dan langkah-langkah tanggapan yang sesuai, serta tetap waspada terhadap operasi yang mencurigakan.
Ini mengingatkan kita pada konsensus para profesional di industri keamanan: seiring matangnya industri, kerentanan teknis murni di tingkat kode akan berkurang, sementara "kerentanan kesadaran" dari logika bisnis yang tidak jelas batasnya dan tanggung jawab yang kabur akan menjadi tantangan terbesar.
Perusahaan audit dapat memastikan bahwa kode tidak memiliki celah, tetapi bagaimana mewujudkan "logika memiliki batas" memerlukan pemahaman yang lebih dalam dari tim proyek tentang esensi bisnis dan kemampuan untuk mengontrol batasan. Ini juga menjelaskan mengapa banyak proyek yang telah melalui audit keamanan masih mengalami serangan Hacker.
Masa depan keuangan terdesentralisasi pasti akan menjadi milik tim yang tidak hanya memiliki teknologi kode yang kuat, tetapi juga pemahaman yang mendalam tentang logika bisnis!
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Cetus protokol diretas mengungkapkan kelemahan keamanan DeFi: celah teknis dan finansial perlu segera dijembatani
Refleksi dan Pelajaran dari Insiden Serangan Hacker pada Protokol Cetus
Sebuah protokol baru-baru ini merilis laporan keamanan "replay" tentang serangan Hacker. Laporan tersebut mengungkapkan detail teknis dan respons darurat dengan cukup transparan, bisa dibilang setara dengan buku teks. Namun, ketika menjawab pertanyaan inti "mengapa bisa diserang", laporan tersebut tampak menghindari inti permasalahan.
Laporan tersebut menjelaskan secara panjang lebar tentang kesalahan pemeriksaan fungsi checked_shlw dalam pustaka integer-mate (seharusnya ≤2^192, tetapi sebenarnya ≤2^256), dan mengkualifikasikannya sebagai "kesalahpahaman semantik". Meskipun narasi ini secara teknis tidak dapat diperdebatkan, namun dengan cerdik mengalihkan fokus ke tanggung jawab eksternal, seolah-olah protokol itu sendiri juga merupakan korban yang tidak bersalah dari cacat teknis ini.
Namun, yang patut dipikirkan adalah: mengingat integer-mate adalah pustaka matematika sumber terbuka yang banyak digunakan, mengapa kesalahan yang begitu konyol muncul dalam protokol ini, sehingga hanya dengan 1 token dapat memperoleh bagian likuiditas yang sangat besar?
Menganalisis jalur serangan Hacker dapat menemukan bahwa untuk berhasil melaksanakan serangan, empat kondisi harus dipenuhi secara bersamaan: pemeriksaan overflow yang salah, operasi pergeseran besar yang ekstrem, aturan pembulatan ke atas, dan kurangnya verifikasi kelayakan ekonomi. Yang mengejutkan, protokol mengalami 'kelalaian' pada setiap kondisi 'pemicu': menerima input pengguna seperti 2^200 yang merupakan angka astronomis, menggunakan operasi pergeseran besar yang sangat berbahaya, dan sepenuhnya mempercayai mekanisme pemeriksaan dari pustaka eksternal. Yang paling fatal adalah, ketika sistem menghitung hasil '1 token ditukar dengan porsi yang sangat mahal' yang jelas tidak masuk akal, tidak ada pemeriksaan kelayakan ekonomi yang dilakukan sebelum langsung dieksekusi.
Oleh karena itu, pertanyaan yang benar-benar perlu direnungkan tentang protokol ini mencakup:
Mengapa tidak dilakukan pengujian keamanan yang memadai saat menggunakan pustaka eksternal umum? Meskipun pustaka integer-mate memiliki karakteristik sumber terbuka, populer, dan banyak digunakan, saat mengelola aset senilai ratusan juta dolar, jelas bahwa protokol tidak memiliki pemahaman mendalam tentang batas keamanan pustaka tersebut, serta rencana cadangan jika fungsi pustaka gagal. Ini mengungkapkan kurangnya kesadaran protokol terhadap keamanan rantai pasokan.
Mengapa mengizinkan input angka astronomis tanpa menetapkan batasan yang wajar? Meskipun protokol keuangan terdesentralisasi mengejar keterbukaan, semakin terbuka suatu sistem keuangan yang matang, semakin diperlukan batasan yang jelas. Mengizinkan input nilai yang begitu berlebihan menunjukkan bahwa tim kekurangan talenta manajemen risiko yang memiliki intuisi keuangan.
Mengapa setelah beberapa putaran audit keamanan masalah masih belum dapat terdeteksi sebelumnya? Ini mencerminkan kesalahan pemahaman yang fatal: pihak proyek sepenuhnya mengalihkan tanggung jawab keamanan kepada perusahaan keamanan, menganggap audit sebagai medali pembebasan tanggung jawab. Namun, insinyur audit keamanan umumnya lebih ahli dalam menemukan celah kode, dan jarang mempertimbangkan masalah yang mungkin ada ketika sistem pengujian menghitung rasio pertukaran yang sangat tidak masuk akal.
Verifikasi yang melintasi batasan matematika, kriptografi, dan ekonomi ini adalah titik buta terbesar di bidang keamanan keuangan terdesentralisasi modern. Perusahaan audit mungkin menganggap ini sebagai cacat desain model ekonomi, bukan masalah logika kode; pihak proyek mungkin mengeluh bahwa audit tidak menemukan masalah; dan pada akhirnya, yang dirugikan adalah aset pengguna.
Kejadian ini mengungkapkan kekurangan keamanan sistemik dalam industri keuangan terdesentralisasi: tim dengan latar belakang teknis murni sering kali kurang memiliki "indera penciuman risiko keuangan" yang dasar.
Dari laporan protokol tersebut, tim tampaknya tidak sepenuhnya menyadari hal ini. Alih-alih hanya fokus pada kelemahan teknis dari serangan Hacker kali ini, semua tim keuangan terdesentralisasi harus melampaui batasan pemikiran teknis murni dan benar-benar mengembangkan kesadaran risiko keamanan "insinyur keuangan".
Langkah-langkah spesifik dapat mencakup: mengundang ahli manajemen risiko keuangan untuk menutupi kekurangan pengetahuan tim teknis; membangun mekanisme audit dan pemeriksaan multi-pihak, tidak hanya fokus pada audit kode, tetapi juga memperhatikan audit model ekonomi; mengembangkan "indera keuangan", mensimulasikan berbagai skenario serangan dan langkah-langkah tanggapan yang sesuai, serta tetap waspada terhadap operasi yang mencurigakan.
Ini mengingatkan kita pada konsensus para profesional di industri keamanan: seiring matangnya industri, kerentanan teknis murni di tingkat kode akan berkurang, sementara "kerentanan kesadaran" dari logika bisnis yang tidak jelas batasnya dan tanggung jawab yang kabur akan menjadi tantangan terbesar.
Perusahaan audit dapat memastikan bahwa kode tidak memiliki celah, tetapi bagaimana mewujudkan "logika memiliki batas" memerlukan pemahaman yang lebih dalam dari tim proyek tentang esensi bisnis dan kemampuan untuk mengontrol batasan. Ini juga menjelaskan mengapa banyak proyek yang telah melalui audit keamanan masih mengalami serangan Hacker.
Masa depan keuangan terdesentralisasi pasti akan menjadi milik tim yang tidak hanya memiliki teknologi kode yang kuat, tetapi juga pemahaman yang mendalam tentang logika bisnis!