~15,9 Milyon Dolar Kayıp: Güvenilir Hacimler, Wasabi ve Daha Fazlası | BlockSec Haftalık

Son iki hafta (2026/04/27 - 2026/05/10) boyunca BlockSec, birçok blok zinciri ekosisteminde çeşitli saldırı olayları tespit etti. Aşağıdaki tablo, tahmini toplam kaybı yaklaşık 15,9 milyon dolar olan 11 önemli olayı listelemektedir.

Saldırı özgünlüğü, finansal etki ve güvenlik açısından önemi göz önünde bulundurularak üç olay derinlemesine inceleme için seçilmiştir:

• Aftermath Finance: Kalıcı bir DEX üzerinde gerçek bir istismar olayı; ücret doğrulamasındaki ince bir işaretli/işaretsiz anlam uyumsuzluğu, protokol fonlarının tamamen boşaltılmasına yol açmıştır.
• Trusted Volumes: Önemli finansal etki (~5,87 milyon dolar) ve RFQ uzlaşma mantığındaki yetkilendirme uyumsuzluğunun açık bir gösterimi.
• Wasabi Protocol: Altyapıdan sözleşme kontrolüne uzanan bir ele geçirme saldırısı; bu tür saldırılar giderek yaygınlaşmakla birlikte denetim kapsamlarında yeterince yer bulmamaktadır.

Haftanın Öne Çıkanı: Aftermath Finance

Bu olay öne çıkarılmıştır; zira işaretli/işaretsiz anlam uyumsuzluğu, tek bir protokolün ötesine geçen ince bir güvenlik açığı sınıfıdır. İşaretsiz ücret veya fiyat değerlerini doğrulamak için işaretli sabit noktalı bir kütüphane kullanan her DeFi protokolü aynı saldırı düzenine karşı savunmasızdır; bu nedenle bu istismar hem geliştiriciler hem de denetçiler için geniş çapta öğretici niteliktedir.

29 Nisan 2026'da Sui üzerinde faaliyet gösteren zincir üstü kalıcı vadeli işlem borsası Aftermath Perpetuals, yaklaşık 1,14 milyon dolar USDC değerinde bir saldırıya uğradı [1]. Temel neden, protokolün builder-ücret doğrulamasındaki işaretli/işaretsiz anlam uyumsuzluğuydu: ücret karşılaştırma fonksiyonu işaretsiz değerler üzerinde işaretli aritmetik gerçekleştirdi ve bu durum saldırganın işaretli yorumda negatif görünen bir ücret değeri göndermesine olanak tanıdı. Uzlaşma sırasında negatif ücret pozitif bir teminat kredisine dönüştürülerek saldırganın protokol kasasından şişirilmiş miktarda para çekmesi mümkün hale geldi.

Arka Plan

Aftermath Perpetuals, Sui üzerinde faaliyet gösteren zincir üstü bir kalıcı vadeli işlem borsasıdır [2]. Protokol, harici entegratörlerin ön uç arayüzler oluşturarak işlem ücreti kazanmasına olanak tanımaktadır. Her entegratör, kendi arayüzünü kullanan yatırımcılardan alınan bir ücret oranı (taker_fee) belirler [3]. Güvenlik önlemi olarak yatırımcılar, bir entegratörün ne kadar ücret talep edebileceğini sınırlayan önceden belirlenmiş bir ücret oranı üst sınırı (maxTakerFee) yapılandırarak entegratörleri onaylayabilir.

Piyasa emri gerçekleştirilirken protokol, ücretin yatırımcı tarafından onaylanan sınır içinde kalmasını sağlamak amacıyla önce taker_fee ile maxTakerFee'yi karşılaştırır, ardından hesaplanan ücreti alıcının teminatından düşerek entegratörün kayıtlarına ekler.

Protokolün aritmetiği, değerleri u256 tamsayı olarak temsil eden ancak karşılaştırma ve aritmetik işlemler için iki'nin tümleyeni anlambilimi kapsamında yorumlayan işaretli sabit noktalı bir kütüphane (ifixed) üzerine inşa edilmiştir.

Güvenlik Açığı Analizi

Hatalı sözleşmeler arasında arayüz modülü (0x9e2080...25d136) ve takas odası modülü (0x21d001...7c5068) yer almaktadır.

