Garis waktu dan refleksi peretasan Vyper

"Percaya tapi verifikasi" (percaya, tapi verifikasi), jangan lakukan "setelah fakta". Bug paling serius adalah hitam di bawah lampu.

Karena kontrak tidak dapat diubah, proyek secara implisit akan bergantung pada kode yang ditulis bertahun-tahun yang lalu. Saat kami memperbaiki bug, kami perlu lebih memperhatikan potensi dampaknya.

Kali ini terjadi seperti ini.

linimasa

Dalam artikel ini, saya akan menggunakan "kami" untuk merujuk pada semua orang yang telah bekerja keras untuk acara ini. Saya merasa bahwa meskipun awalnya saya berkontribusi sedikit untuk menemukan bug, banyak orang yang membantu lebih banyak selama proses berlangsung.

13:10 UTC pETH/ETH $11 juta [1] mengeringkan.

13:19 UTC Michal memposting di ETHSecurity tentang penurunan harga pETH yang tiba-tiba.

Igor adalah orang pertama yang menyadari ada yang tidak beres. Berkat dia, kami mulai menyelidiki lebih lanjut.

Tapi bagaimana robot memasukkan kembali add_liquidity() dalam panggilan remove_liquidity()?

14:01 UTC Membentuk tim darurat untuk masalah ini.

14:07 UTC Kami menggunakan dekompiler favorit kami [2] Dekompilasi kontrak JPEGd dan perhatikan bahwa slot perlindungan masuk kembali sedikit berbeda.

// Pengiriman entri tabel untuk add_liquidity(uint256 [2] ,uint256) label_0057: jika (penyimpanan [0x00] ) { kembalikan(memori[0x00:0x00]); } penyimpanan [0x00] = 0x01; // Pengiriman entri tabel untuk remove_liquidity(uint256,uint256 [2] ) label_1AF3: jika (penyimpanan [0x02] ) { kembalikan(memori[0x00:0x00]); } penyimpanan [0x02] = 0x01;

14:27 UTC Kami mengonfirmasi masalah ini dengan kontrak uji lokal sederhana.

@luar @nonreentrant("kunci") uji def(addr: alamat) -> bool: kembali Benar @luar @nonreentrant("kunci") def test2(addr: alamat) -> bool: mengembalikan Salah

Ini bukan sekadar bug masuk kembali.

Pada titik ini, kami menyadari seberapa besar dampak yang akan ditimbulkannya. Blokir pesan, kami menghapus pesan publik tentang kerentanan ini.

14:37 UTC Wavey membantu mengidentifikasi komit yang rentan dan versi yang terpengaruh. Charles dan saya juga mengonfirmasi hal ini dengan memeriksa output kompiler Vyper secara manual.

Ini adalah perlombaan melawan peretas.

Untungnya, orang juga mengacaukannya dengan reentrancy read-only. Kutipan dari saluran Peringatan Keamanan Web3 - Alchemix dan Metronome DAO juga diretas karena bug reentrancy read-only [3]

Michael menemukan potensi kerentanan di kumpulan alETH dan msETH yang juga menjalankan versi 0.2.15.

14:50 UTC msETH/ETH habis [4] 。

15:34 UTC alETH/ETH habis [5] 。

15:43 UTC Kami menemukan kerentanan di CRV/ETH yang dikompilasi dengan Vyper versi 0.3.0 [6] . Sangat penting bagi kita untuk menjaga kerahasiaan kontrak yang terpengaruh selama mungkin.

16:11 UTC Kami mulai menangani kerentanan topi putih.

Sayangnya, terlalu banyak organisasi yang melakukan penelitian independen pada saat yang sama, dan banyak rumor. Pada 16:44 UTC, kami memutuskan untuk mengeluarkan pernyataan publik mengenai versi yang terpengaruh [7] 。

Pada pukul 18:32 UTC, kami memiliki eksploitasi proof-of-concept yang dapat digunakan untuk potensi penyelamatan topi putih. Bpak Chainlight juga bekerja pada kerentanan pada saat yang sama dan membagikannya pada 19:06 UTC.

