Merkezi Olmayan Finans Güvenlik Dersi: Yaygın Güvenlik Açıkları ve Önleme Tedbirleri

Son zamanlarda, bir güvenlik uzmanı DeFi güvenliği ile ilgili içerikler paylaştı, son bir yıl içinde Web3 sektöründeki önemli güvenlik olaylarını gözden geçirdi, bu olayların nedenlerini ve nasıl önlenebileceğini tartıştı, yaygın akıllı sözleşme güvenlik açıklarını ve önleme yöntemlerini özetledi ve proje sahipleri ile kullanıcılara bazı güvenlik önerileri sundu.

Yaygın DeFi açık türleri genellikle flash loan, fiyat manipülasyonu, fonksiyon yetki sorunları, rastgele dış çağrılar, fallback fonksiyonu sorunları, iş mantığı açıkları, özel anahtar sızıntıları, reentrancy gibi konuları içerir. Bu yazıda flash loan, fiyat manipülasyonu ve reentrancy saldırıları bu üç tür üzerine odaklanılacaktır.

Hızlı Kredi

Lightning loan, kendisi DeFi'nin bir yeniliğidir, ancak hackerlar tarafından kullanıldığında, herhangi bir maliyet ödemeden para ödünç alabilirler. Tüm arbitraj sürecini tamamladıktan sonra geri ödenir, geriye kalan kısım arbitrajın kazancıdır, sadece az bir miktar Gas ücreti ödeyerek büyük kazançlar elde edebilirler.

Sık karşılaşılan saldırılar genellikle flash loan ile birlikte gelir, saldırganlar flash loan aracılığıyla büyük miktarda fon borç almayı ve fiyatları manipüle etmeyi, iş mantığını saldırmayı severler. Geliştiricilerin dikkate alması gereken, sözleşme işlevinin büyük miktardaki fonlar nedeniyle anormal bir şekilde çalışıp çalışmayacağı veya büyük miktardaki fonlarla tek bir işlemde sözleşmedeki birden fazla fonksiyonla etkileşime geçerek ödül alabileceği senaryolarıdır.

Sözleşmelerde bazı Token sayılarının ödül hesaplamaları için kullanıldığını veya DEX ticaret çiftlerindeki Token sayısının çeşitli hesaplamalara katıldığını sıkça görebiliriz. Geliştiricilerin bu işlevleri tasarlarken saldırganların bu değişkenleri flash loan kullanarak manipüle edebileceğini düşünmemeleri, sözleşme fonlarının çalınmasına neden oldu.

Son iki yılda, flash loan'larla ilgili birçok sorun ortaya çıktı. Birçok Merkezi Olmayan Finans projesi yüksek getiri sağlıyormuş gibi görünse de, projelerin kalitesi oldukça değişken. Örneğin, kodlar satın alınmış olabilir; kodun kendisi bir güvenlik açığı içermese bile, mantıksal olarak sorunlar olabilir. Örneğin, belirli bir zaman diliminde, token sahiplerinin sahip olduğu token sayısına göre ödül dağıtan bir projeyle karşılaştık; ancak saldırganlar, flash loan kullanarak büyük miktarda token satın alarak, ödül dağıtımı sırasında ödüllerin çoğunu kendilerine yönlendirdiler. Ayrıca, fiyat hesaplamak için Token kullanan bazı projeler, flash loan ile fiyatları etkileyebilir; bu nedenle proje sahiplerinin bu sorunlara karşı dikkatli olmaları gerekiyor.

Fiyat Manipülasyonu

Fiyat manipülasyonu sorunu ve flash kredi ilişkisi yakından bağlantılıdır, bu sorun esasen fiyat hesaplamasında bazı parametrelerin kullanıcı tarafından kontrol edilebilmesinden kaynaklanmaktadır, sıkça karşılaşılan sorun türleri ikiye ayrılmaktadır.

• Bir türü, fiyat hesaplamasında üçüncü taraf verilerini kullanmak, ancak kullanım şeklinin yanlış olması veya kontrol eksikliği nedeniyle fiyatın kötü niyetli bir şekilde manipüle edilmesidir.
• Diğer bir tür, bazı adreslerin Token miktarının hesaplama değişkeni olarak kullanılmasıdır ve bu adreslerin Token bakiyeleri geçici olarak artırılabilir veya azaltılabilir.

Yeniden Giriş Saldırısı

Dış sözleşmeleri çağırmanın başlıca tehlikelerinden biri, bunların kontrol akışını ele geçirebilmesi ve verilerinize, beklenmedik değişiklikler yapmak için fonksiyon çağrıları yapabilmesidir.