Güvenlik açığı, entegratörün taker_fee'sini yatırımcının maxTakerFee'siyle karşılaştırmak için ifixed::less_than_eq() kullanan calculate_taker_fees() fonksiyonunda bulunmaktadır:

assert!(
    ifixed::less_than_eq(
        v5.taker_fee,
        account::get_integrator_max_taker_fee(
            account::get_integrator_config(arg1, v5.integrator_address)
        )
    ),
    errors::invalid_integrator_taker_fee()
);

Hem taker_fee hem de maxTakerFee, anlam olarak negatif olmayan ücret oranlarıdır. Ancak ifixed::less_than_eq(), u256 üzerinde işaretli bir karşılaştırma gerçekleştirir. maxTakerFee 0 olarak ayarlandığında, 2^256 - 10^16 gibi bir değer işaretli anlambilim kapsamında -10^16 olarak yorumlanır. -10^16 <= 0 koşulu sağlandığından kontrol geçilir.

İstismar yolu, create_integrator_info() fonksiyonunun herkes tarafından çağrılabilir olması ve sağlanan taker_fee üzerinde herhangi bir izin veya ücret sınırı doğrulaması uygulamaması nedeniyle daha da açık hale gelmektedir:

public fun create_integrator_info(arg0: address, arg1: u256): Option<IntegratorInfo> {
    let v0 = IntegratorInfo {
        integrator_address : arg0,
        taker_fee          : arg1,
    };
    option::some<IntegratorInfo>(v0)
}

Negatif ücret yalnızca kabul edilmekle kalmaz; uzlaşma sırasında doğrudan pozitif bir teminat kredisine dönüştürülür. Uzlaşma aşamasında teminat collateral += pnl - taker_fee - builder_fee formülüyle güncellenir. builder_fee negatif olduğunda, ondan çıkarma işlemi toplama işlemine dönüşür:

position::add_to_collateral_usd(
    arg0,
    ifixed::sub(v6, ifixed::add(v7, v8)),
    arg2
);

Ne ücret doğrulaması ne de uzlaşma aritmetiği, ücret değerlerinin negatif olmayan sayılar olmasını zorunlu kılmaktadır; dolayısıyla iki eksik kontrol birbirini pekiştirir: işaretli karşılaştırma negatif değerin içeri girmesine izin verirken, işaretli aritmetik bunu bir teminat kredisine dönüştürür.

Saldırı Analizi

Aşağıdaki analiz, 4pGQdf...wVD8 işlemine dayanmaktadır.

• Adım 1: Saldırgan, 100e6 USDC'yi 1227 ve 1228 numaralı iki yeni kalıcı hesaba böldü. Bu sayede hem yapıcı (hesap 1227) hem de alıcı (hesap 1228) rolünü üstlenebileceği yalıtılmış bağlamlar oluşturdu.

• Adım 2: Saldırgan, 100e6 USDC'yi 1227 numaralı hesaba teminat olarak yatırdı ve bir piyasa pozisyonu açarak yaklaşan alıcı emrine karşı taraf oluşturdu.

• Adım 3: Saldırgan bir entegratör kasası oluşturdu, ardından 1228 numaralı hesaba maxTakerFee = 0 ile bir yapılandırma ekledi. Üst sınırı sıfıra ayarlamak kritik öneme sahipti; zira bu, işaretli karşılaştırmanın taker_fee <= 0 koşulunu iki'nin tümleyeni kapsamında negatif görünen her değer için kabul etmesini sağladı.

• Adım 4: Saldırgan 1227 numaralı hesaptan bir oturum başlattı ve order_size = 100e6 ile bir limit emri vererek 1228 numaralı hesabın işlem yapacağı likiditeyi sağladı.

• Adım 5: Saldırgan create_integrator_info() fonksiyonunu işaretli ifixed anlambiliminde -100e6'yı temsil eden taker_fee = 2^256 - 100e6 değeriyle çağırdı. Fonksiyon herkese açık olduğundan ve herhangi bir doğrulama yapmadığından çağrı başarıyla tamamlandı.

• Adım 6: Saldırgan 1228 numaralı hesaptan kötü niyetli entegratör bilgilerini kullanarak bir piyasa emri gerçekleştirdi. İşaretli ücret karşılaştırması geçti (-100e6 <= 0) ve uzlaşma sırasında negatif ücret teminattan çıkarılarak 1228 numaralı hesaba 100e6 değerinde ücretsiz teminat eklendi.

