Alasan kejadian ini adalah karena masyarakat gagal menemukan risiko dalam proposal saat memeriksa proposal, dan tidak memverifikasi dengan hati-hati apakah kode kontrak proposal memiliki kerentanan keamanan.

Ditulis oleh: SharkTeam

Pada 20 Mei 2023, waktu Beijing, Tornado.Cash mengalami serangan proposal, dan penyerang mendapat untung sekitar 680.000 dolar AS. SharkTeam melakukan analisis teknis atas insiden ini untuk pertama kalinya, dan merangkum tindakan pencegahan keamanan, berharap proyek selanjutnya dapat belajar darinya dan membangun garis pertahanan keamanan untuk industri blockchain.

1. Analisis Peristiwa

Alamat penyerang:

0x092123663804f8801b9b086b03B98D706f77bD59

0x592340957eBC9e4Afb0E9Af221d06fDDDF789de9

Kontrak serangan:

0xAF54612427d97489707332efe0b6290F129DbAcb

0x03ecf0d22f9ccd21144a7d492cf63b471916497a

0x7dc86183274b28e9f1a100a0152dac975361353d (kontrak penerapan)

0xc503893b3e3c0c6b909222b45f2a3a259a52752d (kontrak proposal palsu)

Kontrak yang diserang:

0x5efda50f22d34F262c29268506C5Fa42cB56A1Ce

Memulai transaksi proposal:

0x34605f1d6463a48b818157f7b26d040f8dd329273702a0618e9e74fe350e6e0d

Transaksi penyerangan:

0x3274b6090685b842aca80b304a4dcee0f61ef8b6afee10b7c7533c32fb75486d

Proses serangan:

(1) Pertama, penyerang (0x08e80ecb) mengajukan proposal ke kontrak yang diserang (0x5efda50f), mengklaim bahwa proposal ini merupakan tambahan dari Proposisi 16

(2) Tapi sebenarnya ada fungsi penghancuran diri tambahan dalam proposal.

(3) Sayangnya, masyarakat tidak menemukan masalah dalam proposal ini, dan sebagian besar anggota memilih untuk menyetujui proposal ini.

(4) Penyerang membuat banyak kontrak untuk mengimplementasikan transfer token

(5) Penyerang (0x08e80ecb) menghancurkan kontrak proposal (0xc503893b) dan kontrak pembuatannya (0x7dc86183). Kontrak serangan (0xc503893b) kemudian diterapkan kembali di alamat yang sama.

(6) Setelah memodifikasi kontrak proposal, penyerang (0x08e80ecb) mengeksekusi proposal dan mengubah jumlah kunci token dari alamat kontrak di bawah kendalinya menjadi 10000.

(7) Setelah proposal dieksekusi, penyerang (0x08e80ecb) mentransfer token ke alamatnya sendiri dan mendapatkan kepemilikan kontrak yang diserang.

Analisis kerentanan: Karena kontrak pembuatan (0x7dc86183) dari kontrak proposal (0xc503893b) diterapkan melalui creat2, setelah kedua kontrak dihancurkan, kontrak logika baru dapat digunakan di alamat yang sama, dan eksekusi proposal dipanggil dalam formulir dari panggilan delegasi. Kontrak yang menyerang dapat secara sewenang-wenang mengubah nilai dalam kontrak yang diserang.

Ringkasan insiden: Alasan insiden ini adalah karena komunitas gagal menemukan risiko dalam proposal saat memeriksa proposal, dan tidak memverifikasi dengan hati-hati apakah kode kontrak proposal memiliki kerentanan keamanan.

2. Rekomendasi Keamanan

Menanggapi serangan ini, kita harus mengikuti tindakan pencegahan berikut selama proses pengembangan:

• Saat merancang proposal, pertimbangkan sepenuhnya keamanan mekanisme proposal dan minimalkan risiko proposal dikendalikan secara terpusat. Pertimbangkan untuk mengurangi nilai serangan, meningkatkan biaya untuk mendapatkan hak suara, dan meningkatkan biaya eksekusi serangan, dll. desain.
• Sebelum memberikan suara pada proposal, komunitas harus hati-hati memeriksa apakah kode kontrak memiliki pintu belakang.
• Sebelum proposal disetujui, perusahaan audit keamanan pihak ketiga dapat dihubungi untuk melakukan audit keamanan terhadap kode logika kontrak.