Tidak hanya sekadar kunci pribadi: dari dompet, L2 hingga rantai pasok, bagaimana menjaga batas keamanan Web3?

Baru saja berlalu bulan Juni, dunia kripto mengalami rentetan insiden keamanan yang mencakup berbagai lapisan.

Laporan keamanan bulanan terbaru yang dirilis oleh PeckShield menunjukkan bahwa pada bulan Juni terjadi 40 serangan peretasan besar dengan total kerugian mencapai 75,87 juta dolar AS. Yang lebih patut diwaspadai, serangan-serangan ini tidak terfokus pada satu jalur serangan tertentu, melainkan mencakup cacat implementasi tanda tangan dompet, kerentanan protokol L2, serangan rantai pasokan pihak ketiga. Beberapa garis pertahanan runtuh secara berurutan dalam satu bulan yang sama.

Ketika risiko keamanan Web3 meluas dari satu titik masuk ke seluruh jalur interaksi on-chain, setiap pengguna harus memikirkan kembali satu pertanyaan: Apakah aset kripto saya masih aman?

1. Di luar kunci privat, pentingnya implementasi tanda tangan di level dompet

Insiden keamanan yang terjadi di SecondFi, dompet ekosistem Cardano, pada bulan Juni adalah contoh yang paling jelas.

SecondFi sebelumnya adalah Yoroi, dompet ekosistem Cardano. Pada 21 hingga 23 Juni, penyerang mentransfer sekitar 16 juta ADA dari beberapa alamat pengguna SecondFi, yang melibatkan sekitar 374 dompet. Berdasarkan harga saat kejadian, kerugiannya sekitar 2,4 juta dolar AS. SecondFi kemudian menyatakan bahwa melalui langkah darurat, mereka juga melindungi sekitar 129 juta ADA yang mungkin terpengaruh.

Yang paling unik dari insiden ini adalah bahwa pengguna yang terkena dampak tidak secara aktif memberikan seed phrase kepada penyerang; masalahnya terletak pada implementasi tanda tangan di level dompet. Menurut analisis dari lembaga keamanan BlockSec, nonce tanda tangan diturunkan secara salah dari data transaksi publik yang dirilis, sehingga melewatkan awalan nonce rahasia yang diperlukan oleh implementasi standar.

Akibatnya, setiap kali pengguna menandatangani transaksi menggunakan versi dompet yang terpengaruh, data tanda tangan publik yang dirilis ke rantai akan mengekspos informasi yang cukup untuk menurunkan kunci privat alamat tersebut. Oleh karena itu, penyerang tidak perlu meretas ponsel pengguna atau mendapatkan seed phrase; cukup dengan menganalisis data on-chain publik, mereka dapat memulihkan kunci privat tanda tangan dari alamat yang sesuai.

Dari sudut pandang pengguna, dompet masih berjalan normal, karena seed phrase tidak muncul di popup, kata sandi tidak diretas, dan transaksi memang dimulai oleh pengguna sendiri. Namun dari sisi kriptografi, selama alamat pengguna telah menghasilkan beberapa tanda tangan yang valid melalui versi yang terpengaruh, data transaksi dan tanda tangan publik dapat membantu penyerang menurunkan kunci privat tanda tangan alamat tersebut.

Singkatnya, keamanan dompet juga bergantung pada apakah kunci privat dihasilkan dengan benar, apakah tanda tangan diselesaikan secara ketat sesuai standar kriptografi, dan apakah kode-kode kunci ini dapat diaudit dan diverifikasi secara eksternal. Inilah pentingnya komponen inti dompet tetap bersifat sumber terbuka.

Tentu saja, ini adalah cacat implementasi pada versi tertentu dari dompet tertentu, bukan masalah umum pada semua dompet non-penyimpanan. Ambil contoh TokenCore milik imToken, repositori kode intinya di-hosting secara publik di GitHub, mencakup fungsi dompet dasar seperti manajemen kunci, derivasi alamat, dan tanda tangan transaksi.

Meskipun sumber terbuka tidak berarti kode tersebut pasti bebas dari kerentanan, apalagi berarti pengguna dapat sepenuhnya lengah, setidaknya untuk komponen kriptografi dan tanda tangan yang paling sensitif dalam dompet, sumber terbuka memberikan prasyarat penting: peneliti keamanan, pengembang, dan komunitas dapat memeriksa kode, mereproduksi masalah, dan terus menguji, bukan hanya mempercayai kotak hitam 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 resmi atau toko aplikasi resmi, dan perbarui ke versi keamanan tepat waktu.

