~$104.6M Kaybedildi: Verus, RetoSwap ve Daha Fazlası

Geçtiğimiz hafta (2026/05/18 - 2026/05/24), BlockSec birden fazla blok zinciri ekosisteminde çeşitli saldırı olayları tespit etti. Aşağıdaki tablo, toplam tahmini kayıpların yaklaşık 104,6 milyon dolar olduğu 5 önemli olayı listelemektedir.

Tarih	Olay	Tür	Tahmini Kayıp
2026/05/18	Verus Olayı	İş Mantığı Açığı	~$11,7M
2026/05/18	EchoProtocol Olayı	Özel Anahtar Ele Geçirilmesi	~$76,7M
2026/05/20	RetoSwap Olayı	İş Mantığı Açığı	~$2,7M
2026/05/22	Polymarket Olayı	Özel Anahtar Ele Geçirilmesi	~$700K
2026/05/24	StablR Olayı	Özel Anahtar Ele Geçirilmesi	~$12,8M

Derinlemesine analiz için iki olay seçilmiştir:

Verus: Saldırgan, köprünün birincil dışa aktarım olarak yanlış sınıflandırdığı el yapımı bir tamamlayıcı dışa aktarım çıktısı göndererek Verus-Ethereum Köprüsü'ndeki tür doğrulama hatasını istismar etti. Zincirler arası mesaj semantiği, saldırı yüzeyinin bir parçasını oluşturmaktadır.
RetoSwap: P2P işlem akışındaki protokol düzeyinde bir kimlik doğrulama açığı, bir saldırganın sahte bir ACK mesajı göndererek tahkim rolünü ele geçirmesine izin verdi. Saldırgan, çoklu imza cüzdanı oluşturma sürecini tamamen zincir dışında ele geçirdi.

Haftanın Öne Çıkanı: Verus

Bu olay öne çıkarılmaktadır; çünkü saldırgan özel bir zincirler arası dışa aktarım türünü kasıtlı olarak kötüye kullandı ve bu durum, Verus zincirinin iç tasarımına derin bir hakimiyete işaret etmektedir. İstismar, tamamlayıcı veri alanları ve kodlama sınırları dahil olmak üzere zincirler arası mesaj formatlarının saldırı yüzeyinin bir parçası olduğunu ve kriptografik kanıt doğrulamasıyla aynı titizliği gerektirdiğini göstermektedir.

18 Mayıs 2026'da, Verus L1 zincirini ve Ethereum'u birbirine bağlayan bir zincirler arası köprü olan Verus-Ethereum Köprüsü, ETH, tBTC ve USDC cinsinden yaklaşık 11,7 milyon dolar zarara uğratıldı [1][2]. Temel neden, Ethereum tarafındaki içe aktarım yolunda yaşanan bir tür doğrulama hatasıydı: köprü sözleşmesi, el yapımı bir tamamlayıcı dışa aktarım çıktısını kabul ederek bunu geçerli bir birincil dışa aktarım olarak yanlış sınıflandırdı ve saldırganın eşleşen transfer verisi sağlayarak fonları boşaltmasına olanak tanıdı. 23 Mayıs itibarıyla, çalınan fonların yaklaşık %75'i iade edilmişti.

Arka Plan

Verus-Ethereum Köprüsü, birinin onaylanmış bir Verus durumu altında uygun bir Verus tarafı dışa aktarımının var olduğunu kanıtlamasının ardından Ethereum üzerindeki varlıkları serbest bırakır. Ethereum, Verus işlemlerini doğrudan gözlemlemez; gönderilen kanıt verilerine ve Verus durumunun güvenilir olduğunu sabitleyen bir onaylamaya dayanır.

Bu olayla ilgili üç köprü nesnesi mevcuttur: birincil dışa aktarım, Ethereum'un içe aktardığı ve ödemeler için kullandığı nesnedir; tamamlayıcı dışa aktarım çıktısı, birincil dışa aktarıma ekli ek veridir ve ödeme amaçlı bağımsız bir aktif dışa aktarım olarak değerlendirilmesi amaçlanmaz; onaylama ise Ethereum'un belirli bir Verus tarafı nesnesinin sonlandırılmış köprü durumunda var olduğunu kanıtlamasına olanak tanır.

