Eksploitasi yang ditemui Curve kali ini dapat membuka ide baru bagi para peretas

Oleh Jaleel, BlockBeats

Industri DeFi telah dilanda kekacauan setelah insiden eksploitasi kerentanan. Curve Finance, raksasa di industri DeFi, telah menjadi sasaran "serangan" yang serius, dan beberapa kumpulan stablecoin seperti alETH/mSETH/pETH berisiko. Menurut statistik yang tidak lengkap, peristiwa eksploitasi kerentanan telah menyebabkan kerugian total sebesar 52 juta dolar AS di kumpulan Alchemix, JPEG'd, MetronomeDAO, deBridge, Ellipsis, dan CRV/ETH, dan kepercayaan seluruh pasar telah sangat terguncang.

Kunci masuk kembali versi Vyper 0.2.15, 0.2.16 dan 0.3.0 tidak valid, dan antarmuka penginstalan dokumen resmi Vyper merekomendasikan versi yang salah. Pihak proyek lain yang menggunakan kompiler Vyper juga bergegas melakukan pemeriksaan diri, mencoba memastikan bahwa mereka tidak akan menjadi korban berikutnya. Karena sumber insiden eksploitasi kerentanan terungkap secara bertahap, pasar secara bertahap menyadari bahwa krisis ini tidak hanya berarti insiden eksploitasi peretas biasa, tetapi juga mengungkapkan potensi risiko besar dari seluruh tumpukan yang mendasarinya ke seluruh industri DeFi.

Dibandingkan dengan masa lalu, jumlah insiden peretasan pada periode sebelumnya semakin berkurang, yang tidak terlepas dari kemakmuran pasar. Selama musim panas DeFi dan musim panas NFT, perjanjian miliaran dolar baru diluncurkan setiap minggu, dibandingkan dengan pasar saat ini yang sangat menyusut. Pada saat yang sama, peluang pasar bagi peretas untuk menemukan eksploit atau membuat serangan skala besar secara bertahap menyusut, yang berarti bahwa peretas membutuhkan titik masuk yang lebih baru dan belum dimanfaatkan untuk dijelajahi.

Peretas yang kembali ke "prinsip pertama" telah menemukan titik masuk yang sempurna pada kompiler tingkat rendah untuk memakan "kue" besar dan lezat di pasar DeFi. Kompiler tingkat rendah telah menjadi peretas yang lebih "pintar". Pilihan. BlockBeats mewawancarai pengembang kontrak pintar Box (@BoxMrChen) dan peneliti BTX Derek (@begas_btxcap) tentang insiden ini dan masalah terkait yang terungkap.

Bagaimana peristiwa Curve terjadi?

Stani (@StaniKulechov), pendiri Aave dan Lens, mengungkapkan pandangannya tentang insiden tersebut di media sosial: "Ini adalah kemunduran yang tidak menguntungkan bagi Curve dan DeFi. Meskipun DeFi adalah ruang terbuka yang dapat berkontribusi, itu harus dilakukan dengan benar. sulit dan taruhannya tinggi. Dalam kasus Curve, mereka melakukannya dengan benar di tingkat protokol.

Eksploitasi yang dialami Curve adalah salah satu bentuk serangan tertua dan mungkin paling umum pada kontrak cerdas Ethereum, serangan reentrancy. Serangan reentrancy memungkinkan penyerang berulang kali memanggil fungsi kontrak cerdas tanpa menunggu panggilan sebelumnya ke fungsi tersebut selesai. Dengan cara ini, mereka dapat terus menggunakan celah untuk menarik dana hingga kontrak korban kehabisan dana.

Kunci reentrant dan prinsip CEI

Berikan contoh sederhana untuk mengilustrasikan serangan masuk kembali: bank memiliki total 100.000 uang tunai. Tetapi bank ini memiliki celah besar, setiap kali orang menarik uang, staf bank tidak segera memperbarui saldo rekening, tetapi menunggu hingga penghujung hari untuk memeriksa dan memperbarui. Pada saat ini, seseorang menemukan celah ini, dia membuka rekening di bank, pertama menyetor 1.000 yuan, kemudian menarik 1.000 yuan, dan kemudian mengambil 1.000 yuan setelah 5 menit. Karena bank tidak memperbarui saldo secara real time, sistem akan berpikir bahwa akunnya masih memiliki 1.000 yuan sebelum memeriksa dan memperbarui. Melalui operasi berulang kali, pengguna akhirnya mengeluarkan semua uang tunai sebesar US$100.000 di bank. Baru pada penghujung hari, bank menemukan bahwa celah tersebut telah dieksploitasi.

