Geçen hafta (2026/05/25 - 2026/05/31), BlockSec birçok blokzincir ekosisteminde çeşitli saldırı olayları tespit etti. Aşağıdaki tablo, toplam tahmini kaybı yaklaşık 16 milyon dolar olan 5 önemli olayı listelemektedir.
| Tarih | Olay | Tür | Tahmini Kayıp |
|---|---|---|---|
| 2026/05/27 | SquidRouterModule | Hatalı Girdi Doğrulaması | ~$3,2M |
| 2026/05/29 | Stake DAO | Ele Geçirilmiş Özel Anahtar | ~$91K* |
| 2026/05/29 | DxSale | Yanlış İş Mantığı ve Anahtar Ele Geçirme | ~$7,3M |
| 2026/05/30 | Gravity Bridge | Zafiyetli Zincir Dışı İmzalama Süreci | ~$5,4M |
| 2026/05/30 | Alephium | Zafiyetli Zincir Dışı İmzalama Süreci | ~$300K* |
*Ek notlar:
- Stake DAO olayında, saldırgan dağıtıcının özel anahtarını ele geçirerek Arbitrum'daki
vsdCRVsözleşmesinde LayerZero v2 OFT eşini yeniden yapılandırdı ve 5,4 trilyonvsdCRVbasılmasını sağladı. Sınırlı DEX likiditesi nedeniyle, havuzlar kurumadan önce yalnızca yaklaşık 91.000 dolar nakde çevrilebildi. - Alephium olayında, Ethereum'daki
USDT,USDC,WETH,WBTCve BNB Chain'dekiUSDT,WBNBolmak üzere yaklaşık 300.000 dolarlık köprü emanet varlıklarının boşaltılmasının ötesinde, saldırgan Ethereum'da 13,7 milyon adet karşılıksızwALPHda bastı. Köprü kapatıldı ve bu sayede saldırganın söz konusu token'ları Alephium köprüsü aracılığıyla kullanması veya geri köprülemesi engellendi.
Derinlemesine analiz için iki olay seçildi:
- SquidRouterModule: CrossCurveFi açığına çok benzer şekilde, aynı entegrasyon hatasını tekrarladı; bu durum, derin bir anlayış ve titiz bir güvenlik incelemesi olmadan zincirler arası mantığın çatallanmasının, miras alınan karmaşıklığı miras alınan riske ne kadar çabuk dönüştürebileceğini göstermektedir.
- DxSale: Uzun saldırı zaman çizelgesi, istismar edilmemiş eski sözleşmelerin mutlaka güvenli olmadığını ve protokollerin zincir içi ve zincir dışı faaliyetleri sürekli izlemesi, ayrıcalıklı erişimi en aza indirmesi ve yıllarca süren sessizliği güvenliğin kanıtı olarak asla yorumlamaması gerektiğini göstermektedir.
Web3 İçin En İyi Güvenlik Denetçisi
Lansmandan önce tasarımı, kodu ve iş mantığını doğrulayın
Haftanın Öne Çıkanı: DxSale
Bu olay, yıllarca yamalanmamış kilit sözleşmesi ile ele geçirilmiş dağıtıcı anahtarının birleşiminin tekrarlayan bir örüntüyü gözler önüne sermesi nedeniyle haftanın öne çıkanı olarak seçildi: dağıtım zamanı koduna sürekli denetim veya ayrıcalık rotasyonu olmaksızın kalıcı biçimde güvenli gözüyle bakan protokoller, her an silah olarak kullanılabilecek gizli riskler taşımaktadır.
29 Mayıs 2026'da, BNB Chain üzerinde bir token satış ve likidite kilitleme platformu olan DxSale, yaklaşık 7,3 milyon dolar [1] zarara uğratıldı. Token çekme fonksiyonu, herhangi bir kullanıcının geçerli bir kilit pozisyonuyla tekrar tekrar çekim yapmasına ve tüm ortak havuzu boşaltmasına izin veren üç eksik durum güncellemesi içeriyordu; bunun için herhangi bir sahip ayrıcalığı gerekmiyordu. DxSale dağıtıcı anahtarının EIP-7702 delegasyonu yoluyla ayrıca ele geçirilmesi, istismar için bir ön koşul değildi; ancak saldırganın ücret manipülasyonu yapmasına ve diğer kullanıcıların yeni kilit oluşturmasını engellemesine olanak tanıyarak verimliliğini artırdı.
Arka Plan
DxSale, BNB Chain üzerinde bir token satış ve likidite kilitleme platformudur. DxLock bileşeni, proje geliştiricilerinin LP token'larını zaman kilitli kasalara kilitlemesine olanak tanıyarak yatırımcılara likiditenin çekilemeyeceğine dair güvence sağlar.
Temel kilitleme mekanizması şu şekilde işler: bir kullanıcı token'ları kilit sözleşmesine yatırarak, çağrıcının adresi ile bir token kimliğinin kombinasyonuyla dizinlenen bir kilit kaydı oluşturur. Her kayıt; kilit kaydının var olup olmadığını, token'ların şu anda kilitli olup olmadığını, kilitli miktarı, kilit açma zaman damgasını ve token adresini saklar. Kilit süresi sona erdiğinde, kullanıcı token'larını çekmek için unlockToken(tokenId) fonksiyonunu çağırır.
Kilit sözleşmesi, ortak bir bakiyede aynı anda birçok kullanıcının token'larını tuttuğundan, bireysel tahsisatların ayrı kilit kayıtları aracılığıyla doğru biçimde takip edilmesi gerekir. Tüm havuzun güvenliği, her çekimin çağrıcının kendi kaydını doğru şekilde doğrulamasına ve transferin ardından güncellenmesine bağlıdır.
Güvenlik Açığı Analizi
Hatalı sözleşmedeki (0xeb3a...e449) unlockToken fonksiyonu, birbirini pekiştiren üç eksiklik içeriyordu; bunların her biri eksik bir durum güncellemesi veya kontrolüydü:
function unlockToken(uint256 tokenId) public nonPayable {
require(_increaseLockTime[msg.sender][tokenId].field0_0_0); // kilit mevcut
require(_increaseLockTime[msg.sender][tokenId].field0_1_1); // token'lar kilitli
require(_increaseLockTime[msg.sender][tokenId].field2); // miktar > 0
if (block.timestamp > _increaseLockTime[msg.sender][tokenId].field3) {
_increaseLockTime[msg.sender][tokenId].field0_1_1 = 0;
}
v0, v1 = _increaseLockTime[msg.sender][tokenId].field5_0_19.balanceOf(this);
require(v1 >= _increaseLockTime[msg.sender][tokenId].field2);
v2, v3 = _increaseLockTime[msg.sender][tokenId].field5_0_19.transfer(
msg.sender, _increaseLockTime[msg.sender][tokenId].field2
);
}
-
Kilit süresi zorlaması yok. Kilit süresi,
requireyerine birififadesiyle korunuyordu. Kilit açma zaman damgasından önce çağrıldığında, fonksiyon geri döndürmek yerine kilitli bayrağı temizlemeyi atlıyordu. Bu, kilit süresinden bağımsız olarak token'ların her zaman çekilebileceği anlamına geliyordu. -
Kilitli miktar hiçbir zaman sıfırlanmıyor. Token'ları çağrıcıya transfer ettikten sonra, fonksiyon
field2'yi (kilitli miktar) sıfırlamıyordu. Her sonraki çağrı aynı orijinal değeri okuyor ve aynı miktarı tekrar çekiyordu; bu da sonsuz bir çekim döngüsü oluşturuyordu. -
Bireysel tahsisat yerine ortak bakiye kontrolü.
balanceOf(this)çağrısı, çağrıcının bireysel tahsisatı yerine sözleşmenin toplam token bakiyesini doğruluyordu. Küçük bir kilit pozisyonuna sahip bir çağrıcı, sözleşme yeterli toplam token tuttuğu sürece tüm ortak havuzu boşaltabiliyordu.
Bu üç eksik durum güncellemesi bir arada, fonksiyondan her çıkış koşulunu kaldırdı: çağrı hiçbir zaman erken geri dönmedi, çekilen miktar hiçbir zaman azalmadı ve bakiye kontrolü sözleşme tamamen boşalana kadar hiçbir zaman engel olmadı. Açık, kilit pozisyonu oluşturan herhangi bir kullanıcı tarafından istismar edilebilirdi; temel boşaltma için herhangi bir sahip ayrıcalığı gerekmiyordu.
Saldırı Analizi
EIP-7702 delegasyonu aracılığıyla işlem yapan DxSale dağıtıcı hesabı (0x47bacf93), 2026-04-15'ten itibaren toplu sahiplik transferleri, ücret değişiklikleri ve birden fazla DxSale sözleşmesinde LP kilit açma işlemleri dahil anormal faaliyetler sergiledi. 2026-05-26'da dağıtıcı, kurban kilit sözleşmesinin (0xeb3a...e449) sahipliğini saldırgan sözleşmesine (0xc457...fa69) devretti. İki gün sonra saldırgan beş adımlı bir boşaltma gerçekleştirdi.
Aşağıdaki analiz, temsili bir işlem olan 0x437b26...c1b303 esas alınarak hazırlanmıştır.
-
Adım 1: Saldırgan, PancakeSwap'te
BNB'yiBNBCtoken'larıyla takas etti ve yeni birCake-LP (BNBC/WBNB)çifti oluşturmak için likidite sağladı; karşılığında yaklaşık 0,323 LP token aldı. -
Adım 2: Önceki sahiplik devri yoluyla elde edilen sahip ayrıcalıklarını kullanarak saldırgan, kilit oluşturma ücretini 1 wei'ye ayarlamak için
changeFees(1)fonksiyonunu çağırdı, ardından yaklaşık 0,323 LP token'ı yeni bir kilit pozisyonuna (tokenId=131) yatırmak içincreateLockerfonksiyonunu çağırdı. Hemen ardından saldırgan, ücreti astronomik bir değere yükseltmek ve diğer kullanıcıların yeni kilit oluşturmasını engellemek içinchangeFees(10^36)fonksiyonunu çağırdı. -
Adım 3: Saldırgan, istismar fonksiyonunu (
0x11b432b4) çağırdı; bu fonksiyon tek bir işlemde tekrarlananunlockTokençağrılarını düzenledi. Birden fazla işlem boyunca saldırgan, kilit sözleşmesini sistematik biçimde boşalttı: 0x437b26...c1b303, tokenId=131 aracılığıyla 161,4 LP token boşalttı; 0x82f541...a9fa73 ve 0x5dd61f...4298aa ek kilit pozisyonlarını boşalttı; 0xac8f5e...d36df9 ise 478 çağrı boyunca tokenId=319 aracılığıyla 260,3 LP token boşalttı. -
Adım 4: Saldırgan, boşaltılan LP token'larını temel token'larına (
BNBCveWBNB) dönüştürmek için PancakeSwap'teremoveLiquidityfonksiyonunu çağırdı. -
Adım 5: Saldırgan, temel token'ları PancakeSwap aracılığıyla
WBNBveBUSDile takas etti ve gelirleri harici adreslere aktardı. BSCScan, bu saldırgan sözleşmesi için 4 gün (2026-05-28 ile 05-31 arası) içinde 123.447 işlem kaydetti.
Sonuç
Bu olayın temel nedeni, unlockToken fonksiyonundaki üç eksik durum güncellemesidir. Her birinin doğrudan bir çözümü vardır: kilit süresini if yerine require ile zorlamak, her çekimden sonra kilitli miktarı sıfırlamak ve sözleşmenin toplam bakiyesi yerine çağrıcının bireysel tahsisatını kontrol etmek. Bu eksiklikler tek başına istismara yeterliydi; kilit pozisyonu oluşturan herhangi bir kullanıcı, herhangi bir sahip ayrıcalığı olmaksızın tekrarlanan çağrılarla tüm ortak havuzu boşaltabiliyordu.
DxSale dağıtıcısının EIP-7702 delegasyonu yoluyla önceden ele geçirilmesi, istismar için bir ön koşul değildi; ancak saldırganın verimliliğini artırdı. Sahipliği devrederek ve ücretleri manipüle ederek saldırgan, neredeyse sıfır maliyetli kilit pozisyonları oluşturdu ve meşru kullanıcıların rakip kilit oluşturmasını engelledi. Operasyonel açıdan protokoller, özellikle kullanıcı fonlarını tutanlar olmak üzere eski sözleşmeleri sürekli denetlemeli ve yönetici işlevlerinin tek anahtarlı gözetiminden kaçınmalıdır. Yıllarca sorunsuz çalışma, denetlenmemiş kodun güvenliğini doğrulamaz.
Kaynaklar
- [1] DxSale duyurusu
Phalcon Explorer ile Başlayın
Akıllıca Hareket Etmek İçin İşlemleri Derinlemesine İnceleyin
Şimdi ücretsiz deneyinBu Haftaki Diğer Olaylar
SquidRouterModule
27 Mayıs 2026'da, SquidRouterModule adlı bilinmeyen bir sözleşme, hatalı girdi doğrulaması nedeniyle Ethereum'da istismar edilerek [1] yaklaşık 3,2 milyon dolar kayba yol açtı. Temel neden, daha önceki CrossCurveFi saldırı örüntüsüne [2] benzer şekilde Axelar Bridge entegrasyonunun yanlış kullanılmasıydı. Sözleşme, Axelar Gateway üzerinden gelen zincirler arası mesajları gereği gibi doğrulamadı; bu da saldırganın kurbanların token'larını önceden oluşturulmuş kötü amaçlı havuzlara yetkilendiren ve takas eden sahte yükler oluşturmasına olanak tanıdı. Sahte token'ı dağıtan ve havuzlara likidite sağlayan ayrı bir saldırgan adresi daha sonra gerçek varlıkları çıkarmak için likiditeyi kaldırdı. Bu saldırı 86 Safe cüzdanını etkiledi. Adına karşın, SquidRouterModule, Squid protokol ekibi tarafından inşa edilmedi, dağıtılmadı veya işletilmedi [3].
Arka Plan
Sözleşme, Axelar zincirler arası protokolü üzerine inşa edilmiş, Safe cüzdanı için tasarlanmış bir zincirler arası takas hizmeti modülüdür. Sözleşme, zincirler arası mesaj onayından önce işlemlerin erken yürütülmesini destekleyen expressExecuteWithToken fonksiyonunu sağlar. Kullanıcıların bu hizmeti kullanabilmek için Safe cüzdanlarında sözleşmenin APPROVE ve SWAP izinlerini önceden yetkilendirmeleri gerekir. expressExecuteWithToken çağrıldığında, sözleşme yükteki işlem talimatlarını çözer ve token yetkilendirme ile takas işlemlerini gerçekleştirmek için Safe cüzdanının execTransactionFromModule fonksiyonunu çağırır.
Güvenlik Açığı Analizi
Zafiyetli sözleşmedeki (0x1f1d...23ca) _executeWithToken fonksiyonu yalnızca srcAddress'in squidRouter sabitiyle eşit olup olmadığını kontrol ediyordu. Ancak srcAddress çağrıcı tarafından sağlanan bir parametre iken, squidRouter herkesin sözleşmeden okuyabileceği değişmez bir dizedir. Bu durum, saldırganın kontrolü kolayca atlamasına ve rastgele yük içeriğiyle _processPayload fonksiyonunu yürütmesine olanak tanıdı.