Güvenlik Açığı Analizi

Hatalı Ethereum tarafı köprü sözleşmeleri 0xa045...6fc87f ve 0x08f0...d0107d adreslerinde dağıtılmıştır.

Temel neden, Ethereum içe aktarım yolundaki bir tür doğrulama hatasıydı. Köprü, gerçek bir Verus tarafı nesnesinin var olduğunu kanıtladı; ancak fonları serbest bırakmak için kullanmadan önce kanıtlanan nesnenin geçerli bir birincil dışa aktarım olduğunu doğrulamadı. Bunun yerine, el yapımı bir tamamlayıcı çıktıyı sanki normal bir aktif dışa aktarımmış gibi kabul edip ayrıştırdı.

Üst düzeyde, güvenlik açığı içeren akış şöyledir:

proveImports(...)
    -> kanıtı doğrula
    -> keccak256(serializedTransfers) == taahhüt edilen transfer hash'i doğrula

processTransactions(...)
    -> Ethereum üzerinde ödemeleri gerçekleştir

Bu akışta FLAG_SUPPLEMENTAL bayrağı ayarlanmış nesneleri reddeden hiçbir kontrol yoktur. Düzeltme, bu bayrağı açıkça kontrol eder ve kanıtlanan nesne tamamlayıcı olduğunda işlemi geri alır:

Saldırı Analizi

Aşağıdaki analiz, Ethereum işlemi 0x6990f0...87eb321 ve Verus işlemi f899e698...b9f5a733 esas alınarak hazırlanmıştır.

Adım 1: 17 Mayıs'ta saldırgan, Tornado Cash aracılığıyla 0x5aBb...9D5777 Ethereum adresini 1 ETH ile fonladı. 18 Mayıs'ta saldırgan, RW9vEW...B3g6zd adresi için Verus musluğundan 0,02 VRSC edindi.
Adım 2: Saldırgan, Verus üzerinde Ethereum hedefli dört dışa aktarım işlemi göndererek içlerine hazırlanmış tamamlayıcı dışa aktarım çıktıları yerleştirdi. Bu tamamlayıcı çıktılar, hatasız ayrıştırılabilir şekilde kodlandı ve saldırganın daha sonra gerçekleştirmeyi planladığı sahte ödemelerle eşleşen bir hashReserveTransfers taahhüdü içeriyordu.
Adım 3: Ethereum üzerinde zincirler arası bir onaylama yeterince ilerledikten sonra saldırgan, Ethereum üzerinde sahte bir içe aktarım işlemi gönderdi. Kanıtlanan Verus tarafı nesnesi, yukarıdaki Verus işleminden elde edilen tamamlayıcı çıktıydı.
Adım 4: Ethereum köprüsü kanıtı kabul etti; ancak kanıtlanan nesneyi tamamlayıcı veri olarak reddetmedi. Bunun yerine, hazırlanmış çıktıyı geçerli bir aktif dışa aktarımmış gibi ayrıştırdı. Saldırgan ayrıca hash'i taahhüt edilen hashReserveTransfers değeriyle eşleşen serializedTransfers verisi de sağladığından köprü, içe aktarım akışından geçmeye devam etti.
Adım 5: Tamamlayıcı çıktı geçerli bir dışa aktarım olarak yanlış yorumlanınca, sahte transferler Ethereum tarafındaki kontrollerden geçti. Saldırgan, ETH, tBTC ve USDC cinsinden yaklaşık 11,7 milyon dolar değerinde fon boşalttı.
Adım 6: Kötü niyetli içe aktarım başarıya ulaşmasının hemen ardından Verus düğümleri, sahte dışa aktarım iş parçacığı ile gerçek bir dışa aktarım iş parçacığının bir arada bulunmasından kaynaklanan geçersiz durum iddiasıyla karşılaştı; bu durum köprünün ilerlemesini durdurdu ve sonraki istismarları sınırladı.