Kompleksitas dari serangan reentrancy terletak pada kenyataan bahwa serangan ini mengambil keuntungan dari panggilan timbal balik antara kontrak dan celah logika dari kontrak itu sendiri, dan mencapai perilaku curang dengan secara sengaja memicu pengecualian dan fungsi rollback. Penyerang dapat berulang kali mengeksploitasi celah logika dalam kontrak untuk mencuri dana. Solusi untuk mencegah serangan masuk kembali juga sangat umum. Konten kode khusus yang ditargetkan diatur terlebih dahulu untuk perlindungan, dan mekanisme perlindungan semacam itu digunakan untuk memastikan keamanan dana. Ini disebut kunci masuk kembali.

Soliditas menetapkan "prinsip CEI" (Periksa Interaksi Efek) untuk pemrograman kontrak cerdas, yang dapat melindungi fungsi dari serangan reentrancy dengan baik. Isi prinsip-prinsip CEI meliputi:

1. Urutan pemanggilan komponen fungsi harus: pertama, inspeksi, kedua, dampak pada variabel status, dan terakhir, interaksi dengan entitas eksternal.

2. Sebelum berinteraksi dengan entitas eksternal, semua variabel status harus diperbarui. Ini disebut "pembukuan optimis", di mana efeknya ditulis sebelum interaksi benar-benar terjadi.

3. Pemeriksaan harus dilakukan di awal fungsi untuk memastikan bahwa entitas pemanggil memiliki izin untuk memanggil fungsi tersebut.

4. Variabel status harus diperbarui sebelum panggilan eksternal apa pun untuk mencegah serangan reentrancy.

5. Bahkan entitas eksternal tepercaya harus mengikuti pola CEI karena mereka dapat mentransfer aliran kontrol ke pihak ketiga yang berbahaya.

Menurut dokumentasi, prinsip CEI membantu membatasi permukaan serangan kontrak, khususnya mencegah serangan reentrancy. Prinsip CEI dapat dengan mudah diterapkan, terutama dalam urutan kode fungsi, tanpa mengubah logika apa pun. Eksploitasi DAO yang terkenal, yang mengarah ke garpu Ethereum, juga mengabaikan "prinsip CEI", dan penyerang mencapai serangan masuk kembali, menyebabkan konsekuensi yang menghancurkan.

Namun Curve pool yang diserang tidak mengikuti prinsip CEI ini karena Curve menggunakan compiler Vyper. Sebagai kerentanan kode Vyper dari kompiler, kunci reentrancy gagal, membuat serangan reentrancy peretas berhasil direalisasikan.

Kebanyakan orang mengetahui Soliditas, tetapi Soliditas bukan satu-satunya bahasa untuk membuat kontrak cerdas. Alternatif populer untuk Soliditas adalah Vyper. Meskipun Vyper tidak sekuat dan sepopuler Solidity, ini sangat ideal untuk pengembang yang terbiasa dengan Python, karena Vyper dapat menerjemahkan kode mirip Python ke dalam bahasa pemrograman kontrak cerdas Ethereum.

Menurut informasi github, pengembang yang memberikan kontribusi pertama ke basis kode github Vyper juga merupakan pengembang Curve. Tidak sulit untuk menjelaskan mengapa Curve menggunakan Vyper, bukan Solidity.

![Peretas kembali ke "prinsip pertama", krisis Kurva bukanlah serangan biasa] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-c30cf03f91-dd1a6f-1c6801)

Mengapa kunci reentrancy Vyper gagal?

Jadi dalam serangan ini, apa masalahnya dengan Vyper? Mengapa kunci masuk kembali gagal? Apakah karena tidak ada tes? BlockBeats mewawancarai pengembang kontrak pintar Box 826.eth (@BoxMrChen), menurutnya, kunci reentrant Vyper telah diuji dengan kasus penggunaan. Tetapi alasan kegagalannya adalah karena test case berorientasi pada hasil, yaitu test case juga salah.

