arka plan

Blast, Blur'un kurucusu Pacman (Tieshun Roquerre, diğer adıyla Tieshun) tarafından başlatılan bir Ethereum Layer 2 ağıdır. 29 Şubat'ta ana ağı hizmete açmıştır. Şu anda Blast ana ağında yaklaşık 19.500 ETH ve 640.000 stETH taahhüt edilmiştir.

Saldırıya uğrayan Munchables projesi, Blast'ın düzenlediği Bigbang yarışmasını kazanan yüksek kaliteli bir projeydi.

Blast yetkilileri, Blast ana ağında ETH taahhüt eden kullanıcılara sıradan puanlar verecek:

Kullanıcıları Blast ekosistemindeki DeFi projelerine katılmaya teşvik etmek amacıyla Blast yetkilileri, tavsiye için yüksek kaliteli projeleri seçecek ve daha hızlı puan artışı ve altın puan elde etmek için kullanıcıları ikinci kez DeFi'ye ETH taahhüt etmeye teşvik edecek, dolayısıyla oldukça fazla teklif var. Birkaç Kullanıcı, Blast ana ağında taahhüt edilen ETH'yi yeni oluşturulan DeFi projesine taahhüt etti.

Bu DeFi projelerinin olgunluğu ve güvenliği henüz incelenmedi ve bu sözleşmelerin, kullanıcıların on milyonlarca, hatta yüz milyonlarca dolarını korumaya yetecek güvenlik hususlarına sahip olup olmadığı henüz incelenmedi.

Etkinliğe genel bakış

Blast ana ağının çevrimiçi hale gelmesinden bir aydan kısa bir süre sonra, 21 Mart 2024'te SSS Token'a (Süper Suşi Samuray) bir saldırı gerçekleşti. Token sözleşmesinde, saldırganın SSS Token'ını artırmasına olanak tanıyan bir transfer mantığı hatası vardı. Belirtilen hesapta havadan bakiye kalmaması nedeniyle proje sonuçta 1.310 ETH'den (yaklaşık 4,6 milyon dolar) fazla kayıp yaşadı.

SSS Token saldırısından bir haftadan kısa bir süre sonra Blast'a daha büyük bir saldırı daha gerçekleşti.Munchables projesi, toplamda yaklaşık 62,5 milyon ABD doları olan 17413,96 ETH ile saldırganlar tarafından süpürüldü.

Saldırının gerçekleşmesinden yarım saat sonra proje sözleşmesinde yer alan 73.49 WETH de başka bir adres hacklenerek çalındı.

Şu anda proje tarafının sözleşme adresinde halen 7.276 WETH, 7.758.267 USDB ve 4 ETH bulunmaktadır ve bunlar her an hackerların eline geçebilir.Hacker, proje tarafının tüm fonlarını alma yetkisine sahiptir. Toplam değeri yaklaşık 97 milyon ABD doları olan projenin tamamı riske maruz.

Olayın hemen ardından X'in (Twitter) tanınmış zincir üstü dedektifi ZachXBT, bu saldırının temel nedeninin belirli bir ülkeden hackerların işe alınması olduğuna dikkat çekti.

Gelin, “belirli bir ülkeden gelen hacker”ın yaklaşık 100 milyon dolar değerindeki bir saldırıyı nasıl gerçekleştirdiğine daha yakından bakalım.

Yerinde restorasyon

[UTC+0] 26 Mart 2024 saat 21:37'de (saldırıdan 5 dakika sonra), Munchables resmi olarak X (Twitter) üzerinden saldırı altında olduğunu belirten bir paylaşım yaptı.

Zincir üstü dedektif Zach'in soruşturmasına göre Saldırgan bazı oyun geliştirme çalışmaları yapmak için geldi. Çok kabaydı ve gerçekten Çinli bir hacker'a benziyordu. Bir ay içinde onu kovduk. Ayrıca kendisinden birini işe almamızı sağlamaya çalıştı. muhtemelen kendisi de bir hackerdı."

Bu saldırının topluluktaki kullanıcılara büyük kayıplar vermesi nedeniyle hemen zincirleme bir inceleme başlattık.Haydi, bu "belirli bir ülkeden gelen hacker"ın saldırı detaylarına derinlemesine bir göz atalım.

[UTC+0] 26 Mart 2024 saat 21:32'de 17413,96 ETH'yi içeren bir saldırı meydana geldi.

Bu saldırı işlemini Blastscan üzerinden görebiliriz: https://blastscan.io/tx/0x9a7e4d16ed15b0367b8ad677eaf1db6a2a54663610696d69e1b4aa1a08f55c95