Kullanıcının bakiyesi fonksiyonun sonunda 0 olarak ayarlandığı için, ikinci ( ve sonraki ) çağrıları hala başarılı olacaktır ve bakiyeyi tekrar tekrar çekecektir.

Farklı sözleşmelere yönelik olarak, yeniden girişin birçok yolu vardır, sözleşmenin farklı fonksiyonları veya birden fazla farklı sözleşmenin fonksiyonları birleştirilerek yeniden giriş saldırıları gerçekleştirilebilir. Bu nedenle, yeniden giriş sorununu çözerken aşağıdaki noktalara dikkat etmemiz gerekiyor:

1. Sadece tek bir fonksiyonun yeniden çağırma sorununu önlemekle kalmaz;
2. Checks-Effects-Interactions modeline göre kodlama yapın;
3. Zamanla test edilmiş reentrancy modifier'ını kullanın.

Aslında en korktuğum şey tekrardan tekerlek icat etmek, neye ihtiyacımız varsa kendimiz yazmak. Bu alanda birçok en iyi güvenlik uygulaması var, bunları kullanmamız yeterli, tekrardan tekerlek icat etmeye kesinlikle gerek yok. Bir tekerlek icat ettiğinizde, yeterince doğrulamadan geçmemiş oluyorsunuz, bu durumda sorun yaşama olasılığı, çok olgun ve uzun süre test edilmiş birinin sorun yaşama olasılığından çok daha fazla.

Omni Protocol açığı arkasındaki hikaye --- dört hacker arasındaki mücadele

Ethereum'un mempool'u sürekli olarak birçok hacker tarafından izleniyor, onlar sürekli olarak işlemleri analiz ediyor ve karlı işlemlerde kapışarak kar elde ediyorlar. Omni Protocol açığı keşfedenin gönderdiği saldırı işlemi, iki hacker tarafından yakalandı; onlar, flashbot'ta kapışma işlemleri yayınlayarak Omni Protocol protokolündeki 1200 ETH'yi ele geçirdiler, oysa açığı keşfeden saldırgan sadece 480 ETH kazandı. Bu süreçte, başka bir hacker, flashbot'ta kapışma işlemi gönderen hackerın saldırı işlemini keşfetti ve saldırı işleminin Doodle ERC20 token'ını satın alma gereksinimini kullanarak ona bir sandviç saldırısı gerçekleştirdi, 151 ETH kazandı.

Açıklık bulan kişilerin kazancı en yüksek değil, kazancı daha fazla olanlar karanlık ormanda diğer avcılardır. Bu ekosistemde her yerde avcılar var, avcılar arasında av olabiliyorlar, hatta saldırıyı başlatan kişi bile yeni başlayan biriyse, bu projenin büyük kısmını alıp gidemeyebilir, ancak tek seferde alabilir. Ayrıca birçok kişi daha yüksek Gas ücreti ödeyerek işlemi öncelikli olarak gerçekleştirmeye çalışacak, eğer DEX'deki tokenların alım satımı ile ilgili bir durum varsa, sandviç saldırısına maruz kalma durumu ortaya çıkabilir, bu da oldukça karmaşık.

Güvenlik Önerileri

Son olarak, proje sahipleri ve sıradan katılımcı kullanıcılar için güvenlik önerileri.

Proje Tarafı Güvenlik İpuçları

Bir, Sözleşme geliştirme en iyi güvenlik uygulamalarına uygun olmalıdır.

İki, Sözleşme Güncellenebilir ve Durdurulabilir: Birçok saldırı, parayı tamamen bir seferde almak yerine, birden fazla işlemle gerçekleştirilir. Eğer nispeten sağlam bir izleme mekanizması varsa, bu durum tespit edilebilir. Tespit edildikten sonra, sözleşmenin durdurulabileceği varsayılırsa, kayıpları etkili bir şekilde azaltmak mümkün olacaktır.

Üç, Zaman Kilidi Kullanma: Bazı durumlarda, eğer bir zaman kilidi varsa, varsayalım ki 48 saat içinde tamamlanması gerekiyor, bu durumda zaman kilidinin altında birçok kişi bu yaratıcı kişinin yeni bir mint yöntemi güncellediğini görebilir, ve herkes kullanabilir, izleyenler projede bir hack olabileceğini anlayacak, böylece proje ekibine değişiklik yapmaları için bildirimde bulunabilir, varsayalım ki bildirildi ama kimse ilgilenmiyor, en azından kendi kısmındaki parayı çekebilir, böylece kendi kazancını korumuş olur. Bu nedenle, bir projenin zaman kilidi yoksa, teorik olarak sorun yaşama olasılığını artırır.