Singkatnya, alasan terbesar mengapa kunci reentrancy Vyper gagal adalah karena orang yang menulis test case menulis test case berdasarkan hasil, tanpa memikirkan mengapa slot akan melewatkan 1 secara tidak dapat dijelaskan.

![Peretas kembali ke "prinsip pertama", krisis Kurva bukanlah serangan biasa] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-0527942e35-dd1a6f-1c6801)

Dalam paragraf kode Vyper berikut yang dibagikan oleh Box, masalahnya dapat dilihat dengan jelas. Saat nama kunci muncul untuk kedua kalinya, jumlah slot_penyimpanan akan ditimpa, artinya, di ret, slot untuk perolehan kunci pertama adalah 0, tetapi setelah fungsi menggunakan kunci lagi, slot untuk kunci ditambahkan satu. Setelah kompilasi, slot yang salah digunakan, menyebabkan kunci reentrant gagal berfungsi.

![Peretas kembali ke "prinsip pertama", krisis Kurva bukanlah serangan biasa] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-87ec9b545c-dd1a6f-1c6801)

Yang kiri adalah kode yang diserang, dan yang kanan adalah kode yang diperbaiki

"Hasil tes yang diharapkan salah, dan tentu saja tidak ada kesalahan yang dapat diverifikasi. Untuk memberikan contoh sederhana, kita sedang melakukan perhitungan soal sekarang, 1+ 1 = 2, tetapi jawaban standar yang diberikan salah, mengatakan 1+ 1 = 3 Dan ini Teman sekelas yang mengerjakan soal memberikan jawaban yang salah, dan menjawab 1+ 1 = 3, tetapi itu sama dengan jawaban standar yang diberikan sebelumnya, sehingga program secara alami tidak memiliki cara untuk menentukan hasil tesnya. salah." kata Box dalam sebuah wawancara dengan BlockBeats.

Gantung selama dua tahun "Sword of Damocles"

Dalam serangan reentrancy pertama yang tercatat dalam sejarah, penyerang WETH Attack adalah para hacker putih yang sengaja membuat serangan agar pengembang memperhatikan serangan reentrancy, dengan tujuan membuat lebih banyak proyek kebal terhadap Kemungkinan serangan reentrancy. Dalam konteks smart contract, developer harus menggunakan mekanisme pemicu yang berbeda, seperti memanggil fungsi perubahan status untuk mencapai perlindungan. Ini mengharuskan pengembang untuk sepenuhnya mempertimbangkan kemungkinan skenario serangan saat merancang kontrak dan mengambil tindakan pencegahan yang sesuai.

Untuk mendapatkan pemahaman mendalam tentang editor Vyper, BlockBeats mewawancarai peneliti BTX Derek (@begas_btxcap), dia mengatakan bahwa bagi pengembang yang terbiasa dengan Python, Vyper adalah pilihan yang lebih ideal daripada Solidity, dengan antarmuka UI yang lebih nyaman dan belajar lebih cepat. Namun ternyata, beberapa versi kode editor Vyper belum diaudit oleh pihak ketiga yang terpercaya. Bahkan beberapa pekerjaan audit dapat dilakukan oleh pengembang sendiri. "Hal semacam ini tidak akan terjadi di industri TI tradisional, karena setelah bahasa baru keluar, akan ada banyak perusahaan audit yang mencari celah Anda."

Belum lagi, membiarkan bug ada secara terbuka selama dua tahun.

Kontributor Vyper fubuloubu juga berkata: Kompiler tidak ditinjau atau diaudit seperti yang dipikirkan semua orang. Sebagian besar kompiler memiliki perubahan yang signifikan dan sering, yang membuat audit menjadi kerugian. Bahkan dengan audit basis kode penuh, itu akan menjadi usang semakin banyak versi ditambahkan setelah itu. Mengaudit kompiler bukanlah ide yang baik, karena lebih masuk akal untuk mengaudit produk akhir (yaitu kode EVM mentah) yang dihasilkan oleh pengguna akhir menggunakan alat tersebut.

Semua ini mengarah pada masalah terakhir: motivasi. Yang mengatakan, tidak ada yang memiliki insentif untuk menemukan bug kritis dalam kompiler, terutama versi yang lebih lama. fubuloubu sebelumnya membuat proposal yang akan membantu meningkatkan Vyper dengan menambahkan program hadiah yang disponsori bersama oleh pengguna, tetapi tidak berhasil.

