Bulan Juni yang baru lalu, dunia kripto mengalami serangkaian insiden keamanan yang melintasi banyak segmen.
Laporan keamanan bulanan terbaru dari PeckShield menunjukkan, pada Juni terjadi 40 insiden peretasan besar, dengan total kerugian mencapai 75,87 juta dolar AS. Yang lebih perlu diwaspadai adalah, serangan-serangan ini tidak terpusat pada satu jalur serangan tertentu, justru meliputi cacat implementasi tanda tangan dompet, kerentanan protokol L2, serangan rantai pasokan layanan pihak ketiga. Beberapa garis pertahanan berjatuhan dalam bulan yang sama.
Ketika risiko keamanan Web3 berkembang dari pintu masuk tunggal menjadi seluruh jalur interaksi on-chain, setiap pengguna dipaksa untuk memikirkan kembali sebuah pertanyaan: Apakah aset Crypto saya masih aman?
1. Di Luar Kunci Pribadi, Pentingnya Implementasi Tanda Tangan Dasar Dompet
Insiden keamanan yang terjadi pada dompet SecondFi di ekosistem Cardano bulan Juni, adalah contoh yang paling gamblang.
SecondFi adalah penerus dari dompet Yoroi di ekosistem Cardano. Pada tanggal 21 hingga 23 Juni, penyerang mentransfer sekitar 16 juta ADA dari alamat-alamat pengguna SecondFi tertentu, melibatkan sekitar 374 dompet. Menurut harga saat kejadian, nilainya sekitar 2,4 juta dolar AS. SecondFi kemudian menyatakan, melalui tindakan darurat telah melindungi sekitar 129 juta ADA lainnya yang mungkin terpengaruh.
Hal paling khusus dari peristiwa ini adalah, pengguna yang terdampak tidak secara aktif memberikan frasa pemulihan (seed phrase) kepada penyerang. Masalahnya terletak pada implementasi tanda tangan di lapisan dasar dompet, menurut analisis lembaga keamanan BlockSec, terdapat kesalahan dalam menurunkan nonce tanda tangan dari pesan transaksi publik, mengabaikan secret nonce prefix yang disyaratkan oleh implementasi standar.
Hal ini menyebabkan setiap kali pengguna menggunakan versi dompet yang terdampak untuk menandatangani transaksi, data tanda tangan publik yang dipublikasikan ke chain, akan membocorkan informasi yang cukup untuk menurunkan kunci pribadi alamat. Oleh karena itu, penyerang tidak perlu meretas ponsel pengguna, juga tidak perlu mendapatkan frasa pemulihan, cukup dengan menganalisis data on-chain yang publik, mungkin dapat memulihkan kunci pribadi tanda tangan alamat terkait.
Dari sudut pandang pengguna, dompet tetap berjalan normal, toh frasa pemulihan tidak muncul pop-up bocor, kata sandi tidak diretas, dan transaksi memang dimulai oleh diri sendiri. Namun dari perspektif kriptografi, selama alamat pengguna pernah menghasilkan beberapa tanda tangan yang valid melalui versi yang terdampak, data transaksi dan tanda tangan publik dapat membantu penyerang menurunkan kunci pribadi tanda tangan alamat tersebut.
Pada dasarnya, keamanan dompet masih bergantung pada apakah ia menghasilkan kunci pribadi dengan benar, apakah menandatangani dengan ketat sesuai standar kriptografi, serta apakah kode-kode kritis ini dapat diperiksa dan diverifikasi secara eksternal. Inilah pentingnya komponen inti dompet tetap bersumber terbuka (open-source).
Tentu saja, ini adalah cacat implementasi versi spesifik dompet tertentu, bukan masalah umum semua dompet self-custody. Sebagai contoh TokenCore dari imToken, repositori kode intinya dihosting secara terbuka di GitHub, mencakup fungsi-fungsi dasar dompet seperti manajemen kunci, penurunan alamat, dan penandatanganan transaksi.
Meskipun open-source tidak berarti kode pasti bebas dari kerentanan, apalagi berarti pengguna dapat sepenuhnya mengabaikan kewaspadaan, namun untuk komponen kriptografi dan tanda tangan yang paling sensitif dalam dompet, open-source setidaknya menyediakan prasyarat penting, yaitu peneliti keamanan, pengembang, dan komunitas dapat memeriksa kode, mereproduksi masalah, dan melakukan pengujian berkelanjutan, bukan hanya percaya pada black box yang tidak dapat diverifikasi.
Bagi pengguna biasa, insiden semacam ini juga sesuai dengan beberapa prinsip keamanan yang lebih realistis.
- Pertama, dompet harus selalu diunduh melalui situs web resmi atau toko aplikasi resmi, dan segera memperbarui ke versi aman;
- Kedua, tidak disarankan menyimpan semua aset dalam dompet interaksi harian yang sama. Aset bernilai besar untuk jangka panjang dapat disimpan menggunakan dompet perangkat keras (hardware wallet) atau dompet dingin (cold wallet) terpisah, diisolasi dari dompet panas (hot wallet) yang sering terhubung ke DApp.
- Yang lebih penting, begitu pihak dompet resmi mengkonfirmasi adanya kerentanan di tingkat pembangkitan kunci atau implementasi tanda tangan, sekadar mengimpor frasa pemulihan yang sama ke dompet lain biasanya tidak menyelesaikan masalah;
Karena setelah mengimpor set frasa pemulihan yang sama ke dompet lain, alamat dan kunci pribadi yang sebelumnya telah terbuka tidak akan berubah. Aset yang terdampak perlu dipindahkan ke alamat baru yang belum pernah menandatangani melalui versi yang bermasalah; bagi pengguna biasa, cara yang lebih aman biasanya adalah mengikuti prosedur darurat resmi untuk membuat ulang set dompet dan frasa pemulihan yang benar-benar baru, baru kemudian melakukan migrasi aset, bukan mengimpor atau mengoperasikan alamat lama berulang kali secara mandiri.
2. L2 Bukan Hanya "Ethereum yang Lebih Murah", Tetapi Juga Rangkaian Rantai Kepercayaan yang Kompleks
Selain dompet, beberapa insiden di bulan Juni juga mengarahkan risiko pada sistem L2 yang semakin kompleks.
Pada 14 dan 18 Juni, dua deployment Rollup versi lama yang terkait dengan Aztec berturut-turut diserang, dengan total kerugian sekitar 4,35 juta dolar AS.
Perlu dijelaskan khusus, yang diserang adalah deployment lama seperti Aztec Connect yang sudah dalam status warisan (legacy), tidak sama dengan Aztec Network mainnet saat ini yang diserang. Namun kedua insiden ini mengungkap masalah yang cukup memberi peringatan bagi seluruh bidang ZK Rollup.
Dalam salah satu insiden, penyerang memanfaatkan ketidaksesuaian antara jumlah transaksi dan data yang diproses secara aktual, membuat sistem mencatat deposit di dalam bukti (proof), tetapi melewati proses pengurangan saldo yang sesuai di L1.
Insiden lainnya berasal dari kurangnya kendala (constraint) dalam sirkuit bukti pengetahuan nol (zero-knowledge proof). Sistem memverifikasi sebuah bukti yang secara bentuk valid, tetapi tidak memastikan bahwa pohon status privat yang digunakan bukti tersebut, sepenuhnya konsisten dengan akar status publik di Ethereum yang benar-benar digunakan untuk penyelesaian (settlement). Penyerang karena itu dapat menghasilkan bukti seputar pohon status palsu, dan menarik aset dari kontrak L1.
Masalah semacam ini sulit digambarkan dengan istilah tradisional "apakah kontrak memiliki baris kode kerentanan tertentu". Bagaimanapun, bukti pengetahuan nol dapat membuktikan bahwa suatu proses perhitungan mematuhi aturan yang ditetapkan, namun syaratnya adalah aturan itu sendiri benar dan lengkap. Jika pengembang lupa memberikan kendala pada variabel kunci tertentu, bukti mungkin masih valid secara matematis, tetapi membuktikan hasil yang tidak konsisten dengan status penyelesaian yang sebenarnya.
Insiden keamanan yang kemudian terjadi di Taiko, mengungkap risiko lain dalam rantai kepercayaan L2.
Pada 22 Juni, proses verifikasi bukti berbasis SGX di Taiko dieksploitasi, menyebabkan kerugian sekitar 1,7 juta dolar AS. Menurut analisis BlockSec, penyerang menggunakan kunci pribadi tanda tangan SGX enclave yang pernah disubmit ke repositori GitHub publik, sekaligus memanfaatkan kelemahan kontrak verifikasi on-chain yang tidak menolak Enclave mode DEBUG, untuk mendaftarkan prover jahat sebagai instance yang sah.
Penyerang kemudian memalsukan bukti status L2, membuat kontrak di Ethereum menerima status L2 yang tidak ada, akhirnya menarik aset dari dana jembatan (bridge). Intinya, karena kunci yang digunakan untuk menandatangani lingkungan eksekusi tepercaya (TEE) dipublikasikan, sementara aturan autentikasi jarak jauh tidak memeriksa secara lengkap atribut lingkungan eksekusi, akhirnya membuat sebuah bukti yang "terautentikasi" kehilangan makna tepercaya yang seharusnya dimiliki.
Sementara itu, Base pada 25 hingga 26 Juni mengalami penghentian produksi blok mainnet secara berturut-turut. Base dalam review pasca-kejadian menyatakan, kedua interupsi berasal dari cacat logika pembangunan blok yang sama: sebuah transaksi yang gagal dieksekusi tidak membersihkan dengan benar status yang tercatat sebelumnya, menyebabkan transaksi berikutnya salah menghitung Gas, dan menghasilkan blok yang berisi konversi status tidak valid. Karena node lain tidak dapat menerima blok tersebut, jaringan akhirnya berhenti melanjutkan. Base menyatakan, selama insiden, integritas chain tidak rusak, dana pengguna tetap aman.
Ini bukan pencurian aset atau serangan eksternal, melainkan kerusakan teknis yang mempengaruhi ketersediaan (availability) dan kemampuan pemulihan jaringan. Namun dari perspektif keamanan yang lebih luas, ketersediaan itu sendiri juga merupakan bagian dari model keamanan L2.
Karena bagi pengguna, apakah suatu chain aman, tidak hanya tergantung pada apakah peretas dapat memalsukan aset, tetapi juga pada apakah blok dapat terus diproduksi, apakah jembatan silang rantai (cross-chain bridge) dapat bekerja normal, apakah node dapat cepat pulih, serta apakah ketika sistem mengalami kerusakan, pengguna masih memiliki jalur keluar yang layak.
Oleh karena itu, pengguna saat menggunakan L2 juga sebaiknya tidak hanya membandingkan biaya transaksi dan ekspektasi airdrop. Untuk L2 yang skalanya kecil, baru diluncurkan, atau mekanisme keamanannya masih berubah cepat, hindari menyimpan aset bernilai besar melebihi kebutuhan penggunaan aktual untuk jangka panjang; sebelum melakukan cross-chain, konfirmasi menggunakan bridge resmi, dan pahami waktu penarikan, mekanisme penangguhan, dan cara keluar darurat; ketika menghadapi jaringan yang berhenti memproduksi blok, cross-chain abnormal, atau peringatan keamanan resmi dirilis, jangan berulang kali mengirimkan transaksi atau terus mengirim aset melalui bridge.
Cara yang lebih aman adalah mengelola aset dengan tujuan dan tingkat risiko berbeda secara tersebar, bukan menaruh semua likuiditas pada L2 yang sama, bridge silang yang sama, atau mekanisme keluar yang sama.
3. Kontrak Tidak Diretas, Layanan Pihak Ketiga Juga Dapat Membawa Serangan kepada Pengguna
Jika masalah dompet dan L2 masih terjadi pada komponen teknis yang relatif mendasar, maka insiden Polymarket menunjukkan bahwa frontend web yang paling dekat dengan pengguna, juga dapat menjadi pintu masuk dana.
Pada 25 Juni, Polymarket menyatakan, salah satu vendor pihak ketiga yang digunakannya diretas, penyerang memanfaatkannya untuk menyuntikkan skrip jahat ke frontend Polymarket yang diakses sebagian pengguna.
Menurut statistik lembaga keamanan dan analis on-chain, insiden menyebabkan kerugian aset pengguna sekitar 3 juta dolar AS, melibatkan sekitar 11 dompet. Dana yang dicuri kemudian dicross-chain dari Polygon ke Ethereum, dan ditukar menjadi sekitar 1.893 ETH. Namun kemudian Polymarket menyatakan telah menghapus dependensi yang terdampak, dan akan mengganti kerugian sepenuhnya kepada pengguna yang terdampak.
Kunci dari insiden ini adalah, yang diakses pengguna mungkin masih domain Polymarket yang benar, pengungkapan yang ada sejauh ini juga tidak mengarah pada kerentanan inti kontrak pintar Polymarket. Masalahnya terutama terletak pada dependensi frontend pihak ketiga yang dimuat halaman web.
Ini juga merupakan cerminan, kebanyakan aplikasi Web3 saat ini tidak berjalan sepenuhnya on-chain. Halaman web yang dilihat pengguna, seperti antarmuka perdagangan, masih sangat bergantung pada infrastruktur internet tradisional dan paket perangkat lunak pihak ketiga. Setiap dependensi yang diserang, dapat membuat situs web sah menampilkan informasi salah kepada pengguna, mengganti alamat penerima, atau mengarahkan dompet untuk menandatangani transaksi jahat.
Karena itu, "URL-nya benar" tidak secara otomatis sama dengan "semua kode yang dimuat saat ini aman". "Kontrak telah diaudit" juga tidak berarti seluruh jalur interaksi antara pengguna dan kontrak bebas risiko. Menghadapi serangan frontend dan rantai pasokan semacam ini, pengguna biasa sulit memeriksa secara mandiri setiap segmen kode yang dimuat halaman web. Namun mereka masih dapat membatasi kerugian potensial dengan mengurangi izin interaksi sekali pakai:
- Gunakan dompet interaksi DApp yang terpisah: Dompet tabungan jangka panjang sebisa mungkin jangan langsung terhubung ke berbagai situs web DeFi, NFT, pasar prediksi, dan airdrop. Dompet interaksi harian hanya menyimpan dana yang direncanakan digunakan dalam waktu dekat. Sekalipun frontend atau otorisasi bermasalah, cakupan dampaknya relatif terbatas;
- Perhatikan operasi aktual sebelum menandatangani, bukan hanya tombol di halaman web: Yang tertulis di halaman web adalah "Login", "Klaim", atau "Konfirmasi Pesanan", tidak berarti tanda tangan yang muncul di dompet juga hal yang sama;
- Ketika halaman web menunjukkan keanehan, jangan mengandalkan kebiasaan untuk terus beroperasi: Halaman tiba-tiba meminta mengimpor ulang frasa pemulihan, mengunduh ekstensi tambahan, atau konten transaksi yang ditampilkan tidak sesuai dengan deskripsi di halaman web, hentikan interaksi, konfirmasi situasi melalui beberapa saluran resmi proyek, dan periksa atau cabut otorisasi sejarah yang tidak lagi digunakan;
Dari perspektif produk dompet, ini juga berarti peran yang diemban dompet sedang berubah.
Ia tidak boleh hanya menjadi alat penyimpan kunci pribadi dan memunculkan jendela tanda tangan, tetapi juga perlu sebisa mungkin membantu pengguna memahami maksud transaksi, mengidentifikasi otorisasi abnormal, menampilkan perubahan aset, dan memberikan peringatan yang cukup jelas sebelum interaksi berisiko tinggi terjadi.
Tetapi dompet juga tidak dapat menghilangkan semua risiko bagi pengguna. Model keamanan yang lebih realistis adalah dompet, protokol, L2, penyedia layanan pihak ketiga, dan pengguna bersama-sama memperkecil permukaan serangan, bukan mengalihkan seluruh tanggung jawab kepada pihak mana pun.
Sebagai Penutup
Dulu, orang sering berkata, siapa yang menguasai kunci pribadi, dialah yang menguasai aset on-chain.
Pernyataan ini masih berlaku, tetapi tidak mencakup seluruh proses aset pengguna dari "munculnya niat transaksi" hingga "penyelesaian on-chain". Keamanan Web3 hari ini bukan lagi hanya melindungi satu set frasa pemulihan, tetapi melindungi seluruh jalur mulai dari pembangkitan kunci oleh dompet, penampilan transaksi, eksekusi tanda tangan, hingga verifikasi jaringan dan penyelesaian akhir.
Tentu saja, ini tidak berarti pengguna harus menjauhi semua interaksi on-chain. Bagi pengguna, kebiasaan keamanan yang benar-benar efektif berarti perlu memisahkan pengelolaan antara tujuan aset, tingkat risiko, dan skenario interaksi: Aset jangka panjang, prioritaskan isolasi; interaksi harian, gunakan jumlah kecil; DApp asing, beri otorisasi rendah; operasi berisiko tinggi, lakukan verifikasi berlapis.
Bagaimanapun, ketika risiko keamanan berkembang dari sebuah titik menjadi sebuah rantai, pertahanan pengguna juga harus ditingkatkan dari melindungi kunci pribadi, menjadi seperangkat kebiasaan yang lengkap.
Semangat bersama.