Lima menit kemudian, pada pukul 19:11 UTC, seseorang mencuri dana tersebut [8] 。

Struktur serangan sangat berbeda dari bukti konsep kami dan tidak mungkin bocor dari tim kami. Pokoknya sangat merepotkan.

Tetap saja, masih banyak yang harus dilakukan.

21:26 UTC Addison membuat rencana ambisius untuk menyelamatkan aset yang tersisa di kumpulan CRVETH.

Jika Anda mengirim 30k crv ke crv/eth pool, Anda dapat memperbarui biaya admin lalu atur rasio crv/eth sekitar 0,15 eth per crv Pada dasarnya semua ratusan K crv di kolam dapat diekstrak

21:52 UTC bpak membuat bukti konsep yang dapat menghemat 3100 ETH.

Sepuluh menit kemudian, pukul 22:02 UTC, kami kembali dikalahkan. Anehnya, CRV mengelola robot pengeluaran [9] Dana telah diambil dan kolam dikuras [10] 。

menyalahkan

menyalahkan (Balme) adalah kata yang kuat. Menunjuk jari tidak ada gunanya. Saya pikir itu berguna untuk memikirkan apa yang bisa dilakukan dengan lebih baik.

Kontes

Semua upaya White Hat dikalahkan dalam waktu kurang dari setengah jam. Terkadang, setiap detik berharga.

Mungkin serangan ini bisa dilakukan dengan persiapan dan sumber daya yang lebih baik. Pada saat yang sama, ini tampaknya menjadi pedang bermata dua. Apakah mengumpulkan informasi tentang cara melakukan peretasan merupakan ide yang bagus? Siapa yang harus kita percayai?

Di sisi lain, menurut saya keseluruhan proses ini sangat efektif. Kami beralih dari kecurigaan awal menjadi konfirmasi siapa yang rentan dalam 2 jam 4 menit.

Keterbukaan Informasi

Saya seorang auditor dan peretas topi putih.

Industri audit memiliki budaya penerbitan yang unik. Kami dibayar untuk kepemimpinan pemikiran teknis kami dan pemahaman mendalam tentang kerentanan. Salah satu cara untuk menunjukkan kepemimpinan dan kedalaman mereka adalah dengan menerbitkan [11] The "sendok" pada hacking. Peneliti mahal, dan laba atas investasi adalah publisitas.

Di sisi lain, ada argumen kuat bahwa pengungkapan awal versi yang terpengaruh akan berdampak signifikan pada penyelamatan whitehat.

Seandainya setengah jam ekstra, $ 18 juta bisa dihemat.

Auditor tidak membayar dampak dari laporan mereka. Sebaliknya, mereka mendapatkan suka, retweet, dan liputan. Ini sepertinya menjadi masalah.

Langkah berikutnya

Saya tidak setuju dengan "kami memerlukan verifikasi formal untuk menyelesaikan masalah ini" dan sejenisnya. Kesalahan ini dapat ditangkap dengan pengujian unit. Verifikasi formal sangat berguna untuk banyak jenis kesalahan, tetapi saya tidak percaya ini juga berguna untuk kompiler yang relatif sederhana dan tidak mengoptimalkan.

Perhatikan bahwa bug ini telah diperbaiki pada November 2021 [12] 。

Saya pikir kerentanan Vyper ini bukan masalah dengan teknologi atau bahasa tim Vyper itu sendiri, tetapi lebih merupakan masalah proses. Bug ini telah diperbaiki sejak lama tanpa menyadari potensi dampaknya pada saat perbaikan.

Sayangnya, barang publik mudah terabaikan. Karena kekekalan kontrak, proyek secara implisit mengandalkan kode yang ditulis bertahun-tahun yang lalu. Pengembang protokol dan pakar keamanan harus mengetahui perkembangan keamanan terbaru di seluruh tumpukan eksekusi.