Haftalık Web3 Güvenlik Olayları Özeti | 2 Şubat – 8 Şubat 2026

Geçen hafta (2 Şubat–8 Şubat 2026) BlockSec, toplam tahmini kaybı yaklaşık 3,8 milyon dolar olan altı saldırı olayını tespit edip analiz etti. Aşağıdaki tablo bu olayları özetlemekte olup her bir olaya ait ayrıntılı analizler izleyen alt bölümlerde sunulmaktadır.

1. CrossCurve Olayı

Kısa Özet

2 Şubat 2026'da CrossCurve protokolü istismar edildi ve yaklaşık 2,8 milyon dolar kayıp yaşandı. Temel neden, ReceiverAxelar sözleşmesinin izinsiz çağrılabilir bir expressExecute() fonksiyonu açığa çıkarmasıydı; bu fonksiyon standart Axelar Gateway doğrulama sürecini atlıyordu. Alıcı yalnızca dışarıdan sağlanan verilere dayalı eş adres kontrolleri gerçekleştiriyordu. Sonuç olarak saldırgan, yakma ve kilit açma mekanizmasını tetiklemek için kötü amaçlı bir zincirler arası çağrı oluşturdu ve bu durum saldırgana 999.787.453e18 EYWA tokeninin yetkisiz olarak serbest bırakılmasına yol açtı.

Arka Plan

CrossCurve, Axelar zincirler arası mesajlaşma çerçevesi üzerine inşa edilmiş, Eywa.Fi tarafından geliştirilen bir zincirler arası köprü protokolüdür.

Axelar'ın amaçlanan güvenlik modelinde, zincirler arası mesajlar Axelar Gateway tarafından iletilir ve hedef zincirde validateContractCall() aracılığıyla açıkça doğrulanmak zorundadır. Yalnızca Gateway tarafından kriptografik olarak onaylanmış mesajların yürütmeye geçmesine izin verilir.

Gecikmeyi azaltmak amacıyla Axelar, bir alıcı sözleşmenin Gateway doğrulamayı tamamlamadan önce bir mesajı iyimser biçimde yürütebildiği bir hızlı yürütme mekanizması da sunmaktadır. Bu tasarım, yalnızca güvenilir yürütücülerin hızlı yürütme yollarını çağırabilmesini sağlamak için katı erişim kontrolü gerektirmektedir; aksi takdirde doğrulanmamış zincirler arası mesajlar erken işlenebilir.

Güvenlik Açığı Analizi

Temel neden, ReceiverAxelar'ın Axelar Gateway yetkisi olmadan doğrudan ayrıcalıklı _execute() yoluna ulaşabilen izinsiz bir expressExecute() fonksiyonu açığa çıkarmasıydı.

Axelar'ın doğru güvenlik modelinde, zincirler arası mesajların önce kanıt destekli yürütme yoluyla Gateway tarafından onaylanması ve ardından hedef zincirde validateContractCall() aracılığıyla doğrulanması gerekir; bu fonksiyon (commandId, sourceChain, sourceAddress, contractAddress, payloadHash) değerlerini tek bir yetkili yürütmeye bağlar.

Ancak expressExecute() yolu bu doğrulamayı tamamen atlıyordu. Yalnızca saldırgan kontrolündeki sourceChain ve sourceAddress kullanılarak bir eş kontrolüne dayanıyordu ve bu nedenle gerçek bir güvenlik sağlamıyordu. Bu durum, saldırganın sahte bir mesaj sağlamasına, receiveData dalını zorlamasına ve nihayetinde Eywa CLP Portal üzerinde unlock() fonksiyonunu tetikleyen keyfi bir yük yürütmesine olanak tanıdı; bu da zincirler arası varlıkların yetkisiz olarak serbest bırakılmasıyla sonuçlandı.

Saldırı Analizi

• Adım 1: Saldırgan, sourceChain, sourceAddress ve payload değerlerini taklit ederek doğrudan expressExecute() fonksiyonunu çağırdı. expressExecute(), Gateway doğrulamasını atlayarak doğrudan _execute() fonksiyonuna geçtiğinden, geriye kalan tek güvenlik önlemi bir eş adres beyaz liste kontrolüydü: require(peers[sourceChain] == sourceAddress.toAddress()). Bu kontrol yetersizdi çünkü hem sourceChain hem de sourceAddress dışarıdan sağlanmaktaydı. Saldırgan, doğru beyaz listedeki eş adresini girerek bu kontrolü aştı.

