Fiyat Manipülasyonu İçin Kara Büyü: Balancer V2 Değişmez Hesaplama Açığı Analizi

Derleme: Sade Blok Zinciri

2025 yılının 3 Kasım'ında, Balancer V2'nin bileşen stabil havuzları (Composable Stable Pools) ve birçok zincirdeki birkaç çatallanma projesi bir koordineli saldırıya uğradı ve toplam kayıplar 1.25 milyon doları aştı. BlockSec, ilk anda alarm verdi ve ardından ön analiz yayınladı.

Bu son derece karmaşık bir saldırıdır. Araştırmalarımız, temel nedenin değişmez (invariant) hesaplamalarındaki hassasiyet kaybının fiyat manipülasyonuna yol açtığını ve bu durumun BPT (Balancer Pool Token) fiyat hesaplamalarını bozduğunu göstermektedir. Bu değişmez manipülasyonu, saldırganların belirli bir stabil havuzdan tek bir toplu takas (batch swap) ile kâr elde etmelerini sağlamaktadır. Bazı araştırmacılar içgörü dolu analizler sunmuş olsa da, bazı yorumlar yanıltıcıdır ve temel nedenler ile saldırı süreci henüz tam olarak aydınlatılamamıştır. Bu blog, bu olayı kapsamlı ve doğru bir teknik analiz ile ele almayı amaçlamaktadır.

Ana Noktalar (TL;DR)

• Temel Sebep: Yuvarlama Tutarsızlığı ve Hassasiyet Kaybı

• Büyütme (upscaling) işlemi tek yönlü yuvarlama (aşağı yuvarlama) kullanırken, küçültme (downscaling) işlemi çift yönlü yuvarlama (yukarı ve aşağı yuvarlama) kullanır.
• Bu tutarsızlık, dikkatle tasarlanmış değişim yolları kullanıldığında, “yuvarlama her zaman protokole fayda sağlamalıdır” temel ilkesini ihlal ederek hassasiyet kaybına neden olur.

• Saldırı Uygulama

• Saldırgan, hassasiyet kaybının etkisini maksimize etmek için yineleme sayısı ve giriş değerleri dahil olmak üzere parametreleri titizlikle tasarladı.
• Saldırgan, tespiti atlatmak için iki aşamalı bir yöntem kullanır: önce bir işlemde ana saldırıyı gerçekleştirir, hemen kâr etmez, ardından başka bir işlemde varlıkları çekerek kâr sağlar.

• Operasyon Etkisi ve Büyütme

• Bazı kısıtlamalar nedeniyle protokol duraklatılamaz. Bu durdurulamayan durum, saldırının etkilerini artırmış ve çok sayıda sonraki veya taklit saldırısına yol açmıştır.

Aşağıdaki kısımda, öncelikle Balancer V2 ile ilgili temel arka plan bilgilerini sağlayacağız, ardından tespit edilen sorunlar ve ilgili saldırılar üzerinde derinlemesine analiz yapacağız.

0x1 Arka Plan

1. Balancer V2'nin Kombinasyon Stabil Havuzu

Bu saldırıda etkilenen bileşen, Balancer V2 protokolünün kombine stabil havuzudur. Bu havuzlar, 1:1 sabitleme (veya bilinen döviz kuru ile işlem yapma) beklentisiyle tasarlanmış varlıklara özeldir ve minimum fiyat etkisi ile büyük miktarda takas yapılmasına izin vererek benzer veya ilgili varlıklar arasındaki sermaye verimliliğini önemli ölçüde artırır. Her havuzun kendi Balancer Havuz Token'ı (BPT) vardır ve bu, likidite sağlayıcılarının havuzdaki payını ve ilgili temel varlıkları temsil eder.

Bu havuz, D değişkeninin havuzun sanal toplam değerini temsil ettiği Stable Math (Curve tabanlı StableSwap modeli) kullanmaktadır.

BPT fiyatı yaklaşık olarak şudur:

Yukarıdaki formülden de anlaşılacağı gibi, eğer D muhasebe kaydında küçültülebiliyorsa (gerçek bir finansal kayıp olmaksızın), BPT fiyatı daha ucuz görünecektir.

2. batchSwap() ve onSwap()