Sonuç

Olay, Verus-Ethereum Köprüsü'ndeki bir tür doğrulama hatasından kaynaklandı: Ethereum sözleşmesi gerçek bir kriptografik kanıtı kabul etti; ancak kanıtlanan nesne, ödemeler için geçerli bir birincil dışa aktarım değil, tamamlayıcı bir dışa aktarım çıktısıydı.

Zincirler arası mesaj formatları, saldırı yüzeyinin bir parçasıdır. Tamamlayıcı veriler, isteğe bağlı alanlar, kompakt kodlamalar ve ayrıştırıcı ofsetleri, imza veya Merkle kanıt kontrollerindekiyle aynı titizlikle ele alınmalıdır. Bir nesne, gerçekleştirilen eylem için beklenen türle eşleşmediğinde köprü, nesneyi ayrıştırmaya çalışmak yerine doğrudan reddetmelidir.

Referanslar

Bu Haftaki Diğer Olaylar

RetoSwap

20 Mayıs 2026'da, Haveno Protocol'den çatallanmış Monero üzerinde merkezi olmayan bir P2P borsası olan RetoSwap, yaklaşık 2,7 milyon dolar (7.000 XMR) zarara uğratıldı [1]. Temel neden, protokol düzeyinde bir kimlik doğrulama açığıydı: istemci, sahte ve sıra dışı bir ACK mesajını kabul ederek göndereni tahkim eden bilinen genel anahtarına karşı doğrulamadan, tahkim kuruluşunun depolanan Tor adresinin üzerine saldırgan kontrolündeki bir adresi yazdı. Bu durum, saldırganın çoklu imza cüzdan oluşturma sürecini ele geçirmesine ve fonlar yatırılır yatırılmaz çalmasına olanak tanıdı.

Arka Plan

RetoSwap, Haveno Protocol'den çatallanmış, Monero üzerinde merkezi olmayan bir P2P borsasıdır. Ticaret protokolü, işlemleri güvence altına almak için 2/3 tahkim çoklu imza modelini kullanır ve işlemleri Tor üzerinden zincir dışında koordine eder.

Normal bir işlem üç aşamada gerçekleşir: birincisi, alıcı, satıcı ve tahkim kurumu çoklu imza cüzdanı oluşturmak için zincir dışı mesaj alışverişini tamamlar; ikincisi, fonlar yalnızca cüzdan tam olarak oluşturulduktan sonra çoklu imza cüzdanına kilitlenir; üçüncüsü, alıcı ve satıcı ödemeyi tamamlamak için ödeme işlemini birlikte imzalar ya da anlaşmazlıkları çözmek için tahkim kurumu devreye girer. Tüm iletişim Tor üzerinden yürütülür ve her düğüm yalnızca .onion adresiyle tanımlanır.

Güvenlik Açığı Analizi

20 Mayıs'ta Haveno projesi, "core: çoklu imza oluşturulmadan önce düğüm adresi güncellemesini reddet" başlıklı bir çekme isteği açtı [2]. O tarihe gelindiğinde RetoSwap zaten saldırı altındaydı.

Yama, TradeProtocol.java:onAckMessageAux(...) içindeki bir güvenlik açığını ortaya koydu. İstemci, eşleri mesaj tarafından sağlanan senderNodeAddress kullanarak tanımladı; ancak göndericinin beklenen tahkim kuruluşunun genel anahtarıyla eşleştiğini kriptografik olarak doğrulamadı. Bir saldırgan, saldırgan kontrolündeki bir .onion adresini taşıyan sahte bir ACK mesajı gönderebiliyor ve istemci, depolanan tahkim adresinin üzerine bu adresi yazıyordu.

Bu durum 1. Aşama'da (çoklu imza cüzdanı oluşturulmadan önce) gerçekleştiğinden, saldırganın adresi gerçek tahkim adresinin yerini aldı. Dolayısıyla saldırgan, çoklu imza cüzdanının hem işlem tarafı anahtarını hem de tahkim tarafı anahtarını elinde bulundurarak fonlar yatırılır yatırılmaz tüm bakiyeyi çalabildi.