• Adım 2: Sahte payload daha sonra Receiver.receiveData() dalına iletildi. resume() fonksiyonu, kötü amaçlı yüke dayanarak PortalV2.unlock() zincirler arası işlemini yürüttü ve bu durum fonların saldırgana yetkisiz biçimde kilidinin açılmasıyla sonuçlandı.

Sonuç

Bu olay, temel olarak bir zincirler arası alıcı sözleşmesi içindeki hızlandırılmış yürütme yolunda yetersiz erişim kontrolünden kaynaklandı. expressExecute() fonksiyonunu izinsiz çağrılabilir bir fonksiyon olarak açığa çıkararak ve yalnızca dışarıdan sağlanan eş bilgisine dayanarak CrossCurve, saldırganlara Axelar Gateway'in güvenlik garantilerini atlatarak keyfi zincirler arası yükler yürütme imkânı tanıdı.

Gelecekte benzer riskleri azaltmak için hızlı veya iyimser yürütme mekanizmalarını entegre eden zincirler arası protokoller şunları yapmalıdır:

• Hızlı yol yürütme fonksiyonlarında katı çağrı kimlik doğrulaması uygulamalı, yalnızca güvenilir aktarıcıların veya ağ geçitlerinin bunları çağırabilmesini sağlamalıdır.

• Yetkilendirme için tek dayanak olarak saldırgan kontrollü meta verilere (kaynak zincir veya adres gibi) güvenmekten kaçınmalıdır.

• Hızlı yürütmeyi ayrıcalıklı bir işlem olarak değerlendirmeli ve standart doğrulanmış yürütme yollarına eşdeğer derinlemesine savunma kontrolleri uygulamalıdır.

Bu ilkelere dikkatli bir şekilde uymak, tek bir doğrulama atlamasının birden fazla ağda sistemik varlık kaybına yol açabileceği zincirler arası sistemlerin tasarımında kritik önem taşımaktadır.

2. GYD Olayı

Kısa Özet

3 Şubat 2026'da GYD Protokolü istismar edildi ve yaklaşık 700 bin dolar kayıp yaşandı. Temel neden, CCIP alıcısının saldırgan kontrollü mesaj verilerini yürütme bağlamı olarak güvenilir kabul etmesiydi. İstismar, mesajlaşma katmanında doğru biçimde kimlik doğrulaması yapılmış ancak kodu çözülmüş yükü daha sonra _ccipReceive() içinde keyfi harici çağrılar yapmak için kullanılan Arbitrum'dan gönderilen bir CCIP mesajıyla tetiklendi. Saldırgan, kodu çözülmüş alıcıyı GYD token sözleşmesine ayarlayıp approve(attacker, type(uint256).max) için çağrı verisi sağlayarak emanet sözleşmesinin GYD bakiyesi üzerinde sınırsız onay vermesini istemeden sağladı. Ardından saldırgan transferFrom() aracılığıyla fonları boşalttı.

Arka Plan

GydL1CCipEscrow sözleşmesi, Chainlink CCIP standardı üzerine inşa edilmiş bir zincirler arası varlık emanet sözleşmesidir. Kullanıcılar L1'de bu sözleşmeye GYD tokeni kilitler; sözleşme daha sonra CCIP aracılığıyla hedef zincire bir zincirler arası mesaj gönderir. Tersine, emanet sözleşmesine bir zincirler arası mesaj ulaştığında, CCIP özgünlüğünü doğrular ve _ccipReceive() fonksiyonunu tetikler. Bu fonksiyon, tx.recipient ve data değerlerini çıkarmak için gelen çağrı verisini ayrıştırır, ayrıştırılan parametrelere (miktar ve alıcı) göre GYD transferi veya kilit açma mantığını yürütür ve data boş değilse recipient.functionCall(data) aracılığıyla keyfi bir harici çağrı gerçekleştirir.

Güvenlik Açığı Analizi

Temel güvenlik açığı, GydL1CCipEscrow'un zincirler arası mesajlardan çözümlenen tx.recipient adresini doğrulamamasıdır. Saldırgan tx.recipient değerini GYD token sözleşmesi adresine ayarlayabilir ve data değerini approve(attacker, type(uint256).max) olarak hazırlayabilir. Emanet sözleşmesi büyük miktarda kilitli GYD tokeni barındırdığından, bu kısıtsız harici çağrı emanet sözleşmesinin GYD tokenlerinin tamamı üzerinde saldırgana tam onay vermesine neden olur; saldırgan daha sonra transferFrom() aracılığıyla tüm fonları boşaltabilir.

