Pada 15 Mei 2024, Sonne Finance mengalami serangan terhadap Optimism on-chain, dengan kerugian hingga $2 k 0000.

Setelah serangan terjadi, pengguna @tonyke_bot di X mengungkapkan dalam tweet bahwa dia telah mengamankan sekitar 100 dolar untuk kolam jaminan token Sonne Finance (juga dikenal sebagai pasar, mirip dengan cToken di Compound) dengan sisa sekitar 6,5 juta dolar.

（\_bot/status/1790547461611860182）

Setelah menemukan serangan itu, tim proyek Sonne Finance dengan cepat menangguhkan semua pasar di Optimism dan mengatakan bahwa pasar di Base aman.

（**）

Pengarahan Serangan

Sonne Finance adalah protokol pinjaman dan peminjaman terdesentralisasi yang merupakan fork Compound V2 di Optimism, menyediakan layanan keuangan bagi individu, institusi, dan protokol. Protokol Sonne Finance mengumpulkan aset token pengguna ke dalam sebuah kolam likuiditas pinjaman, menyediakan layanan pinjaman yang mirip dengan bank. Seperti Compound, peserta protokol dapat menggadaikan token yang mereka miliki ke dalam kolam likuiditas pinjaman Sonne Finance dan pada saat yang sama mendapatkan sertifikat soToken (mirip dengan cToken). soToken adalah token pendapatan yang menghasilkan keuntungan seiring dengan kemajuan blok, dan juga mendapatkan insentif token SONNE. Peserta juga dapat meminjam token lain dari kolam aset pinjaman Sonne dengan menggunakan soToken yang mereka miliki, misalnya dengan menggadaikan sejumlah USDC untuk mendapatkan sertifikat soUSDC, dan kemudian meminjamkan WETH untuk sirkulasi lebih lanjut. Pinjaman dan peminjaman yang digunakan dalam protokol Sonne Finance dapat berupa hubungan aset banyak-ke-banyak. Selama proses pinjaman dan peminjaman, protokol akan secara otomatis menghitung kesehatan alamat peserta (Health Factor), ketika Health Factor jatuh di bawah 1, jaminan di alamat tersebut berisiko dilikuidasi dan penglikuidasi juga akan mendapatkan sejumlah imbalan.

Hubungan antara token dasar yang disimpan oleh pengguna dan jumlah pencetakan soTokens terutama terkait dengan variabel yang disebut exchangeRate, yang secara kasar dapat digunakan untuk mewakili nilai setiap token soToken yang paling panjang atau kurang yang mendasarinya. Nilai tukar dihitung sebagai berikut:

Dalam rumus di atas, totalCash mengacu pada jumlah token dasar yang dipegang oleh soToken, totalBorrows mengacu pada jumlah token dasar yang dipinjamkan di pasar, totalReserves mengacu pada jumlah total cadangan (termasuk bunga yang dibayarkan oleh peminjam), dan totalSupply mengacu pada jumlah pencetakan soTokens.

Saat menebus, pengguna dapat menentukan jumlah token dasar yang akan ditebus, redeemAmount, untuk menghitung jumlah soTokens yang perlu dibakar, redeemTokens, metode perhitungannya kira-kira "redeemTokens = redeemAmount / exchangeRat", **perhatikan bahwa tidak ada pemrosesan kehilangan presisi di sini **.

Bentuk dasar dari serangan ini adalah ketika pasar (soToken) dibuat, penyerang melakukan operasi cetak pertama dengan jaminan, mencetak sejumlah kecil underlying token menjadi soToken yang sangat sedikit, sehingga nilai "totalSupply" soToken menjadi terlalu kecil. Selanjutnya, penyerang memanfaatkan kerugian akurasi kontrak Solidity untuk mengirim langsung underlying token ke kontrak soToken (tanpa mencetak soToken, artinya "totalSupply" tetap sama, tetapi "totalCash" menjadi lebih besar) bukan dengan cara jaminan + pencetakan underlying token. Tindakan ini membuat variabel "totalCash" dalam kontrak menjadi lebih besar, tetapi "totalSupply" tetap sama, sehingga exchangeRate menjadi lebih besar. Akhirnya, saat penyerang menebus underlying token, jumlah soToken yang perlu dihancurkan lebih sedikit dari jumlah soToken yang dicetak dengan jaminan, penyerang menggunakan soToken yang diperoleh untuk meminjam underlying token WETH, USDC, dan lainnya dalam soToken (seperti soWETH, soUSDC), dan pada akhirnya mendapatkan keuntungan hingga 20 juta USD.

** Alamat Kritis yang Terlibat dalam Serangan

Perdagangan Siap Serang:

\u003e \u003e ** > \u003e

Menyerang Perdagangan yang Menguntungkan:

\u003e > \u003e ** > \u003e

Serangan Alamat terkait EOA:

> \u003e \u003e 0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb \u003e \u003e

> >

0xae4a7cde7c99fb98b0d5fa414aa40f0300531f43 \u003e \u003e

Alamat terkait dengan penyerang (kontrak):

\u003e

\u003e 0xa78aefd483ce3919c0ad55c8a2e5c97cbac1caf8

\u003e

0x02fa2625825917e9b1f8346a465de1bbc150c5b9 > >

token yang mendasarinya (VELO Token V2):

\u003e

0x9560e827af36c94d2ac33a39bce1fe78631088db > > (in Indonesian)

Token kontrak bocor (soVELO, mirip dengan cToken Compound):

> >

0xe3b81318b1b6776f0877c3770afddff97b9f5fe5 >

X 上 @tonyke_bot pengguna perdagangan bantuan:

\u003e > **

\u003e

Analisis Proses Serangan

Ringkasan Latar Belakang

Sonne Finance baru-baru ini mengusulkan penambahan pasar VELO ke Sonne Finance (), dan mengatur lima transaksi yang akan dilaksanakan dalam dua hari ke depan melalui dompet multi tanda tangan (). Lima transaksi ini digunakan untuk membuat pasar VELO (kontrak soVELO) dan mengatur beberapa konfigurasi kunci pasar tersebut, seperti model suku bunga, mesin oracle, faktor penjaminan, dan lain-lain. Setelah pasar VELO dibuat, pengguna dapat menyimpan token VELO untuk mencetak token soVELO, yang nantinya dapat digunakan untuk pinjaman soToken lainnya.

Persiapan Serangan

Langkah Persiapan Serangan utamanya adalah setelah masa kunci dua hari proposal berakhir, berdasarkan informasi dalam proposal tim Sonne Finance, membuat pasar VELO (kontrak soVELO), mengatur konfigurasi kunci, dan mencetak token soVELO dengan menggadaikan token VELO ke kontrak soVELO, sambil juga mengirimkan token VELO yang dimiliki secara langsung ke kontrak soVELO untuk meningkatkan exchangeRate, sebagai persiapan untuk mendapatkan keuntungan dari serangan selanjutnya.

Langkah-langkah yang spesifik adalah sebagai berikut:

1. Setelah waktu kunci dua hari berakhir, penyerang pertama-tama menggabungkan operasi empat transaksi yang diatur dalam proposal ke dalam satu transaksi (transaksi 0x45c0cc) untuk membuat pasar VELO (kontrak soVELO) dan mengatur konfigurasi kunci. Saat pasar VELO diinisialisasi, exchangeRate diatur menjadi "200.000.000.000.000.000.000.000.000".
2. Penyerang memanggil fungsi "mint" kontrak soVELO untuk menyimpan token VELO dan mencetak token soVELO, penyerang menentukan "mintAmount" menjadi "400,000,001" (jumlah token VELO). Dari fungsi "exchangeRateStoredInternal" dapat dilihat bahwa karena saat ini "totalSuppl" token soVELO adalah 0, maka exchangeRate adalah nilai yang ditetapkan pada langkah pertama. Berdasarkan rumus "mintTokens = actualMintAmount / exchangeRate", jumlah token soVELO yang seharusnya dicetak adalah 2. Singkatnya, pada langkah ini, penyerang menyimpan token VELO dengan nilai "400,000,001" ke dalam kontrak soVELO dan mendapatkan token soVELO dengan nilai 2.

soVELO.mint:

3. Penyerang mengirimkan token VELO langsung ke kontrak soVELO dengan jumlah "2,552,964,259,704,265,837,526". Pada saat ini, kontrak soVELO memiliki lebih banyak token VELO, tetapi karena tidak ada pencetakan token soVELO yang baru, totalSupply tetap tidak berubah, yang berarti exchangeRate yang dihitung berdasarkan rumus akan menjadi lebih besar. 4. Penyerang mentransfer token soVELO yang mereka pegang beberapa kali, dan akhirnya mentransfernya ke EOA serangan lainnya 0xae4a.

Serangan untuk Keuntungan