Kedua, jangan menyimpan semua aset dalam satu dompet interaksi harian. Aset besar jangka panjang dapat disimpan menggunakan dompet perangkat keras atau dompet dingin independen, terisolasi dari dompet panas yang sering terhubung dengan DApp.

Yang lebih penting, begitu dompet resmi mengonfirmasi adanya kerentanan pada level pembuatan kunci atau implementasi tanda tangan, hanya mengimpor seed phrase yang sama ke dompet lain biasanya tidak menyelesaikan masalah.

Karena setelah mengimpor seed phrase yang sama ke dompet lain, alamat dan kunci privat yang sudah terekspos tidak akan berubah. Aset yang terpengaruh perlu dipindahkan ke alamat baru yang belum pernah ditandatangani melalui versi rentan. Bagi pengguna biasa, tindakan yang lebih aman biasanya adalah membuat ulang dompet dan seed phrase yang benar-benar baru sesuai prosedur darurat resmi, lalu melakukan migrasi aset, daripada terus-menerus mengimpor atau memanipulasi alamat asli sendiri.

2. L2 bukan hanya "Ethereum yang lebih murah", tetapi juga rantai kepercayaan yang kompleks

Selain dompet, beberapa insiden di bulan Juni juga mengarahkan risiko ke sistem L2 yang semakin kompleks.

Pada 14 dan 18 Juni, dua penyebaran Rollup lawas yang terkait dengan Aztec diserang secara berurutan, dengan total kerugian sekitar 4,35 juta dolar AS.

Perlu dicatat secara khusus bahwa yang diserang adalah penyebaran lawas seperti Aztec Connect yang sudah dalam status peninggalan (legacy), bukan berarti jaringan utama Aztec Network saat ini diserang. Namun, masalah yang terungkap dari kedua insiden ini memberikan peringatan yang cukup signifikan bagi seluruh bidang ZK Rollup.

Dalam salah satu insiden, penyerang memanfaatkan ketidaksesuaian antara jumlah transaksi dan data yang diproses secara aktual, sehingga sistem mencatat setoran dalam bukti, tetapi melewatkan proses pengurangan saldo yang sesuai di L1.

Insiden lainnya berasal dari kurangnya batasan dalam rangkaian zero-knowledge proof. Sistem memverifikasi bukti yang valid secara formal, tetapi tidak memastikan bahwa state tree privat yang digunakan dalam bukti tersebut sepenuhnya konsisten dengan akar state publik yang benar-benar digunakan untuk penyelesaian di Ethereum. Akibatnya, penyerang dapat menghasilkan bukti berdasarkan state tree palsu dan menarik aset dari kontrak L1.

Masalah semacam ini sulit dirangkum dengan "apakah kontrak memiliki satu baris kode kerentanan tertentu". Lagi pula, zero-knowledge proof dapat membuktikan bahwa suatu proses komputasi mematuhi aturan yang ditetapkan, tetapi dengan syarat aturan itu sendiri benar dan lengkap. Jika pengembang lupa membatasi variabel kunci, bukti tersebut mungkin masih valid secara matematis, namun membuktikan hasil yang tidak konsisten dengan state penyelesaian yang sebenarnya.

Insiden keamanan yang terjadi pada Taiko kemudian mengekspos risiko rantai kepercayaan L2 jenis lain.

Pada 22 Juni, proses verifikasi bukti berbasis SGX milik Taiko dieksploitasi, menyebabkan kerugian sekitar 1,7 juta dolar AS. Menurut analisis BlockSec, penyerang menggunakan kunci privat tanda tangan enclave SGX yang sebelumnya pernah dikirimkan ke repositori GitHub publik, dan memanfaatkan cacat bahwa kontrak verifikasi on-chain tidak menolak Enclave mode DEBUG, sehingga mendaftarkan pembuktian jahat sebagai instance yang sah.