Saldırı Analizi

• Adım 1: Saldırgan Arbitrum'da kötü amaçlı bir CCIP mesajı başlattı; tx.recipient olarak Ethereum'daki GYD token sözleşmesi adresini, tx.data olarak ise approve(attacker, type(uint256).max) için kodlanmış çağrı verisini belirtti.

• Adım 2: Mesaj Ethereum'da işlendiğinde, GydL1CCipEscrow sözleşmesinin _ccipReceive() fonksiyonu tx.recipient değerini doğrulamadan GYD token sözleşmesinde onayı yürüttü. Saldırgan daha sonra tüm emanetteki fonları boşaltmak için GYD tokeninde transferFrom() fonksiyonunu çağırdı.

Sonuç

Bu olayın temel nedeni, GydL1CCipEscrow sözleşmesinin zincirler arası mesajları işlerken çözümlenen yükü doğrulamaması ve saldırganın kötü amaçlı bir zincirler arası çağrı oluşturabilmesine imkân tanımasıdır. Zincirler arası köprü mesajlaşması için geliştiriciler şunları yapmalıdır:

• Emanet sözleşmesinden token sözleşmelerine doğrudan çağrıları yasaklamak: Zincirler arası mesaj yüklerinin emanetteki token sözleşmesine yapılan çağrıları tetiklememesini sağlamak.

• Bir yürütme hedefi beyaz listesi uygulamak: tx.recipient (veya tx.target) değerini iyi tanımlanmış bir güvenilir adresler kümesiyle sınırlandırmak.

3. SOFI Token Olayı

Kısa Özet

5 Şubat 2026'da BNB Chain üzerindeki SOFI tokeni istismar edildi ve yaklaşık 29,6 bin dolar kayıp yaşandı.

Temel neden, tokenin geçersiz kılınan _transfer() fonksiyonu içinde uygulanan hatalı yakma mekanizmasıydı. Saldırgan, tokenları doğrudan PancakeSwap likidite havuzundan kaldıran ve ardından sync() fonksiyonunu tetikleyen gecikmeli yakma mantığını istismar ederek SOFI fiyatını yapay olarak şişirebildi. Saldırgan, tekrarlanan transferler ve takaslar aracılığıyla havuzdan fazladan USDT likiditesi çekti ve flash krediyi kârla geri ödedi.

Arka Plan

SOFI, BNB Chain üzerinde dağıtılmış özel bir ERC-20 tokendir. Standart bir ERC-20 uygulamasından farklı olarak SOFI tokeni, satış işlemleri sırasında token yakmaya ilişkin ek mantık eklemek için dahili _transfer() fonksiyonunu geçersiz kılmaktadır.

Token, PancakeSwap tarzı sabit çarpım AMM havuzunda (SOFI–USDT) işlem görmektedir. Bu tür havuzlarda token fiyatı, token rezervlerinin oranından türetilmektedir. Özellikle takaslardan kaynaklanmayan, havuz bakiyelerinde beklenmedik herhangi bir değişiklik fiyatı doğrudan manipüle edebilir.

Bu tasarımda token sözleşmesinin kendisi, transferler sırasında likidite havuzuyla etkileşime girmekte; bu da havuzun rezerv muhasebesini yalnızca AMM mekaniğine değil, token tarafı mantığına bağımlı hale getirmektedir.

Güvenlik Açığı Analizi

Güvenlik açığı, SOFI'nin yakma mekanizması ile _transfer() içindeki havuz etkileşiminin birleşiminde yatmaktadır.

SOFI tokenleri likidite havuzu adresine transfer edildiğinde, sözleşme transferi bir satış olarak yorumlar ve dahili bir toplayıcı değişken olan waitBurnTokenAmount'u artırır. Ancak biriken miktar hemen yakılmaz. Bunun yerine, havuza yapılan sonraki bir transferde havuzun bakiyesinden yakılır ve ardından havuzun sync() fonksiyonu çağrılır.

Bu tasarım iki kritik soruna yol açmaktadır:

1. Doğrudan havuz bakiyesi manipülasyonu Tokenlerin doğrudan havuzdan yakılması, karşılık gelen bir USDT çıkışı olmadan SOFI rezervini azaltır; bu durum AMM değişmezini ihlal eder ve SOFI fiyatını yapay olarak artırır.

2. Gecikmeli ve saldırgan tarafından kontrol edilebilir yürütme Yakma işlemi yalnızca gelecekteki bir transferde gerçekleştiğinden, saldırgan yakmanın ve sync() fonksiyonunun ne zaman gerçekleşeceğini tam olarak kontrol edebilir; bu da fiyat bozulmasından kâr elde etmek için kendini konumlandırmasına olanak tanır.

Sonuç olarak havuz fiyatı artık gerçek arz-talep dinamiklerini yansıtmamakta ve çıkarılabilir arbitraja imkân tanımaktadır.

Saldırı Analizi

• Adım 1: Flash kredi aracılığıyla USDT ödünç alındı.

• Adım 2: SOFI–USDT havuzunda USDT, SOFI ile takas edildi.

• Adım 3: SOFI havuza transfer edildi ve minimum kayıpla waitBurnTokenAmount'u artırmak için skim() çağrıldı.

• Adım 4: SOFI tekrar havuza transfer edilerek yakma + sync() tetiklendi; bu sayede SOFI fiyatı yükseldi ve ardından SOFI, USDT ile takas edildi.

• Adım 5: Adım 4 tekrarlandı. Yeni biriken waitBurnTokenAmount yalnızca bir sonraki transferde yakıldığından birden fazla iterasyon gereklidir.

• Adım 6: Havuzdan USDT boşaltıldı, ardından flash kredi geri ödendi.

Sonuç

Bu olay, sonuç olarak AMM havuz bakiyelerini doğrudan manipüle eden güvensiz bir token tarafı yakma mekanizmasından kaynaklandı. _transfer() içine gecikmeli yakma mantığı yerleştirerek ve yakmayı doğrudan likidite havuzundan yürüterek SOFI tokeni, sabit çarpım AMM'lerin temel varsayımlarını bozdu ve deterministik fiyat manipülasyonuna olanak tanıdı.

_transfer() fonksiyonunu geçersiz kılan ERC-20 tokenler için geliştiriciler özellikle şunlardan kaçınmaya özen göstermelidir:

• Tokenleri doğrudan likidite havuzlarından yakmak

• Havuz rezervlerini etkileyen gecikmeli veya durumlu mekanizmalar oluşturmak

• Token mantığını AMM içselliğiyle çok sıkı biçimde ilişkilendirmek

Genel olarak tokenomik ile ilgili mantığın havuz bakiyelerini keyfi olarak değiştirmesine hiçbir zaman izin verilmemelidir; zira küçük sapmalar bile likiditeyi boşaltmak için tekrar tekrar istismar edilebilir.

4. Bilinmeyen Staking Protokolü Olayı (5 Şubat 2026)

Kısa Özet

5 Şubat 2026'da Ethereum üzerindeki Bilinmeyen Staking Protokolü istismar edildi ve yaklaşık 71,6 bin dolar kayıp yaşandı.

Temel neden, protokolün para çekme işlemleri sırasında doğrulanmamış, kullanıcı tarafından sağlanan giriş verilerine güvenmesiydi. Özellikle protokol, saldırgan kontrollü routerCalldata ve LP miktarlarını doğrulama yapmadan Pendle Router'a iletiyordu. Saldırgan, protokolün tüm LP pozisyonunu kaldıran ve kendisini alıcı olarak ayarlayan çağrı verisi hazırlayarak kasanın tuttuğu tüm varlıkları boşaltabildi.

Arka Plan

Bilinmeyen Staking Protokolü, Pendle Finance üzerine inşa edilmiş basit bir getiri kasasıdır. Kullanıcılar varlıkları kasaya yatırır; kasa daha sonra bu varlıkları getiri sağlayan pozisyonlar oluşturmak amacıyla Pendle Router aracılığıyla yönlendirir. Dahili olarak yatırmalar SY'ye dönüştürülür, PT ve YT'ye bölünür ve Pendle LP tokenları oluşturmak için birleştirilir.