• Adım 7: Saldırgan 1228 numaralı hesaptan şişirilmiş teminatı serbest bırakıp çekerek 79.610 USDC kazandı. Saldırgan bu düzeni birden fazla işlem boyunca tekrarlayarak toplamda yaklaşık 1,14 milyon dolar biriktirdi.

Sonuç

Bu olay, Aftermath Perpetuals'ın builder-ücret doğrulamasındaki işaretli/işaretsiz anlam uyumsuzluğundan kaynaklanmaktadır. Temel sorun, ücret karşılaştırma fonksiyonunun (ifixed::less_than_eq) işaretsiz ücret değerlerini işaretli anlambilim kapsamında yorumlamasıdır. Hiçbir sınır doğrulaması yapmayan, herkese açık bir ücret belirleme fonksiyonuyla birleştiğinde, bir saldırgan işaretli karşılaştırmayı "negatif" olarak geçen ve uzlaşma sırasında pozitif teminata dönüştürülen bir değer enjekte edebilmektedir.

Daha geniş örüntünün de göz önünde bulundurulması gerekmektedir: doğası gereği negatif olmayan değerleri (ücretler, fiyatlar, miktarlar) doğrulamak için işaretli sabit noktalı bir kütüphane kullanan her protokol, aynı saldırı sınıfına karşı savunmasızdır. Önlemler şunları içermelidir: (1) herhangi bir karşılaştırmadan önce ücret değerlerinin negatif olmadığının zorunlu kılınması (assert!(taker_fee >= 0)), (2) create_integrator_info() fonksiyonunun yalnızca yetkili çağırıcılarla sınırlandırılması ve (3) anlam olarak işaretsiz olan değerler için işaretsiz karşılaştırma fonksiyonlarının kullanılması.

Kaynaklar

• [1] Aftermath Finance Olay Sonrası Açıklaması
• [2] Aftermath Perpetuals Belgeleri
• [3] Builder Kodları / Ön Uç Ücreti

Bu Dönemdeki Diğer Olaylar

Trusted Volumes

7 Mayıs 2026'da Ethereum üzerindeki özel bir RFQ (Fiyat Teklifi Talebi) proxy sözleşmesi istismar edilerek piyasa yapıcısı TrustedVolumes'dan yaklaşık 5,87 milyon dolar boşaltıldı. Temel neden, RFQ uygulama sözleşmesinin emir doldurma fonksiyonundaki bir yetkilendirme uyumsuzluğuydu: imzalayıcı izin sorgusu ve token transfer işlemi emrin farklı alanlarına başvurduğundan, yetkilendirme kontrolü bir adres için geçilirken fonlar başka bir adresten çekildi. Saldırgan yaklaşık 1.291 WETH, 206 bin USDT, 16,94 WBTC ve 1,27 milyon USDC boşalttı.

Arka Plan

TrustedVolumes, Ethereum üzerinde konuşlandırılmış RFQ protokolünde piyasa yapıcısı olarak faaliyet göstermektedir. Piyasa yapıcıları sürekli olarak zincir dışında imzalı fiyat teklifleri üretir; alıcılar (genellikle yatırımcılar veya toplayıcı yönlendiriciler) seçtikleri bir teklifi zincir üzerinde sunar ve protokol sözleşmesi imzayı doğrulayarak maker ile taker arasında transferFrom aracılığıyla token transferini atomik olarak gerçekleştirir. Protokol, kasa bulundurmayan bir tasarım izler: fon saklamaz. Her piyasa yapıcı, teklif vermeyi planladığı her token için protokol sözleşmesine önceden ERC-20 harcama izni verir ve protokol, doldurma sırasında token'ları doğrudan piyasa yapıcının cüzdanından çeker.

Piyasa yapıcıların imzalama işlemini sıcak bir cüzdana devretmesine olanak tanımak amacıyla protokol sözleşmesi, piyasa yapıcı başına bir imzalayıcı kaydı tutar. Piyasa yapıcı, sıcak bir anahtarı beyaz listeye almak için registerAllowedOrderSigner(signer, allowed) fonksiyonunu çağırabilir; bu anahtarla imzalanan sonraki emirler, piyasa yapıcı tarafından imzalanmış gibi kabul edilir.

Güvenlik Açığı Analizi