Penyerang kemudian memalsukan bukti state L2, sehingga kontrak di Ethereum menerima state L2 yang sebenarnya tidak ada, dan akhirnya menarik aset dari dana jembatan. Intinya, hal ini terjadi karena kunci yang digunakan untuk menandatangani lingkungan tepercaya (enclave) telah dipublikasikan, dan aturan remote attestation tidak sepenuhnya memeriksa atribut lingkungan operasi, sehingga bukti yang "terverifikasi" kehilangan makna kepercayaan yang seharusnya.

Sementara itu, Base mengalami penghentian produksi blok utama pada 25-26 Juni. Dalam tinjauan pasca-insiden, Base menyatakan bahwa dua gangguan tersebut berasal dari cacat logika pembuatan blok yang sama: sebuah transaksi yang gagal dieksekusi tidak membersihkan state yang tercatat sebelumnya dengan benar, menyebabkan transaksi berikutnya salah menghitung Gas, dan menghasilkan blok yang berisi transisi state yang tidak valid. Karena node lain tidak dapat menerima blok tersebut, jaringan akhirnya berhenti berlanjut. Base menyatakan bahwa integritas rantai tidak terganggu selama insiden, dan dana pengguna tetap aman.

Ini bukanlah pencurian aset atau serangan eksternal, melainkan kegagalan teknis yang memengaruhi ketersediaan dan kemampuan pemulihan jaringan. Namun, dari sudut pandang keamanan yang lebih luas, ketersediaan itu sendiri adalah bagian dari model keamanan L2.

Karena bagi pengguna, apakah suatu rantai aman tidak hanya bergantung pada apakah peretas dapat memalsukan aset, tetapi juga pada apakah blok dapat diproduksi terus-menerus, apakah jembatan lintas rantai dapat berfungsi normal, apakah node dapat pulih dengan cepat, dan apakah pengguna masih memiliki jalur keluar yang layak saat sistem mengalami kegagalan.

Oleh karena itu, saat menggunakan L2, pengguna tidak boleh hanya membandingkan biaya dan harapan airdrop. Untuk L2 dengan skala kecil, baru diluncurkan, atau mekanisme keamanan yang masih berubah dengan cepat, usahakan untuk tidak menyimpan aset besar dalam jangka panjang melebihi kebutuhan penggunaan aktual. Sebelum melakukan bridging, pastikan menggunakan jembatan resmi, dan pahami waktu penarikan, mekanisme jeda, serta cara keluar darurat. Jika jaringan berhenti memproduksi blok, terjadi anomali lintas rantai, atau peringatan keamanan resmi dikeluarkan, jangan terus-menerus mengirimkan transaksi atau melakukan bridging aset.

Tindakan yang lebih aman adalah mengelola aset dengan berbagai tujuan dan tingkat risiko secara terpisah, daripada menempatkan seluruh likuiditas pada satu L2, satu jembatan lintas rantai, atau satu mekanisme keluar yang sama.

3. Kontrak tidak diretas, tetapi layanan pihak ketiga dapat membawa serangan ke pengguna

Jika masalah dompet dan L2 masih terjadi pada komponen teknis yang relatif mendasar, maka insiden Polymarket menunjukkan bahwa front-end web yang paling dekat dengan pengguna juga dapat menjadi pintu masuk dana.

Pada 25 Juni, Polymarket menyatakan bahwa salah satu vendor pihak ketiga yang mereka gunakan telah diretas, dan peretas menyuntikkan skrip berbahaya ke front-end Polymarket yang diakses oleh sebagian pengguna.

Menurut statistik dari lembaga keamanan dan analis on-chain, insiden ini menyebabkan kerugian sekitar 3 juta dolar AS pada aset pengguna, melibatkan sekitar 11 dompet. Dana yang dicuri kemudian di-bridge dari Polygon ke Ethereum dan ditukar menjadi sekitar 1.893 ETH. Namun, selanjutnya Polymarket menyatakan bahwa dependensi yang terpengaruh telah dihapus dan akan memberikan pengembalian dana penuh kepada pengguna yang terkena dampak.

Kunci dari insiden ini adalah bahwa pengguna mungkin masih mengakses domain Polymarket yang benar, dan pengungkapan yang ada juga tidak menunjuk pada kerentanan kontrak pintar inti Polymarket. Masalahnya terutama terletak pada dependensi front-end pihak ketiga yang dimuat oleh halaman web.

