Blast adalah jaringan Ethereum Layer 2 yang diluncurkan oleh Pacman (Tieshun Roquerre, alias Tieshun), pendiri Blur, yang meluncurkan mainnet pada tanggal 29 Februari. Saat ini, sekitar 19,500 ETH dan 640,000 stETH dijanjikan di mainnet Blast.
Proyek Munchables yang diserang adalah proyek berkualitas tinggi yang memenangkan kompetisi Bigbang yang diselenggarakan oleh Blast.
Pejabat Blast akan memberikan poin biasa kepada pengguna yang menjanjikan ETH di mainnet Blast:
Untuk mendorong pengguna berpartisipasi dalam proyek DeFi di ekosistem Blast, pejabat Blast akan memilih proyek berkualitas tinggi untuk rekomendasi dan mendorong pengguna untuk menjaminkan ETH untuk kedua kalinya ke DeFi untuk mendapatkan peningkatan poin dan poin emas yang lebih cepat, sehingga ada cukup banyak beberapa Pengguna menjanjikan ETH yang dijanjikan pada jaringan utama Blast ke proyek DeFi yang baru dibuat.
Kematangan dan keamanan proyek DeFi ini belum diperiksa, dan apakah kontrak ini memiliki pertimbangan keamanan yang memadai untuk melindungi puluhan juta atau bahkan ratusan juta dolar pengguna.
Ikhtisar Acara
Kurang dari sebulan setelah mainnet Blast online, serangan terhadap SSS Token (Super Sushi Samurai) terjadi pada tanggal 21 Maret 2024. Ada kesalahan logika transfer dalam kontrak Token, yang memungkinkan penyerang meningkatkan SSS Token dari token tersebut. akun tertentu keluar dari keseimbangan, proyek akhirnya kehilangan lebih dari 1,310 ETH (sekitar $4.6 juta).
Kurang dari seminggu setelah serangan SSS Token, serangan lain yang lebih besar terjadi di Blast.Proyek Munchables disapu oleh penyerang dengan 17413.96 ETH, total sekitar 62.5 juta dolar AS.
Setengah jam setelah transaksi serangan terjadi, 73,49 WETH dalam kontrak proyek juga dicuri oleh hacker dari alamat lain.
Saat ini, masih terdapat 7276 WETH, 7758267 USDB, dan 4 ETH yang tersimpan di alamat kontrak pihak proyek, yang sewaktu-waktu akan jatuh ke tangan hacker. Peretas mempunyai kewenangan untuk mengambil seluruh dana dari keseluruhan proyek, yang berjumlah sekitar 97 juta dolar AS, terkena risiko.
Segera setelah kejadian tersebut, detektif on-chain terkenal X (Twitter) zachXBT menunjukkan bahwa akar penyebab serangan ini adalah perekrutan peretas dari negara tertentu.
Mari kita lihat lebih dekat bagaimana “peretas dari negara tertentu” menyelesaikan serangan senilai hampir $100 juta.
Restorasi di tempat
Korban angkat bicara
[UTC+ 0 ] Pada pukul 21:37 tanggal 26 Maret 2024 (5 menit setelah serangan), Munchables secara resmi memposting di X (Twitter) yang menyatakan bahwa mereka sedang diserang.
Menurut penyelidikan detektif on-chain Zach Penyerang datang untuk melakukan beberapa pekerjaan pengembangan game. Dia sangat kasar dan benar-benar terlihat seperti peretas Tiongkok. Kami memecatnya dalam waktu satu bulan. Dia juga mencoba membuat kami mempekerjakan salah satu miliknya teman-teman, yang mungkin juga seorang hacker.hacker."
Karena serangan ini menyebabkan kerugian besar bagi pengguna di komunitas, kami segera meluncurkan penyelidikan on-chain. Mari kita lihat lebih dalam detail serangan “peretas dari negara tertentu” ini.
Adegan pertama
[UTC+ 0 ] Pada pukul 21:32 tanggal 26 Maret 2024, terjadi serangan yang melibatkan 17413,96 ETH.
Melalui Blastscan kita bisa melihat transaksi serangan ini:
Kontrak yang rusak (0x 29..1 F) adalah kontrak proxy yang menyimpan dana yang dijanjikan pengguna. Kita dapat melihat bahwa penyerang memanggil fungsi buka kunci kontrak janji, melewati semua pemeriksaan izin, dan mentransfernya. Semua ETH di kontrak masuk ke alamat penyerang 1 (0x 6 E..c 5).
Tampaknya penyerang memanggil fungsi buka kunci dengan perilaku seperti penarikan dan mengambil sebagian besar ETH pada kontrak yang dikompromikan (0x 29..1 F).
Apakah pihak proyek lupa mengunci brankas?
Ada dua pemeriksaan terkait untuk membuka kunci dalam kontrak yang rusak (0x 29..1 F). Mari kita lihat satu per satu.
Pertama, kami menemukan bahwa selama proses verifikasi izin, metode kontrak isRegistered (0x 16..A 0) dipanggil untuk memeriksa apakah pengirim pesan saat ini, yaitu alamat peretas 1 (0x 6 E..c 5) Sudah terdaftar:
Jawabannya adalah: lolos verifikasi.
Ini melibatkan kontrak (0x 16..A 0) dan kontrak logis terbaru yang sesuai (0x e 7..f 1)
[UTC+ 0 ] Pada 08:39 tanggal 24 Maret 2024 (2 hari sebelum serangan), kontrak logis yang sesuai dengan kontrak (0x 16..A 0) ditingkatkan.
Transaksi peningkatan kontrak yang logis:
Kontrak logika diperbarui ke 0x e 7..f 1 .
Alamat kontrak logis asli dapat dilihat di sini, yaitu 0x 9 e..CD.
Saat ini, kami menduga peretas sedang memperbarui kontrak implementasi logika dari kontrak agen, yang akan menjadi 0x 9 e.. CD menjadi berbahaya 0x e 7..f 1 , menyelesaikan bypass izin verifikasi.
Benarkah?
Di Web3.0, Anda tidak perlu menebak atau mendengarkan orang lain. Anda hanya perlu menguasai teknologinya untuk mendapatkan jawabannya sendiri.
Dengan membandingkan kedua kontrak (bukan kontrak sumber terbuka), terdapat beberapa perbedaan nyata antara kontrak 0x 9 e..CD asli dan 0x e 7..f 1 yang diperbarui:
Bagian fungsi inisialisasi dari 0x e 7..f 1 diimplementasikan sebagai berikut:
Bagian fungsi inisialisasi dari 0x 9 e..CD diimplementasikan sebagai berikut:
Terlihat bahwa penyerang menetapkan alamat penyerang (0x 6 e..c 5) sebagai register dalam kontrak logis asli (0x 9 e..CD), dan ada juga dua alamat penyerang lainnya 0x c 5 ..0 d, 0x bf..87 juga didaftarkan, dan field 0 diatur ke waktu blok selama inisialisasi.Penggunaan field 0 akan dijelaskan nanti.
Faktanya, bertentangan dengan dugaan kami, kontrak logika sebenarnya dengan pintu belakang sudah ada sejak awal, dan pembaruan berikutnya normal!
Tunggu, pembaruan ini muncul pada 08:39 tanggal 24 Maret 2024 [UTC+ 0] (2 hari sebelum serangan), yaitu sebelum kejadian ini, kontrak logika telah menjadi kontrak tanpa pintu belakang. Mengapa? Penyerang masih dapat menyelesaikannya serangan itu?
Hal ini karena panggilan delegasi, sehingga pembaruan penyimpanan status sebenarnya ada dalam kontrak (0x 16..A 0), yang menghasilkan fakta bahwa meskipun kontrak logika kemudian diperbarui ke kontrak logika tanpa pintu belakang 0x e 7.. f 1 , slot yang diubah dalam kontrak (0x 16..A 0) tetap tidak akan dipulihkan.
Mari kita verifikasi:
Seperti yang Anda lihat, slot terkait dalam kontrak (0x 16....A 0) memiliki nilai numerik.
Hal ini memungkinkan penyerang untuk melewati pemeriksaan metode isRegistered:
Penyerang kemudian mengubah kontrak pintu belakang menjadi kontrak normal untuk menyembunyikan fakta bahwa pintu belakang telah ditanam.
Selain itu, proses membuka kunci juga melibatkan verifikasi kedua:
Mengenai pemeriksaan lock time, bagian ini untuk memastikan bahwa aset yang terkunci tidak akan dialihkan sebelum habis masa berlakunya.
Penyerang perlu memastikan bahwa waktu blok saat pembukaan kunci dipanggil lebih besar dari waktu berakhirnya kunci yang diperlukan (bidang 3).
Bagian verifikasi ini melibatkan kontrak yang rusak (0x 29..1 F) dan kontrak logis yang sesuai 0x f 5..cd.
Dalam transaksi pada 11:54 tanggal 21 Maret 2024 [UTC+ 0] (5 hari sebelum serangan),
Kita dapat melihat bahwa kontrak logis asli dari kontrak yang rusak (0x 29..1 F) adalah 0x 91..11, dan hanya empat menit kemudian, pada
Ditingkatkan ke 0x f 5..cd.
Kami juga membandingkan kedua kontrak tersebut dan kami menemukan bahwa penyerang juga melakukan trik dalam fungsi inisialisasi seperti sebelumnya.
Implementasi sebagian dari fungsi inisialisasi 0x f 5..cd:
Implementasi sebagian dari fungsi inisialisasi 0x 91..11:
Terlihat jelas bahwa metode yang sama digunakan lagi untuk mengutak-atik jumlah ETH dan waktu pembukaan kunci, lalu menggantinya dengan kontrak normal untuk menipu orang lain.Ketika tim proyek dan peneliti keamanan sedang melakukan debug, semuanya kontrak logis yang terlihat adalah normal, dan karena semua kontrak tersebut adalah kontrak non-open source, semakin sulit untuk melihat inti masalahnya dengan jelas.
Sejauh ini, kami memahami transaksi yang melibatkan 17413 ETH ini dan bagaimana penyerang melakukannya. Namun apakah hanya informasi sebanyak ini di balik kejadian ini?
Dalam analisis kami di atas, kami sebenarnya melihat bahwa peretas memasukkan 3 alamat ke dalam kontrak:
0x 6 e..c 5 (alamat penyerang 1)
0x c 5..0 d (alamat penyerang 2)
0x bf..87 (alamat penyerang 3)
Namun, kami hanya melihat 0x 6 e..c 5 dalam transaksi serangan yang kami temukan di atas. Apa yang dilakukan dua alamat lainnya? Dan rahasia apa yang tersembunyi di alamat(0), _dodoApproveAddress, _uniswapV3Factorty?
Adegan kedua
Pertama mari kita lihat alamat penyerang 3 (0x bf..87), yang mencuri 73.49 WETH melalui metode yang sama:
Dan menyerang alamat sumber gas (0x 97..de), dan memberikan biaya penanganan ke 0x c 5..0 d (alamat penyerang 2) dan 0x bf..87 (alamat penyerang 3).
Sumber 0,1 ETH yang menyerang alamat sumber gas (0x 97..de) berasal dari Owlto.finance (jembatan lintas rantai).
0x c 5..0 d (alamat penyerang 2) tidak melakukan serangan apa pun setelah menerima biaya penanganan, tetapi sebenarnya memiliki rencana tersembunyi. Mari kita terus melihatnya.
Padahal menurut transaksi penyelamatan resmi, alamat asli kontrak yang rusak (0x 29..1 F) bukan hanya 73.49 WETH, hingga akhir penyerangan masih ada 7276.5 WETH & 7758267 USDB.
Kesepakatan penyelamatan:
Penyerang awalnya berencana untuk mencuri aset ini. Anda dapat melihat bahwa alamat 0x c 5..0 d (alamat penyerang 2) awalnya digunakan untuk mencuri USDB.
_dodoApproveAddress di sini adalah 0x00000000000000000000000043000000000000000000000000000000000000003
adalah alamat usb
0x bf..87 (alamat penyerang 3) Alamat ini digunakan untuk mencuri weth:
Pabrik _uniswap V3 di sini adalah 0x0000000000000000000000004300000000000000000000000000000000000004
adalah alamat basah
Dan 0x 6 e..c 5 (alamat penyerang 1) bertanggung jawab untuk mencuri alamat (0), yang merupakan aset asli ETH.
Dengan menyetel kolom 0, penyerang dapat mencuri aset terkait melalui logika berikut:
pertanyaan
Mengapa penyerang tidak mencuri semua aset?
Secara teoritis dia bisa mencuri seluruh aset yaitu sisa WETH dan USDB.
0x bf..87 (alamat penyerang 3) hanya mencuri 73,49 WETH.0x bf..87 (alamat penyerang 3) sebenarnya dapat mengambil semua 7350 WETH, atau Anda dapat menggunakan 0x c 5..0 d (Alamat penyerang 2) mengambil hilangkan semua 7758267 USDB. Mengapa berhenti setelah hanya mengambil sedikit WETH? Kami tidak tahu. Mungkin diperlukan detektif berantai terkenal untuk melakukan penyelidikan internal yang mendalam.
Mengapa penyerang tidak mentransfer 17413 ETH ke mainnet Ethereum?
Seperti kita ketahui, jaringan utama Blast mungkin saja mencegat ETH ini melalui metode terpusat dan membiarkannya tetap di sini secara permanen tanpa menyebabkan kerugian besar bagi pengguna. Namun, begitu ETH ini memasuki jaringan utama Ethereum, tidak ada cara untuk mencegatnya. dia.
Kami mengevaluasi jembatan lintas rantai Blast saat ini. Tidak ada batasan jumlah jembatan lintas rantai resmi, tetapi memerlukan waktu 14 hari untuk keluar, yang cukup bagi petugas Blast untuk menyiapkan rencana intersepsi.
Jembatan lintas rantai pihak ketiga dapat dikreditkan hampir secara real-time, sama seperti sumber biaya penyerang, dan dapat dengan cepat menyelesaikan lintas rantai. Mengapa penyerang tidak segera melakukan lintas rantai?
Faktanya, penyerang melakukan cross-chain pada saat pertama (dalam waktu 2 menit setelah serangan):
Selain itu, dibutuhkan waktu 20 detik agar dana tiba di jaringan utama Ethereum. Secara teori, penyerang dapat terus melakukan lintas rantai dan mentransfer sejumlah besar ETH lintas rantai sebelum jembatan lintas rantai dapat melakukan intervensi secara manual.
Adapun kenapa hanya bisa 3 ETH dalam satu waktu, alasannya adalah batas likuiditas jembatan lintas rantai, dari Blast ke ETH:
Jembatan lintas rantai lain yang mendukung Blast bahkan lebih sedikit lagi:
Setelah transaksi lintas rantai ini, penyerang tidak melanjutkan operasi lintas rantai lainnya. Alasannya tidak kami ketahui. Tampaknya "peretas dari negara tertentu" tidak melakukan persiapan yang memadai untuk penarikan dana dari Blast.
Perkembangan kejadian setelah penyerangan
Berdasarkan masukan dari pengguna komunitas Nearisbuilding, dia menemukan lebih banyak informasi identitas penyerang dan menemukan cara untuk mendorong penyerang mengembalikan dana.
Pada akhirnya, dengan perhatian dan upaya komunitas enkripsi, "peretas dari negara tertentu", mungkin karena takut mengungkapkan identitasnya, memberikan kunci pribadi dari tiga alamat penyerang di atas kepada pihak proyek dan mengembalikan semua dana Pihak proyek juga melakukan transaksi penyelamatan. Mentransfer semua dana dari kontrak yang rusak ke kontrak multi-tanda tangan untuk disimpan.
Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Ulasan pertarungan Blast Chain senilai $97 juta, apakah peretas dari negara tertentu masih asing?
latar belakang
Blast adalah jaringan Ethereum Layer 2 yang diluncurkan oleh Pacman (Tieshun Roquerre, alias Tieshun), pendiri Blur, yang meluncurkan mainnet pada tanggal 29 Februari. Saat ini, sekitar 19,500 ETH dan 640,000 stETH dijanjikan di mainnet Blast.
Proyek Munchables yang diserang adalah proyek berkualitas tinggi yang memenangkan kompetisi Bigbang yang diselenggarakan oleh Blast.
Pejabat Blast akan memberikan poin biasa kepada pengguna yang menjanjikan ETH di mainnet Blast:
Untuk mendorong pengguna berpartisipasi dalam proyek DeFi di ekosistem Blast, pejabat Blast akan memilih proyek berkualitas tinggi untuk rekomendasi dan mendorong pengguna untuk menjaminkan ETH untuk kedua kalinya ke DeFi untuk mendapatkan peningkatan poin dan poin emas yang lebih cepat, sehingga ada cukup banyak beberapa Pengguna menjanjikan ETH yang dijanjikan pada jaringan utama Blast ke proyek DeFi yang baru dibuat.
Kematangan dan keamanan proyek DeFi ini belum diperiksa, dan apakah kontrak ini memiliki pertimbangan keamanan yang memadai untuk melindungi puluhan juta atau bahkan ratusan juta dolar pengguna.
Ikhtisar Acara
Kurang dari sebulan setelah mainnet Blast online, serangan terhadap SSS Token (Super Sushi Samurai) terjadi pada tanggal 21 Maret 2024. Ada kesalahan logika transfer dalam kontrak Token, yang memungkinkan penyerang meningkatkan SSS Token dari token tersebut. akun tertentu keluar dari keseimbangan, proyek akhirnya kehilangan lebih dari 1,310 ETH (sekitar $4.6 juta).
Kurang dari seminggu setelah serangan SSS Token, serangan lain yang lebih besar terjadi di Blast.Proyek Munchables disapu oleh penyerang dengan 17413.96 ETH, total sekitar 62.5 juta dolar AS.
Setengah jam setelah transaksi serangan terjadi, 73,49 WETH dalam kontrak proyek juga dicuri oleh hacker dari alamat lain.
Saat ini, masih terdapat 7276 WETH, 7758267 USDB, dan 4 ETH yang tersimpan di alamat kontrak pihak proyek, yang sewaktu-waktu akan jatuh ke tangan hacker. Peretas mempunyai kewenangan untuk mengambil seluruh dana dari keseluruhan proyek, yang berjumlah sekitar 97 juta dolar AS, terkena risiko.
Segera setelah kejadian tersebut, detektif on-chain terkenal X (Twitter) zachXBT menunjukkan bahwa akar penyebab serangan ini adalah perekrutan peretas dari negara tertentu.
Mari kita lihat lebih dekat bagaimana “peretas dari negara tertentu” menyelesaikan serangan senilai hampir $100 juta.
Restorasi di tempat
Korban angkat bicara
[UTC+ 0 ] Pada pukul 21:37 tanggal 26 Maret 2024 (5 menit setelah serangan), Munchables secara resmi memposting di X (Twitter) yang menyatakan bahwa mereka sedang diserang.
Menurut penyelidikan detektif on-chain Zach Penyerang datang untuk melakukan beberapa pekerjaan pengembangan game. Dia sangat kasar dan benar-benar terlihat seperti peretas Tiongkok. Kami memecatnya dalam waktu satu bulan. Dia juga mencoba membuat kami mempekerjakan salah satu miliknya teman-teman, yang mungkin juga seorang hacker.hacker."
Karena serangan ini menyebabkan kerugian besar bagi pengguna di komunitas, kami segera meluncurkan penyelidikan on-chain. Mari kita lihat lebih dalam detail serangan “peretas dari negara tertentu” ini.
Adegan pertama
[UTC+ 0 ] Pada pukul 21:32 tanggal 26 Maret 2024, terjadi serangan yang melibatkan 17413,96 ETH.
Melalui Blastscan kita bisa melihat transaksi serangan ini:
Kontrak yang rusak (0x 29..1 F) adalah kontrak proxy yang menyimpan dana yang dijanjikan pengguna. Kita dapat melihat bahwa penyerang memanggil fungsi buka kunci kontrak janji, melewati semua pemeriksaan izin, dan mentransfernya. Semua ETH di kontrak masuk ke alamat penyerang 1 (0x 6 E..c 5).
Tampaknya penyerang memanggil fungsi buka kunci dengan perilaku seperti penarikan dan mengambil sebagian besar ETH pada kontrak yang dikompromikan (0x 29..1 F).
Apakah pihak proyek lupa mengunci brankas?
Ada dua pemeriksaan terkait untuk membuka kunci dalam kontrak yang rusak (0x 29..1 F). Mari kita lihat satu per satu.
Pertama, kami menemukan bahwa selama proses verifikasi izin, metode kontrak isRegistered (0x 16..A 0) dipanggil untuk memeriksa apakah pengirim pesan saat ini, yaitu alamat peretas 1 (0x 6 E..c 5) Sudah terdaftar:
Jawabannya adalah: lolos verifikasi.
Ini melibatkan kontrak (0x 16..A 0) dan kontrak logis terbaru yang sesuai (0x e 7..f 1)
[UTC+ 0 ] Pada 08:39 tanggal 24 Maret 2024 (2 hari sebelum serangan), kontrak logis yang sesuai dengan kontrak (0x 16..A 0) ditingkatkan.
Transaksi peningkatan kontrak yang logis:
Kontrak logika diperbarui ke 0x e 7..f 1 .
Alamat kontrak logis asli dapat dilihat di sini, yaitu 0x 9 e..CD.
Benarkah?
Di Web3.0, Anda tidak perlu menebak atau mendengarkan orang lain. Anda hanya perlu menguasai teknologinya untuk mendapatkan jawabannya sendiri.
Dengan membandingkan kedua kontrak (bukan kontrak sumber terbuka), terdapat beberapa perbedaan nyata antara kontrak 0x 9 e..CD asli dan 0x e 7..f 1 yang diperbarui:
Bagian fungsi inisialisasi dari 0x e 7..f 1 diimplementasikan sebagai berikut:
Bagian fungsi inisialisasi dari 0x 9 e..CD diimplementasikan sebagai berikut:
Terlihat bahwa penyerang menetapkan alamat penyerang (0x 6 e..c 5) sebagai register dalam kontrak logis asli (0x 9 e..CD), dan ada juga dua alamat penyerang lainnya 0x c 5 ..0 d, 0x bf..87 juga didaftarkan, dan field 0 diatur ke waktu blok selama inisialisasi.Penggunaan field 0 akan dijelaskan nanti.
Faktanya, bertentangan dengan dugaan kami, kontrak logika sebenarnya dengan pintu belakang sudah ada sejak awal, dan pembaruan berikutnya normal!
Tunggu, pembaruan ini muncul pada 08:39 tanggal 24 Maret 2024 [UTC+ 0] (2 hari sebelum serangan), yaitu sebelum kejadian ini, kontrak logika telah menjadi kontrak tanpa pintu belakang. Mengapa? Penyerang masih dapat menyelesaikannya serangan itu?
Hal ini karena panggilan delegasi, sehingga pembaruan penyimpanan status sebenarnya ada dalam kontrak (0x 16..A 0), yang menghasilkan fakta bahwa meskipun kontrak logika kemudian diperbarui ke kontrak logika tanpa pintu belakang 0x e 7.. f 1 , slot yang diubah dalam kontrak (0x 16..A 0) tetap tidak akan dipulihkan.
Mari kita verifikasi:
Seperti yang Anda lihat, slot terkait dalam kontrak (0x 16....A 0) memiliki nilai numerik.
Hal ini memungkinkan penyerang untuk melewati pemeriksaan metode isRegistered:
Penyerang kemudian mengubah kontrak pintu belakang menjadi kontrak normal untuk menyembunyikan fakta bahwa pintu belakang telah ditanam.
Selain itu, proses membuka kunci juga melibatkan verifikasi kedua:
Mengenai pemeriksaan lock time, bagian ini untuk memastikan bahwa aset yang terkunci tidak akan dialihkan sebelum habis masa berlakunya.
Penyerang perlu memastikan bahwa waktu blok saat pembukaan kunci dipanggil lebih besar dari waktu berakhirnya kunci yang diperlukan (bidang 3).
Bagian verifikasi ini melibatkan kontrak yang rusak (0x 29..1 F) dan kontrak logis yang sesuai 0x f 5..cd.
Dalam transaksi pada 11:54 tanggal 21 Maret 2024 [UTC+ 0] (5 hari sebelum serangan),
Kita dapat melihat bahwa kontrak logis asli dari kontrak yang rusak (0x 29..1 F) adalah 0x 91..11, dan hanya empat menit kemudian, pada
Ditingkatkan ke 0x f 5..cd.
Kami juga membandingkan kedua kontrak tersebut dan kami menemukan bahwa penyerang juga melakukan trik dalam fungsi inisialisasi seperti sebelumnya.
Implementasi sebagian dari fungsi inisialisasi 0x f 5..cd:
Implementasi sebagian dari fungsi inisialisasi 0x 91..11:
Terlihat jelas bahwa metode yang sama digunakan lagi untuk mengutak-atik jumlah ETH dan waktu pembukaan kunci, lalu menggantinya dengan kontrak normal untuk menipu orang lain.Ketika tim proyek dan peneliti keamanan sedang melakukan debug, semuanya kontrak logis yang terlihat adalah normal, dan karena semua kontrak tersebut adalah kontrak non-open source, semakin sulit untuk melihat inti masalahnya dengan jelas.
Sejauh ini, kami memahami transaksi yang melibatkan 17413 ETH ini dan bagaimana penyerang melakukannya. Namun apakah hanya informasi sebanyak ini di balik kejadian ini?
Dalam analisis kami di atas, kami sebenarnya melihat bahwa peretas memasukkan 3 alamat ke dalam kontrak:
0x 6 e..c 5 (alamat penyerang 1)
0x c 5..0 d (alamat penyerang 2)
0x bf..87 (alamat penyerang 3)
Namun, kami hanya melihat 0x 6 e..c 5 dalam transaksi serangan yang kami temukan di atas. Apa yang dilakukan dua alamat lainnya? Dan rahasia apa yang tersembunyi di alamat(0), _dodoApproveAddress, _uniswapV3Factorty?
Adegan kedua
Pertama mari kita lihat alamat penyerang 3 (0x bf..87), yang mencuri 73.49 WETH melalui metode yang sama:
Dan menyerang alamat sumber gas (0x 97..de), dan memberikan biaya penanganan ke 0x c 5..0 d (alamat penyerang 2) dan 0x bf..87 (alamat penyerang 3).
Sumber 0,1 ETH yang menyerang alamat sumber gas (0x 97..de) berasal dari Owlto.finance (jembatan lintas rantai).
0x c 5..0 d (alamat penyerang 2) tidak melakukan serangan apa pun setelah menerima biaya penanganan, tetapi sebenarnya memiliki rencana tersembunyi. Mari kita terus melihatnya.
Padahal menurut transaksi penyelamatan resmi, alamat asli kontrak yang rusak (0x 29..1 F) bukan hanya 73.49 WETH, hingga akhir penyerangan masih ada 7276.5 WETH & 7758267 USDB.
Kesepakatan penyelamatan:
Penyerang awalnya berencana untuk mencuri aset ini. Anda dapat melihat bahwa alamat 0x c 5..0 d (alamat penyerang 2) awalnya digunakan untuk mencuri USDB.
_dodoApproveAddress di sini adalah 0x00000000000000000000000043000000000000000000000000000000000000003
adalah alamat usb
0x bf..87 (alamat penyerang 3) Alamat ini digunakan untuk mencuri weth:
Pabrik _uniswap V3 di sini adalah 0x0000000000000000000000004300000000000000000000000000000000000004
adalah alamat basah
Dan 0x 6 e..c 5 (alamat penyerang 1) bertanggung jawab untuk mencuri alamat (0), yang merupakan aset asli ETH.
Dengan menyetel kolom 0, penyerang dapat mencuri aset terkait melalui logika berikut:
pertanyaan
Mengapa penyerang tidak mencuri semua aset?
Secara teoritis dia bisa mencuri seluruh aset yaitu sisa WETH dan USDB.
0x bf..87 (alamat penyerang 3) hanya mencuri 73,49 WETH.0x bf..87 (alamat penyerang 3) sebenarnya dapat mengambil semua 7350 WETH, atau Anda dapat menggunakan 0x c 5..0 d (Alamat penyerang 2) mengambil hilangkan semua 7758267 USDB. Mengapa berhenti setelah hanya mengambil sedikit WETH? Kami tidak tahu. Mungkin diperlukan detektif berantai terkenal untuk melakukan penyelidikan internal yang mendalam.
Mengapa penyerang tidak mentransfer 17413 ETH ke mainnet Ethereum?
Seperti kita ketahui, jaringan utama Blast mungkin saja mencegat ETH ini melalui metode terpusat dan membiarkannya tetap di sini secara permanen tanpa menyebabkan kerugian besar bagi pengguna. Namun, begitu ETH ini memasuki jaringan utama Ethereum, tidak ada cara untuk mencegatnya. dia.
Kami mengevaluasi jembatan lintas rantai Blast saat ini. Tidak ada batasan jumlah jembatan lintas rantai resmi, tetapi memerlukan waktu 14 hari untuk keluar, yang cukup bagi petugas Blast untuk menyiapkan rencana intersepsi.
Jembatan lintas rantai pihak ketiga dapat dikreditkan hampir secara real-time, sama seperti sumber biaya penyerang, dan dapat dengan cepat menyelesaikan lintas rantai. Mengapa penyerang tidak segera melakukan lintas rantai?
Faktanya, penyerang melakukan cross-chain pada saat pertama (dalam waktu 2 menit setelah serangan):
Selain itu, dibutuhkan waktu 20 detik agar dana tiba di jaringan utama Ethereum. Secara teori, penyerang dapat terus melakukan lintas rantai dan mentransfer sejumlah besar ETH lintas rantai sebelum jembatan lintas rantai dapat melakukan intervensi secara manual.
Adapun kenapa hanya bisa 3 ETH dalam satu waktu, alasannya adalah batas likuiditas jembatan lintas rantai, dari Blast ke ETH:
Jembatan lintas rantai lain yang mendukung Blast bahkan lebih sedikit lagi:
Setelah transaksi lintas rantai ini, penyerang tidak melanjutkan operasi lintas rantai lainnya. Alasannya tidak kami ketahui. Tampaknya "peretas dari negara tertentu" tidak melakukan persiapan yang memadai untuk penarikan dana dari Blast.
Perkembangan kejadian setelah penyerangan
Berdasarkan masukan dari pengguna komunitas Nearisbuilding, dia menemukan lebih banyak informasi identitas penyerang dan menemukan cara untuk mendorong penyerang mengembalikan dana.
Pada akhirnya, dengan perhatian dan upaya komunitas enkripsi, "peretas dari negara tertentu", mungkin karena takut mengungkapkan identitasnya, memberikan kunci pribadi dari tiga alamat penyerang di atas kepada pihak proyek dan mengembalikan semua dana Pihak proyek juga melakukan transaksi penyelamatan. Mentransfer semua dana dari kontrak yang rusak ke kontrak multi-tanda tangan untuk disimpan.