Balancer V2, Vault içinde çoklu sıçramalar (multi-hop swaps) gerçekleştiren batchSwap() fonksiyonunu sunar. Bu fonksiyona geçirilen parametrelere göre iki tür değişim vardır:

• GIVEN_IN (“Verilen Giriş”): Çağrıcı, belirli bir Token miktarını belirtir, havuz buna karşılık gelen çıkış miktarını hesaplar.
• GIVEN_OUT（“Verilen Çıktı”）：Çağrıcı, beklenen çıktı miktarını belirtir, havuz gerekli giriş miktarını hesaplar.

Genellikle, batchSwap() birden fazla onSwap() fonksiyonu aracılığıyla gerçekleştirilen Token'lar arası değişimlerden oluşur. Aşağıda, bir SwapRequest'in GIVEN_OUT değişim türü olarak atandığında izlenecek yol özetlenmiştir (lütfen ComposableStablePool'un BaseGeneralPool'dan miras aldığını unutmayın):

! [resim] ()

Aşağıda GIVEN_OUT değişim türünde amount_in'in hesaplanması gösterilmektedir; bu, sabit D ile ilgilidir.

// inGivenOut token x for y - polinom denklemi çözmek için // ax = hesaplanacak miktar // bx = token bakiyesi içinde // x = bx + ax (finalBalanceIn)
// D = değişmez // A = amplifikasyon katsayısı // n = token sayısı // S = nihai bakiyelerin toplamı ama x // P = nihai bakiyelerin çarpımı ama x

               D                     D^(n+1)  

x^2 + ( S - ---------- - D) * x - ------------- = 0
(A * n^n) A * n^2n * P

3. Ölçekleme ve Yuvarlama

Farklı Token bakiyeleri arasında standartlaştırılmış hesaplama yapmak için, Balancer aşağıdaki iki işlemi gerçekleştirir:

• Büyütme (Upscaling): Hesaplama yapılmadan önce bakiyeyi ve tutarı birleştirilmiş iç hassasiyete büyütmek.

! [resim] ()

• Küçültme (Downscaling): Sonuçları orijinal hassasiyetine geri döndürmek ve yönlendirilmiş yuvarlama uygulamak (örneğin, giriş tutarı genellikle yukarı yuvarlanır, böylece havuzun yetersiz ücret almadığından emin olunur, çıkış tutarı ise sıklıkla aşağı yuvarlanır).

! [resim] ()

Açıkça, büyütme ve küçültme teorik olarak birbirine bağlı işlemlerdir - sırasıyla çarpma ve bölme. Bununla birlikte, bu iki işlemin uygulanmasında tutarsızlıklar bulunmaktadır. Özellikle, küçültme işleminin iki varyantı veya yönü vardır: divUp ve divDown. Buna karşılık, büyütme işleminin yalnızca bir yönü vardır, yani mulDown.

Bu tutarsızlığın nedeni henüz net değil. _upscale() fonksiyonundaki yorumlara göre, geliştiriciler tek yönlü yuvarlamanın etkisinin önemsiz olduğunu düşünüyor.

// Büyütme (Upscale) yuvarlama her zaman aynı yönde olmayabilir: örneğin, bir değişimde,

// Token bakiyesi yukarı doğru yuvarlanmalı, çıkış Token bakiyesi ise aşağı doğru yuvarlanmalıdır. Bu, tüm tutarları aynı yönde yuvarladığımız tek yerdir.

// Çünkü bu tür yuvarlama etkisinin en az olması bekleniyor.

// (ve eğer _scalingFactor() üzerine yazılmadıysa, yuvarlama hatası yoktur).

0x2 Açık Analizi

Temel sorun, BaseGeneralPool._swapGivenOut() fonksiyonunda ölçeklendirme (upscaling) işlemi gerçekleştirilirken yapılan aşağı yuvarlama işlemi ile ilgilidir. Özellikle, _swapGivenOut(), _upscale() fonksiyonu aracılığıyla swapRequest.amount değerini yanlış bir şekilde aşağı yuvarlamaktadır. Bu yuvarlanmış değer daha sonra amountOut olarak kullanılır ve _onSwapGivenOut() ile amountIn hesaplanırken kullanılır. Bu davranış, 'yuvarlama, protokole faydalı olacak şekilde uygulanmalıdır' standart uygulamasıyla çelişmektedir.

! [resim] ()

