Cetus güvenlik sorunları ipucu: Merkezi Olmayan Finans ekiplerinin nelere dikkat etmesi gerekiyor?

Teknik geçmişe sahip ekipler, temel "finansal risk sezgisi" açısından ciddi bir eksiklik yaşıyor.

Yazı: Haotian

@CetusProtocol'un siber saldırı güvenlik "değerlendirme" raporunu okuduktan sonra, "ilginç" bir olgu ile karşılaşacaksınız: teknik detaylar oldukça şeffaf bir şekilde açıklanmış, acil müdahale ise ders kitaplarını aratmayacak bir seviyede, ancak en kritik olan "neden hacklendi" sorusunun ruhsal sorgulamasında, önemli noktalardan kaçınılmış gibi görünüyor:

Rapor, integer-mate kütüphanesinin checked\_shlw fonksiyonunun hata kontrolünü (en fazla ≤2^192, gerçekte ≤2^256) açıklamak için büyük miktarda yer ayırıyor ve bunu "anlamsal bir yanlış anlama" olarak nitelendiriyor. Bu anlatım teknik olarak geçerli olsa da, dikkatleri dış sorumluluğa yönlendirmek için ustaca bir yol buluyor, sanki Cetus bu teknik açığın masum bir kurbanıymış gibi.

Sorun şu ki, integer-mate açık kaynaklı ve yaygın olarak kullanılan bir matematik kütüphanesi olduğuna göre, neden burada 1 token ile yüksek fiyatlı likidite payı alabileceğinize dair saçma bir hata meydana geldi?

Korsan saldırı yollarını analiz ettiğimizde, korsanın mükemmel bir saldırı gerçekleştirebilmesi için dört koşulu aynı anda sağlaması gerektiği görülmektedir: Hatalı taşma kontrolü, büyük kaydırma işlemleri, yukarı yuvarlama kuralları ve ekonomik makullük doğrulamasının eksikliği.

Cetus tam her "tetikleme" koşulunda "dikkatsiz davrandı", örneğin: kullanıcıdan 2^200 gibi astronomik bir sayı kabul etmek, son derece tehlikeli büyük kaydırma işlemleri yapmak, dış kütüphanenin kontrol mekanizmasına tamamen güvenmek, en ölümcül olanı ise - sistem "1 token ile astronomik hisse" gibi absürt bir sonuç hesapladığında, hiçbir ekonomik mantık kontrolü olmadan doğrudan uygulamaya geçmesiydi.

Bu nedenle, Cetus'un gerçekten düşünmesi gereken noktalar şunlardır:

1. Neden genel dış kütüphaneler kullanılırken güvenlik testleri yapılmadı? integer-mate kütüphanesinin açık kaynak, popüler ve yaygın olarak kullanılması gibi özellikleri olsa da, Cetus bu kütüphaneyi yüz milyonlarca dolarlık varlıkları yönetmek için kullanırken bu kütüphanenin güvenlik sınırlarını yeterince anlamadı; eğer kütüphanenin işlevi başarısız olursa uygun bir yedek seçenek var mı gibi sorular göz ardı edildi. Açıkça, Cetus en temel tedarik zinciri güvenlik koruma bilincinden yoksundur;

2. Neden astronomik rakamların girilmesine izin veriliyor ve sınırlandırma yok? DeFi protokolleri merkeziyetsiz olmaya çalışsa da, olgun bir finansal sistem ne kadar açık olursa olsun, o kadar net sınırlar gerektirir.

Sistem, saldırganların özenle oluşturduğu astronomik sayıları girmesine izin verdiğinde, ekip açıkça bunun gibi bir likidite talebinin makul olup olmadığını düşünmemiş. Küresel en büyük hedge fonların bile bu kadar abartılı bir likidite payına ihtiyacı olamaz. Açıkça, Cetus ekibi finansal sezgiye sahip risk yönetimi uzmanlarından yoksun.

3. Neden birden fazla güvenlik denetiminden geçmesine rağmen sorunlar önceden tespit edilmedi? Bu cümle, projeyi yürütenlerin güvenlik sorumluluğunu güvenlik şirketlerine devretme ve denetimi bir tür muafiyet belgesi olarak görme konusunda ölümcül bir yanlış anlama sergilediğini fark etmeden ortaya koyuyor. Ama gerçekler çok sert: Güvenlik denetim mühendisleri kod hatalarını bulmada uzmandır, kimse sistemin absürt bir değişim oranını hesaplamaya çalışırken sorun olabileceğini düşünmez ki?

Matematik, kriptografi ve ekonomi arasındaki bu sınır doğrulaması, modern DeFi güvenliğinin en büyük kör noktasıdır. Denetim şirketleri "Bu ekonomik model tasarım hatası, kod mantığı sorunu değil" der; proje sahipleri ise "Denetim sorunları bulamadı" diye şikayet eder; kullanıcılar ise sadece paralarının kaybolduğunu bilir!

Görüyorsunuz, bu nihayetinde DeFi sektörünün sistematik güvenlik zayıflıklarını ortaya koyuyor: tamamen teknik geçmişe sahip ekiplerin temel "finansal risk sezgisi" konusunda ciddi bir eksiklikleri var.

Cetus raporuna göre, ekip açıkça yeterince düşünmemiş.

Bu tür bir siber saldırının teknik eksikliklerine dair yalnızca bir değerlendirme yapmak yerine, Cetus'tan itibaren tüm DeFi ekiplerinin saf teknik düşüncenin sınırlılıklarını aşması ve gerçekten "finans mühendisleri" olarak güvenlik risk bilincini geliştirmesi gerektiğini düşünüyorum.

Örneğin: Finansal risk uzmanlarını dahil etmek, teknik ekibin bilgi boşluklarını doldurmak; çoklu denetim inceleme mekanizmaları uygulamak, sadece kod denetimine bakmakla kalmayıp, gerekli ekonomik model denetimlerinin de tamamlanması; "finansal sezgi" geliştirmek, çeşitli saldırı senaryolarını ve ilgili yanıt önlemlerini simüle etmek, anormal işlemlere karşı her an hassas kalmak vb.

Bu, beni daha önceki güvenlik şirketi deneyimime ve sektördeki güvenlik büyükleri @evilcos, @chiachih_wu, @yajinzhou, @mikelee205 ile yapılan iletişimde de benzer bir fikir birliği olduğu gerçeğine götürüyor:

Sektörün giderek olgunlaşmasıyla birlikte, kod düzeyindeki teknik hata sorunları giderek azalacak, ancak sınırların belirsiz olduğu ve sorumlulukların bulanık olduğu iş mantığı "bilinç hatası" en büyük zorluk olmaya devam edecek.

Denetim şirketleri yalnızca kodun hatasız olduğunu garanti edebilir, ancak "mantığın sınırları" nasıl sağlanır, bu da proje ekibinin işin doğasını daha derinlemesine anlaması ve sınırları kontrol etme yeteneğine bağlıdır. (Daha önce birçok güvenlik denetiminden sonra hala hacker saldırısına uğrayan "suçlama olaylarının" temel nedeni de buradadır.)

DeFi'nin geleceği, hem kodlama becerileri yüksek hem de iş mantığını derinlemesine anlayan takımlara aittir!