Hasarlı sözleşme (0x29..1F), kullanıcının taahhüt ettiği fonları saklayan bir proxy sözleşmesidir.Saldırganın rehin sözleşmesinin kilit açma işlevini çağırdığını, tüm izin kontrollerini geçtiğini ve sözleşmedeki fonları aktardığını görebiliriz. Tüm ETH'ler saldırganın adresi 1'e (0x6E..c5).

Saldırganın, geri çekilme davranışına benzer bir kilit açma işlevini çağırdığı ve hasarlı sözleşmedeki (0x29..1F) ETH'nin çoğunu elinden aldığı görülüyor.

Proje ekibi kasayı kilitlemeyi mi unuttu?

Hasarlı sözleşmede kilit açma için birbiriyle ilişkili iki kontrol var (0x29..1F).Bunlara tek tek bakalım.

Öncelikle izin doğrulama işlemi sırasında mevcut msg.sender'ın yani hacker adresi 1'in (0x6E..c5) kayıtlı olup olmadığını kontrol etmek için sözleşmenin isRegistered yönteminin (0x16..A0) çağrıldığını tespit ettik. :

Cevap: doğrulamayı geçti.

Bu, sözleşmeyi (0x16..A0) ve ona karşılık gelen en son mantıksal sözleşmeyi (0xe7..f1) içerir.

[UTC+0] 24 Mart 2024 08:39'da (saldırıdan 2 gün önce), sözleşmeye karşılık gelen mantıksal sözleşme (0x16..A0) yükseltildi.

Mantıksal sözleşme yükseltme işlemi:

https://blastscan.io/tx/0x9c431e09a80d2942319853ccfdaae24c5de23cedfcef0022815fdae42a7e2ab6

Mantık sözleşmesi 0xe7..f1 olarak güncellendi.

Orijinal mantıksal sözleşme adresi burada görülebilir, yani 0x9e..CD.

https://blastscan.io/tx/0x7ad050d84c89833aa1398fb8e5d179ddfae6d48e8ce964f6d5b71484cc06d003

Şu anda, bilgisayar korsanının aracı sözleşmesinin mantıksal uygulama sözleşmesini güncellediğinden ve 0x9e..CD'yi kötü amaçlı 0xe7..f1 olarak değiştirdiğinden ve doğrulama izinlerinin atlanmasını tamamladığından şüpheleniyoruz.

Gerçekten mi?

Web3.0'da hiçbir zaman başkalarını tahmin etmenize veya dinlemenize gerek yok. Cevabı kendiniz almak için yalnızca teknolojide uzmanlaşmanız yeterli.

İki sözleşmeyi (açık kaynak sözleşmeleri değil) karşılaştırarak, orijinal 0x9e..CD sözleşmesi ile güncellenmiş 0xe7..f1 sözleşmesi arasında bazı belirgin farklar olduğunu gördük:

0xe7..f1'in başlatma işlevi kısmı şu şekilde uygulanır:

0x9e..CD'nin başlatma işlevi kısmı aşağıdaki şekilde uygulanır:

Saldırganın orijinal mantıksal sözleşmede (0x9e..CD) saldırgan adresini (0x6e..c5) kayıt olarak ayarladığı ve ayrıca 0xc5..0d ve 0xbf..87 olmak üzere iki saldırgan adresinin daha bulunduğu görülmektedir. kaydedilmiştir ve field0, başlatma sırasındaki blok zamanına ayarlanmıştır. field0'ın kullanımı daha sonra açıklanacaktır.

Aslında tahmin ettiğimizin aksine arka kapı ile gerçek mantık sözleşmesi en başından beri vardı ve sonraki güncellemeler normaldi!

Durun, bu güncelleme 24 Mart 2024 08:39'da [UTC+0] yayınlandı (saldırıdan 2 gün önce). Yani bu olaydan önce mantık sözleşmesi arka kapısı olmayan bir sözleşme haline gelmişti. Neden? Saldırgan tamamlayabilir mi? saldırı daha sonra mı?

Bunun nedeni temsilci çağrısıdır, dolayısıyla gerçek durum depolama güncellemesi sözleşmededir (0x16..A0), bu da mantık sözleşmesi daha sonra arka kapı olmadan 0xe7..f1 mantık sözleşmesine güncellense bile, sözleşme (0x16. .A0) yine de geri yüklenmeyecek.

Doğrulayalım:

Sözleşmede karşılık gelen slotun (0x16....A0) sayısal bir değere sahip olduğu görülmektedir.

Bu, bir saldırganın isRegistered yöntem kontrolünü geçmesine olanak tanır:

Saldırgan daha sonra arka kapının zaten yerleştirilmiş olduğu gerçeğini gizlemek için arka kapı sözleşmesini normal bir sözleşmeye dönüştürür.

Ayrıca kilit açma işlemi ikinci bir doğrulamayı da içerir:

Kilitlenme süresi kontrolü ile ilgili olarak bu bölüm, kilitli varlıkların süresi dolmadan devredilmeyeceğinden emin olmak içindir.