Protokol tüm LP tokenlarını muhafaza eder ve her kullanıcının yatırdığı temel miktarın dahili muhasebesini tutar. Kullanıcılar para çekmek istediklerinde kasa, LP tokenlarını Pendle Router aracılığıyla kullanır ve karşılık gelen varlıkları kullanıcıya iade eder.

Güvenlik Açığı Analizi

Temel neden, doğrulanmamış giriş verisidir. withdrawWithCalldataMultiToken() fonksiyonu dört parametre alır: temel token, temel miktar, LP miktarı ve routerCalldata. Yalnızca kullanıcının kayıtlı temel bakiyesinin yeterli olup olmadığını kontrol eder, ancak LP miktarını veya routerCalldata içeriğini doğrulamaz. Pendle Router aracılığıyla likidite kaldırılırken sözleşme tamamen routerCalldata içine gömülü parametrelere dayanır. Sonuç olarak saldırgan, protokolün tüm LP bakiyesini geçirerek kendisini alıcı olarak ayarlayabilir ve protokolün tuttuğu tüm varlıkları boşaltabilir.

Saldırı Analizi

• Adım 1: USDC flash kredisi alındı.

• Adım 2: Protokole az miktarda USDC yatırıldı; bu işlem fonları likidite eklemek ve LP oluşturmak için Pendle Router üzerinden yönlendirdi.

• Adım 3: withdrawWithCalldataMultiToken() fonksiyonu, receiver değerini saldırgan olarak ve lpAmount değerini protokolün tüm LP bakiyesi olarak ayarlayan hazırlanmış bir routerCalldata ile çağrıldı.

• Adım 4: Protokol, saldırgan kontrollü parametreleri kullanarak Pendle Router aracılığıyla likiditeyi kaldırdı ve tüm varlıkları saldırgana gönderdi.

• Adım 5: Alınan varlıklar USDC'ye geri dönüştürüldü, flash kredi geri ödendi ve kalan tutar kâr olarak alındı.

Sonuç

Bu olay, sonuç olarak kritik bir para çekme yolunda saldırgan kontrollü harici girdiye kör güvenden kaynaklandı. Keyfi çağrı verisini ve LP miktarlarını doğrulama yapmadan harici bir router'a ileterek protokol, kullanıcıların hak ettikleri payı çok aşan para çekme işlemleri yürütmesine izin verdi ve kasanın Pendle pozisyonunun tamamen boşaltılmasına yol açtı.

Özellikle karmaşık harici router'ları entegre eden üretim kasaları ve getiri stratejileri için geliştiriciler şunları yapmalıdır:

• Çağrı verisi dahil tüm kullanıcı tarafından sağlanan girdileri güvenilmez olarak değerlendirmeli ve titizlikle doğrulamalıdır.

• LP miktarları ve alıcılar gibi hassas parametreleri kullanıcılardan kabul etmek yerine dahili olarak türetmelidir.

• Dahili muhasebe ile harici yürütme sonuçları arasında tutarlılığı zorunlu kılarak derinlemesine savunma uygulamalıdır.

Bunu yapmamak, tek bir para çekme çağrısının protokolün tuttuğu tüm varlıkları tehlikeye atmasına neden olabilir.

5. LZMultiCall Protokolü Olayı

Kısa Özet

7 Şubat 2026'da LZMultiCall olayı Ethereum'da yaklaşık 142 bin dolar kayıpla sonuçlandı.

Olay, LZMultiCall sözleşmesinin kendisindeki bir güvenlik açığından değil, kullanıcı hatasından kaynaklandı. LZMultiCall, varlık muhafazası veya ERC-20 onayları tutacak şekilde tasarlanmamış durumsal olmayan bir toplu yürütme sözleşmesidir. Ancak bazı kullanıcılar yanlışlıkla sözleşmeye token onayları verdi. Bir saldırgan daha sonra bu asılı kalan onayları, transferFrom() fonksiyonunu çağırmak için hazırlanmış çağrı verisiyle execute() fonksiyonunu çağırarak istismar etti ve etkilenen kullanıcıların tokenlarını boşalttı.

Arka Plan

LZMultiCall, genel amaçlı bir toplu yürütme yardımcı sözleşmesidir. Temel amacı, kullanıcıların birden fazla çağrıyı tek bir işlemde paketlemesine olanak tanımak; kullanıcı tarafından sağlanan çağrı verilerini hedef sözleşmelere iletmektir.