Düzeltme bu durumu iki şekilde ele alır: göndereni eşin bilinen genel anahtarına karşı doğrular ve doğrulanmamış eşlerden gelen mesajları reddeder; ayrıca adres güncellemelerini trade.isDepositRequested() koşuluna bağlayarak çoklu imza cüzdanı oluşturulmadan önce üzerine yazılmasını engeller.

Saldırı Analizi

Bu olay için zincir üzerinde herhangi bir saldırı işlemi tespit edilemedi. RetoSwap, tamamen Tor üzerinde zincir dışı mesaj işlemeyle çalışmaktadır; bu nedenle kritik eylemler herhangi bir genel defterin dışında gerçekleşmektedir. Aşağıdaki yeniden yapılandırma, kamuya açık yama ve resmi iletişimlere dayanmaktadır.

Adım 1: Saldırgan, mevcut bir işleme alıcı veya satıcı olarak katıldı.
Adım 2: Saldırgan, tahkim kuruluşundan geliyormuş gibi görünen, senderNodeAddress olarak saldırgan kontrolündeki bir .onion adresini taşıyan sahte ve sıra dışı bir ACK mesajı gönderdi.
Adım 3: Kurbanın istemcisi mesajı kabul etti ve göndereni tahkim kuruluşunun bilinen genel anahtarına karşı doğrulamadan tahkim kuruluşunun depolanan adresinin üzerine yazdı.
Adım 4: Tahkim kuruluşu için tasarlanan tüm sonraki iletişim; çoklu imza cüzdanı oluşturma da dahil olmak üzere saldırgana yönlendirildi ve saldırgan üçüncü çoklu imza anahtarını elde etti.
Adım 5: Alıcı ve satıcı, ele geçirilmiş çoklu imza cüzdanına fon yatırınca saldırgan cüzdanın tüm içeriğini çaldı. Toplam kâr yaklaşık 7.000 XMR (~$2,7M) tutarına ulaştı.

Sonuç

Olay, kriptografik bir başarısızlık değil, protokol düzeyinde bir kimlik doğrulama açığıydı: mesajlar iyi biçimlendirilmiş olarak doğrulandı; ancak adres güncellemeleri uygulanmadan önce gönderici, bilinen bir genel anahtara kriptografik olarak bağlanmadı. Sonuç olarak, çoklu imza cüzdanı oluşturulmadan önce istemci, sahte bir ACK mesajından gelen doğrulanmamış bir senderNodeAddress'i tahkim kuruluşunun yeni iletişim noktası olarak kabul etti ve saldırganın tahkim rolünü ele geçirmesine olanak tanıdı.

Temel dersler şunlardır: (1) eş kimliğini güncelleyen her mesaj, güncelleme uygulanmadan önce eşin bilinen genel anahtarına karşı kriptografik olarak doğrulanmalıdır ve (2) karşı taraf adresleri gibi kimlik açısından kritik durumlar, güvenlik açısından hassas aşama (ör. çoklu imza cüzdanı oluşturma) başladıktan sonra değiştirilemez olmalıdır.

Referanslar

BlockSec Hakkında

BlockSec, tam yığın blok zinciri güvenliği ve kripto uyumluluk sağlayıcısıdır. Müşterilerin kod denetimi (akıllı sözleşmeler, blok zinciri ve cüzdanlar dahil) yapmasına, saldırıları gerçek zamanlı olarak engellememesine, olayları analiz etmesine, yasadışı fonları takip etmesine ve protokollerin ve platformların tam yaşam döngüsü boyunca AML/CFT yükümlülüklerini yerine getirmesine yardımcı olan ürünler ve hizmetler geliştiriyoruz.

BlockSec, prestijli konferanslarda birden fazla blok zinciri güvenlik makalesi yayımladı, DeFi uygulamalarına yönelik çeşitli sıfır gün saldırıları bildirdi, 20 milyonun üzerinde dolar kurtarmak için birden fazla saldırıyı engelledi ve milyarlarca dolar değerinde kripto parayı güvence altına aldı.