2 milyondan fazla dolar çalındı, Cetus güvenlik olayı hangi dersleri getirdi?

@CetusProtocol'ün hacker saldırısı güvenlik "şu anki durumu" raporunu okuduğunuzda, "ilginç" bir olgu ile karşılaşacaksınız: teknik detaylar oldukça şeffaf bir şekilde açıklanmış, acil müdahale ise adeta ders kitabı seviyesinde, ama en kritik "neden hacklendi" bu ruhsal sorgulama konusunda, daha önemlisi üzerinde durulmamış:

Rapor, integer-mate kütüphanesinin checked\_shlw fonksiyonunun hata kontrolünü (≤2^192 olmalı, gerçek ≤2^256) geniş bir şekilde açıklıyor ve bunu "anlam yanılgısı" olarak nitelendiriyor. Bu anlatım teknik olarak doğru olsa da, odak noktası dış sorumluluğa ustaca kaydırılmış, sanki Cetus da bu teknik hatanı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 astronomik bir likidite payı elde etme absürt hatası 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 mantık doğrulamasının eksikliği.

Cetus her bir "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üphanelerin kontrol mekanizmasına tamamen güvenmek, en ölümcül olanı ise - sistemin "1 token ile astronomik bir pay" gibi absürt bir sonuç hesapladığında, hiçbir ekonomik mantık kontrolü olmadan doğrudan bunu uygulaması.

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

1. Neden genel dış kütüphaneler için yeterli güvenlik testi yapılmadı? integer-mate kütüphanesinin açık kaynak, popüler ve yaygın olarak kullanıldığı gibi özellikleri olmasına rağmen, Cetus, yüz milyonlarca dolarlık varlığı yönetmek için bunu kullanırken bu kütüphanenin güvenlik sınırlarını tam olarak anlamadı; kütüphanenin işlevinin bozulması durumunda uygun bir yedek çözümün olup olmadığını göz önünde bulundurmadı. Açıkça görüldüğü üzere, Cetus temel tedarik zinciri güvenliği bilincinden yoksun.

2. Neden astronomik rakamların girilmesine izin veriliyor ve sınır yok? DeFi protokolleri merkeziyetsizliği hedeflese de, olgun bir finansal sistem ne kadar açık olursa olsun, yine de net sınırlar gerektirir.

Sistem, bir saldırgan tarafından dikkatlice oluşturulmuş astronomik bir miktara izin verdiğinde, ekip görünüşe göre böyle bir likidite gereksiniminin makul olup olmadığını düşünmedi. Dünyanın en büyük hedge fonunun bile bu kadar abartılı bir likidite payına ihtiyaç duyması pek olası değildir. Açıkçası, Cetus ekibi finansal sezgiye sahip risk yönetimi yeteneğinden yoksundu;

3. Neden birden fazla güvenlik denetiminden geçmesine rağmen sorunlar önceden tespit edilemedi? Bu cümle, projelerin güvenlik sorumluluğunu güvenlik şirketlerine devretmesi ve denetimi bir muafiyet belgesi olarak görmesi gibi ölümcül bir bilişsel yanılgıyı yanlışlıkla ortaya koyuyor. Ancak gerçek oldukça sert: Güvenlik denetim mühendisleri kod hatalarını bulmada uzmandır, kimse sistemin hesapladığı, abartılı bir değişim oranının yanlış olabileceğini test etmeyi düşünmez.

Bu matematik, kriptografi ve ekonomi sınırlarını aşan doğrulama, modern DeFi güvenliğinin en büyük kör noktasıdır. Denetim şirketleri "Bu ekonomi modeli 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üyorsun, bu sonuçta DeFi sektörünün sistematik güvenlik açığını ortaya koyuyor: tamamen teknik bir geçmişe sahip ekiplerin temel "finansal risk koklama" yeteneğinden ciddi şekilde yoksun olması.

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

Bu tür bir hacker saldırısındaki teknik eksikliklerden ziyade, Cetus'tan itibaren tüm DeFi ekiplerinin yalnızca teknik düşüncenin sınırlılığını aşması ve gerçek anlamda "finans mühendisleri" olarak güvenlik risk bilincini geliştirmesi gerektiğini düşünüyorum.

Örneğin: Finansal risk yönetimi uzmanlarını dahil ederek teknik ekibin bilgi boşluklarını doldurmak; sadece kod denetimini değil, gerekli ekonomik model denetimini de tamamlamak için çoklu denetim inceleme mekanizması oluşturmak; "finansal sezgiyi" geliştirmek, çeşitli saldırı senaryolarını ve buna karşılık gelen önlemleri simüle etmek, olağandışı işlemlere karşı her zaman duyarlı kalmak gibi.

Bu, bana daha önceki güvenlik şirketi deneyimlerini hatırlatıyor, sektörün güvenlik devleri @evilcos, @chiachih_wu, @yajinzhou, @mikelee205 ile yapılan iletişimde de böyle bir ortak görüş var:

Sektörün giderek olgunlaşmasıyla birlikte, kod seviyesindeki teknik hata sorunları giderek azalacak, ancak sınırları belirsiz ve sorumlulukları bulanık olan iş mantığındaki "bilinç hatası" en büyük zorluk olacaktır.

Denetim şirketleri yalnızca kodun hatasız olduğunu garanti edebilir, ancak "mantığın sınırları nasıl sağlanır" sorusu, proje ekibinin işin özünü daha derinlemesine anlaması ve sınırları kontrol etme yeteneğine ihtiyaç duyar. (Daha önce birçok güvenlik denetiminden sonra hâlâ Hacker saldırısına uğrayan "sorumluluk atma 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!