Kritik olarak, LZMultiCall durumsal olmayan ve velayet içermeyen bir yapıda olacak şekilde tasarlanmıştır. Varlık tutması amaçlanmamıştır ve kullanıcıların hiçbir zaman buna ERC-20 onayları vermemesi gerekir. LZMultiCall'a verilen herhangi bir token onayı, açık kullanım varsayımlarını ihlal eder ve kullanıcıları riske maruz bırakır; zira sözleşme, çağrı sahibi adına keyfi çağrıları iletebilir.

Güvenlik Açığı Analizi

LZMultiCall tasarlandığı gibi çalışmış olsa da, kullanıcıların yanlışlıkla ERC-20 onayları vermesinin ardından izinsiz execute() fonksiyonu istismar edilebilir hale geldi. Sözleşme herhangi bir hedefe keyfi çağrı verisi ilettiğinden, saldırgan token sözleşmelerinde transferFrom(kurban, saldırgan, miktar) kodlayan çağrı verisiyle execute() fonksiyonunu çağırarak mevcut onayları etkin biçimde boşaltabildi.

Saldırı Analizi

• Saldırgan, LZMultiCall'a yanlışlıkla onay vermiş kullanıcılardan token transfer etmek için transferFrom() fonksiyonunu kullanarak token sözleşmesini hedef alan hazırlanmış çağrı verisiyle execute() fonksiyonunu çağırdı.

Sonuç

Bu olay, sonuç olarak durumsal olmayan bir toplu yürütme sözleşmesinin açık kullanım varsayımlarının ihlal edilmesinden kaynaklandı. LZMultiCall hiçbir zaman fon muhafazası veya ERC-20 onayları tutmak amacıyla tasarlanmamıştı. Kullanıcılar yanlışlıkla onay verdikten sonra sözleşmenin izinsiz yürütme modeli, herhangi bir çağrı sahibinin keyfi iletilen çağrılar aracılığıyla bu onayları boşaltmasına imkân tanıdı.

Toplu yürütme veya multicall tarzı sözleşmelerle etkileşime giren kullanıcılar ve entegratörler için:

• Açıkça varlık muhafazası için tasarlanmamış sözleşmelere hiçbir zaman ERC-20 onayı vermemelidir.

• Genel çağrı iletme sözleşmelerini güvenilmez yürütme yüzeyleri olarak değerlendirmelidir.

• Mümkün olan durumlarda işlem başına onayları veya onaysız tasarımları (örn. permit) tercih etmelidir.

Bir protokol güvenlik açığı olmasa dahi, bir sözleşmenin güven modelini yanlış anlamak önemli ve geri döndürülemez kayıplara yol açabilir.

6. Bilinmeyen Protokol Olayı (8 Şubat 2026)

Kısa Özet

8 Şubat 2026'da Ethereum üzerindeki Bilinmeyen Protokol istismar edildi ve yaklaşık 63 bin dolar kayıp yaşandı.

Temel neden, Gnosis Safe modül yürütme yolundaki doğrulanmamış saldırgan kontrollü giriş verisiydi. SafeModule olarak kayıtlı bir yardımcı sözleşme (0xF5E4), keyfi kullanıcı tarafından sağlanan verileri çözen ve doğrudan GnosisSafe.execTransactionFromModule() fonksiyonunu çağıran bir flash kredi geri çağırımı açığa çıkardı. Modül kaynaklı çağrılar tasarım gereği imza doğrulamasını atladığından, saldırgan keyfi Safe yetkili işlemler yürütebildi, Safe'in Aave V3 borcunu geri ödedi ve tüm teminatı saldırgan kontrollü adreslere çekti.

Arka Plan

Protokol mimarisi, Aave V3 üzerinde kaldıraçlı bir pozisyonu yöneten bir Gnosis Safe etrafında şekillenmektedir. Gnosis Safe, belirlenen SafeModule'lerin sahip imzaları gerektirmeksizin Safe adına işlem yürütebildiği modüler bir yürütme modeli destekler. Bu tasarım, otomasyon, entegrasyonlar ve gelişmiş stratejileri desteklemek amacıyla oluşturulmuştur.

Bu kurulumda 0xF5E4 sözleşmesi, Gnosis Safe'in bir SafeModule'ü olarak yapılandırılmıştı. Sözleşme, flash kredi tabanlı pozisyon yönetimini desteklemek için tasarlanmış bir yardımcı araç olarak görünmektedir. Flash kredi yürütmesi sırasında harici likidite sağlayıcıları tarafından çağrılan receiveFlashLoan() adlı bir flash kredi geri çağırımı uygulamaktadır.