Saldırganın, kilit açma çağrıldığında blok süresinin gerekli kilit sona erme süresinden (alan3) daha büyük olduğundan emin olması gerekir.

Doğrulamanın bu kısmı hasarlı sözleşmeyi (0x29..1F) ve karşılık gelen mantıksal sözleşme 0xf5..cd'yi içerir.

21 Mart 2024 [UTC+0] saat 11:54'te (saldırıdan 5 gün önce) yapılan bir işlemde,

https://blastscan.io/tx/0x3d08f2fcfe51cf5758f4e9ba057c51543b0ff386ba53e0b4f267850871b88170

Hasarlı sözleşmenin (0x29..1F) orijinal mantıksal sözleşmesinin 0x91..11 olduğunu ve yalnızca dört dakika sonra,

https://blastscan.io/tx/0xea1d9c0d8de4280b538b6fe6dbc3636602075184651dfeb837cb03f8a19ffc4f

0xf5..cd'ye yükseltildi.

Ayrıca iki sözleşmeyi karşılaştırdığımızda saldırganın daha önce olduğu gibi başlatma fonksiyonunda da hileler yaptığını görebiliriz.

0xf5..cd'nin başlatma fonksiyonunun kısmi uygulaması:

0xf5..cd'ye yükseltildi.

Ayrıca iki sözleşmeyi karşılaştırdığımızda saldırganın daha önce olduğu gibi başlatma fonksiyonunda da hileler yaptığını görebiliriz.

0xf5..cd'nin başlatma fonksiyonunun kısmi uygulaması:

0x91..11'in başlatma fonksiyonunun kısmi uygulaması:

Aynı yöntemin ETH miktarını ve kilit açma süresini değiştirmek için tekrar kullanıldığı ve daha sonra başkalarını kandırmak için normal sözleşme ile değiştirildiği açıkça görülüyor.Proje ekibi ve güvenlik araştırmacıları hata ayıklama yaparken, , görülen tüm mantıksal sözleşmeler normaldir ve sözleşmelerin tümü açık kaynaklı olmayan sözleşmeler olduğundan sorunun özünü net bir şekilde görmek daha da zordur.

Şu ana kadar 17413 ETH'yi içeren bu işlemi ve saldırganın bunu nasıl yaptığını anladık ama bu olayın arkasında sadece bu kadar bilgi mi var?

Yukarıdaki analizimizde aslında hackerın sözleşmeye 3 adres eklediğini gördük:

0x6e..c5 (saldırgan adresi 1)

0xc5..0d (saldırgan adresi 2)

0xbf..87 (saldırgan adresi 3)

Ancak yukarıda bulduğumuz saldırı işleminde sadece 0x6e..c5 gördük, diğer iki adres ne yaptı? Adres(0), _dodoApproveAddress ve _uniswapV3Factorty'de hangi sırlar gizli?

Öncelikle aynı yöntemle 73.49 WETH çalan saldırgan adresi 3'e (0xbf..87) bir göz atalım:

https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233

Ve gazın kaynak adresine (0x97..de) saldırın ve hem 0xc5..0d (saldırganın adresi 2) hem de 0xbf..87'ye (saldırganın adresi 3) işlem ücreti sağlayın.

Gaz kaynağı adresine (0x97..de) saldıran 0.1 ETH'nin kaynağı owlto.finance'dan (zincirler arası köprü) geliyor.

0xc5..0d (saldırganın adresi 2) işlem ücretini aldıktan sonra herhangi bir saldırı gerçekleştirmedi ama aslında gizli bir planı omuzladı.

Aslında kurtarma sonrası yapılan resmi işleme göre hasarlı sözleşmenin orijinal adresi (0x29..1F) sadece 73.49 WETH değildi, saldırının sonuna kadar hala 7276.5 WETH & 7758267 USDB vardı.

Aslında kurtarma sonrası yapılan resmi işleme göre hasarlı sözleşmenin orijinal adresi (0x29..1F) sadece 73.49 WETH değildi, saldırının sonuna kadar hala 7276.5 WETH & 7758267 USDB vardı.

Kurtarma anlaşması:

https://blastscan.io/tx/0x1969f10af9d0d8f80ee3e3c88d358a6f668a7bf4da6e598e5be7a3407dc6d5bb

Saldırgan başlangıçta bu varlıkları çalmayı planlamıştı. 0xc5..0d adresinin (saldırganın adresi 2) başlangıçta USDB'yi çalmak için kullanıldığını görebilirsiniz.

Buradaki _dodoApproveAddress: 0x0000000000000000000000000043000000000000000000000000000000000000003

usb'nin adresi

0xbf..87 (saldırgan adresi 3) Bu adres aşağıdakileri çalmak için kullanılır:

0xbf..87 (saldırgan adresi 3) Bu adres aşağıdakileri çalmak için kullanılır:

Buradaki _uniswapV3Factory 0x000000000000000000000000043000000000000000000000000000000000000004

Weth'in adresi

Ve 0x6e..c5 (saldırganın adresi 1), yerel varlık ETH olan adresin (0) çalınmasından sorumludur.

Saldırgan, field0'ı ayarlayarak ilgili varlıkları aşağıdaki mantık yoluyla çalabilir:

soru

Teorik olarak tüm varlıkları, yani kalan WETH ve USDB'yi çalabilir.

0xbf..87 (saldırgan adresi 3) yalnızca 73.49 WETH çaldı. 0xbf..87 (saldırgan adresi 3) aslında 7350 WETH'in tamamını alabilir. Ayrıca 0xc5..0d (saldırgan adresi 2) kullanabilirsiniz) 7758267 USDB'nin tamamını çaldı Biraz WETH aldıktan sonra neden durduğunu bilmiyoruz.Tanınmış bir zincir dedektifinin derinlemesine bir iç soruşturma yürütmesi gerekebilir.

0xbf..87 (saldırgan adresi 3) yalnızca 73.49 WETH çaldı. 0xbf..87 (saldırgan adresi 3) aslında 7350 WETH'in tamamını alabilir. Ayrıca 0xc5..0d (saldırgan adresi 2) kullanabilirsiniz) 7758267 USDB'nin tamamını çaldı Biraz WETH aldıktan sonra neden durduğunu bilmiyoruz.Tanınmış bir zincir dedektifinin derinlemesine bir iç soruşturma yürütmesi gerekebilir.

https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233

Hepimizin bildiği gibi Blast ana ağının merkezi bir yöntemle bu ETH'lere müdahale etmesi ve ciddi kullanıcı kayıplarına yol açmadan burada kalıcı olarak kalmasını sağlaması mümkün ancak bu ETH'ler Ethereum ana ağına girdikten sonra müdahalenin hiçbir yolu yok. BT.

Mevcut Blast çapraz zincir köprüsünü değerlendirdik. Resmi çapraz zincir köprü sayısında herhangi bir sınırlama yok ancak çıkış için 14 gün gerekiyor ve bu da Blast yetkililerinin bir müdahale planı hazırlaması için yeterli.

Üçüncü taraf çapraz zincir köprüsü, tıpkı saldırganın ücret kaynağı gibi neredeyse gerçek zamanlı olarak kredilendirilebilir ve çapraz zinciri hızlı bir şekilde tamamlayabilir.Saldırgan neden hemen çapraz zincir oluşturmadı?

Aslında saldırgan ilk anda (saldırıdan sonraki 2 dakika içinde) çapraz zincir gerçekleştirdi:

https://blastscan.io/tx/0x10cf2f2b884549979a3a1dd912287256229458ef40d56df61738d6ea7d9d198f

Üstelik fonların Ethereum ana ağına ulaşması 20 saniye sürdü.Teorik olarak, bir saldırgan, zincirler arası köprünün manuel olarak müdahale edebilmesinden önce çapraz zincirlemeye devam edebilir ve zincirler arasında büyük miktarda ETH aktarabilir.

Tek seferde yalnızca 3 ETH olabilmesinin nedeni, Blast'tan ETH'ye zincirler arası köprünün likidite limitidir:

Tek seferde yalnızca 3 ETH olabilmesinin nedeni, Blast'tan ETH'ye zincirler arası köprünün likidite limitidir:

Blast'ı destekleyen başka bir zincirler arası köprü daha da azını destekliyor:

Bu zincirler arası işlemden sonra saldırgan diğer zincirler arası operasyonlara devam etmedi.Sebebi bizim için bilinmiyor.Görünüşe göre "belirli bir ülkeden gelen hacker" Blast'tan fon çekmek için yeterli hazırlık yapmamış.

Saldırının ardından yaşananlar

Topluluk kullanıcısı Nearisbuilding'den gelen geri bildirimlere dayanarak, saldırganın daha fazla kimlik bilgisini buldu ve saldırganın parayı iade etmesini sağlamanın yollarını buldu.

https://twitter.com/Nearisbuilding/status/1772812190673756548

Sonunda, şifreleme topluluğunun dikkat ve çabalarıyla, "belirli bir ülkeden gelen hacker", belki de kimliğini açığa vurmaktan korktuğu için, yukarıdaki üç saldırgan adresinin özel anahtarlarını proje ekibine verdi ve hepsini geri verdi. Proje ekibi ayrıca bir kurtarma işlemi gerçekleştirdi Hasarlı sözleşmedeki tüm fonları, saklama amacıyla çoklu imzalı sözleşmeye aktarın.