Dördüncü, güvenlik yatırımlarını artırın, kapsamlı bir güvenlik sistemi kurun: Güvenlik bir nokta değil, bir çizgi da değil, güvenlik sistematik bir yapıdır. Proje sahibi olarak, sözleşmenin birden fazla şirket tarafından denetimden geçmesinin yeterli olduğunu düşünmeyin; sonuçta hackerlar özel anahtarı çalabilir, hatta birden fazla imza ile, birkaç özel anahtarı tamamen çalabilirler. Ya da ekonomik modelde sorunlar olabilir, iş modelinde sorunlar olabilir... Paranın kaybolmasına neden olabilecek binlerce yol var; mesele, önceden güvenlik risklerini tamamen bertaraf edip edemeyeceğinizdir. Risk modellemesi yapmaya çalışmalısınız ve ardından aşamalı olarak çoğu riski ortadan kaldırmalısınız; kalan riskler kabul edilebilir riskler olmalı ve tolere edilebilir bir aralıkta kalmalıdır. Güvenlik ve verimlilik asla bir arada olamaz; belirli bir fedakarlık yapmanız gerekir. Ancak güvenliğe tamamen kayıtsız kalırsanız ve güvenlik için hiçbir yatırım yapmazsanız, saldırıya uğramak oldukça normaldir.

Beş, Tüm Çalışanların Güvenlik Farkındalığını Artırmak: Güvenlik farkındalığını artırmak çok fazla teknik bilgi gerektirmez. Twitter'da sıklıkla birçok insanın oltalama yoluyla NFT kaybettiğini görüyoruz, aslında oltalama yöntemleri insan doğasının zayıflıklarını kullanıyor. Biraz daha dikkat edersek, bu tuzağa düşmeyiz. Web3 bu geniş ortamda, sadece biraz daha fazla neden sormak, biraz daha fazla düşünmek birçok sorunun önüne geçebilir.

Altı, iç kötü niyetli davranışları önlemek, verimliliği artırırken risk kontrolünü güçlendirmek: Bazı örnekleri tekrar ele alalım. İlk olarak, sözleşmenin sahibi tek imza yerine çoklu imza; özel anahtar kaybolursa tüm proje kontrol altına alınır; ikinci olarak, zaman kilidi kullanılmamış; bazı kritik operasyon güncellemeleri hemen güncelleniyor, kimse bilmiyor, bu da tüm protokol katılımcıları için son derece adaletsiz; bir de iç kötü niyetli davranışlar, iç güvenlik mekanizması hiçbir işe yaramadı.

Blokzincir üzerindeki protokoller, verimliliği sağlarken güvenlik açısından nasıl belirli bir iyileşme sağlayabilir? Bazı güvenlik araçları, belirli bir kişinin belirli bir işlemi gerçekleştirmesini sağlayabilir, örneğin üçte beş çoklu imza; belirli bir adresin belirli bir işlemi gerçekleştirmesine olanak tanıyabilir, örneğin güvenilir bir düğümün güvenlik risklerini izleme işlemini yapabilmesi, eğer protokolün saldırıya uğradığını ve fonların yavaş yavaş bir hacker adresine doğru gittiğini tespit ederse, eğer bu sözleşmenin durdurma işlevi varsa, bu durdurma işlevini belirli bir kişiye verirsek, o kişi bu işlemi gerçekleştirebilir.

Örneğin, DEX için piyasa yapan piyasa yapıcıları, Owner yetkilerini kısıtlamazlarsa, Owner parayı başka bir adrese aktarabilir, para transferi yapılacak adresleri kısıtlayabilir, yalnızca belirli işlem çiftleri üzerinde işlem yapmaya izin verebilir, paranın yalnızca belirli bir adrese çekilmesine izin verebilir. Verimlilik artışı sağlarken, belirli bir güvenliğin de sağlanmış olur.

Yedi, Üçüncü Tarafların Güvenliği: Ekosistemin bir parçası olarak, proje taraflarının kendi üst ve alt akışları olacaktır. Güvenlik açısından "varsayılan olarak üst ve alt akışların güvensiz olduğu" ilkesi vardır. Hem üst akış hem de alt akış için doğrulama yapılmalıdır. Üçüncü taraflar üzerinde kontrol sağlamak oldukça zordur, güvenlik risk açığı aslında oldukça büyüktür, bu yüzden üçüncü tarafların dahil edilmesine dikkat edilmelidir. Sözleşmeler açık kaynaklıdır, bunları dahil etmek ve çağırmak mümkündür; eğer sözleşme açık kaynaklı değilse, kesinlikle referans alınmamalıdır. Çünkü içindeki mantığın ne olduğunu bilmiyoruz veya bu sözleşmenin kendisi yükseltilebilir bir sözleşme olabilir, normal kullanımda sorun yoktur, ancak bir gün yükseltilip kötü bir sözleşmeye dönüşeceğini önceden tahmin edemeyiz, bu kontrol edilemez.

Kullanıcı/LP Akıllı Sözleşmenin Güvenli Olup Olmadığını Nasıl Belirler?

Normal kullanıcılar için bir projenin güvenli olup olmadığını değerlendirirken öncelikle aşağıdaki altı noktaya bakıyoruz:

1. Sözleşme açık kaynak mı: Açık kaynak olmayan projelerle kesinlikle ilgilenmiyoruz, çünkü sözleşmenin ne yazdığını bilemeyiz.

İki, Owner çoklu imza kullanıyor mu, çoklu imza merkeziyetsiz mi: Eğer çoklu imza kullanılmıyorsa, projenin iş mantığı ve içeriğini değerlendiremeyiz, bir güvenlik olayı meydana geldiğinde bunun bir hacker tarafından mı yapıldığını belirleyemeyiz. Çoklu imza kullanılsa bile, çoklu imzanın merkeziyetsiz olup olmadığını da değerlendirmek gerekir.

Üçüncü, Sözleşmenin Mevcut Ticaret Durumu: Özellikle piyasada birçok dolandırıcılık projesi var, bu nedenle oldukça benzer bir sözleşme yapabilirler. Bu durumda sözleşmenin dağıtım zamanını, etkileşim sayısını vb. kontrol etmemiz gerekiyor. Bunlar, sözleşmenin güvenli olup olmadığını değerlendirmek için ölçütlerdir.

Dört, sözleşme bir vekalet sözleşmesi mi, yükseltilebilir mi, zaman kilidi var mı: Eğer sözleşme tamamen yükseltilemezse, bu çok katı olur; bu yüzden projelerin sözleşmelerinin yükseltilebilir olmasını öneriyoruz. Ancak yükseltme yöntemlerine dikkat edilmesi gerekir; bir yükseltme içeriği veya önemli parametre değişikliği olduğunda, bir zaman kilidi olmalı ve kullanıcılara gerçek yükseltmenin zararlı mı yoksa faydalı mı olduğunu değerlendirmeleri için bir zaman aralığı sunulmalıdır, bu da şeffaflığın bir yoludur.

Beş, sözleşme birden fazla kurum tarafından denetlendi mi ( denetim şirketlerine körü körüne güvenmeyin ), Sahip yetkisi fazla mı: Öncelikle sadece bir denetim şirketine güvenmeyin, çünkü farklı denetim şirketleri, farklı denetim personeli, sorunlara bakış açıları farklıdır. Eğer bir projenin birden fazla kurumun denetim sonuçları varsa ve farklı sorunlar tespit edilmişse, proje ekibi bunları düzeltmişse, sadece bir denetim şirketinin denetimi olmasından daha güvenli olacaktır. Sorumlu bir proje ekibi, birden fazla denetim kurumu ile çapraz denetim yapmayı tercih eder.

İkincisi, Owner'ın yetkilerinin ne kadar büyük olduğuna bakmak gerekir. Örneğin, bazı 貔恘盘 projelerinde, Owner kullanıcıların fonlarını tamamen kontrol edebilir; eğer token miktarı azsa normal alım satım yapılabilir, ancak token alım miktarı büyükse, Owner hemen kontrol ederek kilitleyebilir ve işlem yapılamaz hale getirebilir. Bazı NFT projeleri de aynıdır. Normal bir projede Owner'ın yetkileri kesinlikle kontrol edilebilir olmalıdır, böylece çok fazla yüksek riskli işlem yapılmaz ve işlemler zaman kilidi yöntemiyle gerçekleştirilir, böylece kullanıcılar işlemin ne olduğunu bilirler. Özellikle piyasa kötü olduğunda, her türlü dolandırıcılık projesi ortaya çıkıyor, bu yüzden herkes Owner'ın yetkilerine kesinlikle dikkat etmelidir.

Altı, Oracle'lara Dikkat: Eğer proje piyasadaki önde gelen oracle'ları kullanıyorsa, temelde büyük bir sorun olmayacaktır, ancak eğer kendi yaptıkları oracle'ları kullanıyorlarsa veya bazı rastgele token'leri teminat olarak kullanarak buraya ekliyorlarsa.