Modül çağrıları imza doğrulamasını atladığından, modül mantığının doğruluğu ve güvenliği kritik önem taşımaktadır: herhangi bir hata, Safe üzerinde fiilen kısıtsız kontrol sağlar.

Güvenlik Açığı Analizi

SafeModule 0xF5E4, dışarıdan sağlanan userData'yı çözümleyen ve bunu doğrudan GnosisSafe.execTransactionFromModule() çağrısında kullanan bir flash kredi geri çağırımı olan receiveFlashLoan() fonksiyonunu açığa çıkarmaktadır. 0xF5E4 bir SafeModule olarak kayıtlı olduğundan, bu sözleşmeden kaynaklanan çağrılar imza doğrulamasını atlar. Ancak receiveFlashLoan(), çağrıyı yapanın kimliğini doğrulamaz veya çözümlenen parametreleri (örn. hedef adres, değer, çağrı verisi veya işlem türü) doğrulamaz. Sonuç olarak saldırgan, modülün Safe aracılığıyla keyfi işlemler yürütmesini sağlamak için hazırlanmış userData sağlayabilir; bu da Safe'in Aave V3 borcunu geri ödemeyi, tüm teminatı çekmeyi ve pozisyonu kâr amacıyla boşaltmayı mümkün kılar.

Saldırı Analizi

• Adım 1: Saldırgan Uniswap V4 aracılığıyla flash kredi aldı ve fonları GnosisSafe'e transfer etti.

• Adım 2: Saldırgan, hazırlanmış userData ile Balancer'ın flashLoan() fonksiyonunu çağırdı; gerçek varlık ödünç almadı ve recipient değerini 0xF5E4 olarak belirledi.

• Adım 3: 0xF5E4.receiveFlashLoan() fonksiyonunda sözleşme, saldırgan tarafından sağlanan userData'yı çözümledi. 0xF5E4 bir Safe modülü olarak kayıtlı olduğundan imza kontrollerini atlayarak execTransactionFromModule() fonksiyonunu çağırdı ve userData içine gömülü parametreler tarafından belirlenen keyfi çağrıları yürüttü.

• Adım 4: Bu kapasiteyi kullanarak saldırgan, GnosisSafe'in Aave V3'teki borcunu geri ödedi ve tüm teminatı çekerek kâr elde etti.

Sonuç

Bu olay, sonuç olarak modül tabanlı yürütmenin güvensiz kullanımı ile doğrulanmamış harici girdinin birleşiminden kaynaklandı. Keyfi saldırgan tarafından sağlanan userData'yı execTransactionFromModule() fonksiyonuna ileterek SafeModule 0xF5E4, Gnosis Safe üzerinde fiilen kısıtsız kontrol açığa çıkardı. Safe modülleri tasarım gereği imza kontrollerini atladığından, bu hata Safe'in Aave V3 pozisyonunun tamamen ele geçirilmesine yol açtı.

Gnosis Safe modüllerine veya benzer ayrıcalıklı yürütme çerçevelerine dayanan sistemler için geliştiriciler şunları yapmalıdır:

• Flash kredi userData'sı dahil tüm harici girdileri güvenilmez olarak değerlendirmeli ve titizlikle doğrulamalıdır.

• Modül yürütmesini iyi tanımlanmış bir eylemler, hedefler ve seçiciler kümesiyle sınırlandırmalıdır.

• Keyfi çağrı verisini ayrıcalıklı yürütme fonksiyonlarına ileten genel amaçlı "yardımcı" modüllerden kaçınmalıdır.

Bu güvenceleri uygulamayı ihmal etmek, tek bir yardımcı sözleşmeyi tam bir idari arka kapıya dönüştürebilir.

BlockSec Hakkında

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

BlockSec, saygın konferanslarda birden fazla blok zinciri güvenliği makalesi yayımlamış, DeFi uygulamalarına yönelik çeşitli sıfır gün saldırılarını raporlamış, 20 milyon doları aşan miktarı kurtarmak için birden fazla saldırıyı 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 Güvenlik UYGULAMASI: Demo rezervasyonu yapın

• 🔗 Phalcon Uyumluluk