Ini juga merupakan cermin. Saat ini, sebagian besar aplikasi Web3 tidak sepenuhnya berjalan di rantai. Halaman web yang dilihat pengguna, seperti antarmuka perdagangan, masih sangat bergantung pada infrastruktur internet tradisional dan paket perangkat lunak pihak ketiga. Salah satu dependensi yang diretas dapat menyebabkan situs web yang sah menampilkan informasi yang salah kepada pengguna, mengganti alamat penerima, atau menginduksi dompet untuk menandatangani transaksi berbahaya.

Oleh karena itu, "URL-nya asli" tidak selalu berarti "semua kode yang dimuat saat ini aman", dan "kontrak telah diaudit" tidak berarti seluruh jalur interaksi antara pengguna dan kontrak bebas risiko. Menghadapi serangan front-end dan rantai pasokan semacam ini, pengguna biasa sulit memeriksa setiap bagian kode yang dimuat halaman web secara independen, namun mereka masih dapat membatasi potensi kerugian dengan mengurangi izin setiap interaksi:

Gunakan dompet terpisah untuk interaksi DApp: dompet tabungan jangka panjang usahakan jangan langsung terhubung ke berbagai situs DeFi, NFT, prediksi pasar, dan airdrop. Dompet interaksi harian hanya menyimpan dana yang akan digunakan dalam waktu dekat. Bahkan jika front-end atau otorisasi bermasalah, dampaknya relatif terbatas.

Perhatikan operasi aktual saat menandatangani, jangan hanya melihat tombol di halaman web: halaman web bertuliskan "Login", "Klaim", atau "Konfirmasi Pesanan" tidak berarti tanda tangan yang muncul di dompet juga merupakan hal yang sama.

Jika halaman web menunjukkan anomali, jangan terus beroperasi karena kebiasaan: jika halaman tiba-tiba meminta untuk mengimpor ulang seed phrase, mengunduh plugin tambahan, atau konten transaksi yang ditampilkan tidak sesuai dengan deskripsi halaman, hentikan interaksi, konfirmasi situasi melalui beberapa saluran resmi proyek, dan periksa atau cabut otorisasi historis yang tidak lagi digunakan.

Dari sudut pandang produk dompet, ini juga berarti peran dompet sedang berubah.

Dompet tidak boleh hanya menjadi alat untuk menyimpan kunci privat dan memunculkan jendela tanda tangan, tetapi juga perlu membantu pengguna memahami niat transaksi sebanyak mungkin, mengidentifikasi otorisasi abnormal, menampilkan perubahan aset, dan memberikan peringatan yang cukup jelas sebelum interaksi berisiko tinggi terjadi.

Namun dompet juga tidak dapat menghilangkan semua risiko untuk pengguna. Model keamanan yang lebih realistis adalah dompet, protokol, L2, penyedia layanan pihak ketiga, dan pengguna bersama-sama memperkecil permukaan serangan, bukan membebankan semua tanggung jawab kepada salah satu pihak.

Penutup

Dulu, orang sering berkata: siapa yang memegang kunci privat, dialah yang memiliki aset on-chain.

Pernyataan itu masih benar, tetapi tidak mencakup seluruh proses dari "munculnya niat transaksi" hingga "penyelesaian on-chain" untuk aset pengguna. Keamanan Web3 saat ini tidak lagi hanya tentang melindungi satu set seed phrase, tetapi melindungi seluruh jalur mulai dari dompet menghasilkan kunci, menampilkan transaksi, mengeksekusi tanda tangan, hingga verifikasi jaringan dan penyelesaian akhir.

Tentu saja, ini tidak berarti pengguna harus menjauh dari semua interaksi on-chain. Bagi pengguna, kebiasaan keamanan yang benar-benar efektif berarti mengelola penggunaan aset, tingkat risiko, dan skenario interaksi secara terpisah: aset jangka panjang diisolasi, interaksi harian dengan jumlah kecil, DApp yang tidak dikenal dengan otorisasi rendah, operasi berisiko tinggi dengan verifikasi berlapis.

Bagaimanapun, ketika risiko keamanan meluas dari satu titik menjadi sebuah rantai, pertahanan pengguna juga harus ditingkatkan dari sekadar melindungi kunci privat menjadi serangkaian kebiasaan yang utuh.

Semoga kita semua dapat terus waspada.