Laporan Keamanan Web3 Bulan Agustus: 29 Insiden Keamanan Utama, Total Kerugian Melebihi 68,29 Juta Dolar

Pada bulan Agustus 2026, insiden keamanan besar disebabkan oleh kerentanan kontrak, di mana terdapat 18 insiden keamanan akibat kerentanan kontrak/jaringan, dan 2 insiden keamanan akibat kebocoran kunci pribadi. Keamanan kontrak pintar dan manajemen kunci pribadi tetap menjadi titik lemah dalam keamanan Web3.

Penulis: Beosin

Menurut data pemantauan dari platform Beosin Alert, pada bulan Agustus 2026, total kerugian dari berbagai insiden keamanan mencapai sekitar 76,15 juta dolar, dengan total 29 insiden keamanan besar, yang sebagian besar disebabkan oleh kerentanan kontrak. Dari jumlah tersebut, 18 insiden keamanan disebabkan oleh kerentanan kontrak/jaringan, dan 2 insiden keamanan akibat kebocoran kunci pribadi. Keamanan kontrak pintar dan manajemen kunci pribadi tetap menjadi titik lemah dalam keamanan Web3.

Kerugian Terbesar Bulan Agustus

Pada tanggal 13 Agustus, alamat pengguna pribadi 0x13e3....179e kehilangan aset kripto seperti WBTC, cbBTC, LDO, USDS, CRV akibat kebocoran kunci pribadi, dengan total kerugian sekitar 25,6 juta dolar, menjadikannya insiden keamanan dengan kerugian terbesar. Pada tanggal 30 Agustus, protokol pinjaman Tectonic di jaringan Cronos mengalami serangan peretas akibat kerentanan kontrak, dengan kerugian diperkirakan mencapai 74 juta dolar. Serangan ini menyebabkan jaringan Cronos mengambil langkah darurat, menghentikan jaringan dan membatalkan transaksi, peretas akhirnya berhasil mentransfer sekitar 6 juta dolar ke jaringan Ethereum melalui transaksi lintas rantai.

Selain itu, blockchain Harmony mengalami pencetakan tambahan sekitar 4 miliar token ONE akibat kerentanan, dengan kerugian nominal melebihi 4 juta dolar, tetapi akhirnya status token palsu dihapus melalui pembatalan transaksi, sehingga tidak dihitung sebagai kerugian.

Jenis Proyek yang Diserang dan Kerugian di Setiap Rantai

Bulan ini, objek yang diserang mencakup berbagai jenis seperti blockchain publik, protokol pinjaman, aplikasi dompet, kontrak token, jembatan lintas rantai, dan pengguna biasa. Di mana proyek DeFi mengalami kerugian terbesar, mencapai 33,09 juta dolar; sementara alamat pribadi mengalami kerugian sekitar 28,4 juta dolar akibat kebocoran kunci pribadi atau phishing. Kontrak token diserang paling sering, tercatat sebanyak 10 kali; kontrak DeFi diserang sebanyak 9 kali.

Rantai dengan Kerugian Terbesar Bulan Mei adalah Ethereum, dengan kerugian melebihi 48,58 juta dolar, total 15 insiden keamanan. Saat ini, sebagian besar protokol DeFi dan serangan phishing terhadap whale masih berfokus pada Ethereum. Rantai dengan insiden keamanan terbanyak kedua adalah BNB Chain, tetapi target serangan terutama adalah kontrak token, dengan kerugian yang relatif kecil. Selain itu, blockchain publik seperti Cronos, Base, Harmony, Bitcoin, dan Solana juga mengalami insiden keamanan, menunjukkan tren serangan lintas rantai.

Analisis Insiden Keamanan Utama

1. Tectonic dan Moonwell: Manipulasi Harga

Tectonic dan Moonwell adalah protokol pinjaman di blockchain, yang diserang karena harga jaminan dari beberapa token dengan likuiditas rendah dimanipulasi, sehingga meminjam aset dengan nilai yang terlalu tinggi untuk mendapatkan keuntungan. Dalam serangan Tectonic, penyerang berhasil meningkatkan harga token tata kelola Tectonic $TONIC hingga 100 kali lipat, mendapatkan batas pinjaman sekitar 74 juta dolar, kemudian meminjam aset seperti USDT. Setelah insiden tersebut, jaringan Cronos dengan cepat menghentikan seluruh rantai, dan penyerang berhasil mentransfer sekitar 6 juta dolar ke Ethereum sebelum jaringan dihentikan. Setelah itu, jaringan Cronos melakukan rollback untuk memulihkan kerugian.