Pada fase penyerangan untuk mendapatkan keuntungan, penyerang melakukan transaksi proposal kelima dan meminjam token VELO secara langsung ke kontrak soVELO melalui Pinjaman Flash untuk meningkatkan exchangeRate lebih lanjut. Kemudian penyerang menggunakan token soVELO bernilai 2 dalam tangan untuk meminjam token dasar seperti WETH, USDC, dan lainnya dari kontrak soToken (seperti soWETH, soUSDC, dll.). Bagian ini menjadi keuntungan bagi penyerang. Selanjutnya, penyerang menebus token dasar mereka dari kontrak soVELO. Karena exchangeRate meningkat dan masalah kehilangan presisi saat menghitung token soVELO yang harus dihancurkan saat menebus, akhirnya penyerang dapat menebus hampir seluruh token VELO yang mereka setorkan hanya dengan menggunakan token soVELO bernilai 1 saja. Dapat dikatakan bahwa penyerang menggunakan token soVELO bernilai 1 yang lebih banyak untuk mendapatkan keuntungan dengan meminjam WETH, USDC, dan token dasar lainnya dari soToken lainnya. Penyerang menggunakan metode yang sama berulang kali untuk mendapatkan keuntungan besar.

Langkah-langkah yang spesifik adalah sebagai berikut:

1. Pelaku melakukan transaksi kelima dalam kasus ini, mengatur faktor pinjaman sesuai dengan ketentuan dalam proposal.
2. Penyerang meminjamkan secara kilat token VELO dengan nilai "35,469,150,965,253,049,864,450,449" dari kolam VolatileV2 AMM - USDC/VELO ini akan memicu fungsi hook penyerang. Dalam fungsi hook, penyerang melanjutkan operasi serangannya.
3. Penyerang mengirimkan token VELO yang dimilikinya ke kontrak soVELO untuk meningkatkan exchangeRate lebih lanjut. Saat ini, kontrak soVELO memiliki total token VELO sebesar "35.471.703.929.512.754.530.287.976" (termasuk token VELO yang dikirimkan oleh penyerang sebanyak tiga kali).
4. Pengguna jahat membuat kontrak baru 0xa16388a6210545b27f669d5189648c1722300b8b, dalam konstruktor, mentransfer 2 token soVELO yang dimiliki ke kontrak baru yang dibuat 0xa163 (selanjutnya disebut sebagai pengguna jahat 0xa163).
5. Penyerang 0xa163 meminjamkan WETH dengan nilai "265.842.857.910.985.546.929" dari Token soWETH yang dimilikinya.
6. Penyerang 0xa163 memanggil fungsi "redeemUnderlying" soVELO, dengan menentukan nilai penebusan token VELO sebesar "35.471.603.929.512.754.530.287.976" (hampir semua jumlah token VELO yang telah ditransfer atau digadaikan oleh penyerang ke dalam kontrak soVELO). Pada saat ini, perlu menghitung jumlah token soVELO yang perlu dihancurkan untuk penebusan menggunakan rumus "redeemTokens = redeemAmountIn / exchangeRate".

Dari fungsi "exchangeRateStoredInternal", dapat dilihat bahwa karena pada saat ini \_totalSupply adalah 2 bukan 0, maka perlu menghitung nilai exchangeRate menggunakan rumus "exchangeRate = (totalCash + totalBorrows - totalReserves) / totalSupply", saat ini exchangeRate adalah "17,735,851,964,756,377,265,143,988,000,000,000,000,000,000" yang jauh lebih besar dari exchangeRate awal yang ditetapkan yaitu "200,000,000,000,000,000,000,000,00".

Berdasarkan perhitungan "redeemTokens" yang baru, nilai yang dihasilkan adalah "1,99", karena Solidity membulatkan ke bawah, nilai "redeemTokens" akhirnya menjadi 1. Ini berarti penyerang 0xa163 menggunakan token soVELO dengan nilai 1 untuk menebus hampir semua token VELO yang sebelumnya disimpan. Pada saat yang sama, penyerang 0xa163 juga menghasilkan WETH sebesar "265.842.857.910.985.546.929" yang dipinjam dari soWETH.

soVELO.redeemUnderlying:

soVELO.exchangeRateStoredInternal: 7. Penyerang 0xa163 mentransfer semua WETH yang dipinjam dan menebus VELO Token ke penyerang atas, dan kemudian menghancurkan diri sendiri. 8. Penyerang memanggil fungsi "liquidateBorrow" dari soWETH untuk melikuidasi aset yang dipinjamkan oleh kontrak baru 0xa163 yang telah dibuat sebelumnya, dengan tujuan mengambil kembali token soVELO yang terkunci dengan nilai 1. Saat ini, penyerang hanya memiliki token soVELO dengan nilai 1. 9. Penyerang memanggil fungsi "mint" soVELO, dan sekali lagi melakukan pencetakan token soVELO sebagai jaminan, dengan tujuan mencapai jumlah token soVELO sebesar 2, kemudian melanjutkan langkah-langkah 3-8 seperti yang telah disebutkan sebelumnya, untuk mendapatkan keuntungan dari token undeylying lainnya. 10. Penyerang melakukan langkah 9 beberapa kali, melunasi pinjaman flash, dan keluar dari pasar dengan keuntungan.