RFQ proxy sözleşmesi 0xeEeEEe...051756 adresinde, uygulama sözleşmesi ise 0x88eb28...2760d8 adresinde konuşlandırılmıştır.

RFQ uygulama sözleşmesindeki 0x4112e1c2() emir doldurma fonksiyonu, ecrecover() aracılığıyla imzalayıcıyı kurtarır ve imzayı kabul edip etmeyeceğine karar vermek için allowedOrderSigner eşlemesini kontrol eder. Bu kontrolün arama anahtarı varg4, yani emrin alıcı tarafı adresidir. Ancak fonları borçlandıran sonraki transferFrom işlemi varg5, yani emrin maker alanını kullanmaktadır. varg4 ve varg5, emir yapısının bağımsız alanları olduğundan, yetkilendirme kontrolü ve fon akışı işlemi farklı taraflara başvurmaktadır. Yetkili imzalayıcı etki alanının, token'ların gerçekte çekildiği adresle eşleşmesini zorunlu kılan herhangi bir kontrol bulunmamaktadır.

registerAllowedOrderSigner fonksiyonu beyaz listeyi dış anahtar olarak msg.sender ile yazarken, doldurma yolu dış anahtar olarak varg4'ü okumaktadır. varg4'teki çağırıcı daha önce registerAllowedOrderSigner aracılığıyla kendini kaydettiği sürece, varg5'te hangi üçüncü taraf piyasa yapıcı adresi görünürse görünsün yetkilendirme kontrolü başarılı olacaktır.

Saldırı Analizi

Aşağıdaki analiz, 0xc5c61b...990513 işlemine dayanmaktadır.

• Adım 1: Saldırgan bir saldırı sözleşmesi konuşlandırdı ve bu sözleşme aracılığıyla registerAllowedOrderSigner fonksiyonunu çağırarak saldırgan EOA'yı izin verilen imzalayıcı beyaz listesine kaydetti. Bu sayede saldırgan tarafından imzalanan emirlerin protokolün imzalayıcı yetkilendirme kontrolünden geçmesi sağlandı.

• Adım 2: Saldırı sözleşmesi, saldırgan EOA'dan 4 wei USDC çekti ve RFQ protokolüne 4 wei harcama izni vererek saldırı sözleşmesini alıcı rolünü üstlenmek için gereken asgari karşılıkla donattı.

• Adım 3: Saldırgan, her biri saldırgan EOA tarafından imzalanmış ve TrustedVolumes'u maker olarak belirten dört sahte emir oluşturdu. İmzalayıcı kontrolü varg4'ü (saldırganın sözleşmesi) sorgularken transferFrom işlemi varg5'ten (TrustedVolumes) borçlandırma yaptığından, her emir TrustedVolumes'dan fon boşalttı. Dört emir sırasıyla 1 wei USDC karşılığında 1.291 WETH, 206.282 USDT, 16,939 WBTC ve 1.268.771 USDC takasladı; bu işlemler toplamda yaklaşık 5,87 milyon dolar kâr sağladı.

Sonuç

Temel kusur, emir doldurma fonksiyonundaki yetkilendirme uyumsuzluğudur: imzalayıcı izin kontrolü için kullanılan adres, gerçekte ödeme yapan adresten farklıdır. Daha ayrıntılı belirtmek gerekirse, registerAllowedOrderSigner beyaz listeyi msg.sender altına yazarken, doldurma yolu alıcı alanını (varg4) dış anahtar olarak okur ve transferFrom maker alanından (varg5) borçlandırma yapar. Bu üç işlem farklı taraflara başvurduğundan, kendi imzalayıcısını kaydettiren herhangi bir saldırgan üçüncü taraf piyasa yapıcıları boşaltan sahte emirler oluşturabilmektedir. Varlık hareketini kontrol eden yetkilendirme kontrollerinin, gerçekte ödeme yapacak adresle ilişkilendirilmesi ve yazma ile okuma yollarının aynı anahtarı kullanması gerekmektedir.

Wasabi Protocol