Alamat keuntungan peretas di Ethereum: 0xc404160B79BD8905061a1cAecBeCa2EEab3f72DD dan aliran dana yang dicuri:

Saat ini sekitar 2659 ETH masih disimpan di 0xc4041, 140,1 ETH dipindahkan ke 0x6df89c42f0abdfaa2b5b77edcdafbc945ed6ee6c dan kemudian terus disebar ke beberapa alamat baru yang dibuat.

Moonwell diserang karena penyerang memanipulasi harga token MAMO yang likuiditasnya rendah untuk meminjam cbBTC, dengan kerugian sekitar 8,7 juta dolar:

Kedua serangan ini bukan disebabkan oleh kerentanan kontrak pintar, tetapi karena protokol itu sendiri menetapkan harga jaminan dari likuiditas pasar yang lemah, menghitung nilai jaminan dengan salah. Untuk menghindari serangan semacam ini, protokol dapat menggunakan beberapa oracle untuk mendapatkan data dari berbagai sumber dan melakukan penilaian tambahan terhadap perubahan harga yang tajam.

2. Harmony: Serangan Replay

Harmony adalah Layer 1 yang mendukung sharding, menjalankan empat shard, dan mentransfer aset di antara mereka melalui mekanisme lintas shard asinkron berbasis bukti. Shard sumber menghasilkan bukti kriptografi untuk transaksi keluar, dan shard tujuan bertanggung jawab untuk memverifikasi bukti tersebut dan bukti Merkle sebelum mencatat transaksi, dan setiap bukti hanya dapat digunakan sekali.

Kerentanan dalam serangan ini ada di bagian warisan sistem shard Harmony. Sebelumnya, Harmony memeriksa apakah bukti shard telah digunakan dengan melihat dua bidang CXMerkleProof.ShardID dan BlockNum,

Karena kedua bidang ini berada di luar kepala blok yang telah ditandatangani, penyerang dapat memodifikasinya tanpa merusak fungsi yang ada. Dalam serangan ini, penyerang mendapatkan bukti lintas shard dan memodifikasi ShardID dan BlockNum, sehingga verifikator mengenalinya sebagai bukti baru. Shard tujuan menerima bukti yang dimodifikasi dan mencatatnya lagi, sementara shard asli tidak mengurangi aset yang sesuai.

Ini adalah contoh klasik dari serangan replay. Untuk setiap bidang yang digunakan sebagai "tanda penggunaan sekali", harus menjadi bagian dari header yang disetujui. Saat memverifikasi bukti, ID shard dan nomor blok harus dibaca langsung dari header blok yang telah diverifikasi, bukan dari bidang yang tidak terverifikasi dalam struktur bukti.

3. Term Finance: Serangan Tata Kelola

Term Finance adalah protokol pinjaman dengan suku bunga tetap DeFi, di mana setiap brankas (Vault) adalah ERC-4626 Vault yang didasarkan pada kode Yearn V3. Namun, tata kelola brankas Term Finance tidak menggunakan suara persetujuan, melainkan suara penolakan. Ketika kurator mengajukan proposal perubahan parameter, pengelola membuka jendela untuk meminta pemegang token LP untuk mengajukan keberatan. Namun, ada celah serius dalam pengaturan ambang batas suara:

● Kurangnya batasan jumlah suara atau modal absolut: Syarat untuk proposal yang disetujui, isSupportThresholdReached() dan isMinParticipationReached(), hanya memeriksa proporsi relatif, bukan jumlah suara absolut. Ini berarti bahwa selama proporsi relatif terpenuhi, proposal dapat disetujui, tanpa memperhatikan jumlah total orang yang memberikan suara atau total modal.

● Tingkat partisipasi yang sangat rendah: Hampir tidak ada deposan yang mengubah bagian brankas (tmvETH) menjadi token tata kelola (gtmvETH) untuk berpartisipasi dalam pemungutan suara. Ini mengakibatkan total pasokan token tata kelola untuk brankas terkait sangat rendah.

