Penulis: imToken
Sebuah bot MEV yang telah lama memburu trader biasa di Ethereum, akhirnya juga terjebak dalam perangkap "edisi khusus" senilai $7,5 juta.
Pada 21 Juni, bot arbitrase sandwich terkenal di Ethereum, Jaredfromsubway.eth, diserang. Aset-aset seperti WETH dan USDC di alamatnya dipindahkan, dengan perkiraan awal kerugian melebihi $7,5 juta (meskipun demikian, pernyataan publik tentang jumlah kerugian masih berbeda-beda).
Yang menarik, serangan ini bukan karena kebocoran private key, dan juga tidak memanfaatkan kerentanan smart contract dalam arti tradisional. Melainkan penyerang terlebih dahulu melakukan deploy banyak token palsu, liquidity pool, dan kontrak bantu, membungkusnya agar terlihat seperti jalur perdagangan yang mungkin memiliki ruang arbitrase, menginduksi bot untuk secara otomatis memberikan Approval ERC-20 kepada kontrak jahat selama proses eksekusi otomatis, dan akhirnya "secara legal" mentransfer aset bot MEV tersebut.
Hingga saat artikel ini ditulis, Jaredfromsubway.eth telah menyampaikan pesan on-chain kepada penyerang secara terbuka, menyatakan "jika mengembalikan 2.150 ETH dalam waktu 48 jam, bersedia membayar setengah dari hadiah white hat, jika tidak, akan mengambil semua tindakan hukum dan penegakan hukum yang layak untuk menuntut pertanggungjawaban."
Namun, jika bahkan bot MEV yang digerakkan oleh kode yang sangat terspesialisasi pun bisa jatuh karena Approval, tidak heran jika kita mempertanyakan kembali, betapa besarnya bahaya yang tersembunyi di balik tindakan "Approval" yang kita gunakan setiap hari ini?
1. Perburuan Terbalik yang Dirancang Khusus untuk Bot MEV
Jika menganalisis peristiwa serangan ini dengan cermat, akan terlihat bahwa ini bukanlah kerentanan yang dipicu secara kebetulan, melainkan sebuah perburuan jangka panjang yang dirancang berdasarkan logika perdagangan Jaredfromsubway.eth.
Jaredfromsubway.eth selalu menjadi salah satu bot arbitrage sandwich paling terkenal di Ethereum. Serangan sandwich, sederhananya, adalah ketika bot menemukan sebuah transaksi on-chain yang akan terjadi, membeli terlebih dahulu sebelum pengguna, mendorong kenaikan harga; setelah pengguna menyelesaikan transaksi dengan harga yang lebih buruk, bot segera menjual, mengambil keuntungan dari selisih harga.
Karena itu pula, strategi ini mengharuskan bot untuk terus memindai transaksi on-chain, menilai peluang arbitrase dengan kecepatan sangat tinggi, dan mengatur jalur perdagangan untuk memanggil token dan kontrak yang berbeda, yang juga berarti semakin cepat dan semakin banyak aset serta protokol yang dicakup, semakin banyak peluang yang dapat ditangkap oleh bot.
Tapi justru poin inilah yang menjadi titik masuk bagi peristiwa ini.
Berdasarkan analisis setelah kejadian, penyerang tidak langsung menyerang kontrak dana bot, melainkan menghabiskan waktu beberapa minggu untuk membangun satu set lingkungan perdagangan yang terlihat menguntungkan:
- Langkah pertama, adalah melakukan deploy banyak token palsu dan liquidity pool. Token-token ini meniru aset umum seperti WETH, USDC, USDT dalam hal nama, antarmuka, dan perilaku perdagangan, membuat sistem identifikasi otomatis bot mengira menemukan jalur perdagangan normal;
- Langkah kedua, adalah secara bertahap mendapatkan kepercayaan bot. Dalam pengujian awal, izin (approval) yang diberikan bot digunakan secara normal seiring dengan perdagangan. Setelah sistem bot mulai berulang kali mengeksekusi jalur serupa, penyerang kemudian menyesuaikan logika kontrak, membuat sebagian izin yang dihasilkan bot tidak lagi dikonsumsi secara aktual, dan juga tidak di-nol-kan setelah perdagangan selesai, menyebabkan izin-izin ini tetap tertinggal;
- Terakhir, penyerang memanggil secara terpusat batas izin yang masih berlaku, mentransfer WETH, USDC, dan USDT asli dari kontrak bot;
Intinya, seluruh rangkaian serangan ini sepenuhnya menyasar karakteristik operasional bot MEV, yaitu pertama-tama menciptakan lingkungan yang sesuai dengan aturan penilaian profitabilitasnya, kemudian memanfaatkan mekanisme eksekusi otomatis jalur perdagangannya, membuat sistem secara aktif menyerahkan hak panggil aset.
Ini juga menjelaskan mengapa bahkan bot MEV yang sangat terspesialisasi pun bisa menjadi korban.
Ia tahu cara menghitung selisih harga, biaya Gas, dan urutan transaksi, tetapi belum tentu melakukan verifikasi identitas yang cukup terhadap setiap kontrak baru yang muncul. Dari sudut pandang ini, masalah pengguna biasa adalah "mengklik konfirmasi tanpa memahami", sedangkan masalah bot otomatis adalah "mengeksekusi secara otomatis tanpa konfirmasi".
Secara permukaan, keduanya sangat berbeda, tetapi risiko mendasarnya cukup mirip, karena keduanya menganggap izin (approval) sebagai langkah biasa sebelum menyelesaikan transaksi, tanpa menyadari seberapa tinggi risiko yang tersembunyi di dalamnya.
2. Mengapa Approval Selalu Diremehkan?
Seperti diketahui, dalam standar ERC-20 di Ethereum dan rantai yang kompatibel dengan EVM, Approve (persetujuan/izin) adalah desain yang cukup mendasar.
Namun, saat pengguna melakukan transfer langsung di dompet, biasanya yang dipanggil adalah transfer, dan umumnya tidak melibatkan Approve. Hanya dalam skenario smart contract seperti DEX, pinjaman, staking, atau penambahan likuiditas, pengguna perlu membiarkan smart contract mewakili mereka untuk memanggil token, barulah melibatkan Approval.
Sebagai contoh, ketika kita ingin menukar USDT dengan ETH di Uniswap, smart contract Uniswap tidak dapat langsung mengambil USDT dari dompet Anda. Pertama-tama harus menjalankan satu kali Approve untuk memberi tahu sistem "saya mengizinkan Uniswap menarik X USDT dari dompet saya".
Setelah izin selesai, kontrak yang mendapatkan izin baru dapat memanggil USDT pengguna melalui transferFrom, dalam batas kuota yang ditetapkan, dan swap selanjutnya baru dapat diselesaikan.
Dengan kata lain, Approval itu sendiri bukanlah kerentanan, melainkan fondasi penting agar DeFi dapat beroperasi normal. Hanya saja, masalahnya adalah ia agak mirip dengan izin pembayaran otomatis Alipay/WeChat:
Pengguna tidak memberikan kata sandi akun kepada merchant, tetapi mengizinkan merchant untuk secara aktif melakukan pemotongan dalam batas yang disepakati. Selama izin masih berlaku, pemotongan berikutnya tidak memerlukan pengguna untuk memasukkan kata sandi atau konfirmasi per transaksi lagi, dan hal ini secara alami menimbulkan beberapa masalah.
Pertama, masalah izin tak terbatas (unlimited approval), di mana orang sering mengubah satu transaksi menjadi izin jangka panjang. Terutama untuk mengurangi operasi dan biaya Gas yang timbul dari izin berulang, banyak DApp secara default meminta kuota izin yang sangat besar, yang biasa disebut "unlimited approval".
Pengguna awalnya mungkin hanya ingin menggunakan 100 USDC untuk menyelesaikan satu transaksi, tetapi malah mengizinkan kontrak untuk menggunakan semua USDC di alamat mereka di masa depan. Selama izin tersebut tidak dicabut, bahkan jika dompet pengguna saat itu hanya memiliki sedikit aset, USDC yang ditransfer ulang di masa depan mungkin juga terus terpengaruh.
Kedua, izin secara default tidak hilang saat meninggalkan DApp. Banyak pengguna yang mencampuradukkan "memutuskan koneksi dompet" dengan "mencabut izin". Sebenarnya, memutuskan koneksi hanya membuat halaman web sementara tidak dapat membaca atau meminta dompet saat ini, dan tidak mengubah Approval yang telah ditulis ke blockchain.
Menutup halaman web, menghapus DApp, menghapus cache browser, bahkan mengganti aplikasi dompet, tidak akan membuatnya otomatis tidak berlaku.
Terakhir, bahkan kontrak normal pun bisa menjadi berbahaya di masa depan. Karena banyak risiko izin tidak hanya berasal dari situs phishing yang sejak awal memang jahat, seperti perburuan dalam peristiwa ini. Pengguna mungkin memberikan izin kepada sebuah protokol yang saat itu normal, tetapi kemudian kontrak protokol tersebut diserang, kunci admin bocor, logika yang dapat ditingkatkan diganti, atau kontrak routing yang dipanggilnya bermasalah.
Bagi pengguna, aset masih tersisa di alamat mereka, tetapi dari sudut pandang izin, kontrak lain tetap memiliki kemampuan untuk memanggil aset-aset tersebut. Oleh karena itu, risiko Approval tidak hanya tentang "apakah saya memberikan izin kepada pihak yang buruk", tetapi juga mencakup "apakah pihak yang saya beri izin akan bermasalah di kemudian hari".
3. Lalu, Bagaimana Mengelola Risiko Approval?
Menghadapi risiko Approval, saran paling sederhana adalah "jangan memberikan izin tak terbatas (unlimited approval)".
Tapi dalam lingkungan penggunaan DeFi yang sebenarnya, menolak izin sepenuhnya tidak realistis. Seperti yang dijelaskan di atas, izin itu sendiri bukanlah kerentanan, ia adalah cara dasar aplikasi on-chain untuk memanggil aset.
Apa yang benar-benar perlu diubah adalah mengubah Approval dari tindakan konfirmasi satu kali, menjadi mekanisme manajemen izin yang berkelanjutan.
Bagi pengguna biasa, pertama-tama perlu membangun beberapa kebiasaan dasar:
- Pertama, ikuti prinsip "izin minimum". Saat dompet muncul notifikasi permintaan izin, usahakan untuk menetapkan jumlah sesuai kebutuhan aktual interaksi ini. Misalnya, jika hanya berencana menggunakan 100 USDT, usahakan hanya memberikan izin mendekati 100 USDT, bukan langsung membuka izin tak terbatas;
- Kedua, bedakan dompet penyimpanan dan dompet interaksi. Alamat yang menyimpan aset besar untuk jangka panjang, usahakan jangan sering terhubung ke DApp asing; saat berpartisipasi dalam airdrop, mint, proyek baru, dan interaksi DeFi berisiko tinggi, gunakan alamat terpisah, membatasi potensi kerugian dalam lingkup yang lebih kecil;
- Ketiga, periksa secara berkala dan cabut izin yang tidak lagi diperlukan. Pengguna dapat menggunakan alat seperti Revoke.cash, atau di imToken masuk ke halaman token terkait, klik "Token Function" di kiri bawah, lalu pilih "Manajemen Izin", untuk melihat pihak yang diizinkan, token, dan jumlah izin untuk alamat tersebut, dan mengajukan pencabutan terhadap izin yang tidak lagi digunakan atau berasal dari sumber yang tidak jelas (bacaan lebih lanjut: "Panduan Lengkap Menggunakan Revoke.cash untuk Manajemen Izin");
Tentu saja, setinggi apapun penjelasannya, menghadapi serangan izin yang sulit dihindari, hanya mengandalkan kesadaran keamanan pengguna dan pemeriksaan berkala masih belum cukup. Bagaimanapun, sebagian besar pengguna sulit membedakan apakah sebuah string alamat kontrak milik siapa, dan juga sulit menilai apakah suatu jumlah izin masuk akal atau tidak.
Sebagai parit pelindung pertama bagi pengguna memasuki Web3, dompet harus menyediakan pertahanan aktif dalam kemampuan produknya.
Sebagai contoh, imToken akan menandai atau memblokir token, alamat, dan DApp berisiko yang telah teridentifikasi. Saat pengguna memberikan izin token ke akun eksternal biasa, atau mentransfer langsung ke alamat kontrak, juga akan memberikan peringatan risiko yang disasar. Peringatan ini tidak dapat menggantikan penilaian pengguna, tetapi setidaknya dapat menambah penyangga keamanan yang diperlukan sebelum penandatanganan sesungguhnya.
Selain itu, imToken juga melakukan parsing terstruktur dan presentasi yang dapat dibaca terhadap konten tanda tangan pada tautan kunci seperti login DApp, transfer, pertukaran token, dan pemberian izin, sebisa mungkin membantu pengguna memahami apa yang sedang mereka setujui sebelum konfirmasi, memastikan konten yang ditandatangani pengguna harus konsisten dengan tindakan yang mereka lihat, bukan dikompresi menjadi sekumpulan data hash yang sulit dikenali.
Seiring dengan berkembangnya standar Clear Signing seperti ERC-7730, presentasi yang dapat dibaca "Apa yang Kamu Lihat adalah Apa yang Kamu Tandatangani (What You See Is What You Sign)" ini juga diharapkan dapat berkembang dari kemampuan produk dompet tunggal, secara bertahap menjadi standar industri yang dibagikan antara dompet, DApp, dan smart contract.
Secara keseluruhan, private key menentukan siapa yang memiliki akun, Approval menentukan siapa lagi yang dapat memanggil aset di dalam akun. Keduanya bukanlah hal yang sama, tetapi sama pentingnya.
Ini juga berarti bahwa keamanan dompet tidak boleh hanya berhenti pada "apakah private key bocor", dan ini memerlukan kerja sama dari semua pihak, mulai dari pengguna hingga dompet: bagi pengguna, perlu melihat dengan jelas pihak dan jumlah izin sebelum memberikan izin, serta membersihkan izin yang tidak lagi diperlukan setelah interaksi selesai; bagi dompet, perlu membuat izin-izin yang awalnya tersembunyi di dalam kontrak ini menjadi lebih terlihat, lebih mudah dipahami, dan juga lebih mudah dibatasi dan dicabut.
Bagaimanapun, yang benar-benar berbahaya belum tentu transfer yang baru saja terjadi, tetapi juga bisa berupa sebuah izin yang sudah lama terlupakan, namun tetap tidak kehilangan masa berlakunya.
