Neden Hook'un Uniswap V4 için bir "çift taraflı kılıç" olduğunu söylüyoruz?

Uniswap v4'ün yakında herkesle buluşması bekleniyor. Bu sefer Uniswap ekibi büyük hedefler belirledi ve her bir işlem çifti için sonsuz sayıda likidite havuzu ve dinamik ücretler, tekil tasarım, anlık muhasebe, Hook ve ERC1155 token standardını destekleyen yeni özellikler getirmeyi planlıyor. Geçici depolamadan yararlanarak, Uniswap v4'ün Ethereum Cancun güncellemesinden sonra piyasaya sürülmesi bekleniyor.

Birçok yenilik arasında, Hook mekanizması güçlü potansiyeli nedeniyle geniş bir ilgi görmektedir. Likidite havuzunun yaşam döngüsünün belirli noktalarında belirli kodların yürütülmesini destekleyerek havuzun ölçeklenebilirliğini ve esnekliğini büyük ölçüde artırmaktadır.

Ancak, Hook mekanizması aynı zamanda çift taraflı bir kılıç olabilir. Güçlü ve esnek olmasına rağmen, Hook'un güvenli bir şekilde kullanılması da önemli bir zorluktur. Hook'un karmaşıklığı kaçınılmaz olarak yeni potansiyel saldırı vektörlerini beraberinde getirir. Bu nedenle, Hook mekanizmasıyla ilgili güvenlik sorunlarını ve potansiyel riskleri sistematik bir şekilde ele alan bir dizi makale yazmayı umuyoruz, böylece topluluğun güvenli bir şekilde gelişmesini teşvik edebiliriz. Bu görüşlerin, güvenli bir Uniswap v4 Hook inşa etmeye yardımcı olacağına inanıyoruz.

Bu makale serisinin ilk eseri olarak, Uniswap v4'teki Hook mekanizmasıyla ilgili kavramları tanıtmakta ve Hook mekanizmasının mevcut güvenlik risklerini özetlemektedir.

Uniswap V4 mekanizması

Derinlemesine incelemeden önce, Uniswap v4'ün mekanizması hakkında temel bir anlayışa sahip olmamız gerekiyor. Hook, tekil mimari ve anlık muhasebe, özelleştirilmiş likidite havuzları oluşturmanın ve birden fazla havuzda verimli yönlendirme sağlamanın üç önemli işlevidir.

1.1 Kanca

Hook, likidite havuzunun yaşam döngüsünün farklı aşamalarında çalışan bir sözleşmeyi ifade eder. Uniswap ekibi, Hook'u tanıtarak herkesin denge kararları almasını sağlamayı umuyor. Bu şekilde, dinamik ücretleri yerel olarak desteklemek, zincir üzerindeki limit emirlerini eklemek veya zaman ağırlıklı ortalama piyasa yapıcı (TWAMM) büyük siparişleri dağıtmak mümkün olabilir.

Şu anda sekiz Hook geri çağrısı var, dört gruba ayrılmıştır (her grup bir çift geri çağrıyı içerir):

• beforeInitialize/afterInitialize

• beforeModifyPosition/afterModifyPosition

• beforeSwap/afterSwap

• bağış öncesi/bağış sonrası

1.2 Singleton, Şimşek Muhasebesi ve Kilit Mekanizması

Singleton yapısı ve lightning muhasebesi, maliyetleri düşürerek ve verimliliği sağlamaya çalışarak performansı artırmayı amaçlamaktadır. Tüm likidite havuzlarının aynı akıllı sözleşmede saklandığı yeni bir singleton sözleşmesi tanıtılmaktadır. Bu singleton tasarımı, tüm havuzların durumunu depolamak ve yönetmek için bir PoolManager'a bağımlıdır.

Uniswap protokolünün erken sürümlerinde, takas veya likidite eklemek gibi işlemler doğrudan token transferini içeriyordu, ancak v4 sürümü, flaş muhasebe ve kilit mekanizmasını tanımasıyla farklılık gösteriyor.

Kilitleme mekanizmasının çalışma şekli şöyledir:

1. Bir locker sözleşmesi PoolManager'dan lock talep ediyor.

2. PoolManager, bu locker sözleşmesinin adresini lockData kuyruğuna ekler ve lockAcquired geri çağrısını çağırır.

3. Bu locker sözleşmesi geri çağırmada mantığını yürütür. Yürütme sürecinde, locker sözleşmesinin havuzla etkileşimi sıfırdan farklı bir para artışına neden olabilir. Ancak, yürütme sona erdiğinde, tüm artışların sıfıra ayarlanması gerekir. Ayrıca, eğer lockData kuyruğu boş değilse, yalnızca son locker sözleşmesi işlem yapabilir.

4. PoolManager, lockData kuyruğunu ve para artışının durumunu kontrol eder. Doğrulandıktan sonra, PoolManager bu locker sözleşmesini silecektir.

Özetle, kilitleme mekanizması eşzamanlı erişimi engeller ve tüm işlemlerin tasfiye edilmesini garanti eder. Locker sözleşmesi, lock için sırayla başvurur ve ardından lockAcquired geri çağrısı ile işlemi gerçekleştirir. Havuz işlemleri öncesinde ve sonrasında ilgili Hook geri çağrıları tetiklenir. Son olarak, PoolManager durumu kontrol eder.

Bu yöntem, yapılan işlemlerin iç net bakiyeyi ayarladığı anlamına gelir, anlık transferler gerçekleştirilmez. Herhangi bir değişiklik, havuzun iç bakiyesinde kaydedilir ve gerçek transfer işleminin sonunda gerçekleştirilir. Bu süreç, hiçbir tasfiye edilmemiş tokenin olmadığını garanti eder, böylece fonların bütünlüğü korunur.

Kilitleme mekanizmasının varlığı nedeniyle, dışarıdaki tüm hesaplar (EOA) doğrudan PoolManager ile etkileşimde bulunamaz. Bunun yerine, herhangi bir etkileşim bir sözleşme aracılığıyla gerçekleştirilmelidir. Bu sözleşme, herhangi bir havuz işlemi gerçekleştirilmeden önce kilit talep edilmesi gereken bir ara kilitleyici olarak işlev görmektedir.

Başlıca iki tür sözleşme etkileşim senaryosu vardır:

• Belirli bir locker sözleşmesi resmi kod kütüphanesinden gelir veya kullanıcı tarafından dağıtılır. Bu durumda, etkileşimi bir yönlendirici aracılığıyla gerçekleştirebiliriz.

• Bir locker sözleşmesi ve Hook'un aynı sözleşmeye entegre edilmesi veya üçüncü taraf bir varlık tarafından kontrol edilmesi durumunda, etkileşimi Hook aracılığıyla gerçekleştirebiliriz. Bu durumda, Hook hem locker sözleşmesinin rolünü üstlenir hem de geri çağırmaları işlemekle sorumludur.

Tehdit Modeli

İlgili güvenlik sorunlarını tartışmadan önce, tehdit modelini belirlememiz gerekiyor. Öncelikle aşağıdaki iki durumu dikkate alıyoruz:

• Tehdit Modeli I: Hook kendisi iyi niyetli, ancak açıklar içeriyor.

• Tehdit modeli II: Hook kendisi kötü niyetli.

Sonraki bölümde, bu iki tehdit modeli temelinde potansiyel güvenlik sorunlarını tartışacağız.

2.1 Tehdit Modeli I'ndeki Güvenlik Sorunları

Tehdit modeli I, Hook ile ilgili açıkları dikkate alıyor. Bu tehdit modeli, geliştiricilerin ve onların Hook'larının kötü niyetli olmadığını varsayıyor. Ancak, akıllı sözleşmelerdeki mevcut bilinen açıklar Hook içinde de ortaya çıkabilir. Örneğin, eğer Hook, yükseltilebilir bir sözleşme olarak uygulanıyorsa, OpenZeppelin'in UUPSUpgradeable açığına benzer sorunlarla karşılaşabilir.

Yukarıdaki faktörleri göz önünde bulundurarak, v4 sürümüne özgü potansiyel açılara odaklanmayı seçiyoruz. Uniswap v4'te, Hook, temel havuz işlemleri (başlatma, konum değiştirme, takas yapma ve toplama dahil) öncesinde veya sonrasında özel mantık yürütebilen bir akıllı sözleşmedir. Hook'un standart bir arayüzü gerçekleştirmesi beklenirken, aynı zamanda özel mantık içermesine de izin verir. Bu nedenle, tartışma alanımız standart Hook arayüzüyle ilgili mantıkla sınırlı olacaktır. Sonrasında, Hook'un bu standart Hook fonksiyonlarını nasıl kötüye kullanabileceği gibi potansiyel açılma kaynaklarını tespit etmeye çalışacağız.

Özellikle, aşağıdaki iki tür Hook'a odaklanacağız:

• İlk tür hook, kullanıcı fonlarını saklamak. Bu durumda, saldırgan bu hook'u saldırarak fonları transfer edebilir ve varlık kaybına neden olabilir.

• İkinci tür hook, kullanıcıların veya diğer protokollerin bağımlı olduğu kritik durum verilerini depolar. Bu durumda, saldırgan kritik durumu değiştirmeye çalışabilir. Diğer kullanıcılar veya protokoller yanlış durumu kullandığında, potansiyel riskler ortaya çıkabilir.

Lütfen dikkat edin, bu iki aralığın dışındaki kancalar tartışmamızın konusu değildir.

Genel olarak, Uniswap v4 ile ilgili olmayan projeleri hariç tutarak 22 ilgili proje bulduk. Bu projelerden 8'inin (%36) güvenlik açığı olduğunu düşünüyoruz. Bu 8 güvenlik açığı olan projeden 6'sında erişim kontrol sorunları, 2'sinde ise güvensiz dış çağrılara karşı hassasiyet var.

2.1.1 Erişim Kontrolü Sorunu

Bu bölümde, v4'teki geri çağırma işlevlerinden kaynaklanabilecek sorunlara, 8 adet hook geri çağırma ve lock geri çağırma dahil olmak üzere, odaklanıyoruz. Elbette, doğrulanması gereken başka durumlar da var, ancak bu durumlar tasarımdan kaynaklandığından, tartışma kapsamımızda değil.

Bu fonksiyonlar yalnızca PoolManager tarafından çağrılmalıdır, diğer adresler (EOA ve sözleşmeler dahil) tarafından çağrılmamalıdır. Örneğin, ödüllerin havuz anahtarı ile dağıtıldığı durumda, ilgili fonksiyon herhangi bir hesap tarafından çağrılabiliyorsa, ödüller yanlış bir şekilde alınabilir.

Bu nedenle, hook için güçlü bir erişim kontrol mekanizması oluşturmak hayati öneme sahiptir, özellikle de bunların havuzun kendisi dışında başka taraflar tarafından çağrılabilmesi durumunda. Erişim izinlerinin sıkı bir şekilde yönetilmesiyle, likidite havuzları yetkisiz veya kötü niyetli etkileşimlerle ilgili riskleri önemli ölçüde azaltabilir.

2.1.2 Giriş Doğrulama Sorunu

Uniswap v4'te, kilit mekanizması bulunduğundan, kullanıcıların herhangi bir likidite havuzu işlemi gerçekleştirmeden önce bir sözleşme aracılığıyla bir lock alması gerekmektedir. Bu, mevcut etkileşimde bulunan sözleşmenin en son locker sözleşmesi olduğunu garanti eder.

Buna rağmen, bazı savunmasız Hook uygulamalarında giriş doğrulamasının yetersiz olmasından kaynaklanan güvensiz dış çağrılar için bir saldırı senaryosu hala mevcuttur:

• Öncelikle, hook kullanıcının etkileşimde bulunmayı planladığı likidite havuzunu doğrulamamıştır. Bu, sahte token'lar içerebilen ve zararlı mantık yürütebilen kötü niyetli bir likidite havuzu olabilir.

• İkincisi, bazı anahtar hook fonksiyonları, rastgele dış çağrılara izin verir.

Güvenilmeyen dış çağrılar son derece tehlikelidir, çünkü çeşitli saldırı türlerine yol açabilir, bunlar arasında bildiğimiz yeniden giriş saldırısı da bulunmaktadır.

Bu savunmasız hook'lara saldırmak için, saldırgan kendi sahte token'ı için kötü niyetli bir fon havuzu kaydedebilir ve ardından fon havuzunda işlem yapmak için hook'u çağırabilir. Fon havuzuyla etkileşimde bulunurken, kötü niyetli token mantığı, kötü niyetli eylemler gerçekleştirmek için kontrol akışını ele geçirir.

2.1.3 Tehdit Modeli I için Önleme Önlemleri

Hook ile ilgili bu tür güvenlik sorunlarından kaçınmak için, hassas dış/uzun süreli fonksiyonların gerekli erişim kontrolünü uygun şekilde uygulamak ve giriş parametrelerini doğrulamak, etkileşimlerin doğrulanması açısından kritik öneme sahiptir. Ayrıca, yeniden giriş koruması, hook'un standart mantık akışında tekrar tekrar yürütülmemesini sağlamada yardımcı olabilir. Uygun güvenlik önlemleri uygulayarak, fon havuzları bu tür tehditlerle ilgili riskleri azaltabilir.

2.2 Tehdit Modeli II'ndeki Güvenlik Sorunları

Bu tehdit modelinde, geliştiricilerin ve onların hook'larının kötü niyetli olduğunu varsayıyoruz. Kapsam oldukça geniş olduğu için, yalnızca v4 sürümü ile ilgili güvenlik sorunlarına odaklanıyoruz. Bu nedenle, sağlanan hook'un kullanıcı transferi veya yetkilendirmesi ile ilgili kripto varlıkları işleyip işleyemediği önemlidir.

Hook'a erişim yönteminin hook'a verilebilecek izinleri belirlemesi nedeniyle, hook'ları iki türe ayırıyoruz:

• Yönetilen Hook: hook giriş noktası değildir. Kullanıcı, hook ile etkileşimde bulunmak için bir yönlendirici (muhtemelen Uniswap tarafından sağlanan) üzerinden geçmelidir.

• Bağımsız Hook: hook, kullanıcıların doğrudan etkileşimde bulunmasına izin veren bir giriş noktasıdır.

2.2.1 Yönetilen Hook

Bu durumda, kullanıcının kripto varlıkları (yerel tokenler ve diğer tokenler dahil) router'a transfer edilir veya yetkilendirilir. PoolManager bakiye kontrolü gerçekleştirdiği için kötü niyetli hook'ların bu varlıkları doğrudan çalması kolay değildir. Ancak, hala potansiyel bir saldırı noktası bulunmaktadır. Örneğin, v4 sürümündeki ücret yönetim mekanizması, saldırganlar tarafından hook aracılığıyla manipüle edilebilir.

2.2.2 Bağımsız Tip Hook

Hook bir giriş noktası olarak kullanıldığında durum daha karmaşık hale gelir. Bu durumda, kullanıcılar doğrudan hook ile etkileşimde bulunabildiğinden, hook daha fazla güce sahip olur. Teorik olarak, hook bu etkileşim aracılığıyla istediği herhangi bir işlemi gerçekleştirebilir.

v4 sürümünde, kod mantığının doğrulanması son derece önemlidir. Ana sorun, kod mantığının manipüle edilip edilemeyeceğidir. Eğer hook yükseltilebilir ise, bu, görünüşte güvenli bir hook'un yükseltme sonrasında kötü niyetli hale gelebileceği anlamına gelir ve bu da önemli bir risk oluşturur. Bu riskler şunları içerir:

• Yükseltilebilir ajan (doğrudan saldırıya uğrayabilir);

• Kendini yok etme mantığına sahip. selfdestruct ve create2'nin birlikte çağrılması durumunda saldırıya uğrayabilir.

2.2.3 Tehdit Modeli II için Önlemler

Hook'un kötü niyetli olup olmadığını değerlendirmekte kritik bir nokta vardır. Özellikle, yönetilen hook'lar için maliyet yönetimi davranışlarına dikkat etmemiz gerekir; bağımsız hook'lar için ise, esas olarak onların yükseltilebilir olup olmadığına odaklanmalıyız.

sonuç

Bu yazıda, öncelikle Uniswap v4'ün Hook güvenlik sorunlarıyla ilgili temel mekanizmaları kısaca özetliyoruz. Ardından, iki tehdit modeli öneriyoruz ve ilgili güvenlik risklerini kısaca özetliyoruz.

Sonraki makalelerde, her bir tehdit modelini inceleyeceğiz.