Penyerang memanfaatkan celah desain di atas untuk melakukan serangan tata kelola terhadap brankas dengan biaya yang sangat rendah:

(1) Mendapatkan hak suara: Penyerang menggunakan sekitar 0,5 ETH untuk mendapatkan sekitar 0,485 bagian brankas tmvETH, dan mengubahnya menjadi 0,485 token tata kelola gtmvETH, sehingga memperoleh hak suara.

(2) Mengajukan proposal jahat: Saat penyerang membuat proposal, kontrak mencatat total pasokan token tata kelola saat itu hanya 0,535 gtmvETH. Ini berarti bahwa 0,485 gtmvETH yang dimiliki penyerang telah mencapai 90,66% dari total pasokan.

(3) Pemungutan suara dan pelaksanaan: Penyerang sebagai satu-satunya pemilih memberikan suara setuju. Karena tidak ada suara penolakan, tingkat dukungannya jauh melebihi ambang batas 50%; pada saat yang sama, hak suara pribadinya juga melebihi ambang batas partisipasi minimum yang dihitung berdasarkan total pasokan yang sangat rendah (minVotingPower).

(4) Menarik aset: Setelah proposal disetujui, tindakan jahat dilaksanakan, menarik aset (WETH) dari brankas.

Penyerang menggunakan metode yang sama untuk menyerang 6 brankas Term Finance, menyebabkan kerugian sekitar 8,5 juta dolar.

Serangan ini juga merupakan contoh klasik dari serangan tata kelola protokol di blockchain. Untuk tata kelola di blockchain, pihak proyek harus menetapkan titik pemeriksaan berikut untuk pencegahan:

● Menetapkan batasan jumlah suara atau modal absolut: Proposal tata kelola tidak dapat hanya bergantung pada proporsi relatif untuk disetujui. Harus ada ambang batas yang ketat berdasarkan jumlah absolut, seperti meminta suara setuju mencapai jumlah tertentu (misalnya 1 juta dolar) atau jumlah alamat independen.

● Menyediakan pengawas atau jalur pembatalan untuk penguncian waktu: Meskipun pelaksanaan tata kelola biasanya memiliki penundaan, ini hanya memberikan waktu respons tertentu. Pihak proyek harus menyediakan mekanisme pengawas yang efektif (Guardian) atau jalur pembatalan untuk periode penundaan pelaksanaan. Jika proposal jahat ditemukan dalam periode penundaan, pengawas dapat segera campur tangan dan membatalkan.

● Memantau tingkat partisipasi tata kelola: Protokol harus membangun pemantauan waktu nyata terhadap tingkat partisipasi tata kelola di setiap brankas. Ketika menemukan bahwa total pasokan token tata kelola atau tingkat partisipasi suara untuk brankas tertentu sangat rendah, segera mengeluarkan peringatan, bahkan secara otomatis memicu langkah perlindungan.

Tren Ancaman Keamanan Web3

Tahun 2026 menunjukkan tren terdalam dalam keamanan Web3 adalah perluasan sistematis dari permukaan serangan. Kerentanan muncul di tingkat kode, operasi sehari-hari, dan interaksi, hanya mengandalkan beberapa audit keamanan atau alat tidak dapat mencakup keamanan operasional, tata kelola di blockchain, dan kerentanan logika bisnis. Ini memberikan tantangan baru bagi pihak proyek Web3 dalam membangun sistem pertahanan keamanan.

Selain itu, serangan terhadap kontrak DeFi dan pengguna pribadi semakin sering terjadi. Kerentanan kontrak atau otorisasi sangat mudah dimanfaatkan oleh penyerang, pengembang atau operator kontrak harus memeriksa kembali keamanan kontrak, dan untuk kontrak yang menangani bisnis inti, harus dilakukan audit keamanan berkali-kali dan dari berbagai pihak. Untuk pengguna pribadi, harus secara berkala menggunakan penjelajah blockchain atau alat pencabutan otorisasi untuk memeriksa dan membatalkan otorisasi kontrak yang tidak lagi digunakan, serta lebih memahami metode phishing yang umum dan baru, untuk meningkatkan kesadaran keamanan.