$100 Bagaimana Membangkitkan $650 Juta

Setelah serangan terjadi, pengguna @tonyke_bot di X melakukan transaksi di 0x0a284cd, dengan menggadaikan 1144 token VELO ke kontrak soVELO, dan mencetak 0.00000011 token soVELO. Tindakan ini dapat mencegah serangan lebih lanjut karena transaksi ini mengubah totalSupply soVELO dan jumlah totalCash token VELO yang dimiliki. Pertumbuhan totalSupply memiliki dampak yang lebih besar terhadap perhitungan exchangeRate daripada pertumbuhan totalCash, sehingga exchangeRate menjadi lebih kecil. Hal ini mengakibatkan penyerang tidak dapat lagi memanfaatkan kerugian presisi untuk mendapatkan keuntungan dari soVELO, sehingga serangan tidak dapat dilanjutkan.

Pelacakan Dana

Para penyerang mentransfer dana tak lama setelah mengambil hasil ilegal, yang sebagian besar ditransfer ke 4 Alamat berikut, beberapa untuk melanjutkan serangan di Alamat lain, dan beberapa ke Pencucian Uang:

1. 0x4ab93fc50b82d4dc457db85888dfdae28d29b98d

Penyerang mentransfer 198 WETH ke Alamat, dan kemudian Alamat menggunakan taktik serangan yang sama untuk mendapatkan hasil ilegal dalam transaksi berikut:

Setelah serangan itu, Alamat mentransfer hasilnya ke * 0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb *.

2. 0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb

攻击者 mentransfer 724277 USDC, 2353 VELO ke alamat ini, dan menukarkan USDC menjadi Ether. Kemudian sebagian dana segera ditransfer ke jembatan lintas-rantai Stargate, sementara sebagian besar dana ilegal masih tersisa di alamat ini:

3. 0xbd18100a168321701955e348f03d0df4f517c13b

Penyerang mentransfer 33 WETH ke Alamat dan menggunakan rantai kulit untuk mencoba Pencucian Uang, tautan Pencucian Uang adalah sebagai berikut:

0xbd18100a168321701955e348f03d0df4f517c13b -> 0x7e97b74252b6df53caf386fb4c54d4fb59cb6928 -> 0xc521bde5e53f537ff208970152b75a003093c2b4 -> * 0x9f09ec563222fe52712dc413d0b7b66cb5c7c795*。

4. 0x4fac0651bcc837bf889f6a7d79c1908419fe1770

Pada alamat tersebut, penyerang mentransfer 563 WETH, kemudian mentransfer ke 0x1915F77A116dcE7E9b8F4C4E43CDF81e2aCf9C68, saat ini tidak ada tindakan lebih lanjut.

Pendekatan pencucian uang yang dilakukan oleh pelaku kali ini tergolong profesional dan memiliki berbagai variasi teknik. Oleh karena itu, bagi para peserta Web3, peningkatan kemampuan anti pencucian uang harus terus-menerus dilakukan dalam hal keamanan, dengan menggunakan produk keamanan transaksi blockchain yang terkait seperti KYT, AML, dan sebagainya guna meningkatkan keamanan proyek Defi.

Saran Keamanan

1. Kehilangan akurasi perlu diperhatikan. Masalah keamanan yang disebabkan oleh hilangnya akurasi muncul satu demi satu, terutama dalam proyek Defi, di mana hilangnya akurasi sering menyebabkan kerugian finansial yang serius. Disarankan agar tim proyek dan auditor keamanan dengan hati-hati meninjau kode dengan kehilangan akurasi dalam proyek dan melakukan pekerjaan yang baik untuk mengujinya untuk menghindari kerentanan sebanyak mungkin.
2. Disarankan agar pembuatan dan operasi pencetakan staking pertama dari pasar yang mirip dengan cToken di Compound dilakukan oleh pengguna istimewa untuk menghindari manipulasi oleh penyerang, sehingga dapat memanipulasi Nilai Tukar.
3. Ketika terdapat variabel kunci dalam kontrak yang bergantung pada nilai "this.balance" atau "token.balanceOf()", perlu dipertimbangkan dengan hati-hati kondisi perubahan variabel kunci tersebut, seperti apakah diizinkan untuk mengubah nilai variabel tersebut langsung melalui transfer aset kripto atau token ke kontrak, atau hanya dapat diubah melalui panggilan fungsi tertentu.

Artikel ini ditulis bersama oleh Cara (ID akun @Cara6289) dan XiG (ID akun @SHXiGi) dari Tim ZAN.