30 Nisan 2026'da birden fazla EVM zincirinde konuşlandırılmış bir opsiyon ve kalıcı vadeli işlem protokolü olan Wasabi Protocol, yaklaşık 5,7 milyon dolar kayıpla (4,8 milyon dolar kullanıcı fonu, 900 bin dolar Wasabi hazinesi) sonuçlanan bir güvenlik olayına maruz kaldı [1][2]. Saldırı bir altyapı ele geçirmesinden kaynaklandı: kamuya açık bir sunucudaki analytics uç noktasının açıkta kalması, sonunda protokolün EVM akıllı sözleşmelerini kontrol eden özel anahtarların çalınmasına yol açan kimlik bilgilerinin sızdırılmasına neden oldu. Saldırgan bu anahtarları kullanarak Ethereum, Base, Blast ve Berachain üzerindeki birden fazla Wasabi kasasından yetkisiz para çekme işlemleri gerçekleştirdi.

Arka Plan

Wasabi Protocol, EVM zincirleri (Ethereum, Base, Blast, Berachain) ve Solana üzerinde konuşlandırmalar yürütmektedir. Bu olay protokolün yalnızca EVM tarafını etkiledi; Solana konuşlandırmaları ve Prop AMM etkilenmedi.

Wasabi'nin EVM sözleşmeleri (WasabiLongPool, WasabiShortPool, WasabiVault), ayrıcalıklı anahtarlar aracılığıyla yönetilmektedir. Protokol aynı zamanda Spring Boot üzerine inşa edilmiş analitik ve izleme hizmetleri de dahil olmak üzere zincir dışı altyapı da işletmektedir.

Saldırı Analizi

Olay, altyapıdan sözleşme kontrolüne uzanan bir ele geçirme zincirini izledi:

• Adım 1: Saldırgan, kamuya açık bir Wasabi sunucusunda Spring Boot Actuator'ın yüklü olduğunu keşfetti. Actuator heap dump'ları normalde parola korumalıdır; ancak bu sunucu, standart parola koruma mekanizmasıyla uyumsuz farklı bir Spring framework varyantı kullandığından heap dump uç noktası açıkta kaldı.

• Adım 2: Saldırgan, ayrı bir iç sunucunun kimlik bilgilerini içeren heap dump'ı elde etti.

• Adım 3: Saldırgan sızdırılan kimlik bilgilerini kullanarak iç sunucuya geçiş yaptı ve Wasabi'nin EVM akıllı sözleşmelerini kontrol eden özel anahtarları ele geçirdi.

• Adım 4: Ayrıcalıklı anahtarlara sahip olan saldırgan, Ethereum, Base, Blast ve Berachain üzerindeki WasabiLongPool, WasabiShortPool ve WasabiVault sözleşmelerine karşı yetkisiz para çekme akışları gerçekleştirerek toplamda yaklaşık 5,7 milyon dolar boşalttı.

Sonuç

Bu olay, akıllı sözleşme güvenliğinin kod düzeyinde sona ermediğini göstermektedir. İstismar herhangi bir zincir üstü güvenlik açığı gerektirmedi; saldırgan kontrolü tamamen altyapı açığı yoluyla ele geçirdi. Temel çıkarımlar şunlardır: (1) hata ayıklama ve analitik arayüzler (heap dump'lar, profilleme uç noktaları, günlük dışa aktarıcılar) hiçbir zaman kamuya açık altyapıda erişilebilir olmamalıdır, (2) üretim sistemlerine ait kimlik bilgileri analiz ve izleme ortamlarından kesinlikle ayrı tutulmalıdır ve (3) akıllı sözleşme yönetim anahtarları; çoklu imza gözetimi, donanım destekli imzalama, rol ayrımı, gerçek zamanlı izleme ve acil durum durdurma prosedürleri de dahil olmak üzere derinlemesine savunma kontrolleriyle korunmalıdır.

Kaynaklar

• [1] BlockSec Phalcon Uyarısı
• [2] Wasabi Protocol Olay Sonrası Açıklaması

BlockSec Hakkında

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

BlockSec, prestijli konferanslarda birden fazla blok zinciri güvenliği makalesi yayımlamış, çeşitli DeFi uygulamalarının sıfır gün saldırılarını raporlamış, 20 milyon dolardan fazlasını kurtarmak için birden fazla hack girişimini engellemiş ve milyarlarca dolarlık kripto parayı güvence altına almıştır.

• Resmi web sitesi: https://blocksec.com/

• Resmi Twitter hesabı: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Denetim Hizmeti : Talep gönderin

• 🔗 Phalcon Security Uygulaması: Demo rezervasyonu yapın

• 🔗 Phalcon Uyumluluk