Bu nedenle, belirli bir havuz (wstETH/rETH/cbETH) için hesaplanan amountIn, gereken gerçek girişi düşük gösterir. Bu, kullanıcıların daha az miktardaki bir temel varlığı (örneğin wstETH) bir başka varlıkla (örneğin cbETH) değiştirmesine olanak tanır; bu da etkili likiditenin azalması nedeniyle D değişkeninin azalmasına yol açar. Bu nedenle, ilgili BPT'nin (wstETH/rETH/cbETH) fiyatı yapay olarak düşer (deflated), çünkü $\text{BPT price} = \frac{D}{\text{totalSupply｝｝$.

0x3 Saldırı Analizi

Saldırgan gerçekleştirdi

İki aşamalı saldırı, tespit edilme riskini en aza indirmek için olabilir:

• İlk aşamada, çekirdek tek bir işlemde gerçekleştirilir, hemen kâr elde edilmez.
• İkinci aşamada, saldırgan başka bir işlemde varlıkları çekerek kâr elde eder.

Birinci aşama iki alt aşamaya daha ayrılabilir: parametre hesaplama ve toplu değişim. Aşağıda, bu aşamaları açıklamak için Arbitrum üzerindeki bir saldırı işlemi (TX) örneğini kullanıyoruz.

Parametre Hesaplama Aşaması

Bu aşamada, saldırganlar, mevcut durumuna (ölçek faktörü, büyütme katsayısı, BPT döviz kuru, işlem ücretleri ve diğer parametreler dahil) göre kombinasyon stabil havuzunun zincir dışı hesaplamalarını ve zincir içi simülasyonları birleştirerek, bir sonraki aşamadaki (toplu değişim) her bir adımın parametrelerini hassas bir şekilde ayarlamaktadır. İlginç bir şekilde, saldırganlar bu hesaplamaları desteklemek için bir yardımcı akıllı sözleşme de dağıttılar, bu da “ön koşma” (front-running) riskini azaltmak amacıyla olabilir.

Öncelikle, saldırganlar hedef havuzun temel bilgilerini toplar, bu bilgiler arasında her Token'ın ölçekleme faktörü, büyütme parametreleri, BPT döviz kuru ve takas ücret yüzdesi bulunmaktadır. Ardından, manipüle edilmiş hedef Token sayısını belirlemek için hassasiyet kaybını tetikleyen anahtar değer trickAmt'yi hesaplarlar.

Hedef Token'ın ölçekleme faktörünü (scaling factor) sF olarak adlandırın, hesaplama aşağıdaki gibidir:

Sonraki aşamanın (toplu değişim) 2. adımında kullanılan parametreleri belirlemek için, saldırgan aşağıdaki calldata ile yardımcı sözleşmenin 0x524c9e20 fonksiyonuna ardışık simülasyon çağrısı yapar:

uint256[] bakiyeler; // Havuz Token'larının bakiyesi (BPT dahil değil) uint256[] ölçekleme Faktörleri; // Her havuz Token'ı için ölçekleme faktörü uint tokenIn; // Bu atlama simülasyonundaki giriş Token indeksi uint tokenOut; // Bu atlama simülasyonunun çıktı Token indeksi uint256 amountOut; // Beklenen çıkış Token miktarı uint256 amp; // Havuzun büyütme parametresi uint256 fee; // Havuz değişim ücreti yüzdesi

Dönen veri şudur:

uint256[] bakiyeler; // İşlem sonrası havuz Token'larının bakiyesi (BPT dahil değil)

Özellikle, başlangıç bakiyesi ve yineleme döngü sayısı, zincir dışı hesaplanır ve saldırganın sözleşmesine parametre olarak iletilir (rapor sırasıyla 100.000.000.000 ve 25). Her yineleme üç değişim gerçekleştirir:

1. Değişim 1: Hedef Token miktarını trickAmt + 1'e yükselt, varsayılan değişim yönü 0 → 1.
2. Değişim 2: trickAmt ile hedef Token'ı değiştirmeye devam edin, bu _upscale() çağrısındaki aşağı yuvarlamayı tetikleyecektir. 320,000.

Lütfen dikkat edin, StableMath hesaplamalarında Newton–Raphson yönteminin kullanılması nedeniyle, bu adım bazen başarısız olabilir. Bu durumu hafifletmek için, saldırgan iki kez tekrar deneme yapmayı gerçekleştirmiştir, her seferinde orijinal değerin 9/10'unu yedek değer olarak kullanmaktadır.