Peretas Akan Kembali ke "Prinsip Pertama"

Ini adalah contoh hidup lain dari praktik pengembangan kontrak-aman untuk pengembang protokol dan proyek. Tapi yang terpenting, insiden Curve memberi kita semua peringatan bahwa keamanan kompiler yang mendasarinya telah diabaikan secara serius, dan peretas yang kembali ke "prinsip pertama" telah menemukan yang sempurna di kompiler yang lebih rendah.

Setelah itu, Stani (@StaniKulechov), pendiri Aave dan Lens, juga memposting artikel panjang di media sosial untuk mengungkapkan perasaannya: Serangan terhadap Curve berarti bahwa risiko DeFi selalu melibatkan seluruh tumpukan yang mendasarinya, bahasa pemrograman, EVM , dll. Ini mengingatkan kita untuk lebih berhati-hati dan peka, terutama saat menggunakan EVM khusus dan rangkaian aplikasi di masa mendatang.

![Peretas kembali ke "prinsip pertama", krisis Kurva bukanlah serangan biasa] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-3324fcfbcd-dd1a6f-1c6801)

Serangan dari level yang lebih rendah

Untuk kerentanan kompiler, sulit diketahui hanya dengan mengaudit logika kode sumber kontrak. Hanya meneliti perbedaan antara versi dan versi juga merupakan proyek besar. Penting untuk menggabungkan versi kompiler tertentu dengan pola kode tertentu untuk menentukan apakah kontrak pintar dipengaruhi oleh kerentanan kompiler.

"Saat ini hanya dua kompiler yang terbaik, basis kode Vyper lebih kecil, lebih mudah dibaca, dan memiliki lebih sedikit perubahan untuk menganalisis sejarahnya, yang mungkin mengapa peretas mulai dari sini, basis kode Solidity sedikit lebih besar" fubuloubu bahkan mencurigai pernyataan itu- peretas yang didukung mungkin terlibat dalam serangan Curve ini: "Dibutuhkan waktu berminggu-minggu hingga berbulan-bulan untuk menemukan kerentanan, dan mengingat sumber daya yang diinvestasikan, ini dapat dilakukan oleh kelompok atau tim kecil."

Sebagai bahasa kompilasi yang paling banyak digunakan dalam industri enkripsi, keamanan Solidity bahkan lebih diperhatikan oleh pengguna.Lagipula, jika kompiler Solidity mengalami masalah kegagalan kunci reentry kali ini, maka sejarah seluruh industri DeFi mungkin memiliki untuk ditulis ulang.

Menurut peringatan keamanan yang dikeluarkan secara teratur oleh tim pengembangan Solidity, terdapat kerentanan keamanan di berbagai versi penyusun Solidity.

Bug kompiler terbaru yang dicatat adalah 26 Juni, saat menyelidiki laporan keamanan terkait penggunaan abi.error. Pembuat kode lama tidak mengevaluasi ekspresi kompleks seperti penugasan, pemanggilan fungsi, atau kondisi yang .selector-nya sedang diakses. Hal ini menyebabkan efek samping dari ekspresi tersebut tidak dieksekusi, sehingga kontrak yang dikompilasi dengan pipeline lama mungkin berperilaku tidak benar.

Kita juga dapat melihat file di repositori Github Solidity yang mencantumkan beberapa bug terkait keamanan yang diketahui di kompiler Solidity. Daftar kembali ke versi 0.3.0, bug yang ada hanya sebelum versi ini tidak terdaftar. Di sini, ada file bugs_by_version.json lainnya. File ini dapat digunakan untuk menanyakan bug mana yang dipengaruhi oleh versi kompiler tertentu.

Untungnya, justru karena penerapan bahasa Soliditas yang luas dan bantuan dari Ethereum Foundation, banyak masalah yang ada telah ditunjukkan oleh proyek dan protokol selama proses penerapan. Oleh karena itu, Solidity telah menyelesaikan modifikasi dan peningkatan beberapa langkah lebih cepat daripada Vyper. Dari perspektif ini, inilah salah satu alasan mengapa Solidity lebih terstandarisasi dan lebih aman.

Untuk membantu pengembang Solidity menguji lebih baik dan mencegah hal yang sama terjadi. Salah satu pendiri UnitasProtocol SunSec (@ 1 nf 0 s 3 cpt) merilis panduan pengujian keamanan DeFiVulnLabs Solidity setelah serangan Curve, mendukung 47 jenis kerentanan, termasuk deskripsi kerentanan, skenario, pertahanan, kode kerentanan, dan tindakan mitigasi serta cara menguji .

Bagaimana cara menghindari serangan tingkat rendah sebanyak mungkin?

Dalam insiden Curve ini, Box percaya bahwa pencerahan untuk semua pengembang adalah: jangan mencoba mengikuti tren teknologi dan memilih solusi yang tidak matang; jangan menyetujui kode Anda sendiri tanpa menulis kasus uji (beberapa versi Vyper yang bermasalah Bahkan test case salah); jangan pernah menyetujui kode Anda sendiri; beberapa kekayaan mungkin membutuhkan waktu bertahun-tahun untuk ditemukan; non-upgrade adalah kesombongan terhadap diri sendiri dan penghinaan terhadap orang lain.

Biasanya, pengembang tidak memikirkan jebakan apa pun di sini, dan memilih versi untuk dikompilasi sesuka hati, yang mungkin mengabaikan risiko yang ditimbulkan oleh perbedaan antar versi. Bahkan pemutakhiran versi kecil dapat menyebabkan perubahan besar, yang sangat penting saat mengembangkan aplikasi terdesentralisasi.

Peringatan untuk pengembang dari acara Curve ini adalah: gunakan versi bahasa kompiler yang lebih baru. Penting untuk selalu memperbarui basis kode, aplikasi, dan sistem operasi Anda, dan membangun pertahanan keamanan Anda sendiri di semua aspek. Biasanya ada lebih sedikit masalah keamanan yang diketahui daripada versi lama, meskipun versi yang lebih baru mungkin menimbulkan masalah keamanan baru. Tentu saja, kita juga harus memperhatikan komunitas dan pengumuman pembaruan versi resmi tepat waktu. Pahami perubahan yang dibawa oleh setiap versi, dan perbarui basis kode dan lingkungan operasi Anda sesuai kebutuhan. Mengambil langkah-langkah ini dapat sangat mengurangi insiden keamanan yang disebabkan oleh bug penyusun.

Selain itu, kasus uji unit untuk menyelesaikan kode. Sebagian besar kesalahan tingkat kompiler akan menyebabkan hasil eksekusi kode yang tidak konsisten, yang sulit ditemukan hanya melalui tinjauan kode, tetapi dapat diekspos dalam pengujian. Meningkatkan cakupan kode dapat membantu menghindari masalah tersebut. Dan cobalah untuk menghindari penggunaan fitur bahasa yang kompleks seperti perakitan inline dan pengkodean dan penguraian kode array multidimensi, kecuali ada kebutuhan yang jelas. Sebagian besar kerentanan bahasa Soliditas secara historis terkait dengan fitur lanjutan ini. Pengembang harus menghindari penggunaan fitur bahasa eksperimental demi pamer tanpa kebutuhan khusus.

Untuk lapisan protokol dan personel keamanan, kemungkinan risiko versi kompiler tidak dapat diabaikan saat melakukan audit kode. Diperkirakan bahwa peretas telah membuka ide-ide baru, dan di masa depan, akan ada lebih banyak insiden kerentanan tingkat rendah yang dieksploitasi. Pada saat yang sama, sebagai infrastruktur dasar, tumpukan dasar, bahasa pemrograman, EVM, dll. Perlu diaudit. Di masa depan, pasar untuk perusahaan audit akan semakin besar, dan pasar untuk hadiah tamu kulit putih juga akan semakin besar. Tim Vyper juga berencana untuk mulai meninjau program bug bounty setelah masalah tersebut diselesaikan secara resmi.

Tentu saja, kita tidak perlu terlalu panik dengan risiko infrastruktur yang mendasarinya. Saat ini, sebagian besar bug kompiler hanya terpicu dalam pola kode tertentu, dan dampak sebenarnya perlu dievaluasi sesuai dengan situasi proyek. Meningkatkan versi kompiler secara teratur dan pengujian unit yang memadai dapat membantu mencegah risiko.