Buna karşın, meşru Squid Router'ın executeWithToken fonksiyonu gateway.validateContractCallAndMint() fonksiyonunu çağırır ve Axelar doğrulayıcı ağı işlemi onaylamamışsa NotApprovedByGateway() hatasıyla geri döner.

Zafiyetli sözleşme, expressExecuteWithToken yolunda bu tür bir ağ geçidi yetkilendirmesini zorlamıyordu. Safe cüzdanı kullanıcılarının modüle önceden verdiği APPROVE ve SWAP izinleriyle birleşince, sahte yükler kurbanların fonları üzerinde doğrudan işlem yapabildi.
Saldırı Analizi
Aşağıdaki analiz, 0xd29d1c...3bb854 işlemi esas alınarak hazırlanmıştır.
Saldırıdan önce, ayrı bir saldırgan adresi sahte bir token (
0xe6Ff...3512) dağıttı ve her biri sahte token'ı farklı bir değerli token'a (ör.USDC,ENA,USDT) karşı eşleştiren birden fazla Uniswap V3 havuzu oluşturarak havuzları sahte token likiditesiyle besledi.
-
Adım 1: Saldırgan, kötü amaçlı çağrı verisi oluşturarak zafiyetli sözleşmenin
expressExecuteWithTokenfonksiyonunu çağırdı; doğrulama kontrolünü atlamak için bilinensquidRouteradresinisourceAddressolarak kullandı. Kurbanın modüle önceden verdiği APPROVE ve SWAP izinleri aracılığıyla, sahte yük kurbanın Safe cüzdanından Uniswap havuzuna zorla token onayı yaptırdı. -
Adım 2: Bu zorla onayları kullanarak, yük kurbanın token'larını ilgili kötü amaçlı havuz aracılığıyla değersiz sahte token ile takas etti.
Saldırgan bu yöntemi birden fazla işlem boyunca tekrarlayarak, zafiyetli sözleşmeyi yetkilendirmiş toplam 86 Safe cüzdanını hedef aldı. Sahte token'ı dağıtan ve havuzları besleyen ayrı saldırgan adresi daha sonra gerçek varlıkları çıkarmak için likiditeyi kaldırdı ve nihayetinde yaklaşık 3,2 milyon dolar kâr elde etti.
Sonuç
Bu olay, zincirler arası mesaj işleme yolundaki hatalı girdi doğrulamasından kaynaklandı. Tek güvenlik kontrolü, kamuya açık okunabilir bir sabitle karşılaştırılan, çağrıcı tarafından kontrol edilebilen bir parametreye dayanıyordu ve gerçek bir koruma sağlamıyordu. Safe cüzdanı kullanıcılarının önceden verdiği APPROVE ve SWAP izinleriyle birleşince, saldırgan zincirler arası mesajlar sahtekârlıkla oluşturarak kullanıcı fonlarını çalabildi.
Bu olay, CrossCurveFi açığına [2] benzerlik göstermektedir: her ikisi de gelen zincirler arası mesajları gereği gibi doğrulamayan Axelar Bridge entegrasyonlarını kapsamaktadır. Zincirler arası mesajlaşma altyapısını entegre ederken, hedef sözleşme mesajın özgünlüğünü köprünün yetkilendirme mekanizması aracılığıyla bağımsız olarak doğrulamalıdır. Bu doğrulamanın atlanması ve saldırgan tarafından kontrol edilebilen girdilere güvenilmesi, entegrasyonu açık bir saldırı yüzeyine dönüştürür.
Kaynaklar
- [1] Phalcon Uyarısı: SquidRouterModule açığı
- [2] Phalcon Uyarısı: CrossCurveFi saldırı örüntüsü
- [3] Squid Router açıklaması
BlockSec Hakkında
BlockSec, tam kapsamlı bir blokzincir güvenliği ve kripto uyum sağlayıcısıdır. Müşterilerin kod denetimi (akıllı sözleşmeler, blokzincir ve cüzdanlar dahil) gerçekleştirmesine, saldırıları gerçek zamanlı olarak engellenmesine, olayları analiz etmesine, yasadışı fonları takip etmesine ve protokollerle platformların tam 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 blokzincir güvenliği makalesi yayımlamış, DeFi uygulamalarının çeşitli sıfırıncı gün saldırılarını raporlamış, 20 milyonun üzerinde doları kurtarmak için birden fazla hack girişimini engellemiş ve milyarlarca dolarlık kripto para biriminin güvenliğini sağlamıştır.
-
Resmi web sitesi: https://blocksec.com/
-
Resmi Twitter hesabı: https://twitter.com/BlockSecTeam