Saldırganın yardımcı sözleşmesi, Balancer V2'nin StableMath kütüphanesinden türetilmiştir, bu durum “BAL” tarzı özel hata mesajını içermesiyle kanıtlanabilir.

$d$ Toplu Değişim Aşaması

Sonra, batchSwap###( işlemi üç adım olarak ayrılabilir:

1. Adım 1: Saldırgan, BPT )wstETH/rETH/cbETH('i temel varlıklara dönüştürerek bir Token'ın (cbETH) bakiyesini yuvarlama sınırının kenarına hassas bir şekilde ayarlar (miktar = 9). Bu, bir sonraki adım için hassasiyet kaybı koşullarını yaratır.
2. Adım 2: Ardından, saldırgan özenle tasarlanmış bir miktarı (= 8) başka bir temel varlık (wstETH) ile cbETH arasında takas eder. Token miktarını ölçeklendirirken aşağı yuvarlama nedeniyle, hesaplanan Δx biraz daha küçük hale gelir (8.918'den 8'e), bu da Δy'nin düşük tahmin edilmesine neden olur ve böylece değişmezlik (D, Curve'ün StableSwap modelinden) küçülür. $\text{BPT fiyatı} = \frac{D}{\text{totalSupply｝｝$ olduğundan, BPT fiyatı yapay olarak düşürülür.

! [resim] )( 3. Adım 3: Saldırgan, temel varlıkları geri dönüştürerek BPT'ye çevirir, dengeyi yeniden sağlar ve aynı zamanda düşük fiyatlı BPT'den kazanç elde eder.

0x4: Saldırı ve Kayıp

Bu tablodaki bu saldırıları ve ilgili kayıplarını özetledik, toplam kayıplar 1.25 milyondan fazla.

! [resim] )(

0x5 Sonuç

Bu olay, Balancer V2 protokolü ve onun çatallı projelerine yönelik bir dizi saldırı işlemine ilişkindir ve önemli mali kayıplara yol açmıştır. İlk saldırının ardından, birçok zincirde büyük miktarda takip eden ve taklit eden işlemler gözlemlenmiştir. Bu olay, DeFi protokollerinin tasarımı ve güvenliği ile ilgili birkaç anahtar dersi vurgulamaktadır:

• Yuvarlama Davranışı ve Hassasiyet Kaybı: Büyütme (upscaling) işlemlerinde kullanılan tek yönlü yuvarlama (aşağı yuvarlama) ile küçültme (downscaling) işlemlerinde kullanılan çift yönlü yuvarlama (yukarı ve aşağı yuvarlama) farklıdır. Benzer açıkların önlenmesi için, protokol daha yüksek hassasiyetli aritmetik kullanmalı ve sağlam doğrulama kontrolleri uygulamalıdır. “Yuvarlama her zaman protokole faydalı olmalıdır” standart ilkesine bağlı kalınmalıdır.
• Zafiyet Kullanımının Evrimi: Saldırgan, tespiti atlatmayı amaçlayan karmaşık iki aşamalı bir zafiyet kullanımı gerçekleştirdi. İlk aşamada, saldırgan tek bir işlemde temel kullanımı yürütüyor, hemen kâr elde etmiyor. İkinci aşamada, saldırgan başka bir işlemde varlıkları çekerek kâr elde ediyor. Bu, güvenlik araştırmacıları ile saldırganlar arasındaki sürekli "silahlanma yarışı"nı bir kez daha vurguluyor.
• Operasyon Bilinci ve Tehdit Yanıtı: Bu olay, başlatma ve operasyonel durumlar hakkında zamanında uyarıların önemini vurgulamakta ve sürekli veya taklit saldırıların neden olabileceği potansiyel kayıpları azaltmak için proaktif tehdit tespit ve önleme mekanizmalarının gerekliliğini ortaya koymaktadır.

Operasyon ve iş sürekliliğini sağlarken, sektör katılımcıları varlıklarını korumak için son savunma hattı olarak BlockSec Phalcon'dan yararlanabilirler. BlockSec uzman ekibi, projeniz için kapsamlı bir güvenlik değerlendirmesi yapmak üzere her zaman hazırdır.

Bu makalenin bağlantısı:

Kaynak: